Re: [PROPOSAL] New Virtual Packages and way to handle Classpath
Hallo Jan,
--- Jan Schulz <jasc.usenet@gmx.de> wrote:
> Hallo Dalibor,
>
> * Dalibor Topic wrote:
> >Why do you assume familiarity with some command line synopsis? The effect of
> >-classpath a.jar:b.jar for example can have different effects depending on
> the
> >VM used, and its version. That's what the documentation is good for ;)
>
> >From my limited java experience, it will not matter. For example the
> jikes delegate of the ant javac task uses only the classpath but the
> javac task includes a 'bootclasspath' option. -> jikes will be called
> with 'bootclaspath jars' + 'classpath'. There is always a workaround,
> which will work 'good enough'.
You should avoid turning whatever your 'limited java experience' makes you
believe is the normal way to do things into a policy ;)
The definition of what's to be expected as normal keeps changing all the time
in the java world, as I'm trying to make clear with my questions on your
interpretation of java's class loading semantics.
> >> Just setting them all to 200 isn't any better. This priority system
> >> should IMO fullfill this goals:
> >> * get a newer version before the older one
> >uh, that's what the debian packaging system does already, right? when
> >let's say kaffe 1.1.1 is out, it replaces kaffe 1.1.0 in debian,
> >doesn't it?
>
> Yes, but does kaffe1.1.1 replace sablevm? Or a BD java 1.3?
Why should it? If let's say eclipse depends on sablevm or BD java >= 1.3, then
an update of kaffe shouldn't have any effect on my ability to still run eclipse
afterwards, so it shouldn't mess with sablevm or BD.
I'd consider kaffe removing some other unrelated package from my system to be a
serious bug.
> >> * get a more spec complient version before any not so spec complient
> >> version.
> >that's the ugly part, where someone gets to be the judge who's how much
> >compliant. It's not clear how you want to judge spec compliance. Could you
> >elaborate on that?
>
> Lets say it this way: There is such a thing as a reasonable debian
> developer and I think that he should be able to sort that out.
Unfortunately, I still don't get it. Do you expect VM maintainers to rate the
compliance of their VM packages, some third party (like yourself), or the users
after they install a VM?
> >> * get a free one before a unfree one.
> >yay! I'm all for that ;)
>
> I'm even more happy seeing you happy :)
O.K., you get to be the happier one ;)
> >I think your priority scheme tries to solve the problem what to do when two
> or
> >more VMs are able to run an application.
>
> >From a packages POV, they wont access the priority system. Only the
> unfree interface (and /usr/bin/java, but that shouldn't be accessed by
> debian packages) is controled by this priorities and there only the
> 'greater release gets greater prority' rule applys.
>
> >Let's hypothetically say the user tries to run tomcat-xyz, which is
> >according to the packager able to run on both sun's VM, blackdown,
> >IBM, and sablevm. The user prefers to run free VMs over unfree ones if
> >any possible (not so uncommon for debian users), so his $PATH has
> >sableVMs java executable before the unfree ones. Ideally, debian java
> >wrapper will delegate the call to the first suitable VM package it
> >finds
>
> Hey, thats exactly what I wanted to do with my proposal.
>
> Only that the three unfree ones are used via the 'unfree interface'
> and that the packages may use whatever order it may find suitable. If
> we find a way to factor this 'search' out into a differnt programm, it
> may be able to set preferences.
Great, as that's a system I could live with ;)
I wouldn't let the packager decide what VMs should be tried in which order, as
I want to be able to set my preferences myself (and I may not want to prefer
VMs based on their perceived compliance with JDK 1.4 APIs, for example), just
let the packager limit the options to the VMs that are known to work with the
package.
Since I expect users to have different preferences (spec compliance,
performance, implementation quality, freedom of software, and a thousand of
other reasons to prefer one implementaiton over the other, including prefering
a particular unfree one over another), I don't like the preference rating
system based on some unmeasurable compliance factor. In fact, I'd prefer a
scheme where the suitable VM search is factored out to a third program which
honors my $PATH as a way to express my preferences, for example.
> >on the PATH which is sableVM in this case.
>
> I don't mind which package it finds first, but that it *only* finds JVM,
> which are capable of running the programm.
what about adding a /usr/share/java/jarregistry directory with a file per java
package that contains a
Debian-Can-Run-On-VM: vm-a vm-b
line. the hyptohetical VM lookup script would look at the Can-Run line and run
the application with the first VM in the $PATH that's listed on the line.
there could also be a:
Debian-Uses-JARs: jar-package-a jar-package-b
line for packages that require the use of other jars, for example libraries.
The VM lookup script would then create the intersection subset of all VM
suitable for all involved libraries and applications and run the application
with the first VM from the intersection subset it finds in the $PATH.
cheers,
dalibor topic
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
Reply to: