Re: [PROPOSAL] New Virtual Packages and way to handle Classpath
Hallo Dalibor,
* Dalibor Topic wrote:
>--- Jan Schulz <jasc.usenet@gmx.de> wrote:
>Just because it doesn't do full java 1.x yet, it doesn't mean it's useless. I
I agree.
>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.
Or as a different situation: imagine we have a new implementation of
/usr/bin/perl, which isn't as full featured as perl now. I know that
this is diffrently, as perl does not come as tightly coupled with its
class library (just apart that we can distribute the original per...),
but still...
>> >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.
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
Even if you could setup the bootclasspath in your packages, this
wouldn't work, as this would mean, that we have to seperate the
rt.jar of the bigger VMs. This would break for example every IDE
out there.
>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.
>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 ;)
It's quite a difference, if you have bugs or that APIs are simple
not there.
>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.
>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...
>See for example the mess that results from ant wanting to use sun's javac
.. aehm yes...
>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
BTW, you can provide you own class, which implements this interface.
eclipse for example provides such a class for its own compiler.
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 :(
>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.
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.
>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.
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.
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...
Jan
Reply to: