--- Jan Schulz <[EMAIL PROTECTED]> wrote: > >Now that I am putting some real effort into Kaffe again I would like to > >see an actual functioning framework of Java applications in main. > >There is no Free VM that I am aware of that supports either Sun's 1.4 or > >1.3 or even 1.2. Your solution doesn't fulfill the Social Contract and > >not even Java is specially immune. > > On the other hand there is this 'and our users' part in there. And > they expect, that when I install a JVM of a certain version, that all > programms, which require a JVM of that version will work.
they won't. there is no free VM that supports *all* of JDK 1.0 (yes, including the braindead 1.0 AWT event model) for example, AFAIK. In fact they won't work even with Sun's VM if your users are not lucky and hit upon a bug. That's life. Do as you would do in Sun's (or gcc's, or linux kernel's or any other crucial bits nedded to run programs) case: submit a bug report. If you want to have it fixed for good, make sure that you submit a good patch as well. Fortunately, most programs don't use the whole class library, but just the bits necessary to perform the tasks they do. So a free java compiler like kjc, for example, doesn't need XML to run. If it requires a specific java API version 1.x it doesn't do so because of XML support. since no free java environments support a full java implementation of any API they by definition can not run *all* possible java programs. In the real world, it turns out that this ability is not necessary in many cases. My ant builds with kaffe work as well as under a proprietary offering, despite that kaffe has no corba implementation. But then, ant uses no corba AFAIK. Just because it doesn't do full java 1.x yet, it doesn't mean it's useless. I think you are blowing the problem out of proportion and going for radical, simplistic solutions instead of trying to figure out a better way to handle the complexities involved. > >I do see your point about alternatives. If we constrain my suggestion to > >just base VM classes that problem goes away. > > It will still be a real mess :( Just when you want to have 10 base > packages, it will be 10! of alternatives: > java-net > java-nio > java-awt > java-awt+net > java-awt+net+nio > ... So? I don't understand the debian packaging system, so I don't know why that would be a problem. After a all, a package can depend on several other packages. Is there a hardcoded limit for that somewhere? If your JVM A provided virtual packages java.net java.nio and java.rmi, and JVM B one provides those packages plus java.awt, then the debian packaging system shuold be able to infer that in order to run a networking application it could install both, but in order to run a graphical application it could only install JVM B. Or did I miss something obvious? > Do you want to setup such a lot of alternatives? The only other > sollution I can thing of is Conflicts: java2-... and so effectivly > having just *one* JVM installed at a time. This would mean, that you > will probably end up in a situation, where two free VM have each a > package, which is needed and and which is not in the other VM. -> Mess > again... How is that different from the situation where you have two different Sun VM versions which both have bugs (like all programs do anyway)? Program A works on one, but it's broken on the other, because of some JVM bug, and the other way round for a program B. Of course it's a mess, it's the real world ;) I'm not sure if you are aware that free VMs mostly don't use the same set of class libraries. While kaffe and gcj, for example, share a significant amount of source code in some areas (via GNU Classpath), they are quite different in others for various good reasons, like performance, different focus, licensing, etc. > >Base class libraries are > >not currently shared by any VMs I am aware of. Such an effort would be a > >worthy cause but it isn't likely to happen anytime soon. > > But you could add other packages (-> Jars) to your bootclaspsath and > in this way get the same bootclasspath than the BD/SUN/IBM JVM. nope, you would miss (for example) all the classes for which no free implementation exist. There are quite some, GNU Classpath only covers about half of JDK 1.4, and a good deal of it is just Swing stubs, AFAIK. Plus of course all the missing sun.* and com.* classes are going to be problematic when you have people using those 'forbidden' packages. See for example the mess that results from ant wanting to use sun's javac compiler as the default compiler. Instead of running it in a separate process, (which could adversely affect performance), they chose to load the compiler class directly, breaking ant on every VM that doesn't come with a com.sun.whetever.javac.Main class. That's why you specifically have to tell ant to use kjc as the build compiler on kaffe using -Dbuild.compiler=kjc. The clever way would have been to spawn the build.compiler executable in the PATH in a separate process. then JVMs could come with their own javac wrapper scripts for whatever compiler they wish, with the name javac used as a default for the compiler. that's the real world. It's full of people who sacrifice portability for performance. ;) Obviously, in those cases, using a free VM means having to figure out the quirks of the aplication and to work around them. > IMO, our priority should be on the first. Debian does not gain > anything, if we have a setup, which will fail in some/most cases. > If we do that, we again end up in the same situation as now, where > everybody Depends on $JAVA_HOME/bin/java, where JAVA_HOME is searched > for by a ever again script snippet. Then you don't want to use a free virtual machine. you want to use Sun. There is no certified Java free VM and there won't be as long as sun's licensing policy doesn't change. As long as you don't have a certified java runtime, you can forget about not failing in some cases, because there will be cases where your implementation differs from sun's *within the scope of the spec* (which is quite bad for some classes. Try implementing java.io.StreamTokenizer from the spec if you want to have some fun on the weekend). cheers, dalibor topic __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com
