Hi Jan, On Sun, 2003-09-07 at 13:31, Jan Schulz wrote: > Do you have a better name for 'programm, which runs java byte code'? > for me 'java' stands for exactly this and I don't midn if it is > actually called /usr/bin/kaffe or /usr/lib/sunjdk/bin/java 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.) > >Not if you use the native gcj version. > > 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/>. The point that I am trying to make is not that you should do it all by compiling to native applications and libraries (even though I think that will be the future). If you think that goes to far, to fast then everything that works by compiling to native code will also work by compiling to byte code and then use a free byte code interpreter. When you do that you might get a better policy. Just look at what free applications and libraries there are written in the java programming language and see what is possible at this moment with free tools that Debian can actually package and distribute. That is why is suggest you look into how all the following things are now possible with free VMs, compilers and libraries: - bcel - bouncy castle, - bsf - jakarta-commons - java-cup - ecj - gnu.regexp - ant - log4j - jasmin, - junit - jdbc-drivers - rhino - xalan - xerces - gnu.readline - log4j - oro - struts - tomcat - jython - mx4j - eclipse Except for Eclipse all these things are buildable on a recent Debian system (and as I also pointed out earlier, Eclipe can be run with the gij that Debian currently distributes with only a minimal patch. And the next kaffe version will also at least start it up. Just look at rhug for sources <http://sources.redhat.com/rhug/> or <http://people.redhat.com/gbenson/naoko/> for Red Hat packages. Eclipse takes a bit more work, but a simple way to at least get an idea how it would work on a Debian system is given in: http://lists.debian.org/debian-java/2003/debian-java-200309/msg00056.html The reason I am repeating this (since I know I have pointed this out in earlier emails) is that I truely believe that by studying how this works on a complete free system gives you a much better starting point for a new Debian java policy. I would be glad to help with anything that involves gcj or the Classpath class library (and even kaffe) which doesn't seem to work correctly with the packages above. > The only thing I say is, that nothing can > tell me, where /usr/bin/java points to. Eclipse needs (still) a unfree > VM No, it doesn't. I have it running on the Deebian system I am writing this email on and I have no non-free software installed on it. Please try it out. I am sure there are bugs and things to improve, but it does run! And I would be happy to help clear up any bugs that people find with it. > , so if /usr/bin/java is sableVM, I will get a nice bugreport that > 'eclipse doesn't work'. Under the current policy (BTW, have you read > it?), the only thing I can do about this is 'set JAVA_HOME' and close > the bug. This is why I suggest you drop the /usr/bin/java and /usr/bin/javac alternatives. They give more trouble then they are worth IMHO. But I will read up on the old policy. > Most java apps are designe for this unfree VMs. If a app 'wants' a > unfree one, we can do two things: satisfy this depends (-> unfree > interface) and test whether a less complete VM will also work. > > If you have a different naming, please say so. I'm also not satisfied > with this names... I would just call them free vm/compiler/library implementations versus non-free ones. Then just reverse the two choices. Test whether the application or library that Debian wants to package works with a free vm/compiler/library combination. If yes -> set the dependencies right to show you have tested the package with that particular combination. 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. > ot of the box, they work with the VMs, which are stated in the > readme/webpage. So we can assume that a package will work with one of > 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! > >> Any proposals? IMO the above is good enough for debian java policy. As > >> the proposal says, /usr/bin/java is not meant to be accessed by > >> packages. > >I propose to not define it in the policy at all. > >Except maybe as a note saying that in the past there was a alternative > >system for /usr/bin/java and /usr/bin/javac but it didn't work out. > > I can put a stronger note in there, that this alternatives are not to > be used by packages and are there for backward compatibility and for > the user to try out 'HelloWorld.java'. > > I think removing them completely would be the best, but I think that > too many people will complain if the don't have a 'java/javac' in > their path. It would be the honest thing to do. Really my suggestion is to just remove these alternatives if you cannot satisfy their quality with free implementations. > >> Run every program as good as the unfree ones? > >Every program :) Maybe we could start with a subset of that. > > For debian package dependencies, it needs to be 'every'... IMO Lets start with a list of prospective packages for inclusion in Debian. There must be things that are now not part of Debian, but that people have packaged into debs either in contrib/non-free or on their personal download pages that you want to see in Debian. What prevents those programs from turning into real Debian packages at the moment. You can take the list above from rhug/naoko to see if they needed patches to make it work on a completely free Red Hat system. If anybody needs help with this please contact me and I would be happy to try to get things working on Debian (I might not be a debian developer, so I don't know much about packaging, but I do know enough about free compilers, libraries and interpreters to quickly see what can or cannot work immediatly). > >What doesn't run satisfactory for you? > > eclipse? > > Please note: It doesn't even run 'good enough' for me on a unfree one :) 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! > Lets give this example: I develop webapps. Until now they were able to > run on kaffe/gij/gcj. Now I want to have some pictures put into the > pages and I will use Image to get the size (yes, I know that tehre are > better ways and that this is too slow). I deploy this. Crash. I will > search the net for 'Image tomcat linux' I will get a lot of results, > which points to 'headless mode' for awt available in 1.4. I put the > right things into the tomcat startscript. Crash again. > > And this is only tomcat with some small webapp. I don't completely understand the example. But surely if you report this to the kaffe hackers they can help with fixing this bug or suggest some way to work around it? > >But if they are packaged for Debian cann't you just backport the build > >tools also? > > Yes, but why should I if I have a full sun J2SDK installed already? > Just for the sake of downloading 10+ MB again? 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? > >And packages out there which do not work with free tools are > >probably not packaged for Debian anyway since they would have to go into > >non-free or contrib. > > 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? > >I do expect Debian to have a packaging system that won't give me > >headaches. And I know that is does have that. > > 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. Cheers, Mark
Attachment:
signature.asc
Description: This is a digitally signed message part