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

[Jan Schulz <jasc.usenet@gmx.de>]

Hallo T.,


* T. Alexander Popiel wrote:
>>The rest will be handled independently.
>How, though?  If an application is known to work with kaffe or sablevm
>or Sun's java, how is that application to pick which to use on invocation?
>Will each application have to have a wrapper script which picks an
>appropriate VM?  How will the user pick which VM they want to use, if
>multiple are available?

Yes, this seems to be the only way to go. They anyway have such a
mechanism already.

>Would it be useful to have a tool (as previously mentioned) which
>looked at a collection of classes or a jar and determined all the
>signatures of the external dependencies?  And another tool to generate
>the list of signatures of all methods/fields provided?  Then a third
>to match up the two lists and give a reasonable first approximation
>of if a given application has any hope of running under a given VM?

This will have to be done at packageing time (runing this at runtime
is just not possible). It's probably much easier to just test, if your
package will run with this VM, than do the handling based on this.
There is more than API classes, which can make a start fail (such as
unimplemented methods or not complient to java spec of that version).

>If such is useful, then I can fairly trivially generate those three
>tools (in perl, so we don't have the chicken-and-egg problem).  In
>fact, I think I've previously posted something very close to this
>in the last two years, in the prior go-round of the 'how do we handle
>classpath' debate.

I think this would be very helpfull for packagers and for the BTS (I
need this features, until $VM can run my package). I plan to build
dh_java to handle most of my proposed policy changes. Maybe we could
put such things into a common 'java-dev-tools' package...

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