Re: [PROPOSAL] New Virtual Packages and way to handle Classpath
Hallo Jan,
thanks for taking the time to write a well thought-out, and pointed response. I
wasn't sure whether my reply was a bit vitriolic ;)
Now let's go back to the technical discussion:
--- Jan Schulz <jasc.usenet@gmx.de> wrote:
> >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 might. But I don't see how we could solve this problem. Outside of
> debian, everybody expects that when the programm runs in a java
> virtual maschine, that this a sun/BD/IBM Virtual maschine with all the
> features. By default, we would ship a JVM, which is not that full
> featured. Most likely, this will end up in many people complaining,
> why there program isn't running.
Yes. Send them our way so we can educate them to fix the problems they are
complaining about by writing the missing pieces ;)
People will always complain, as long as the free java implementations are not
equivalent to sun's on all accounts. Frankly, as long as they don't want to put
the little extra effort, and work with us to fix the issues (for example by
implementing and contributing the missing APIs to GNU Classpath), I don't care
that much about it. The free java implementation efforts need contributing
users and developers, people who just say: it doesn't run my Swing app, it
sucks! are not that helpful.
I think we have a different perception of communities that free java caters to:
for you, it's mostly about making life easier for users of java applications.
That's fine with me, but that means endorsing proprietary VMs at the cost of
the free ones, because there are many applications you may want to get into
debian that don't run reasonably well under any free vm. The audience I'm
thinking of is developers and power users, who know a lot about java already,
and use and extend those free VMs to suit their needs.
I'm not quite sure what is debian's target audience.
> >> >I do see your point about alternatives. If we constrain my suggestion to
> >> >just base VM classes that problem goes away.
> >> 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.
>
> On package system level, it isn't a problem. It becomes a problem,
> when you have alternatives. I have a VM, which provides java.net and
> java2-runtime-1.4 and another VM, which provides java.nio and
> java2-runtime-1.4. Now we have Program, which Depends on nio *and*
> net and jre1.4. apt will install both VMs and the program will call
> /usr/bin/java-1.4 and will think that everything should work. And it
> will not, as on of the java packages is not in the classpath.
It wouldn't work even if there is a way to merge the classes together into the
same classpath: both nio and net need native libraries to be impemented fully,
and trying to get internal native libs from one VM to work with another is very
hard, in my experience, due to different internal JNI replacements (i.e. KNI on
kaffe, CNI on gcj), for example.
What I think of is that there should be a way to say:
this VM provides a certain API (obtained by running japitools on that VM's jar
files, as a package kaffe-japi, for example).
this application requires a certain API (obtained by running something similar
to figure out all the fields, method, classes etc an applicastion can access,
as package tomcat-reqs for example)
then matching could be done either on the fly, by apt, by fetching the reqs
file for the java application and checking it against installed java runtimes,
or statically, when an application package is uploaded to debian, resulting is
a specific dependency list of VMs that *could* run the application.
the current approach is not finegrained enough to allow for such obscurities
like kaffe, although it doesn't implement full 1.4 APIs, running saxon just
fine.
> Therefore we need alternatives for each combination of virtual packages:
> VM -> Provides: net, nio
> -> provides alternatives for java-nio, java-net and java-nio-net
I think a better solution would be to put API information in a separate
package.
> >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?
>
> Yes, but that would mean, that each VM needs to comflict with each
> other VM. Then you would be stuck in a situation, where you have two
> packages, on package satisfied by VM_a, one by VM_b and you could only
> install one package at a time. (or VM_unfree, which will provide all).
>
> A similar situation would be to have qt conflicts with gtk and reverse.
I see that it's even more complicated than I anticipated ;) Thanks for the good
example on the effect of conflicts.
> >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.
>
> I know and thats why I want to have both package try to get a (mostly)
> complete bootclaspath by adding the required java package (from other
> debian packages) in a wrapper.
That is bound to cause interesting trouble with native methods being (ab)used
accross VMs.
> >course all the missing sun.* and com.* classes are going to be problematic
> when
> >you have people using those 'forbidden' packages.
>
> Most likely, this programms wouldn't be packaged for debian...
there is a popular office application package called open office, available on
openoffice.org. I think it's being packaged for debian. OpenOffice uses java in
its build process: Sun's java.
I'm in touch with Chris Halls, a debian developer, who's working on making sure
the build works well with fre vms, to make kaffe suitable for open office's
tasks.
The trouble is: a lot of open office's java code was written by complete morons
working for Sun. It uses sun's internal classes everywhere. It's basically
undocumented. Currently, the code in question is undergoing a rewrite, after
Chris and I made some fuss about its miserable quality.
If you want another example: some idiot working on OpenEJB thought he should
have access to the bootclasspath by using reflection to read the undocumented,
private field in Sun's ClassLoader class. Of course, it will only work as long
as Sun doesn't change that field's name. It won't work on anything else but
sun, that's for sure. So kaffe can't run openEJB, and probably never wil, until
someone there starts reviewing their code.
My point is, that while in a lot of cases the free VMs are not up to the task,
in a lot of other cases it's just because the applications are written by lazy
kids disguising as developers.
> BTW, you can provide you own class, which implements this interface.
> eclipse for example provides such a class for its own compiler.
It's not an interface, AFAIK. It's a regular class and we'd have to reverse
engineer it. Then of course, people couldn't run Sun's javac on kaffe anymore,
since our stub would automatically replace com.sun.whatever.javac.Main. It
would be a bad hack to make an even worse hack work. No thanks, I prefer to
root out the cause. ;)
> BTW2: It's a real pain, when people use non API. I just had to spend
> an afternoon on pango issues (eclipse wouldn't compile), which does
> the same whith freetype internals. Nicely wrapped into autoconf at
> compiletime, but not up into a comflicts in the packaging :(
the pango-Xft stuff? happened to me building from sources as well ...
> I don't know the way ant figures out the javac replacements, but with
> /usr/lib/java-dev-env, which requires to have a bin/javac in there,
> this should be preventable by simple setting -dbuild.compiler=javac in
> the ant wrapper. Or a way to set this from a alternative:
> #!/bin/bash
> source /etc/java/java.compiler
> ant -Dbuild.compiler=$JAVAC $@
> if ant does some magic and replaces javac with the above class.
it loads the class directly from tools.jar. If that fails, ant fails, unless
you pass it a build compiler property with a different compiler *for which an
ant 'driver' class exists*. Not exactly what I would call superb code.
> >Then you don't want to use a free virtual machine. you want to use
> >Sun.
>
> Most of our users will do that, after seeing, that they don't get what
> they want/need/expect... And then get a even bigger mess because it
> doesnÄt work with packaging.
If you take a look around on mandrake forums, for exmaple, most users,
recommend getting 'real java from sun' because their LimeWire client doesn't
run with kaffe or gcj. So what? Let them go and get it. But don't encourage
them ;)
> The problem is, that there are at least three (unfree) sources out
> there, which will satisfy the needs of almost every java app out of
> the box. Unfortunatelly we can't package them for debian. This policy
> proposal, together with the inclusion of a patched mpkg-j2sdk, will
> make them at least useable from debian packages. Without any
> improvment, it will become more and more messy, the more API changes
> are between the original java2-runtime and, for example, 1.5.
Yeah, but I don't really care about sun's java packages ;) If they want to
package their java for debian, fine. If they don't, I don't understand why
you're all so keen on doing it, instead of trying to make the free alternatives
better.
I mean, this is debian, it's all about writing, using and promoting free
software, right? I'm not a debian developer, but that was my impression as an
innocent bystander.
> The other thing is, that IMO noone wants to run tomcat under full load
> on a JVM, which doesn't do any JIT compilation. This is real world,
> too...
Then those people should write a jitter for the VM of their choice. Kaffe
actually comes with a jitter on many platforms.
cheers,
dalibor topic
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
Reply to: