[gentoo-java] How to predetermine if ebuilds will compile with 1.5?

[gentoo-java] How to predetermine if ebuilds will compile with 1.5?

[Peter]

Is it possible to predetermine if ebuilds already installed on my system
will work with java jdk 1.5?

peter@mars ~ # equery d jdk
[ Searching for packages depending on jdk... ]
dev-lang/swig-1.3.21
dev-libs/cyrus-sasl-2.1.21-r2
dev-util/subversion-1.2.3-r3
net-dns/libidn-0.5.15
sys-libs/db-4.2.52_p2-r1
sys-libs/db-3.2.9-r10
sys-libs/db-4.1.25_p1-r4

Now, with the exception of libidn, all just show virtual/jdk as a DEPEND.
libidn has >=virtual/jdk-1.4, which would seem to include 1.5 as well.

So, my question is, with this list, can I safely install and have as my
system vm 1.5 without any hassle? And, what would happen if I install a
1.5 JRE only alongside a 1.4 JDK?

TIA

-- 
Peter


-- 
gentoo-java@gentoo.org mailing list

Re: [gentoo-java] How to predetermine if ebuilds will compile with 1.5?

[Caster]

Peter wrote:
> Is it possible to predetermine if ebuilds already installed on my system
> will work with java jdk 1.5?
> 
> peter@mars ~ # equery d jdk
> [ Searching for packages depending on jdk... ]
> dev-lang/swig-1.3.21
> dev-libs/cyrus-sasl-2.1.21-r2
> dev-util/subversion-1.2.3-r3
> net-dns/libidn-0.5.15
> sys-libs/db-4.2.52_p2-r1
> sys-libs/db-3.2.9-r10
> sys-libs/db-4.1.25_p1-r4
> 
> Now, with the exception of libidn, all just show virtual/jdk as a DEPEND.
> libidn has >=virtual/jdk-1.4, which would seem to include 1.5 as well.
> 
> So, my question is, with this list, can I safely install and have as my
> system vm 1.5 without any hassle? 

If you follow the migration overlay guide, yes.

> And, what would happen if I install a
> 1.5 JRE only alongside a 1.4 JDK?
> 
> TIA
> 

JRE can't be used as system VM with generation-1, and won't be used for
building with generation-2, so it won't make problems.

Caster
-- 
gentoo-java@gentoo.org mailing list

[gentoo-java] Re: How to predetermine if ebuilds will compile with 1.5?

[Peter]

On Sun, 04 Jun 2006 22:16:18 +0200, Caster wrote:

> Peter wrote:
>> Is it possible to predetermine if ebuilds already installed on my system
>> will work with java jdk 1.5?
>> 
snip...
>> 
>> So, my question is, with this list, can I safely install and have as my
>> system vm 1.5 without any hassle? 
> 
> If you follow the migration overlay guide, yes.
> 

Actually, what I was asking was _would_ it work without the overlay? I
mean, if the ebuild is marked =virtual/jdk-1.4, then I could understand a
potential for trouble. But when it's just marked (whether by laziness or
whether it's correct) virtual/jdk, it'd be nice to know whether 1.5 could
work.

Anyway, since I don't develop in Java, this is really a non-issue for me
-- more an academic question and a desire to keep current. I _am_ going to
keep fooling with having a 1.5 jre with a 1.4 jdk and see how that works
as described in my other post. Thx for the replies!

-- 
Peter


-- 
gentoo-java@gentoo.org mailing list

Re: [gentoo-java] Re: How to predetermine if ebuilds will compile with 1.5?

[Joshua Nichols]

Peter wrote:
> On Sun, 04 Jun 2006 22:16:18 +0200, Caster wrote:
>
>   
>> Peter wrote:
>>     
>>> Is it possible to predetermine if ebuilds already installed on my system
>>> will work with java jdk 1.5?
>>>
>>>       
> snip...
>   
>>> So, my question is, with this list, can I safely install and have as my
>>> system vm 1.5 without any hassle? 
>>>       
>> If you follow the migration overlay guide, yes.
>>
>>     
>
> Actually, what I was asking was _would_ it work without the overlay? I
> mean, if the ebuild is marked =virtual/jdk-1.4, then I could understand a
> potential for trouble. But when it's just marked (whether by laziness or
> whether it's correct) virtual/jdk, it'd be nice to know whether 1.5 could
> work.
>   
Even if all the ebuilds had the right jdk  version in the DEPEND, it
still wouldn't quite help. This is mostly because the current build
system isn't smart enough to switch to an appropriate JDK at build time,
and because you could still have a 1.4 JDK installed, but your 1.5 JDK
is set as the system VM. Fortunately, the new system (which is coming
soon (TM)) addresses these problems and more.
> Anyway, since I don't develop in Java, this is really a non-issue for me
> -- more an academic question and a desire to keep current. I _am_ going to
> keep fooling with having a 1.5 jre with a 1.4 jdk and see how that works
> as described in my other post. Thx for the replies!
>
>   

- Josh
-- 
gentoo-java@gentoo.org mailing list

Re: [gentoo-java] Re: How to predetermine if ebuilds will compile with 1.5?

[Caster]

> Actually, what I was asking was _would_ it work without the overlay? I
> mean, if the ebuild is marked =virtual/jdk-1.4, then I could understand a
> potential for trouble. But when it's just marked (whether by laziness or
> whether it's correct) virtual/jdk, it'd be nice to know whether 1.5 could
> work.

No idea, how much the dependencies correspond with "would/wouldn't
work". I wouldn't bet on that. The question, why would you so
desperately try to have 1.5 JDK as (generation-1 without migration
overlay) system vm? It can only break things, and gain you nothing.
Somebody correct me if I'm wrong, but the bytecode compiled will be the
same no matter which JDK you use. Any optimisations are done with
run-time JIT compiling, and depends on the VM running the bytecode
(which can be different from the VM used to compile). So, without
migration overlay, you should best follow the java 1.5 faq, have 1.4 as
sytem vm and use whatever vm as user vm.

Caster
-- 
gentoo-java@gentoo.org mailing list

Re: [gentoo-java] Re: How to predetermine if ebuilds will compile with 1.5?

[David Herron]

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


er... Caster, the bytecode does vary based on the compiler.  And the 
class file format has varied a small amount from release to release with 
the 1.5 class file format being the most different.

This is, as I understand it, the crux of the problem you guys are seeing 
with adopting 1.5 ... yes?

- David


Caster wrote:
>> Actually, what I was asking was _would_ it work without the overlay? I
>> mean, if the ebuild is marked =virtual/jdk-1.4, then I could understand a
>> potential for trouble. But when it's just marked (whether by laziness or
>> whether it's correct) virtual/jdk, it'd be nice to know whether 1.5 could
>> work.
>>     
>
> No idea, how much the dependencies correspond with "would/wouldn't
> work". I wouldn't bet on that. The question, why would you so
> desperately try to have 1.5 JDK as (generation-1 without migration
> overlay) system vm? It can only break things, and gain you nothing.
> Somebody correct me if I'm wrong, but the bytecode compiled will be the
> same no matter which JDK you use. Any optimisations are done with
> run-time JIT compiling, and depends on the VM running the bytecode
> (which can be different from the VM used to compile). So, without
> migration overlay, you should best follow the java 1.5 faq, have 1.4 as
> sytem vm and use whatever vm as user vm.
>
> Caster
>   

[-- Attachment #2: Type: text/html, Size: 1750 bytes --]

Re: [gentoo-java] Re: How to predetermine if ebuilds will compile with 1.5?

[Wiktor Wandachowicz]

> This is, as I understand it, the crux of the problem you guys
> are seeing with adopting 1.5 ... yes?
>
>  - David

How about reading the detailed list of reasons here?

https://projects.gentooexperimental.org/expj/wiki/Old_system_new_system_and_why

HTH,
Wiktor
-- 
gentoo-java@gentoo.org mailing list

Re: [gentoo-java] Re: How to predetermine if ebuilds will compile with 1.5?

[Greg Tassone]

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

On Mon, 2006-06-05 at 16:27 +0200, Caster wrote:
> ...
> Somebody correct me if I'm wrong, but the bytecode compiled will be the
> same no matter which JDK you use. Any optimisations are done with
> run-time JIT compiling, and depends on the VM running the bytecode
> (which can be different from the VM used to compile).

I think this statement is a little too broad to be considered correct.
The compiler can (and often does) make changes to the resulting binaries
that may be VM-level specific (e.g., targeted for a 1.5 VM).  Consider
the "-target" argument for javac, for example, which "Allow[s] javac to
use 1.5 specific features in the libraries and virtual
machine" (http://java.sun.com/j2se/1.5.0/docs/relnotes/features.html ).

For more information see the following in the section labeled
"Cross-Compilation Options":

http://java.sun.com/j2se/1.5.0/docs/tooldocs/solaris/javac.html


I also found some interesting information about different bytecode
versions here:
http://alumnus.caltech.edu/~leif/opensource/bcver/BcVerTask.html

More information can be found in Sun articles referenced there.

Finally, it looks like some information appears in the following JSR
abstract:
http://www.jcp.org/en/jsr/detail?id=202

~ Greg


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

Re: [gentoo-java] Re: How to predetermine if ebuilds will compile with 1.5?

[Caster]

Greg Tassone wrote:
> I think this statement is a little too broad to be considered correct.
> The compiler can (and often does) make changes to the resulting binaries
> that may be VM-level specific (e.g., targeted for a 1.5 VM).  Consider
> the "-target" argument for javac, for example, which "Allow[s] javac to
> use 1.5 specific features in the libraries and virtual
> machine" (http://java.sun.com/j2se/1.5.0/docs/relnotes/features.html ).
>
David Herron wrote:
> 
> er... Caster, the bytecode does vary based on the compiler.  And the
> class file format has varied a small amount from release to release with
> the 1.5 class file format being the most different.
> 
> This is, as I understand it, the crux of the problem you guys are seeing
> with adopting 1.5 ... yes?
> 

Sorry, I wasn't clear enough. I didn't mean the class file format which
is indeed different and causes problems. I was trying to ask if there
are any (the compiled bytecode performance?) gains of using 1.5 compiler
for 1.4 source (without specifying --source and --target 1.4). This
source won't use any 1.5 specific features, but you say the bytecode
still can somehow?

Caster

-- 
gentoo-java@gentoo.org mailing list

Re: [gentoo-java] Re: How to predetermine if ebuilds will compile with 1.5?

[David Herron]

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

Okay, that helps.

I'm not a compiler expert but here's a couple factoids:  1) we're always 
working to improve performance, 2) the compiler team is always working 
on improving the compiler (fix bugs etc), 3) the generated byte codes 
can either exhibit certain bugs or performance gains/losses ... hence, 
hence I expect/assume the byte codes output to vary somewhat from 
release to relase. 

I can't say how much or what specifically that would be.

- David


Caster wrote:
> Greg Tassone wrote:
>   
>> I think this statement is a little too broad to be considered correct.
>> The compiler can (and often does) make changes to the resulting binaries
>> that may be VM-level specific (e.g., targeted for a 1.5 VM).  Consider
>> the "-target" argument for javac, for example, which "Allow[s] javac to
>> use 1.5 specific features in the libraries and virtual
>> machine" (http://java.sun.com/j2se/1.5.0/docs/relnotes/features.html ).
> David Herron wrote:
>   
>> er... Caster, the bytecode does vary based on the compiler.  And the
>> class file format has varied a small amount from release to release with
>> the 1.5 class file format being the most different.
>>
>> This is, as I understand it, the crux of the problem you guys are seeing
>> with adopting 1.5 ... yes?
>
> Sorry, I wasn't clear enough. I didn't mean the class file format which
> is indeed different and causes problems. I was trying to ask if there
> are any (the compiled bytecode performance?) gains of using 1.5 compiler
> for 1.4 source (without specifying --source and --target 1.4). This
> source won't use any 1.5 specific features, but you say the bytecode
> still can somehow?
>
> Caster
>
>   

[-- Attachment #2: Type: text/html, Size: 2313 bytes --]

Re: [gentoo-java] Re: How to predetermine if ebuilds will compile with 1.5?

[Calvin Austin]

David Herron wrote:

> Okay, that helps.
>
> I'm not a compiler expert but here's a couple factoids:  1) we're 
> always working to improve performance, 2) the compiler team is always 
> working on improving the compiler (fix bugs etc), 3) the generated 
> byte codes can either exhibit certain bugs or performance gains/losses 
> ... hence, hence I expect/assume the byte codes output to vary 
> somewhat from release to relase. 
>
> I can't say how much or what specifically that would be.
>
> - David
>
>
> Caster wrote:
>
>>Greg Tassone wrote:
>>  
>>
>>>I think this statement is a little too broad to be considered correct.
>>>The compiler can (and often does) make changes to the resulting binaries
>>>that may be VM-level specific (e.g., targeted for a 1.5 VM).  Consider
>>>the "-target" argument for javac, for example, which "Allow[s] javac to
>>>use 1.5 specific features in the libraries and virtual
>>>machine" (http://java.sun.com/j2se/1.5.0/docs/relnotes/features.html ).
>>>
>>David Herron wrote:
>>  
>>
>>>er... Caster, the bytecode does vary based on the compiler.  And the
>>>class file format has varied a small amount from release to release with
>>>the 1.5 class file format being the most different.
>>>
>>>This is, as I understand it, the crux of the problem you guys are seeing
>>>with adopting 1.5 ... yes?
>>>
>>
>>Sorry, I wasn't clear enough. I didn't mean the class file format which
>>is indeed different and causes problems. I was trying to ask if there
>>are any (the compiled bytecode performance?) gains of using 1.5 compiler
>>for 1.4 source (without specifying --source and --target 1.4). This
>>source won't use any 1.5 specific features, but you say the bytecode
>>still can somehow?
>>
>>Caster
>>
>>  
>>
This seems like a long time ago to me, but originally there were major 
changes planned for the class format in 5.0 that fell through and 
ultimately resulted in very minor changes to the classfile format. Most 
of the language changes used existing compatible mechanisms to extend 
the classfile (attributes) or were essentially compiler generated for you.

So in normal use the Java 5 bytecode for vanilla 1.4  source (which is 5 
compliant) isn't going to make any difference compared to the jvm 
improvements like class data sharing in the sun jvm or jvm/jdk class 
libraries

regards
calvin

-- 
gentoo-java@gentoo.org mailing list