Hello, After the last change in the java compilation environment, I cannot compile any ebuild that uses java. The following message is displayed: * Enabling generation-2 compatibility ... * There was a problem determining which VM to use for Generation-1 * See the list of available VMs by using: java-config-1 -L * Then select on of those by using: java-config-1 -S <selected vm> * And once that is done, run: env-update && source /etc/profile * Then to continue the emerge: emerge --resume [ !! ] java-config-1 -L returns nothing. I have only one jdk on my system: dev-java/sun-jdk-1.5.0.07 Until now, I've managed to work with this jdk for all ebuilds. And ebuild that did not work, were patched and submitted to upstream/you. It seems that after the last change in the build environment, you require old jvm to exist side by side with the new one. Please don't require that, or tell me what I am doing wrong. How do I manage a system with only dev-java/sun-jdk-1.5.0.07 installed? Best Regards
"Enabling generation-2 compatibility" uses generation 1 build system, please install latest 1.4 JDK - it has both Generations available. It'll enable you to build generation 1 stuff (not yet migrated to newer system).
Thank, But I don't want to use the old jdk... I understand what you are trying to achieve... But I don't understand why changing the stuff that worked until now. In your terms, (I think), I want to compile all forcing generation 2...
This will be possible when ebuilds for those packages are ported to generation-2 eclasses, you can't "force generation 2" on them. If you are so interested, help porting :) But if you insist on building with 1.5 without -source and -target rewriting, using the old system, try removing the line JAVA_VM_NO_GENERATION1=true in the sun-jdk-1.5.0.07 ebuild and remerge it. This should make it visible to java-config-1 although it's strongly discouraged and not supported... if something breaks, the only correct fix is to port given ebuild to generation-2.
I hate to break it to you, but a 1.4 JDK _is_ required. You must have either patched around packages that didn't like to build with 1.5, or been fortunate enough to not run into any. I can assure you though, there certainly are packages that do not like 1.5, which is part of why it has been package.mask'd for so long. As far as 'changing something that worked already', it really didn't. If only you had seen all the bugs over these years :-X So, what you'll need to do is set the generation-1 system vm to a 1.4 JDK, ie java-config-1 -S blah. This will make sure 1.4 is used to compile all the packages currently in the tree. Then, add "*=sun-jdk-1.5" to /etc/java-config-2/build/jdk.conf . This will tell the new eclasses to use 1.5 whenever possible, but 1.4 will be used if there's a case where the package is known not to compile with 1.4. Note: packages won't be switched over until after the new stuff is unmasked.
(In reply to comment #4) > So, what you'll need to do is set the generation-1 system vm to a 1.4 JDK, ie > java-config-1 -S blah. This will make sure 1.4 is used to compile all the > packages currently in the tree. > > Then, add "*=sun-jdk-1.5" to /etc/java-config-2/build/jdk.conf . This will tell > the new eclasses to use 1.5 whenever possible, but 1.4 will be used if there's > a case where the package is known not to compile with 1.4. Note: packages won't > be switched over until after the new stuff is unmasked. OK... This seems right... Just that I don't think the jdk-1.4 should be required. Can you modify the build environment that it will try to compile using 1.5 (if I update the /etc/java-config-2/build/jdk as you suggest), and if package is known not to compile using 1.5 AND the 1.4 does not exist fail the build? This way we remain in previous status... If you have only 1.5, and you force 1.5 compilation, you will be able to compile only these packages that support 1.5.
(In reply to comment #3) > This will be possible when ebuilds for those packages are ported to > generation-2 eclasses, you can't "force generation 2" on them. If you are so > interested, help porting :) I do! Every java ebuild I run, works with 1.5. > But if you insist on building with 1.5 without > -source and -target rewriting, using the old system, try removing the line > JAVA_VM_NO_GENERATION1=true in the sun-jdk-1.5.0.07 ebuild and remerge it. Done! And it works!!!! > This > should make it visible to java-config-1 although it's strongly discouraged and > not supported... if something breaks, the only correct fix is to port given > ebuild to generation-2. OK. Will do. Thanks!
(In reply to comment #5) > (In reply to comment #4) > > OK... This seems right... Just that I don't think the jdk-1.4 should be > required. Well it won't be, when all packages are ported to new build system and you don't try to emerge package that can't use 1.5. > Can you modify the build environment that it will try to compile using 1.5 (if > I update the /etc/java-config-2/build/jdk as you suggest), and if package is > known not to compile using 1.5 AND the 1.4 does not exist fail the build? This should be possible (again, only with gen-2 ported packages). If you mask =virtual/jdk-1.4, it should result in unsatisfied dependency for package requiring 1.4. > This way we remain in previous status... If you have only 1.5, and you force > 1.5 compilation, you will be able to compile only these packages that support > 1.5. And why would you want to compile packages that are known to not support it? Just to watch it break? Why are you so desperately trying to have only 1.5?
(In reply to comment #3) > This > should make it visible to java-config-1 although it's strongly discouraged and > not supported... Just a stupid question... Why don't you support 1.5 to be visible to generation 1? The user can select the 1.4 or 1.5 as he prefers... (As until now...) Why did you decide to apply this invisibility since sun-jdk-1.5.0.07.ebuild and not applied it to sun-jdk-1.5.0.06-r2.ebuild? They both the same.
(In reply to comment #7) > And why would you want to compile packages that are known to not support it? > Just to watch it break? Why are you so desperately trying to have only 1.5? Because I think the right solution is to patch the packages to support 1.5, and not let it go... Just like you fix packages to use gcc 4.1... I think that your current approach will make it harder to maintain old packages over time, since they will not be ever fixed. Most of changes between the pre 1.5 and 1.5 are minor, and whenever I need a package that does not work with 1.5, after a few hours of work I have a patch for it.
(In reply to comment #8) > Just a stupid question... Why don't you support 1.5 to be visible to generation > 1? The user can select the 1.4 or 1.5 as he prefers... (As until now...) Because it's KNOWN to be broken, why support that? The fact that packages YOU tried didn't break is not enough. > Why did you decide to apply this invisibility since sun-jdk-1.5.0.07.ebuild and > not applied it to sun-jdk-1.5.0.06-r2.ebuild? They both the same. sun-jdk-1.5.0.07 is part of the system, temporarily package.masked for now, sun-jdk-1.5.0.06-r2 stays for users of the old system, until migration is done and then it will be removed I guess. (In reply to comment #9) > Because I think the right solution is to patch the packages to support 1.5, and > not let it go... Just like you fix packages to use gcc 4.1... That's not the same. JDK is not just a compiler, it has also runtime libraries that can change API with new version etc... Also what matters for Java performance is the VM used to run stuff (there the JIT optimizations are performed), not the VM used to build stuff, bytecode won't be that different... So being ricer about having latest build VM is nonsense. > I think that your current approach will make it harder to maintain old packages > over time, since they will not be ever fixed. Yeah and after fixing them for 1.5 we can start fixing them for 1.6, sure. > Most of changes between the pre 1.5 and 1.5 are minor, and whenever I need a > package that does not work with 1.5, after a few hours of work I have a patch > for it. Maybe you didn't try packages complex enough... And if you mean adding -source and -target to build.xml, that "patch" is what generation-2 system is about.
We do not have the manpower to patch every package to work with 1.5, untill upstream fixes it, and releases a new version, a 1.4 will be required to build them. So patch away, send it to the upstream devs, and we will be happy to include it.
(In reply to comment #10) > Maybe you didn't try packages complex enough... And if you mean adding -source > and -target to build.xml, that "patch" is what generation-2 system is about. No... I mean fixing the enum into enum1 etc... I don't like the -source -target when compile from source... And this is what gentoo all about...
Just another quick question... Please consider adding a use flag for java1.5 to add generation1, so that JAVA_VM_NO_GENERATION1=true will be set for people who wishes to have it available for generation one.
