Hallo Dalibor,
* Dalibor Topic wrote:
>> Packages, which want to contribute a alternative for /usr/bin/java and its
>> manpage must provide java-runtime. The alternative must accept the option
>> '-classpath', which sets the classpath and autmatically adds the right
>> rt.jar. The must depend on java-common.
>You need to specify what you mean by setting the classpath more closely.
>Preferably, explain the semantics you want using an example. Current wording is
>too vague.
It seems that the interface specification will get really long (see
the other post asking for more options to be included in that list)
-classpath <jarfile>:<jarfile>, where <jarfile> is a full path to a
Java Archiv file.
...
>> Priorities should be set as follows: highest Spec version multiplied with
>> 100 (1.4 -> 140), free VM may add 30 points, for incomplete spec
>> compatibility subtract 30. Revisions may add 1 point, as appropiate.
>Uh, is this really necessary? It seems like a quite awkward spec compliance
>rating system.
IMO yes. This will ensure, that when using java, the best and
latest version of instaleld JVMs will be /usr/bin/java. This will be
the best and wanted case in most cases.
>> 2.2. Java Development Tools
>what about javap, rmic, rmiregistry ?
I meant "java dev tools for packaging". Everything else is used by
developers (=users, who are IMO able to read the manpages) and so IMO
there is noo need to put a policy around them...
Does anyone needs more java tools which needs to be coverd by policy?
>> * Sun's Community Source Licence. Can we use it? How? The 2.3
>> version of the text can be found [19]here.
>I doubt it, since it's not free software in the DFSG sense. It was not even
>open source last time I looked at it;)
So this part should be removed, if thats clear.
>> * Should there be a default classpath, similar to a repository?
>> Which jars should be included in that? A standard and one optional
>> part? If there are a default classpath (in the wrapper) how should
>> it be overridden?
>Adding unnecessary packages to the classpath can increase application startup
>time, since the java API spec requires the system class loader to search
>linearly through the bootclasspath, system extensions, and the classpath. So
>I'd recommend against a default classpath setting.
IMO, this is also covered with the 'JarDF' Proposal and the helper
scripts.
Jan
--
Jan Schulz [EMAIL PROTECTED]
"Wer nicht fragt, bleibt dumm."
