Re: [PROPOSAL] New Virtual Packages and way to handle Classpath
Hi Jan,
--- Jan Schulz <jasc.usenet@gmx.de> wrote:
> Hallo Dalibor,
>
> * Dalibor Topic wrote:
> >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 ;)
>
> :) This discussion is nothing against being 'Proponent' of a new
> german newsgroup...
ouch, i sense frustration ;)
>
> [free, but not full featured]
> >> 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 ;)
>
> I'd actually do this (I haven't have time yet to test eclipse with
> kaffe...). But I know my skills and they are definitelly not enough to hack
> on kaffe or any other 'bigger' non java app. Just by packaging
> eclipse, I'm learning more about binary libs than I ever thought I
> would...
sure. but quite often it's not as hard as it looks. You see that some
application A doesn't build on, say, kaffe, due to a missing class,method or
field. You look it up in the API docs to see what it does, take a look at GNU
Classpath to see if it is already there. If it's not there, you ponder a few
minutes whether implementing the field, method, class or interface is within
your skills. If you think you can do it, you hop on the mailing list, and we
work together on the code, or you take the lead, as you wish. If you think you
can't do it, you hop on the mailing list, and tell us what you need implemented
and what you need it for, so that we can priritize things a little bit.
That's the ideal case, in practice it can take some time until you get a
response since there is only few developers compared to the number of bug
reports ;) that's also the reason why we need more developers on Classpath and
Kaffe and so on. Java APIs are huge, and a lot of work. Currently all the great
work is being done by a few handful of highly skilled people (that are pleasure
to work with ;). If you don't want free java to always drag on years behind
non-free offerings, you should join GNU Classpath and help them implement
missing java APIs faster ;)
> Seeing that debian is famous about 'that it works', I would say, that
> we should have a policy, which:
>
> * makes all our packages working with every JVM, which will run it:
> . free ones
> . unfree ones by a well defined API and a installer script
that's a great goal. it needs people who test & build java programs on debian
on every java implementation in debian. I believe some of that could be
actually done automatically, like the buildd setup for normal packages.
So let's try another idea:
A java package is uploaded for debian.
It goes into the java-buildd, which tries to build it under all free java VMs
and non-free ones. Where it passes, it also runs the regression tests, if any.
If the package passes any free java VMs, it goes into main, otherwise into
wherever the java application packages currently are (as you can see I'm not
very familiar with debian's package directory system).
Where it doesn't pass the free java VMs, bugs are automatically entered into
the bug tracking system for the respective package.
The dependency information for the package is then set to require one of the
free VMs it passes on, and non-free ones it passes on. If the package passes on
sun's offerings as well, the lowest java release it passes on is also added as
java-1.passed-runtime.
so in practice, if someone makes a new ant package, it goes unto the java build
environment. There it is tested on kaffe 1.x, it breaks during compilation, and
a detailed, automatically generated bug report is added to kaffe's bug list. It
turns out to work fine on gcj 3.y, so it is marked as going into main and the
gcj >= 3.x requirement is added to ant's depenedency information. Testing with
sun's java runtimes reveals that it works with jdk 1.1.8 and above, so it is
also made to automatically depend on java-1.1-virtual-package.
That means, if someday a free implementation can claim java 1.1 compatibility
(without being sued ;) all those packages could move into main.
For java VMs, there should be a similar process. When a VM release is updated,
the new package goes into the java build demon, and all packages that worked
with the older release are rebuilt and tested with the current release. If a
package fails, a bug is files against the new release of the VM. If the result
of the package failing on the new release would be the removal of package from
main, since no other free VM can run it, the new VM release is not allowed to
enter 'testing' (if my debian branch terminology is right).
that would be a *great* way for debian to help free java efforts by providing
efficient regression testing on what will be tons of java apps in debian.
> * make all alternatives of java/javac working in the same way [1]
noble goal, but as I explained in the other mail, there are differences in the
behaviour that some java/javac implements. Some of it is intentional. You could
agree on a common basic synopsis for javac, like -d , -classspath and providing
all the required sources on the command line. Same for the java executable.
> [1] I just got a mail form a user, who wanted to try swt with sableVM
> and kaffe. the first printed a 'error: todo' and the second got him
> into the 'kaffe -classpath' doesn't add rt.jar. The second error could
> very simple be prevented by a wrapper script.
kaffe 1.1.1 should work better with respect to that ;)
> >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.
>
> Are you telling me, that I can't build jni libs (libswt is one), which
> will run on nonfree (which are in my experience working) and kaffe and
> gcj?
No. But internally, some VMs implement some of their native libraries with
faster, VM-specific native interfaces. You can't mix those. JNI yes, you can
mix that, as long as the VMs all implement the same JNI spec (1.1, or 1.2).
> >> -> 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.
>
> This would mean, that we have to split rt.jar. Will kaffe or any of
> the other VMs still work then? It will be hell for packagers, as they
> basicly have to rewrite the original build prozess.
I think we have some linguistic confusion here ;) What I mean is, that you take
a program that walks over rt.jar and lists all the available classes, field,
methods, etc. into a plain text file A. That's what I call the API information
of a particular VM. Then you take another program that walks over an
application's jars and classes and lists all reqired system (i.e. java.* ,
javax.*, org.w3c.*, etc.) classes,methods and fields, into another text file
B. Then apt needs to determine whether textfile B is contained in textfile A.
Though, now I think the java build demon aproach is better, as it actively
figures out what works and what doesn't instead of relying on API descriptions.
> >> 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.
>
> First of all, it will work with packages like xerces, which already
> now can be updated 'endorsed dir' or so, or simple adding a newer
> version to bootclasspath.
fine, but for example you can't put xerces into kaffe's bootclasspath as its
licensed under GPL-incompatible ASF license.
> BTW, I always wanted to ask, why you need java for OOo. The only place
> I found would be XML handling (xalan) and the UNO bridges. Both should
> be relative easily be replaced (first by a diffrent whatever Prozessor
> and the second by simple removing it). Do you know some more?
while they are boostrapping the build, they generate some code using java, xml
and a lot of magic. the second use for java is that you can apparently embed
applets into html pages created by open office. and finally, uno, their
component architecture, uses java.
> >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.
>
> Hm, eclipse uses
> <property name="build.compiler"
> value="org.eclipse.jdt.core.JDTCompilerAdapter"/>
>
> Seems that it extends
> org.apache.tools.ant.taskdefs.compilers.DefaultCompilerAdapter
Eclipse uses it's own builtin java compiler, and needs to tell ant about it. It
is supposed to integrate ant ;) kaffe doesn't integrate ant, ant runs on java,
so there should be no need to add cruft to kaffe to fix ant ;)
> >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.
>
> IMO, that is wrong. The eclipse genrated build.xml is setting
> build.compiler, when eclipse is running. I don't think they would, if
> in all tested cases (SUN, IBM) they would get the internal compiler.
> It should at least be 'first build.compiler and then internal'.
> Anyway, I haven't seen ant internals...
they set it because they want their internal compiler instead of sun's. if
build.compiler is not set, it default to sun's compiler.
> >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.
>
> Im of the 'whatever works best' group :) At least when I can't help
> myself to somthing better.
then you shouldn't use linux, since windows is a much better enviroment for
Sun's java;) it's actively being supported by sun, whereas their linux support
is non-existant on non-i386 linux platforms, i.e. where debian really shines ;)
> >> 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.
>
> Aehm, yes, I will try that in my next break :)
Other people have done it before, it can't be that hard ;)
thanks for keeping the discussion technical, I'd like to hear what you think
about my java build demon proposal.
cheers,
dalibor topic
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
Reply to: