Petter Reinholdtsen <pere <at> hungry.com> writes: > > > [Eric Lavarde] > > Conclusion: > > - if your package works with free VMs, you should write something > > like: kaffe | sablevm | java1-runtime. > > Is it not enough and recommended to list only one non-virtual package, > aka 'kaffe | java1-runtime' or 'sablevm | java1-runtime'? I assume > would kaffe and sablevm provides java1-runtime, but a check show that > at least kaffe only provide java-virtual-machine (did not find > sablevm?). How come kaffe do not provide java1-runtime? >
I'd say that javaX-runtime only makes sense for runtimes that have been through the compatibility tests for X, as otherwise code depending on that platform's features may not run at all. I am not sure whether a virtual means 'may, with a bit of luck, work' or 'does work, of course', though. Given that such compatibility tests have so far[1] been unavailable to free runtimes like Kaffe, it does not seem to be legally safe to call Kaffe java1/2/3/4, if one wants to avoid having to deal with Sun's lawyers at the end of the day. See Sun's trade mark usage rules, and all that fascinating legal stuff. It may make some sense to introduce a 'classpath-runtime' or 'free-runtime' virtual to be used for GNU Classpath based VMs and ahead of time compilers. But, GNU Classpath is so rapidly changing (in particular wrt to the binding between the class library and the runtime, which makes it pretty hard to run sucessive GNU Classpath release without modifying old runtime releases), that such a virtual would not be too useful in practice, other than saying that the code *may* run on at least one GNU Classpath runtime beside the one already listed, good luck finding it. :) That would not seem to be a perfect situation for users, though it would probably be an improvement over the current one. cheers, dalibor topic [1] I'm talking with them about the 1.5 tests, but that's going to take a while. A TCK license is a very long text of legalese and takes a deal of time to decipher and negotiate through. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
