Re: Java libraries and proposal.
On Sat, Apr 07, 2001 at 07:47:29PM -0700, Per Bothner wrote: > I disagree. My goal is that that /usr/share/java (or > /usr/share/java/lib if you prefer) should be similar to Sun's > extensions directory: a directory where *all* .jars > (i.e. /usr/share/java/*.jar) are added to the implied classpath. > (This is of course a default assuming nothing is over-ridden.) Yes, > you could define a standard where all .jars in all subdirectories of > /usr/share/java (i.e. /usr/share/java/*/*.jar) but I think that is > going too far. I think explicitly specifying the .jars you want to import into your library or application, with sonames if necessary, seems better. The 'add everything' approach only invites DLL hell. The list of jars (basically equivalent to CLASSPATH) could simply be stored in a jar member or attribute, and the .so versions could use plain old library dependency information. Class visibility for applets and servlets would of course be handled by the browser resp. server involved rather than use the same mechanism as for applications. > Anyway, I think using Extension-List or something similar should be > a refinement for the future. For now applications that want special > library versions should install a shell script that sets the CLASSPATH > to include the preferred jar file versions. This really ought to go in the first version. Then there's no need to import the whole /usr/share/java directory at all. > Well, each VM is responsible for setting its own builtin classpath. This sounds reasonable, but there might be a problem with things that depend on certain versions of the basic java libraries. > Unless they have trademarked "javac" they don't get to say what gets > run when a user types it. The only relevant license issue I know about > is about re-distributing jdk but only as long as no part is "replaced". If this is an issue 'javac' can simply say it will only run with the jdk jvm. -- James Deikun, Techie(tm), CSI Multimedia The opinions expressed &c.
Re: Java libraries and proposal.
[EMAIL PROTECTED] writes: > I think explicitly specifying the .jars you want to import into your > library or application, with sonames if necessary, seems better. That is fine for nicely-packaged libraries and applications. However, I'm concerned about a random Java programmer who should not have to manually fiddle with their classpath. Such programmers should be able to write Java code without having to know which jar is where. Also, if each application has to specify jars, then you also complicate the life of people developing such applications. Hence, I feel the 'add everything" approach is a reasonable default. > The 'add everything' approach only invites DLL hell. Well, first this is what Sun does, at least to some extent, with the "extensions" mechanism. Secondly, DLL hell as I understand it is a completely different problem, due to lack of support for multiple versions of a library, and applications installing a version they need without consideration for other applications. -- --Per Bothner [EMAIL PROTECTED] http://www.bothner.com/~per/
Re: Java libraries and proposal.
> On Sat, Apr 07, 2001 at 07:47:29PM -0700, Per Bothner wrote: > > I disagree. My goal is that that /usr/share/java (or > > /usr/share/java/lib if you prefer) should be similar to Sun's > > extensions directory: a directory where *all* .jars > > (i.e. /usr/share/java/*.jar) are added to the implied classpath. > > (This is of course a default assuming nothing is over-ridden.) Yes, > > you could define a standard where all .jars in all subdirectories of > > /usr/share/java (i.e. /usr/share/java/*/*.jar) but I think that is > > going too far. > > I think explicitly specifying the .jars you want to import into your > library or application, with sonames if necessary, seems better. The > 'add everything' approach only invites DLL hell. Personally, I like the idea of /usr/share/java/*.jar. I'd take it a step further, though. You see, I jump between projects a lot (I just "cd" between their directories), and I often need different sets of .jars for each one. I could try to maintain a set of scripts that set my classpath for the appropriate project, but that's kind of a pain because: 1 - I have to remember to take it with me if I move development to another server 2 - I have to either "source" the script if it sets the env directly (ie, " . ./setclasspathforprojectX") or "eval" it if the script merely prints out the appropriate line to set the classpath. 3 - Moving the files into production (say, on Tomcat), will often break the app because the app-server doesn't use my script to set the classpath. To this end, the following is a description of how my dream java invoker would build the classpath: 1 - Start with the classpath needed to for this particular JVM/compiler set. 2 - Append contents of the CLASSPATH env variable. 3 - If the directory "./lib" exists, append all files matching "./lib/*.jar" to the classpath. 4 - If the directory "./classes" exists, append that to the classpath. 5 - If the directory "$HOME/lib" exists, append all files matching "$HOME/lib/*.jar" to the classpath. If you want to use a different directory than $HOME, you can specify that directory in, say, JAVALIBDIR, so that it would look for "$JAVALIBDIR/lib" instead. 6 - If the directory "$HOME/classes" exists, append it to the classpath (with same provision for using $JAVALIBDIR instead of $HOME). 7 - Append all files matching "/usr/share/java/lib/*.jar" and the directory "/usr/share/java/classes" to the classpath. The nice things about this are that: 1 - Any user can override existing classes in /usr/share/java or specify additional classes for all of his/her own projects (by using $HOME/lib and $HOME/classes). 2 - Any user can do the same on a *per-project* basis (by using ./lib and ./classes 3 - If you try to keep all of the jars/classes (or links to them) that a particular app needs in your project-wide lib dirs (the "./lib" and ".classes"), then you can just copy the whole tree right into, say, Tomcat's webapps tree and it should work right off. No having to hunt down all of the jars/classes that you've got all over the place. - Joe
Re: Java libraries and proposal.
On Sat, Apr 07, 2001 at 07:47:29PM -0700, Per Bothner wrote: > I disagree. My goal is that that /usr/share/java (or > /usr/share/java/lib if you prefer) should be similar to Sun's > extensions directory: a directory where *all* .jars > (i.e. /usr/share/java/*.jar) are added to the implied classpath. > (This is of course a default assuming nothing is over-ridden.) Yes, > you could define a standard where all .jars in all subdirectories of > /usr/share/java (i.e. /usr/share/java/*/*.jar) but I think that is > going too far. I think explicitly specifying the .jars you want to import into your library or application, with sonames if necessary, seems better. The 'add everything' approach only invites DLL hell. The list of jars (basically equivalent to CLASSPATH) could simply be stored in a jar member or attribute, and the .so versions could use plain old library dependency information. Class visibility for applets and servlets would of course be handled by the browser resp. server involved rather than use the same mechanism as for applications. > Anyway, I think using Extension-List or something similar should be > a refinement for the future. For now applications that want special > library versions should install a shell script that sets the CLASSPATH > to include the preferred jar file versions. This really ought to go in the first version. Then there's no need to import the whole /usr/share/java directory at all. > Well, each VM is responsible for setting its own builtin classpath. This sounds reasonable, but there might be a problem with things that depend on certain versions of the basic java libraries. > Unless they have trademarked "javac" they don't get to say what gets > run when a user types it. The only relevant license issue I know about > is about re-distributing jdk but only as long as no part is "replaced". If this is an issue 'javac' can simply say it will only run with the jdk jvm. -- James Deikun, Techie(tm), CSI Multimedia The opinions expressed &c. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Java libraries and proposal.
[EMAIL PROTECTED] writes: > I think explicitly specifying the .jars you want to import into your > library or application, with sonames if necessary, seems better. That is fine for nicely-packaged libraries and applications. However, I'm concerned about a random Java programmer who should not have to manually fiddle with their classpath. Such programmers should be able to write Java code without having to know which jar is where. Also, if each application has to specify jars, then you also complicate the life of people developing such applications. Hence, I feel the 'add everything" approach is a reasonable default. > The 'add everything' approach only invites DLL hell. Well, first this is what Sun does, at least to some extent, with the "extensions" mechanism. Secondly, DLL hell as I understand it is a completely different problem, due to lack of support for multiple versions of a library, and applications installing a version they need without consideration for other applications. -- --Per Bothner [EMAIL PROTECTED] http://www.bothner.com/~per/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Java libraries and proposal.
> On Sat, Apr 07, 2001 at 07:47:29PM -0700, Per Bothner wrote: > > I disagree. My goal is that that /usr/share/java (or > > /usr/share/java/lib if you prefer) should be similar to Sun's > > extensions directory: a directory where *all* .jars > > (i.e. /usr/share/java/*.jar) are added to the implied classpath. > > (This is of course a default assuming nothing is over-ridden.) Yes, > > you could define a standard where all .jars in all subdirectories of > > /usr/share/java (i.e. /usr/share/java/*/*.jar) but I think that is > > going too far. > > I think explicitly specifying the .jars you want to import into your > library or application, with sonames if necessary, seems better. The > 'add everything' approach only invites DLL hell. Personally, I like the idea of /usr/share/java/*.jar. I'd take it a step further, though. You see, I jump between projects a lot (I just "cd" between their directories), and I often need different sets of .jars for each one. I could try to maintain a set of scripts that set my classpath for the appropriate project, but that's kind of a pain because: 1 - I have to remember to take it with me if I move development to another server 2 - I have to either "source" the script if it sets the env directly (ie, " . ./setclasspathforprojectX") or "eval" it if the script merely prints out the appropriate line to set the classpath. 3 - Moving the files into production (say, on Tomcat), will often break the app because the app-server doesn't use my script to set the classpath. To this end, the following is a description of how my dream java invoker would build the classpath: 1 - Start with the classpath needed to for this particular JVM/compiler set. 2 - Append contents of the CLASSPATH env variable. 3 - If the directory "./lib" exists, append all files matching "./lib/*.jar" to the classpath. 4 - If the directory "./classes" exists, append that to the classpath. 5 - If the directory "$HOME/lib" exists, append all files matching "$HOME/lib/*.jar" to the classpath. If you want to use a different directory than $HOME, you can specify that directory in, say, JAVALIBDIR, so that it would look for "$JAVALIBDIR/lib" instead. 6 - If the directory "$HOME/classes" exists, append it to the classpath (with same provision for using $JAVALIBDIR instead of $HOME). 7 - Append all files matching "/usr/share/java/lib/*.jar" and the directory "/usr/share/java/classes" to the classpath. The nice things about this are that: 1 - Any user can override existing classes in /usr/share/java or specify additional classes for all of his/her own projects (by using $HOME/lib and $HOME/classes). 2 - Any user can do the same on a *per-project* basis (by using ./lib and ./classes 3 - If you try to keep all of the jars/classes (or links to them) that a particular app needs in your project-wide lib dirs (the "./lib" and ".classes"), then you can just copy the whole tree right into, say, Tomcat's webapps tree and it should work right off. No having to hunt down all of the jars/classes that you've got all over the place. - Joe -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Unidentified subject!
-- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
