Re: [PROPOSAL] New Virtual Packages and way to handle Classpath
* 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
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
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 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
Jan Schulz email@example.com
"Wer nicht fragt, bleibt dumm."