[gentoo-java] JDK used for compiling

[gentoo-java] JDK used for compiling

[Sven Köhler]

[-- Attachment #1: Type: text/plain, Size: 725 bytes --]

Hi,

if multiple JDKs are installed, which one is used for compiling
packages? And why have you chosen that strategy?


I was conviced, that ebuilds always use the lowest JDK version possible.
But it seems, that packages use the System VM - which is 1.6 in my case.
But 1.5 is also installed.

So i like the idea, that, once i have troubles with 1.6, i may switch
back to 1.5. But, there is a fair chance, that packages compiled with
1.6 doen't work with 1.5. And no: using "-target 1.5" is NOT sufficiant
due to overloading.


So which JDK version is actually used by daemons? Is it the system-VM
too? So how can i run my daemon with JDK 1.6 while compiling things
against JDK 1.5?


Thanks,
  Sven


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 249 bytes --]

Re: [gentoo-java] JDK used for compiling

[William L. Thomson Jr.]

[-- Attachment #1: Type: text/plain, Size: 1831 bytes --]


On Sun, 2007-11-18 at 16:37 +0100, Sven Köhler wrote:
> Hi,
> 
> if multiple JDKs are installed, which one is used for compiling
> packages? And why have you chosen that strategy?

In short build vm != system vm. That allows for the two to differ and
further choice/control.

> I was conviced, that ebuilds always use the lowest JDK version possible.
> But it seems, that packages use the System VM - which is 1.6 in my case.
> But 1.5 is also installed.

Ebuilds compile source/target based on the lowest JDK version specified
in the ebuild. Which vm is used is controlled by by the ebuild and/or
the env. But most times that's restricted just to a version that
satisfied a virtual. Not specific vms.

> So i like the idea, that, once i have troubles with 1.6, i may switch
> back to 1.5. But, there is a fair chance, that packages compiled with
> 1.6 doen't work with 1.5. And no: using "-target 1.5" is NOT sufficiant
> due to overloading.

You can switch back and forth with no problems. That's why we compile to
lowest possible source/target. If a package requires a certain version
or fails with another. It's deps will reflect that.

> So which JDK version is actually used by daemons?

System vm unless specified otherwise. Like could be done for Tomcat
in /etc/conf.d/tomcat. Which would only effect that one
service/application and not the entire system.

>  Is it the system-VM
> too? So how can i run my daemon with JDK 1.6 while compiling things
> against JDK 1.5?

If you want control over building you can edit the files
in /etc/java-config-2/build/{jdk,compilers}.conf

http://www.gentoo.org/doc/en/java.xml#doc_chap4

It can also be overridden via command line
http://www.gentoo.org/proj/en/java/java-devel.xml#doc_chap7


-- 
William L. Thomson Jr.
Gentoo/Java

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[gentoo-java] Re: JDK used for compiling

[Sven Köhler]

[-- Attachment #1: Type: text/plain, Size: 1677 bytes --]

>> I was conviced, that ebuilds always use the lowest JDK version possible.
>> But it seems, that packages use the System VM - which is 1.6 in my case.
>> But 1.5 is also installed.
> 
> Ebuilds compile source/target based on the lowest JDK version specified
> in the ebuild. Which vm is used is controlled by by the ebuild and/or
> the env. But most times that's restricted just to a version that
> satisfied a virtual. Not specific vms.

Oh good! I was hoping to hear that.

But here, on my machine with default config, i'm compiling
commons-daemon, and it says "using sun-jdk-1.6".
Watch this:

# emerge -1 commons-daemon
Calculating dependencies... done!
>>> Verifying ebuild Manifests...

>>> Emerging (1 of 1) dev-java/commons-daemon-1.0.1-r2 to /
 * daemon-1.0.1.tar.gz RMD160 SHA1 SHA256 size ;-) ...

       [ ok ]
 * checking ebuild checksums ;-) ...

       [ ok ]
 * checking auxfile checksums ;-) ...

       [ ok ]
 * checking miscfile checksums ;-) ...

       [ ok ]
 * checking daemon-1.0.1.tar.gz ;-) ...

       [ ok ]
 * Using: sun-jdk-1.6
>>> Unpacking source...
>>> Unpacking daemon-1.0.1.tar.gz to
/var/tmp/portage/dev-java/commons-daemon-1.0.1-r2/work


Oh, and even if i set the system VM to 1.5, it still uses sun-jdk-1.6.
Strange! Look:

# java-config -L
The following VMs are available for generation-2:
*)      Sun JDK 1.5.0.13 [sun-jdk-1.5]
2)      Sun JDK 1.6.0.03 [sun-jdk-1.6]


Why that? I don't find any particular line in commons-daemon's ebuild
which specifies, that it should use JDK 1.6 instead of JDK 1.5.
The dependencies are >=virtual/jdk-1.4 and such.


Is this a bug, maybe?


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 249 bytes --]

Re: [gentoo-java] Re: JDK used for compiling

[William L. Thomson Jr.]

[-- Attachment #1: Type: text/plain, Size: 1090 bytes --]


On Sun, 2007-11-18 at 20:06 +0100, Sven Köhler wrote:
> >> I was conviced, that ebuilds always use the lowest JDK version possible.
> >> But it seems, that packages use the System VM - which is 1.6 in my case.
> >> But 1.5 is also installed.
> > 
> > Ebuilds compile source/target based on the lowest JDK version specified
> > in the ebuild. Which vm is used is controlled by by the ebuild and/or
> > the env. But most times that's restricted just to a version that
> > satisfied a virtual. Not specific vms.
> 
> Oh good! I was hoping to hear that.
> 
> But here, on my machine with default config, i'm compiling
> commons-daemon, and it says "using sun-jdk-1.6".

> Oh, and even if i set the system VM to 1.5, it still uses sun-jdk-1.6.
> Strange! Look:

SYSTEM VM != BUILD VM

> Why that? I don't find any particular line in commons-daemon's ebuild
> which specifies, that it should use JDK 1.6 instead of JDK 1.5.
> The dependencies are >=virtual/jdk-1.4 and such.

http://www.gentoo.org/doc/en/java.xml#doc_chap5

-- 
William L. Thomson Jr.
Gentoo/Java

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[gentoo-java] Re: JDK used for compiling

[Sven Köhler]

[-- Attachment #1: Type: text/plain, Size: 1180 bytes --]

> On Sun, 2007-11-18 at 20:06 +0100, Sven Köhler wrote:
>>>> I was conviced, that ebuilds always use the lowest JDK version possible.
>>>> But it seems, that packages use the System VM - which is 1.6 in my case.
>>>> But 1.5 is also installed.
>>> Ebuilds compile source/target based on the lowest JDK version specified
>>> in the ebuild. Which vm is used is controlled by by the ebuild and/or
>>> the env. But most times that's restricted just to a version that
>>> satisfied a virtual. Not specific vms.
>> Oh good! I was hoping to hear that.
>>
>> But here, on my machine with default config, i'm compiling
>> commons-daemon, and it says "using sun-jdk-1.6".
> 
>> Oh, and even if i set the system VM to 1.5, it still uses sun-jdk-1.6.
>> Strange! Look:
> 
> SYSTEM VM != BUILD VM
> 
>> Why that? I don't find any particular line in commons-daemon's ebuild
>> which specifies, that it should use JDK 1.6 instead of JDK 1.5.
>> The dependencies are >=virtual/jdk-1.4 and such.
> 
> http://www.gentoo.org/doc/en/java.xml#doc_chap5

OK, so i don't understand.

Why does commons-daemon use sun-jdk-1.6 to compile while sun-jdk-1.5* is
installed too?


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 249 bytes --]

Re: [gentoo-java] Re: JDK used for compiling

[Petteri Räty]

[-- Attachment #1: Type: text/plain, Size: 1694 bytes --]

Sven Köhler kirjoitti:
>> On Sun, 2007-11-18 at 20:06 +0100, Sven Köhler wrote:
>>>>> I was conviced, that ebuilds always use the lowest JDK version possible.
>>>>> But it seems, that packages use the System VM - which is 1.6 in my case.
>>>>> But 1.5 is also installed.
>>>> Ebuilds compile source/target based on the lowest JDK version specified
>>>> in the ebuild. Which vm is used is controlled by by the ebuild and/or
>>>> the env. But most times that's restricted just to a version that
>>>> satisfied a virtual. Not specific vms.
>>> Oh good! I was hoping to hear that.
>>>
>>> But here, on my machine with default config, i'm compiling
>>> commons-daemon, and it says "using sun-jdk-1.6".
>>> Oh, and even if i set the system VM to 1.5, it still uses sun-jdk-1.6.
>>> Strange! Look:
>> SYSTEM VM != BUILD VM
>>
>>> Why that? I don't find any particular line in commons-daemon's ebuild
>>> which specifies, that it should use JDK 1.6 instead of JDK 1.5.
>>> The dependencies are >=virtual/jdk-1.4 and such.
>> http://www.gentoo.org/doc/en/java.xml#doc_chap5
> 
> OK, so i don't understand.
> 
> Why does commons-daemon use sun-jdk-1.6 to compile while sun-jdk-1.5* is
> installed too?
> 

The default choice is the highest version of the default vm set for the
arch.

betelgeuse@pena /usr/share/java-config-2/config $ cat jdk-defaults.conf
# This files contain the default support jdk's
*= sun-jdk blackdown-jdk ibm-jdk-bin jrockit-jdk-bin

On x86 and amd64 this means that the highest version of sun-jdk
installed is used. But yeah I think it would be nicer to use the system
vm in case jdk.conf does not specify anything.

Regards,
Petteri


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [gentoo-java] Re: JDK used for compiling

[Bernhard Frauendienst]

Sorry, I forgot to CC the mailing list on my last response... Please
read now:

Sven Köhler schrieb:
>> Because selecting -target 1.5 is quite sufficient. I'm not sure what you
>> meant by overloading, but 1.4 bytecode compiled with a Java 6 JDK runs
>> fine on a Java1.4 JDK.
> 
> Oh i see!
> 
> Now i got you - and you ran into the old mistake. I know, that it is
> common practice to compile Java-Code with "-target X.Y" and to assume,
> that it automatically run's fine with a Java X.Y VM.
> 
> But i hope, that i can show to you, that this is not true. Assume you
> have the following code:
> 
> public class OverloadTest
> {
> 	public static void main(String[] args)
> 	{
> 		CharSequence sb1 = new StringBuffer("abc");
> 		StringBuffer sb2 = new StringBuffer();
> 		sb2.append(sb1);
> 		System.out.println(sb2);
> 	}
> }
> 
> 
> Compile it with JDK 1.5 or higher. Use "-target 1.4".
> 
> The generated class files run fine with JDK 1.5 or higher. But with JDK
> 1.4 you will get the following exception:
> 
> java.lang.NoSuchMethodError:
> java.lang.StringBuffer.append(Ljava/lang/CharSequence;)Ljava/lang/StringBuffer;
> 	at compat.overload.OverloadTest.main(OverloadTest.java:9)
> 
> 
> I hope, you see, why this error had to happen. The methode
> StringBuffer.append(CharSequence) is documented is marked to be @since
> 1.5 - but this is just a JavaDoc feature. Using "-target 1.4" does NOT
> avoid, that it's actually used within the Bytecode.
> 
> 
> I know, that you might not have seen this issue in real life. On the
> other hand, this kind of issues go unnoticed, until the code is actually
> executed because the NoSuchMethodError is thrown AT RUNTIME.
> 
> 


Such packages will then be marked with RDEPEND=">=virtual/jre-1.5" and
emerging them will pull in a JRE that supports the needed features (if
not already installed). I don't see a problem there.
-- 
gentoo-java@gentoo.org mailing list

Re: [gentoo-java] Re: JDK used for compiling

[Sven Köhler]

[-- Attachment #1: Type: text/plain, Size: 569 bytes --]

> Such packages will then be marked with RDEPEND=">=virtual/jre-1.5" and
> emerging them will pull in a JRE that supports the needed features (if
> not already installed). I don't see a problem there.

No, that's not right either.

The code in the example compiles with BOTH - JDK 1.4 and JDK 1.5.

But the generated bytecode is different:

- compiled with JDK 1.5, the method StringBuffer.append(CharSequence) is
called. (No matter, whether "-target 1.4" has been used, or not)
- compiled with JDK 1.4, the method StringBuffer.append(Object) is called.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 249 bytes --]

Re: [gentoo-java] Re: JDK used for compiling

[Sven Köhler]

[-- Attachment #1: Type: text/plain, Size: 319 bytes --]

> The default choice is the highest version of the default vm set for the
> arch.

Hmm. And the code is also compiled against the newest class library?

For the given reasons (see the example code) that's not a good idea.
Code compiled with a too new JDK might actually throw
NoSuchMethodErrors, for example.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 249 bytes --]

Re: [gentoo-java] Re: JDK used for compiling

[Petteri Räty]

[-- Attachment #1: Type: text/plain, Size: 520 bytes --]

Sven Köhler kirjoitti:
>> The default choice is the highest version of the default vm set for the
>> arch.
> 
> Hmm. And the code is also compiled against the newest class library?
> 
> For the given reasons (see the example code) that's not a good idea.
> Code compiled with a too new JDK might actually throw
> NoSuchMethodErrors, for example.
> 

People committing ebuilds and marking them stable should make sure that
it works with the lowest atom specified by the dependencies.

Regards,
Petteri


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [gentoo-java] Re: JDK used for compiling

[Sven Köhler]

[-- Attachment #1: Type: text/plain, Size: 1045 bytes --]

>>> The default choice is the highest version of the default vm set for the
>>> arch.
>> Hmm. And the code is also compiled against the newest class library?
>>
>> For the given reasons (see the example code) that's not a good idea.
>> Code compiled with a too new JDK might actually throw
>> NoSuchMethodErrors, for example.
>>
> 
> People committing ebuilds and marking them stable should make sure that
> it works with the lowest atom specified by the dependencies.

This is an undoable task, for two reasons:

1) First, things can break, after recompiling with a newer JDK version.
So adding a new JDK to the tree, would yield a HUGE wave of testing.
2) Second, the Exceptions only get thrown at runtime - so especially, if
such an issue is conditional (inside an if-statements) it maybe never
discovered.


Of course, as said in the other postings, the code always compiles fine.
It just isn't sure to assume that it runs with JDK X when it is compiled
against JDK Y - especially if or although Y is newer than X.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]