Hallo Mark, * Mark Wielaard wrote: >On Sun, 2003-09-07 at 13:31, Jan Schulz wrote: >I would call it byte code interpreter then. >Try to avoid the java name a bit since Sun claims a trademark on it. >And it make it more clear that it is only one part of the environment >that people might want. (The others being a byte code or native compiler >and a core class library.)
'Byte code interpreter policy'... the "debian byte code interpreter" mailing list. No, sorry, i won't do that. >> Yes, *if* I do that. Currently I have not done it and this proposal is >> not about compile to native. >But I also pointed out how to get it working with a traditional byte >code interpreter <http://www.klomp.org/mark/gij_eclipse/>. But this is completely besite the point that we are here discussing a policy for using 'java byte code interpreters'. If you want to have 'compiled to native' java packages, then file a bug against the packages, which you want and ask the maintainer to do it. Packages, which will do that will use the normal debian policy to do it. >[...] If no -> it cannot be part of Debian and users will probably be >better of installing the upstram source anyway together with some >proprietary non-free vm/compiler/library combination. You do know that we have a contrib and unfree section, to which this policy also applys? >> the 'unfree interface' versions. If we get that for free, I don't se >> ethe point in denying this fact to the user. >Since the user doesn't get that for free. They have to install non-free >proprietary software which they cannot use according to the DFSG. They >might even have to accept licensing terms which make it impossible to >help others working on free replacements! And? If the users chooses to do so, it's their choice. I don't think that we should *force* them not to. >That is a good starting point. I am sure that I or other gcj hackers >would love to help you make the gcj compiled eclipse the best eclipse >out there. Please bring on the bug reports! I will do that, once I have time again to spend a complete weekend on that. And after all the RH patches have made it into the gcc in unstable. >Because the packager (if it is part of Debian) as obviously tested it >with free implementations that he/she nows work best with the package? So consider a package, which requires a 'sun derived' 1.4 JVM. Without the 'sun derived interface', it will always be the BD java packages, which will be used. The only reason for this is, that the packager knows the location of JAVA_HOME. Even if I install the BD packages via the -bin download, it will not work, even if I use equivs to satisfy the build depends. >> Currently almost every java app is in contrib: eclipse, tomcat, ant. >All the examples you list can soon move into main if the packagers make >them work and test with free implementations. If Red Hat can do this, >why can't Debian? Because RH pays someone for this work? I will not simple drop eclipse into main until I think it will work as good as I expect it. 'just startup' is not good enough. >> Yes, because tomcat and eclipse build-depend on BD java. >Then those packages are currently not part of Debian... >I don't see your point. But they still have to comply to the debian policy and in this case the debian java policy. Jan -- Jan Schulz [EMAIL PROTECTED] "Wer nicht fragt, bleibt dumm." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
