dev-java/netbeans-harness-8.2 fails to emerge on my system: bootstrap: BUILD FAILED /var/tmp/portage/dev-java/netbeans-harness-8.2/work/nbbuild/build.xml:65: You ne ed to run on JDK 8+ to build NetBeans; java.home=/usr/lib64/icedtea7/jre GENTOO_VM=icedtea-7 CLASSPATH="" JAVA_HOME="/usr/lib64/icedtea7" JAVACFLAGS="-source 1.7 -target 1.7" COMPILER="javac" The ebuild claims DEPEND=">=virtual/jdk-1.7 … RDEPEND="|| ( virtual/jdk:1.7 virtual/jdk:1.8 ) … I have “*=icedtea-7” in my /etc/java-config-2/build/jdk.conf, but if the package had contained a clear dependency on 1.8, then depend-java-query would have selected a version 8 jdk instead.
This is because using || ( ) with JVM virtuals doesn't work. It confuses the eclasses. I have repeatedly told people to stop doing this and want to add a repoman check to prevent it. fordfrog?
(In reply to Martin von Gagern from comment #0) > I have “*=icedtea-7” in my /etc/java-config-2/build/jdk.conf, but if the > package had contained a clear dependency on 1.8, then depend-java-query > would have selected a version 8 jdk instead. Out of interest, why are you using jdk.conf? I was thinking of getting rid of it because with all supported JVMs being based off OpenJDK and with a general push towards using the latest Java vesions, it just seems like unnecessary complexity these days. You could set you system VM to icedtea-7 instead. If you prefer to run with Java 8 then you could set your user VM to icedtea-8.
(In reply to James Le Cuirot from comment #1) > This is because using || ( ) with JVM virtuals doesn't work. It confuses the > eclasses. I thought java-pkg_switch-vm would use DEPEND not RDEPEND to select the VM. So in my opinion the real problem is the incorrect dependency here. (In reply to James Le Cuirot from comment #2) > Out of interest, why are you using jdk.conf? For the same reason I am using ~ARCH: to test things. If the ebuild claims to compile with version >=x, then I want to compile it with version x, not only with respect to the language features (which -source should cover), but also with respect to the boot class path. I've repeatedly found packages which had incorrect min dependencies there, using API that got introduced more recently than what the declared dependency suggested. Catching those during testing means they won't hit people in production. I'd say this report here is just another case of why I'd prefer to use older JDK during compilation. I don't know what Java 8 API this package is using, but I assume they have a reason for failing on < 8, so the dependencies are wrong.
(In reply to Martin von Gagern from comment #3) > (In reply to James Le Cuirot from comment #1) > > This is because using || ( ) with JVM virtuals doesn't work. It confuses the > > eclasses. > > I thought java-pkg_switch-vm would use DEPEND not RDEPEND to select the VM. > So in my opinion the real problem is the incorrect dependency here. Yes, sorry, you're right. Not awake yet. :) RDEPEND should also be fixed though. > (In reply to James Le Cuirot from comment #2) > > Out of interest, why are you using jdk.conf? > > For the same reason I am using ~ARCH: to test things. That is appreciated. toralf was building with Java 6 while it was still around (using system VM though, I think) but it was resulting in lots of bugs being filed when we were about to get rid of it. I did some more work this week to get rid of Java 7 too so hopefully that's not far off now. There is another issue that I sometimes mention. While it is obviously important to get the Java version right for the ebuild itself, you also to have to be wary of revdeps. If some library changes RDEPEND=">=virtual/jdk-1.7" to RDEPEND=">=virtual/jdk-1.8" then any revdeps that are supposed to build or run under Java 7 will break. This is hard to keep track of and I haven't found a technical solution (subslots aren't flexible enough) so I'm pleading for others to always put the minimum possible RDEPEND for what we have in the tree (7 currently) and always test with every version. To make this less of a burden, I'm trying to keep the number of Java versions in the tree to a minimum, hence the planned removal of 7. Java 9 should make this easier.
(In reply to James Le Cuirot from comment #4) > There is another issue that I sometimes mention. While it is obviously > important to get the Java version right for the ebuild itself, you also to > have to be wary of revdeps. If some library changes > RDEPEND=">=virtual/jdk-1.7" to RDEPEND=">=virtual/jdk-1.8" then any revdeps > that are supposed to build or run under Java 7 will break. I'm using latest JDK to RUN my Java code, it's just at compile-time that I prefer using older versions. I would assume that via transitive dependencies, if foo has RDEPEND=">=virtual/jre-1.7 bar" and bar has RDEPEND=">=virtual/jre-1.8" then the user has to have a jdk-1.8 installed, right? The way I see it, the more important problem is that if some dependency will start to compile with -target=1.8, then the 1.7 depending package will suddenly fail to compile against this dependency because the 1.7 jdk can't read the 1.8 class file format. Which is what bit me a number of times, as documented in bug 161622, and which eventually caused me to abandon my 1.5 and 1.6 compilers. > To make this less of a burden, I'm trying to keep the > number of Java versions in the tree to a minimum, hence the planned removal > of 7. Java 9 should make this easier. I can understand that, even though it means that for my own projects I either need my self-installed versions of ancient JDKs, or at least their boot class paths, so I can verify that my own code actually is satisfied by its advertised version requirements.
(In reply to Martin von Gagern from comment #5) > (In reply to James Le Cuirot from comment #4) > > There is another issue that I sometimes mention. While it is obviously > > important to get the Java version right for the ebuild itself, you also to > > have to be wary of revdeps. If some library changes > > RDEPEND=">=virtual/jdk-1.7" to RDEPEND=">=virtual/jdk-1.8" then any revdeps > > that are supposed to build or run under Java 7 will break. > > I'm using latest JDK to RUN my Java code, it's just at compile-time that I > prefer using older versions. I would assume that via transitive > dependencies, if foo has RDEPEND=">=virtual/jre-1.7 bar" and bar has > RDEPEND=">=virtual/jre-1.8" then the user has to have a jdk-1.8 installed, > right? > > The way I see it, the more important problem is that if some dependency will > start to compile with -target=1.8, then the 1.7 depending package will > suddenly fail to compile against this dependency because the 1.7 jdk can't > read the 1.8 class file format. Which is what bit me a number of times, as > documented in bug 161622, and which eventually caused me to abandon my 1.5 > and 1.6 compilers. That's exactly the problem I'm describing. I should have mentioned -target. RDEPEND is relevant because that's what determines the -target value.
(In reply to James Le Cuirot from comment #1) > This is because using || ( ) with JVM virtuals doesn't work. It confuses the > eclasses. I have repeatedly told people to stop doing this and want to add a > repoman check to prevent it. fordfrog? there is also another repoman check that complains about jdk slots not being specified so that is the reason i did this change. idk what is the correct fix then...
(In reply to Miroslav Šulc from comment #7) > (In reply to James Le Cuirot from comment #1) > > This is because using || ( ) with JVM virtuals doesn't work. It confuses the > > eclasses. I have repeatedly told people to stop doing this and want to add a > > repoman check to prevent it. fordfrog? > > there is also another repoman check that complains about jdk slots not being > specified so that is the reason i did this change. idk what is the correct > fix then... That is true and I agree that's not helping. It's happening because you have virtual/jdk in RDEPEND, which I'm guessing is correct in this case. repoman would normally complain about all our >=virtual entries but it has explicit overrides to ignore virtual/jdk in DEPEND and virtual/jdk in RDEPEND. I wanted to find out why this override was added instead of telling us to use :* but the people behind it are long gone. Until I get repoman updated, I would just ignore the warning or put >=virtual/jdk-1.8:* instead.
(In reply to James Le Cuirot from comment #8) > explicit overrides to ignore virtual/jdk in DEPEND and virtual/jdk in RDEPEND Sorry, of course I meant virtual/jre in RDEPEND.
i've restricted both depend and rdepend on all netbeans 8.2 ebuilds to jdk 1.8. there might be issues for compilation with jdk 1.9 so it's better this way and 1.7 seems to be already unsupported for netbeans 8.2 so i removed that. for runtime it's probably safer for now to restrict netbeans to jdk 1.8 too and later 1.9 can be added if there is no issue.
(In reply to Miroslav Šulc from comment #10) > i've restricted both depend and rdepend on all netbeans 8.2 ebuilds to jdk > 1.8. there might be issues for compilation with jdk 1.9 so it's better this > way and 1.7 seems to be already unsupported for netbeans 8.2 so i removed > that. for runtime it's probably safer for now to restrict netbeans to jdk > 1.8 too and later 1.9 can be added if there is no issue. You could say that for just about any Java package in the tree. We've never taken the pessimistic approach before and while it's never been perfect, the vast majority of packages have been fine. I do know that Java 9 is different though so... I suspect it'll be fine at run time, Java has a history of being extremely backwards-compatible in that regard. At build time, there will probably be issues unless we use the new --release option in the eclasses, which is effectively the -source -target -bootclasspath options combined. For this to work, we'll need to find a way to package the rt.jar files from older releases. Having the end user build those from source is probably more hassle than it's worth so I may borrow the icedtea-bin tarballs.
(In reply to James Le Cuirot from comment #11) netbeans used -Dpermit.jdk8.builds=true previously to allow building of netbeans on jdk 1.8 but it was (building) unsupported. i did not check the build system for the same for jdk 1.9 but i want to be safe in this case as the history was so. so that's for the building part. as for the runtime, i could as well leave it unrestricted upwards but netbeans is imo more fragile than other apps wrt jdk versions so i'd rather stay safe until i do some tests to be sure it's ok.
That's fair enough, thanks.
Miroslav, you have a typo in https://gitweb.gentoo.org/repo/gentoo.git/commit/dev-java/netbeans-enterprise/netbeans-enterprise-8.2.ebuild?id=92f2f4f84639b691335dda01c0127212296fee9e: CDEPEnd instead of CDEPEND. This leads to GENTOO_VM= CLASSPATH="" JAVA_HOME="" JAVACFLAGS="" COMPILER="javac"
(In reply to Martin von Gagern from comment #14) > Miroslav, you have a typo in > https://gitweb.gentoo.org/repo/gentoo.git/commit/dev-java/netbeans- > enterprise/netbeans-enterprise-8.2. > ebuild?id=92f2f4f84639b691335dda01c0127212296fee9e: CDEPEnd instead of > CDEPEND. This leads to > > GENTOO_VM= CLASSPATH="" JAVA_HOME="" > JAVACFLAGS="" COMPILER="javac" thanks. fixed.
