Re: [PROPOSAL] New Virtual Packages and way to handle Classpath
--- Jan Schulz <jasc.usenet@gmx.de> 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
Reply to: