Java libraries and proposal.
Hi I have followed the java instalation issues thread. So I'l try to summarize and give some new proposals. Java libraries: * Java libraries should go to /usr/share/java if they are jar files and /usr/share/java/repository if they are a collection of classes. * Usage of jar files should be encouraged because they can be versioned. * The jar file should be named name-version.jar and defaults should be a symbolic link with the name name.jar Quite the same way as C-libraries. * Here is a proposal. API dependencies should be specified in a way so that it should be easy to set the classpath. I can create the bash script and place it in java-common if you like. Perhaps /usr/share/java/foo-ver.apidep just lists what jars it depends on. And then a script generates the classpath for the developer to use. Personally I would like to have this when building my java packages. Build: Is it possible to create a script that generates this automaticly? Like a dh_javadeps... It should also generate the dependencies in the control file... Jvm: * .so files should be placed in /usr/lib * We should find a way to make it possible to use switch between java virtual machines without having to reset the classpath or similar. But maybe this simply is too early. * Maybe putting jvm implementation jars in /usr/share/java/$impl is the solution. Packages that proviedes similar functionality should then have the same name. like tools.jar could point to classes.zip (in jdk1.1). * Or maybe each jvm should have its own dependency file that the dependency script could use. Java programs: * Should as before have a exec that fixes all issues. This will be easier if a dependency script is created (see above). Have I missed something? Regards, // Ola -- - Ola Lundqvist --- / [EMAIL PROTECTED] Björnkärrsgatan 5 A.11 \ | [EMAIL PROTECTED] 584 36 LINKÖPING | | +46 (0)13-17 69 83 +46 (0)70-332 1551 | | http://www.opal.dhs.org UIN/icq: 4912500 | \ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 / ---
Re: Java libraries and proposal.
Comments inline: Ola Lundqvist wrote: Hi I have followed the java instalation issues thread. So I'l try to summarize and give some new proposals. Java libraries: * Java libraries should go to /usr/share/java if they are jar files and /usr/share/java/repository if they are a collection of classes. * Usage of jar files should be encouraged because they can be versioned. * The jar file should be named name-version.jar and defaults should be a symbolic link with the name name.jar Quite the same way as C-libraries. Naming the jars with a package name convention would reduce name clashes. For example there may be several XML parsers with a parser.jar These should be named: com.sun.parser.jar org.apache.parser.jar etc. For my own stuff I specify the package name to the first branch in the package nameing. This convention will also encourage common classes to NOT be included in many jar files (eg javax.servlet.* or org.sax.* etc.). I don't think this naming policy should be policed, only encouraged. * Here is a proposal. API dependencies should be specified in a way so that it should be easy to set the classpath. I can create the bash script and place it in java-common if you like. Perhaps /usr/share/java/foo-ver.apidep just lists what jars it depends on. And then a script generates the classpath for the developer to use. Personally I would like to have this when building my java packages. It should also indicate JVM dependancies eg ">1.2.2 & !ibm1.3.2" It would be good to have a common shell script include that would build classpaths and check JVM dependancies that could be included in start scripts. Build: Is it possible to create a script that generates this automaticly? Like a dh_javadeps... It should also generate the dependencies in the control file... Jvm: * .so files should be placed in /usr/lib * We should find a way to make it possible to use switch between java virtual machines without having to reset the classpath or similar. But maybe this simply is too early. * Maybe putting jvm implementation jars in /usr/share/java/$impl is the solution. Packages that proviedes similar functionality should then have the same name. like tools.jar could point to classes.zip (in jdk1.1). * Or maybe each jvm should have its own dependency file that the dependency script could use. Java programs: * Should as before have a exec that fixes all issues. This will be easier if a dependency script is created (see above). Have I missed something? Regards, // Ola
Re: Java libraries and proposal.
* Ola Lundqvist <[EMAIL PROTECTED]> [010406 04:09]: > Build: > Is it possible to create a script that generates this automaticly? > Like a dh_javadeps... It should also generate the dependencies > in the control file... I like this idea. It *ought* to be fairly straightforward (famous last words) to implement this because Java programs declare all the classes they depend upon in the first few lines of their source programs, except for java.lang. (I don't know the Java spec well enough to know if the dependency information is used only at compile time or if the information is also available in the compiled .class files -- I bet it is available in the compiled .class files too.) Nice overview, BTW. -- Earthlink: The #1 provider of unsolicited bulk email to the Internet.
Re: Java libraries and proposal.
On Fri, Apr 06, 2001 at 01:14:24PM +0100, Greg Wilkins wrote: > > Comments inline: > > Ola Lundqvist wrote: > > > Hi > > > > I have followed the java instalation issues thread. So I'l try > > to summarize and give some new proposals. > > > > Java libraries: > > * Java libraries should go to /usr/share/java if they are > > jar files and /usr/share/java/repository if they are a collection > > of classes. > > * Usage of jar files should be encouraged because they can > > be versioned. > > * The jar file should be named name-version.jar and defaults > > should be a symbolic link with the name name.jar > > Quite the same way as C-libraries. > > Naming the jars with a package name convention would reduce name > clashes. For example there may be several XML parsers with a parser.jar > These should be named: > > com.sun.parser.jar > org.apache.parser.jar > > etc. Well to me it seems that this system will have some name clashes. Why not use the debian package name? > For my own stuff I specify the package name to the first branch in the > package nameing. > > This convention will also encourage common classes to NOT be included > in many jar files (eg javax.servlet.* or org.sax.* etc.). > > I don't think this naming policy should be policed, only encouraged. I absolutely agree. > It should also indicate JVM dependancies eg ">1.2.2 & !ibm1.3.2" Is this not better to have in the usual dependency in control... well maybe not... ... It is actually a quite good idéa. > It would be good to have a common shell script include that would > build classpaths and check JVM dependancies that could be included > in start scripts. Ok. I can do that but first I want suggestions on what that script should handle and some file structure. :) Regards, // Ola -- - Ola Lundqvist --- / [EMAIL PROTECTED] Björnkärrsgatan 5 A.11 \ | [EMAIL PROTECTED] 584 36 LINKÖPING | | +46 (0)13-17 69 83 +46 (0)70-332 1551 | | http://www.opal.dhs.org UIN/icq: 4912500 | \ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 / ---
Re: Java libraries and proposal.
On Fri, Apr 06, 2001 at 04:32:17AM -0700, Seth Arnold wrote: > * Ola Lundqvist <[EMAIL PROTECTED]> [010406 04:09]: > > Build: > > Is it possible to create a script that generates this automaticly? > > Like a dh_javadeps... It should also generate the dependencies > > in the control file... > > I like this idea. It *ought* to be fairly straightforward (famous last > words) to implement this because Java programs declare all the classes > they depend upon in the first few lines of their source programs, except > for java.lang. (I don't know the Java spec well enough to know if the > dependency information is used only at compile time or if the > information is also available in the compiled .class files -- I bet it > is available in the compiled .class files too.) Well. Often it just includes foo.* and maybe just uses foo.bar.gax.gaz. And maybe all .java files are not used in compilation. But if it is in the .class files (with some simple script that can output it) this is solved. :) > Nice overview, BTW. Thanks. Regards, // Ola -- - Ola Lundqvist --- / [EMAIL PROTECTED] Björnkärrsgatan 5 A.11 \ | [EMAIL PROTECTED] 584 36 LINKÖPING | | +46 (0)13-17 69 83 +46 (0)70-332 1551 | | http://www.opal.dhs.org UIN/icq: 4912500 | \ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 / ---
Re: Java libraries and proposal.
* Ola Lundqvist <[EMAIL PROTECTED]> [010406 04:41]: > Well to me it seems that this system will have some name clashes. > Why not use the debian package name? The initial revitalization of this thread comes from Per Bothner. His own machine is Red Hat, and he seems pretty happy with it. :) He chose to bother us at all because he figures the Debian policy on Java is as good a starting place as any. We cannot rely upon the Debian package names for this project, because its effects will hopefully be experienced on the other Linux distributions, and perhaps even the *BSD distributions, should any of them decide to try to support multiple Java systems coherently. Or, at the least, they can learn from our mistakes. :) Not a bad idea, but considering the package names were already chosen to try to avoid namespace collisions, we probably should stick with using the package name as much as possible. :) -- Earthlink: The #1 provider of unsolicited bulk email to the Internet.
Re: Java libraries and proposal.
--- Seth Arnold <[EMAIL PROTECTED]> wrote:
> * Ola Lundqvist <[EMAIL PROTECTED]> [010406 04:09]:
> > Build:
> > Is it possible to create a script that generates this automaticly?
> > Like a dh_javadeps... It should also generate the dependencies
> > in the control file...
>
> I like this idea. It *ought* to be fairly straightforward (famous last
> words) to implement this because Java programs declare all the classes
> they depend upon in the first few lines of their source programs, except
> for java.lang. (I don't know the Java spec well enough to know if the
> dependency information is used only at compile time or if the
> information is also available in the compiled .class files -- I bet it
> is available in the compiled .class files too.)
>
> Nice overview, BTW.
No, it's not that simple: you can always use the completely specified name
to refer to a class (e.g. "java.util.Vector", even if you don't import the
package nor the class). The "import" keyword is only there to ease the
developer's work.
It's also possible that 2 different (but very close) APIs have classes in
the same package. Hence including the package does not imply which API is
necessary. I don't have any example in mind, but I think it's the case
with the servlet API and the JSP API. To be confirmed!
Finally, you can also use reflection to access classes dynamically (at run
time, not at compile time). This can be done with e.g.
Class javaUtilVectorClass = Class.forName("java.util.Vector");
Once you have the class reference, a newInstance() call on it and you have
an instance of the object.
I think the proposal was to define a file format to specify which APIs are
used in the software. It's close to the way Debian package dependencies
are specified by the packager. This same list would then be also used to
create the string used in the "-classpath" option (or the equivalent for
other implementations).
François.
PS: I hope I have been clear enough! I'm really tired today and my english
is not fluent as usually...
=
Francois BOTTIN
--
"How kind," the PFY sighs. "But where will I go?"
"Somewhere where they know nothing about computing...
where they wouldn't know a RAM chip from a potato chip!"
"But I don't want to visit Microsoft!" he whines.
The BOFH 1998 - Simon Travaglia (bofh.ntk.net)
__
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail.
http://personal.mail.yahoo.com/
Re: Java libraries and proposal.
> Java libraries: > * Java libraries should go to /usr/share/java if they are > jar files and /usr/share/java/repository if they are a collection > of classes. Well, being a big fan of Tomcat, I'd much more prefer to see .jar files in "/usr/share/java/lib" and .class hierarchies in "/usr/share/java/classes". To prevent name clashes of .jar files, we may or may not want to support/encourage putting .jar files in subdirectories within /usr/share/java/lib. > * The jar file should be named name-version.jar and defaults > should be a symbolic link with the name name.jar > Quite the same way as C-libraries. Nice idea. It lets individual users stay with a particular version if they specify the fully-versioned .jar name. > * Here is a proposal. API dependencies should be specified in > a way so that it should be easy to set the classpath. I'm not sure I follow you. I was under the impression that the /usr/share/java class hierarchy and all of the jars would be auto-included into the classpath whenever you run java/javac/javadoc/whatever. If that's the case, then dependencies don't matter since you always get the whole enchilada. > Jvm: > * .so files should be placed in /usr/lib > * We should find a way to make it possible to use switch between > java virtual machines without having to reset the classpath or similar. Yes, yes, yes! Also, if possible, I'd like the individual users to be able to set an environment variable that picks which JVM gets run when they want to invoke a JVM. (This might be treading a little too close to the edge of legality, since I think Sun's Java license says something like: If the user types "javac", they'd better get the compiler from the JDK.) > But maybe this simply is too early. How so? Why can't you do this: 1 - Put non-JVM-specific classes and jars in /usr/share/java (hence the word "share"). 2 - Put JVM-specific classes and jars within /usr/lib/jvm-name 3 - Give each JVM (and all tools that invoke it) a script to append its JVM-specific classes to the classpath. Also, make these scripts all call a central classpath-builder script that would build a classpath of the non-JVM-specific classes from: the CLASSPATH environment variable from the user, from any "--classpath" parameters, and from anything found in /usr/share/java (and, hopefully, anything in $HOME/java, too). > * Maybe putting jvm implementation jars in /usr/share/java/$impl > is the solution. Well, to me, "share" means share, which the jvm-specific libs aren't meant for. On the other hand, stuff in /usr/lib/appname usually contains most resources used by any app on the system. > Packages that proviedes similar functionality > should then have the same name. like tools.jar could point > to classes.zip (in jdk1.1). U. I don't know about this, Yogi! Different JVM's allocate their functionality across different jar files, no? With JDK 1.0, everything was in classes.zip or something. Nowadays, with Sun's JDK, they've got about 8 or 9 jar files and some have duplicate copies of classes. So, I wouldn't worry about what individual JVM implementations name their private jars. That's their problem. We just need to know them when we write the script that builds the classpath and invokes them. - Joe
Re: Java libraries and proposal.
> No, it's not that simple: you can always use the completely specified name > to refer to a class (e.g. "java.util.Vector", even if you don't import the > package nor the class). The "import" keyword is only there to ease the > developer's work. Correct. Many people assume that Java's "import" works like C's "#include", and it doesn't. "import" only imports the namespace so that the JVM will look there. It's much like adding things to your PATH variable so that you can type "vi" instead of "/usr/bin/vi". > It's also possible that 2 different (but very close) APIs have classes in > the same package. What is Java supposed to do if it encounters two different classes of the same name in the same package? Does it just take the first one that it encounters? - Joe
Re: Java libraries and proposal.
> "Joe" == Joe Emenaker <[EMAIL PROTECTED]> writes: >> * Maybe putting jvm implementation jars in /usr/share/java/$impl >> is the solution. Joe> Well, to me, "share" means share, which the jvm-specific libs Joe> aren't meant for. FYI, traditionally `share' has actually meant `architecture-independent'. This is also the GNU definition. Tom
Java libraries and proposal.
Hi I have followed the java instalation issues thread. So I'l try to summarize and give some new proposals. Java libraries: * Java libraries should go to /usr/share/java if they are jar files and /usr/share/java/repository if they are a collection of classes. * Usage of jar files should be encouraged because they can be versioned. * The jar file should be named name-version.jar and defaults should be a symbolic link with the name name.jar Quite the same way as C-libraries. * Here is a proposal. API dependencies should be specified in a way so that it should be easy to set the classpath. I can create the bash script and place it in java-common if you like. Perhaps /usr/share/java/foo-ver.apidep just lists what jars it depends on. And then a script generates the classpath for the developer to use. Personally I would like to have this when building my java packages. Build: Is it possible to create a script that generates this automaticly? Like a dh_javadeps... It should also generate the dependencies in the control file... Jvm: * .so files should be placed in /usr/lib * We should find a way to make it possible to use switch between java virtual machines without having to reset the classpath or similar. But maybe this simply is too early. * Maybe putting jvm implementation jars in /usr/share/java/$impl is the solution. Packages that proviedes similar functionality should then have the same name. like tools.jar could point to classes.zip (in jdk1.1). * Or maybe each jvm should have its own dependency file that the dependency script could use. Java programs: * Should as before have a exec that fixes all issues. This will be easier if a dependency script is created (see above). Have I missed something? Regards, // Ola -- - Ola Lundqvist --- / [EMAIL PROTECTED] Björnkärrsgatan 5 A.11 \ | [EMAIL PROTECTED] 584 36 LINKÖPING | | +46 (0)13-17 69 83 +46 (0)70-332 1551 | | http://www.opal.dhs.org UIN/icq: 4912500 | \ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 / --- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Java libraries and proposal.
Comments inline: Ola Lundqvist wrote: > Hi > > I have followed the java instalation issues thread. So I'l try > to summarize and give some new proposals. > > Java libraries: > * Java libraries should go to /usr/share/java if they are > jar files and /usr/share/java/repository if they are a collection > of classes. > * Usage of jar files should be encouraged because they can > be versioned. > * The jar file should be named name-version.jar and defaults > should be a symbolic link with the name name.jar > Quite the same way as C-libraries. Naming the jars with a package name convention would reduce name clashes. For example there may be several XML parsers with a parser.jar These should be named: com.sun.parser.jar org.apache.parser.jar etc. For my own stuff I specify the package name to the first branch in the package nameing. This convention will also encourage common classes to NOT be included in many jar files (eg javax.servlet.* or org.sax.* etc.). I don't think this naming policy should be policed, only encouraged. > * Here is a proposal. API dependencies should be specified in > a way so that it should be easy to set the classpath. I can > create the bash script and place it in java-common if you like. > > Perhaps /usr/share/java/foo-ver.apidep just lists what > jars it depends on. And then a script generates the classpath > for the developer to use. Personally I would like to have this > when building my java packages. It should also indicate JVM dependancies eg ">1.2.2 & !ibm1.3.2" It would be good to have a common shell script include that would build classpaths and check JVM dependancies that could be included in start scripts. > Build: > Is it possible to create a script that generates this automaticly? > Like a dh_javadeps... It should also generate the dependencies > in the control file... > > Jvm: > * .so files should be placed in /usr/lib > * We should find a way to make it possible to use switch between > java virtual machines without having to reset the classpath or similar. > But maybe this simply is too early. > * Maybe putting jvm implementation jars in /usr/share/java/$impl > is the solution. Packages that proviedes similar functionality > should then have the same name. like tools.jar could point > to classes.zip (in jdk1.1). > * Or maybe each jvm should have its own dependency file that the > dependency script could use. > > Java programs: > * Should as before have a exec that fixes all issues. This will > be easier if a dependency script is created (see above). > > Have I missed something? > > Regards, > > // Ola -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Java libraries and proposal.
* Ola Lundqvist <[EMAIL PROTECTED]> [010406 04:09]: > Build: > Is it possible to create a script that generates this automaticly? > Like a dh_javadeps... It should also generate the dependencies > in the control file... I like this idea. It *ought* to be fairly straightforward (famous last words) to implement this because Java programs declare all the classes they depend upon in the first few lines of their source programs, except for java.lang. (I don't know the Java spec well enough to know if the dependency information is used only at compile time or if the information is also available in the compiled .class files -- I bet it is available in the compiled .class files too.) Nice overview, BTW. -- Earthlink: The #1 provider of unsolicited bulk email to the Internet. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Java libraries and proposal.
On Fri, Apr 06, 2001 at 01:14:24PM +0100, Greg Wilkins wrote: > > Comments inline: > > Ola Lundqvist wrote: > > > Hi > > > > I have followed the java instalation issues thread. So I'l try > > to summarize and give some new proposals. > > > > Java libraries: > > * Java libraries should go to /usr/share/java if they are > > jar files and /usr/share/java/repository if they are a collection > > of classes. > > * Usage of jar files should be encouraged because they can > > be versioned. > > * The jar file should be named name-version.jar and defaults > > should be a symbolic link with the name name.jar > > Quite the same way as C-libraries. > > Naming the jars with a package name convention would reduce name > clashes. For example there may be several XML parsers with a parser.jar > These should be named: > > com.sun.parser.jar > org.apache.parser.jar > > etc. Well to me it seems that this system will have some name clashes. Why not use the debian package name? > For my own stuff I specify the package name to the first branch in the > package nameing. > > This convention will also encourage common classes to NOT be included > in many jar files (eg javax.servlet.* or org.sax.* etc.). > > I don't think this naming policy should be policed, only encouraged. I absolutely agree. > It should also indicate JVM dependancies eg ">1.2.2 & !ibm1.3.2" Is this not better to have in the usual dependency in control... well maybe not... ... It is actually a quite good idéa. > It would be good to have a common shell script include that would > build classpaths and check JVM dependancies that could be included > in start scripts. Ok. I can do that but first I want suggestions on what that script should handle and some file structure. :) Regards, // Ola -- - Ola Lundqvist --- / [EMAIL PROTECTED] Björnkärrsgatan 5 A.11 \ | [EMAIL PROTECTED] 584 36 LINKÖPING | | +46 (0)13-17 69 83 +46 (0)70-332 1551 | | http://www.opal.dhs.org UIN/icq: 4912500 | \ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 / --- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Java libraries and proposal.
On Fri, Apr 06, 2001 at 04:32:17AM -0700, Seth Arnold wrote: > * Ola Lundqvist <[EMAIL PROTECTED]> [010406 04:09]: > > Build: > > Is it possible to create a script that generates this automaticly? > > Like a dh_javadeps... It should also generate the dependencies > > in the control file... > > I like this idea. It *ought* to be fairly straightforward (famous last > words) to implement this because Java programs declare all the classes > they depend upon in the first few lines of their source programs, except > for java.lang. (I don't know the Java spec well enough to know if the > dependency information is used only at compile time or if the > information is also available in the compiled .class files -- I bet it > is available in the compiled .class files too.) Well. Often it just includes foo.* and maybe just uses foo.bar.gax.gaz. And maybe all .java files are not used in compilation. But if it is in the .class files (with some simple script that can output it) this is solved. :) > Nice overview, BTW. Thanks. Regards, // Ola -- - Ola Lundqvist --- / [EMAIL PROTECTED] Björnkärrsgatan 5 A.11 \ | [EMAIL PROTECTED] 584 36 LINKÖPING | | +46 (0)13-17 69 83 +46 (0)70-332 1551 | | http://www.opal.dhs.org UIN/icq: 4912500 | \ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 / --- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Java libraries and proposal.
* Ola Lundqvist <[EMAIL PROTECTED]> [010406 04:41]: > Well to me it seems that this system will have some name clashes. > Why not use the debian package name? The initial revitalization of this thread comes from Per Bothner. His own machine is Red Hat, and he seems pretty happy with it. :) He chose to bother us at all because he figures the Debian policy on Java is as good a starting place as any. We cannot rely upon the Debian package names for this project, because its effects will hopefully be experienced on the other Linux distributions, and perhaps even the *BSD distributions, should any of them decide to try to support multiple Java systems coherently. Or, at the least, they can learn from our mistakes. :) Not a bad idea, but considering the package names were already chosen to try to avoid namespace collisions, we probably should stick with using the package name as much as possible. :) -- Earthlink: The #1 provider of unsolicited bulk email to the Internet. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Java libraries and proposal.
--- Seth Arnold <[EMAIL PROTECTED]> wrote:
> * Ola Lundqvist <[EMAIL PROTECTED]> [010406 04:09]:
> > Build:
> > Is it possible to create a script that generates this automaticly?
> > Like a dh_javadeps... It should also generate the dependencies
> > in the control file...
>
> I like this idea. It *ought* to be fairly straightforward (famous last
> words) to implement this because Java programs declare all the classes
> they depend upon in the first few lines of their source programs, except
> for java.lang. (I don't know the Java spec well enough to know if the
> dependency information is used only at compile time or if the
> information is also available in the compiled .class files -- I bet it
> is available in the compiled .class files too.)
>
> Nice overview, BTW.
No, it's not that simple: you can always use the completely specified name
to refer to a class (e.g. "java.util.Vector", even if you don't import the
package nor the class). The "import" keyword is only there to ease the
developer's work.
It's also possible that 2 different (but very close) APIs have classes in
the same package. Hence including the package does not imply which API is
necessary. I don't have any example in mind, but I think it's the case
with the servlet API and the JSP API. To be confirmed!
Finally, you can also use reflection to access classes dynamically (at run
time, not at compile time). This can be done with e.g.
Class javaUtilVectorClass = Class.forName("java.util.Vector");
Once you have the class reference, a newInstance() call on it and you have
an instance of the object.
I think the proposal was to define a file format to specify which APIs are
used in the software. It's close to the way Debian package dependencies
are specified by the packager. This same list would then be also used to
create the string used in the "-classpath" option (or the equivalent for
other implementations).
François.
PS: I hope I have been clear enough! I'm really tired today and my english
is not fluent as usually...
=
Francois BOTTIN
--
"How kind," the PFY sighs. "But where will I go?"
"Somewhere where they know nothing about computing...
where they wouldn't know a RAM chip from a potato chip!"
"But I don't want to visit Microsoft!" he whines.
The BOFH 1998 - Simon Travaglia (bofh.ntk.net)
__
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail.
http://personal.mail.yahoo.com/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Java libraries and proposal.
> Java libraries: > * Java libraries should go to /usr/share/java if they are > jar files and /usr/share/java/repository if they are a collection > of classes. Well, being a big fan of Tomcat, I'd much more prefer to see .jar files in "/usr/share/java/lib" and .class hierarchies in "/usr/share/java/classes". To prevent name clashes of .jar files, we may or may not want to support/encourage putting .jar files in subdirectories within /usr/share/java/lib. > * The jar file should be named name-version.jar and defaults > should be a symbolic link with the name name.jar > Quite the same way as C-libraries. Nice idea. It lets individual users stay with a particular version if they specify the fully-versioned .jar name. > * Here is a proposal. API dependencies should be specified in > a way so that it should be easy to set the classpath. I'm not sure I follow you. I was under the impression that the /usr/share/java class hierarchy and all of the jars would be auto-included into the classpath whenever you run java/javac/javadoc/whatever. If that's the case, then dependencies don't matter since you always get the whole enchilada. > Jvm: > * .so files should be placed in /usr/lib > * We should find a way to make it possible to use switch between > java virtual machines without having to reset the classpath or similar. Yes, yes, yes! Also, if possible, I'd like the individual users to be able to set an environment variable that picks which JVM gets run when they want to invoke a JVM. (This might be treading a little too close to the edge of legality, since I think Sun's Java license says something like: If the user types "javac", they'd better get the compiler from the JDK.) > But maybe this simply is too early. How so? Why can't you do this: 1 - Put non-JVM-specific classes and jars in /usr/share/java (hence the word "share"). 2 - Put JVM-specific classes and jars within /usr/lib/jvm-name 3 - Give each JVM (and all tools that invoke it) a script to append its JVM-specific classes to the classpath. Also, make these scripts all call a central classpath-builder script that would build a classpath of the non-JVM-specific classes from: the CLASSPATH environment variable from the user, from any "--classpath" parameters, and from anything found in /usr/share/java (and, hopefully, anything in $HOME/java, too). > * Maybe putting jvm implementation jars in /usr/share/java/$impl > is the solution. Well, to me, "share" means share, which the jvm-specific libs aren't meant for. On the other hand, stuff in /usr/lib/appname usually contains most resources used by any app on the system. > Packages that proviedes similar functionality > should then have the same name. like tools.jar could point > to classes.zip (in jdk1.1). U. I don't know about this, Yogi! Different JVM's allocate their functionality across different jar files, no? With JDK 1.0, everything was in classes.zip or something. Nowadays, with Sun's JDK, they've got about 8 or 9 jar files and some have duplicate copies of classes. So, I wouldn't worry about what individual JVM implementations name their private jars. That's their problem. We just need to know them when we write the script that builds the classpath and invokes them. - Joe -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Java libraries and proposal.
> No, it's not that simple: you can always use the completely specified name > to refer to a class (e.g. "java.util.Vector", even if you don't import the > package nor the class). The "import" keyword is only there to ease the > developer's work. Correct. Many people assume that Java's "import" works like C's "#include", and it doesn't. "import" only imports the namespace so that the JVM will look there. It's much like adding things to your PATH variable so that you can type "vi" instead of "/usr/bin/vi". > It's also possible that 2 different (but very close) APIs have classes in > the same package. What is Java supposed to do if it encounters two different classes of the same name in the same package? Does it just take the first one that it encounters? - Joe -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Java libraries and proposal.
> "Joe" == Joe Emenaker <[EMAIL PROTECTED]> writes: >> * Maybe putting jvm implementation jars in /usr/share/java/$impl >> is the solution. Joe> Well, to me, "share" means share, which the jvm-specific libs Joe> aren't meant for. FYI, traditionally `share' has actually meant `architecture-independent'. This is also the GNU definition. Tom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
