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
Reply to: