Re: java policy java tools?
Some comments on what Conrad Wood sent to me.
On Sun, May 26, 2002 at 10:14:06PM +0100, Conrad Wood wrote:
> The current java policy does not appear to discuss many of the
> useful tools that come with the jdk from sun. ie javadoc, keygen, jdb
> and so forth. No mentioning on how that should be handled.
True. There have not been any need for that (yet). Javadoc have
been discussed but no consensus have been formed.
> What I currently do is that I put a symlink /etc/java-home ->
> /usr/lib/j2dsk_1.3.1 (or 4_0 or whatever current version) and
> then symlink java/javac/javadoc etc... to /etc/java-home/bin/javadoc.
>
> I assume there is no need to simultaneously run 2 different jvms at
There is need for this sometimes. They should work concurrently.
> the same time, but if there is, they ought to be referenced by full name,
> ie sun-java-v2 or sun-javadoc-v2 or similar anyways with the
> corresponding dependency in the package. This approach, however
> allows a developer to install serveral jvms/jdks to test an application
> with several different tools and easily switch between them, something
> using only /etc/alternatives does not provide and I constantly need.
Well the alternatives should provide a good default depending on what
you have installed. Right now it is possible (isn't it?) to call the
jvm directly. It can be easier though.
> The main proplem seems to be here that many jvms and jdks use a
> different file layout than sun-java. However, sun-java being the
> reference implementation of java we could, in a package, enforce
> the filelayout to match that of suns jdk.
No I do not think this is the problem. We should not enforce anything
if not necessary. The solution is a wrapper that takes care of everything
that is special. Actually the only problem that I have discovered is
to set the CLASSPATH and that can be handled by a simple wrapper script.
> This could work quite neatly when installing different packages
> to install parts of a java-package. (ie all packages together make
> up a full jdk as per reference implementation)
We have a problem here. That is that the reference implementation tend
to change over time. A better solution is to make sure that the
jdk provide other packages instead.
> I think we should also include in the java-policy where java.* and
> javax.* classes go. According to sun java.* classes are part of the jre
> and hence they should go in the same directory as the jre.
Well this kind of things should be handled by the wrapper. But you are
right. Things that is not a part of this should probably be broken
out of the jdk package (alternatively that the jdk provides something
that other packages can provide too). Suggestions are very welcome here!
> I would split out javax.* in a seperate package, one per jre.
> (ie sun-jre provides jre and suggests sun-javax) But it is quite
> desirable to run ie sun-jre with ibm-javax. or even kaffe-javax (well,
> maybe ;) ) sun-javax,ibm-javax provides javax.
> Unsure if it should *depend* on javax.
Maybe. The problem here is licensing issues. The sun and ibm java is
not free so why should we conform to that?
> if we put all classes for a package in /usr/share/java then what
> happens to them if you remove jre or jvm with --force-depends?
> do they all get deleted?
Why do we have to handle --force-depends?
> shouldn't they be in /usr/lib/<package-name> and note their existens in
> some file in "/usr/share/classpaths" or some similar mechanism?
Yes it should. Suggestions are VERY welcome. Well not just suggestions
because we already have that. Working solutions are better ;)
> Regarding CLASSPATH documentation, what do you expect there? if it is
> one jar I would suggest that including the jar in the classpath should
> be sufficient, assuming all installed java-packages are in the classpath
> as well and the java app has the correct dependencies set.
In the README.Debian file or in a script that handles it.
A more automated way should be provided but that is still on the
development stage.
> I would suggest that all jar files include a manifest including
> copyright and homepage/maintainer email.
Not necessary. That is already handled (it must be, else it is a bug) by
the deb files.
> Have you thought about applets? applets that can be invoked stand-alone
> as well?
Is there any problem with that? I do not really understand this question.
> having a java-policy is great and absolutely vital. I am fairly new to
> java so if I am just talking rubbish please feel free to ignore me and
> accept my apology for wasting your time ;)
Some of your comments were valuable, thanks. If you reply to this please
add the debian-java@lists.debian.org list too.
Regards,
// Ola
--
--------------------- Ola Lundqvist ---------------------------
/ opal@debian.org Björnkärrsgatan 5 A.11 \
| opal@lysator.liu.se 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 debian-java-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: