[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [PROPOSAL] New Virtual Packages and way to handle Classpath

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

Jan Schulz                     jasc@gmx.net
     "Wer nicht fragt, bleibt dumm."

Reply to: