Re: [PROPOSAL] New Virtual Packages and way to handle Classpath
--- Jan Schulz <jasc.usenet@gmx.de> wrote:
> 2.1. Virtual machines
>
> As it is nearly impossible to treat all java virtual maschines the same,
> JVMs are seperated into two kinds: sun compatible and not. The first ones
> should be used via the below interface, every other virtual maschine has to
> be called seperatly.
>
> Sun compatible virtual maschines of a certain java spec version have to
> provide the virtual package java-runtime-version (where version is the
> curent spec version number) and setup alternatives for /usr/bin/java-version
> and the corresponding manpage. They must depend on java-common.
>
> 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.
> 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.
> 2.2. Java Development Tools
what about javap, rmic, rmiregistry ?
> Chapter 3. Issues to discuss
>
> The following points are discussions about the policy, either because they
> have to be studied more, or are controversial.
>
> * Name and existance of the repository. It was removed in the latest
> version.
> * Core classes (java.*). More study needed.
> * 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;)
> * 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.
cheers,
dalibor topic
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
Reply to: