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...
[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...
>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.
Yes. IMO debian policy should go with this approach.
>I'm not quite sure what is debian's target audience.
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
* make all alternatives of java/javac working in the same way [1]
[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.
>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?
>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,
Will not work without Conflicting with every other JVM. Or more
detailed virtual packages.
>by fetching the reqs
>file for the java application and checking it against installed java runtimes,
might work, when we add a wrapper for every free bin/java and this
wrapper adds the required API to the bootclasspath. That was my
intention when I wrote the 'have all the API on its bootclasspath'
This would basicly mean the 'try to get as much sun-java like as
possible' approach.
>or statically, when an application package is uploaded to debian, resulting is
>a specific dependency list of VMs that *could* run the application.
This is the 'API for unfree VMs' and others by hand approach.
>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.
IMO, no mechanism will be fine grained enough, to allow to set this
dependencies automagically.
>> -> 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 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.
>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.
:) Two weeks ago there was patch on debian-ooo about 'removing the
need for java'.
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?
>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.
eclipse has a similar thing, which just got a patch by the RedHat gcj
guys... Hope it will be in soon. Until now you have to set a
properties, so that eclipse can use it to start programms. Or so I
understood it.
>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.
This could be a task when you package such a app... Or it will never
be included in debian. But this is not the point. Currently, we don't
even work well with app, which are doing 'the right thing'...
>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
>No thanks, I prefer to root out the cause. ;)
If you can. I'm more the 'make it work' guy...
>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...
>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 ;)
I don't encourage them. But IMO, we shouldn't make it hard to use
debian java packages without some handmade magic (like equivs) or
depending on BD packages (which currently are outdated :( )
>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.
>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.
It's also about 'our users' and from that POV, we should react to the
situation, that there are unfree java packages...
>> 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 :)
>Kaffe actually comes with a jitter on many platforms.
Sorry, I didn't know that. This will be the problem with eclipse
and gcj, as every added plugin will run in interpreter mode.
Thansk for your great responses!
Jan
--
Jan Schulz [EMAIL PROTECTED]
"Wer nicht fragt, bleibt dumm."
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
