can i freely bundle dtrace.jar together with my own java application, or is there any license constraint? This message posted from opensolaris.org
I''m not sure about the legality of redistributing dtrace.jar (I assume it''s find, but I''m no CDDL expert), but what are you trying to do? dtrace.jar is coupled with libdtrace.so which, in turn, is coupled to the DTrace kernel infrastructure. Even if you moved dtrace.jar to another system, it probably wouldn''t work. We''re planning on back porting the DTrace JNI stuff to a Solaris 10 update; perhaps Tom can comment on a timeline for that. Adam On Wed, May 10, 2006 at 06:09:55AM -0700, alessioc wrote:> can i freely bundle dtrace.jar together with my own java application, or is there any license constraint? > > > This message posted from opensolaris.org > _______________________________________________ > dtrace-discuss mailing list > dtrace-discuss at opensolaris.org-- Adam Leventhal, Solaris Kernel Development http://blogs.sun.com/ahl
Adam Leventhal wrote:> I''m not sure about the legality of redistributing dtrace.jar (I assume it''s > find, but I''m no CDDL expert), but what are you trying to do? dtrace.jar is > coupled with libdtrace.so which, in turn, is coupled to the DTrace kernel > infrastructure. Even if you moved dtrace.jar to another system, it probably > wouldn''t work.i''d just like to package dtrace.jat together with my own jar, so that i don''t have to set the java classpath to search for dtrace.jar in /usr/share/lib/java> We''re planning on back porting the DTrace JNI stuff to a Solaris 10 update;isn''t it already available a dtrace.jar (or another equivalent java wrapper to dtrace) for Solaris 10?
On Wed, May 10, 2006 at 08:45:20PM +0200, Alessio Cervellin wrote:> Adam Leventhal wrote: > >I''m not sure about the legality of redistributing dtrace.jar (I assume it''s > >find, but I''m no CDDL expert), but what are you trying to do? dtrace.jar is > >coupled with libdtrace.so which, in turn, is coupled to the DTrace kernel > >infrastructure. Even if you moved dtrace.jar to another system, it probably > >wouldn''t work. > > i''d just like to package dtrace.jat together with my own jar, so that i > don''t have to set the java classpath to search for dtrace.jar in > /usr/share/lib/java >I think what you want to do is list dtrace.jar in your jar manifest''s classpath, for example jdtrace has the following manifest: Manifest-Version: 1.0 Main-Class: TestTrace Class-Path: /usr/share/lib/java/dtrace.jar /opt/OSOL0chime/lib/java/dtracex.jar /opt/OSOL0chime/lib/java/gnu.getopt.jar The Makefile specifies this manifest with the following command: jar -cmf jdtrace.jar-manifest jdtrace.jar TestTrace*.class This sample app, including its jar manifest and Makefile are available at http://opensolaris.org/os/project/dtrace-chime/java_dtrace_api/jdtrace/ Let me know if that''s not what you had in mind. Copying dtrace.jar into your own application directory will also work.> >We''re planning on back porting the DTrace JNI stuff to a Solaris 10 update; > > isn''t it already available a dtrace.jar (or another equivalent java > wrapper to dtrace) for Solaris 10?No, it is currently available in Solaris Nevada build 35 or later. I''m not clear yet on the timetable for backporting to Solaris 10, but I''ll look into it. Tom> _______________________________________________ > dtrace-discuss mailing list > dtrace-discuss at opensolaris.org
On Wed, May 10, 2006 at 08:45:20PM +0200, Alessio Cervellin wrote:> Adam Leventhal wrote: > >I''m not sure about the legality of redistributing dtrace.jar (I assume it''s > >find, but I''m no CDDL expert), but what are you trying to do? dtrace.jar is > >coupled with libdtrace.so which, in turn, is coupled to the DTrace kernel > >infrastructure. Even if you moved dtrace.jar to another system, it probably > >wouldn''t work. > > i''d just like to package dtrace.jat together with my own jar, so that i > don''t have to set the java classpath to search for dtrace.jar in > /usr/share/lib/javaSetting the Class-Path variable in your jar''s manifest to point to dtrace.jar is the recommended approach. Including an entire jar file actually seems like a lot more work. Besides, including the jar file is simply the wrong thing to do. It means that you have to release a new version of your jar with every bugfix we make to dtrace.jar. You would also need to maintain a separate version of your package for every version of OpenSolaris. There''s no guarantee that the dtrace.jar from OpenSolaris on day X will work with the libdtrace from OpenSolaris on day Y. You would effectively be statically linking with our Java code, which is a practice so broken we don''t even let you do it with C code anymore. It''s probably easiest if you try not to think of dtrace.jar as a wrapper. It is part of DTrace. Dave
David Powell wrote: > Setting the Class-Path variable in your jar''s manifest to point to > dtrace.jar is the recommended approach. Including an entire jar file > actually seems like a lot more work. > > Besides, including the jar file is simply the wrong thing to do. It > means that you have to release a new version of your jar with every > bugfix we make to dtrace.jar. you are absolutely right, the manifest approach is surely what best fits my needs. it was just too easy to think about it ;) > It''s probably easiest if you try not to think of dtrace.jar as a > wrapper. It is part of DTrace. yes and no, since it''s /not/ part of solaris 10''s DTrace... that''s why i think about it as a wrapper (which is also a quite proper definition for something which uses jni)
Tom Erickson wrote:> No, it is currently available in Solaris Nevada build 35 or later. I''m > not clear yet on the timetable for backporting to Solaris 10, but I''ll > look into it.thank you, i''ll be very interested to know about this timetable. anyway, should i already exclude a backport to the upcoming solaris 10 update2 or i still have a chance to hope? i''d be also interested to know if there''s any "way" to make nevada''s dtrace.jar/libdtrace.so working on solaris 10 too.
On Wed, May 10, 2006 at 11:07:09PM +0200, Alessio Cervellin wrote:> > It''s probably easiest if you try not to think of dtrace.jar as a > > wrapper. It is part of DTrace. > > yes and no, since it''s /not/ part of solaris 10''s DTrace... that''s why i > think about it as a wrapper (which is also a quite proper definition for > something which uses jni)I generally think of a wrapper as something which puts a layer in front of one set of public interfaces to creates another set of interfaces. It''s analogous to a mask you wear over your face. Simple test: it''s a wrapper if you can take it off. In this case, dtrace.jar isn''t consuming a public interface. The interfaces exported by libdtrace are private and undocumented. If you remove dtrace.jar, you have nothing (the Java classes are the *only* non-scripted public interface to DTrace). It''s akin to having the skin removed from your face and having the mask grafted to it. (Sorry, that example turned out to be a bit more gruesome than I expected :) Dave