We'll have to move to Java 8 in Fedora sooner or later. I did some testing of Maven and Ant stacks regards that and most of things seem to be working well, except for javadoc.
Java 8 has a very strict parser for javadocs, and any error or nuisance causes build failure -- almost all packages fail to build with Java 8 due to various errors in javadocs.
In some cases we can probably fix javadoc problems and forward patches upstream, but we have many legacy packages for which we can't push any patches upstream. I don't see how in reality we can fix all packages we have. The only good solution I can think of is disabling javadocs.
My proposal is making javadoc subpackages optional, which means that for some Java packages they could be disabled depending on maintainer decision. Legacy packages with dead upstreams would be able to disable javadocs (no one should try to develop anything depending on such packages, so that's perfectly OK IMO). For packages which have active upstreams we can fix javadocs and forward patches, or disable javadoc packages, report the problem upstream and wait for them to fix it.
The main reasons for making javadoc optional are:
1. Java 8 problems, as explained above.
2. Storage. I took a typical set of 265 Java source packages. When all binary RPMs were installed they took about 1.5 GB of storage. Javadocs themselves take 1.3 GB, everything else is just around 250 MB.
3. Build time. Javadoc generation usually takes more time than compilation. Javadoc tool needs a lot of memory, an can be very slow, especially on ARM or POWER where there is no JIT. There are cases where javadoc generation accounts for more than 90 % of build time.
I am looking to hear your opinion on this matter (positive or negative) and if there is some positive feedback then I would like to submit this proposal as a system-wide change for Fedora 21.
positive
On 14-02-20 1:09 PM, Mikolaj Izdebski wrote:
We'll have to move to Java 8 in Fedora sooner or later. I did some testing of Maven and Ant stacks regards that and most of things seem to be working well, except for javadoc.
Java 8 has a very strict parser for javadocs, and any error or nuisance causes build failure -- almost all packages fail to build with Java 8 due to various errors in javadocs.
In some cases we can probably fix javadoc problems and forward patches upstream, but we have many legacy packages for which we can't push any patches upstream. I don't see how in reality we can fix all packages we have. The only good solution I can think of is disabling javadocs.
My proposal is making javadoc subpackages optional, which means that for some Java packages they could be disabled depending on maintainer decision. Legacy packages with dead upstreams would be able to disable javadocs (no one should try to develop anything depending on such packages, so that's perfectly OK IMO). For packages which have active upstreams we can fix javadocs and forward patches, or disable javadoc packages, report the problem upstream and wait for them to fix it.
The main reasons for making javadoc optional are:
Java 8 problems, as explained above.
Storage. I took a typical set of 265 Java source packages. When
all binary RPMs were installed they took about 1.5 GB of storage. Javadocs themselves take 1.3 GB, everything else is just around 250 MB.
- Build time. Javadoc generation usually takes more time than
compilation. Javadoc tool needs a lot of memory, an can be very slow, especially on ARM or POWER where there is no JIT. There are cases where javadoc generation accounts for more than 90 % of build time.
I am looking to hear your opinion on this matter (positive or negative) and if there is some positive feedback then I would like to submit this proposal as a system-wide change for Fedora 21.
+1 from me too. Jumping to Java 8 is way more valuable.
Alexander Kurtakov Red Hat Eclipse team
----- Original Message -----
From: "Mikolaj Izdebski" mizdebsk@redhat.com To: "Fedora Java Development List" java-devel@lists.fedoraproject.org Sent: Thursday, February 20, 2014 8:09:00 PM Subject: [fedora-java] Javadoc packages
We'll have to move to Java 8 in Fedora sooner or later. I did some testing of Maven and Ant stacks regards that and most of things seem to be working well, except for javadoc.
Java 8 has a very strict parser for javadocs, and any error or nuisance causes build failure -- almost all packages fail to build with Java 8 due to various errors in javadocs.
In some cases we can probably fix javadoc problems and forward patches upstream, but we have many legacy packages for which we can't push any patches upstream. I don't see how in reality we can fix all packages we have. The only good solution I can think of is disabling javadocs.
My proposal is making javadoc subpackages optional, which means that for some Java packages they could be disabled depending on maintainer decision. Legacy packages with dead upstreams would be able to disable javadocs (no one should try to develop anything depending on such packages, so that's perfectly OK IMO). For packages which have active upstreams we can fix javadocs and forward patches, or disable javadoc packages, report the problem upstream and wait for them to fix it.
The main reasons for making javadoc optional are:
Java 8 problems, as explained above.
Storage. I took a typical set of 265 Java source packages. When
all binary RPMs were installed they took about 1.5 GB of storage. Javadocs themselves take 1.3 GB, everything else is just around 250 MB.
- Build time. Javadoc generation usually takes more time than
compilation. Javadoc tool needs a lot of memory, an can be very slow, especially on ARM or POWER where there is no JIT. There are cases where javadoc generation accounts for more than 90 % of build time.
I am looking to hear your opinion on this matter (positive or negative) and if there is some positive feedback then I would like to submit this proposal as a system-wide change for Fedora 21.
-- Mikolaj Izdebski -- java-devel mailing list java-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/java-devel
On Thu, Feb 20, 2014 at 7:09 PM, Mikolaj Izdebski mizdebsk@redhat.comwrote:
I am looking to hear your opinion on this matter (positive or negative) and if there is some positive feedback then I would like to submit this proposal as a system-wide change for Fedora 21.
positive
* Mikolaj Izdebski mizdebsk@redhat.com [2014-02-20 13:09]:
My proposal is making javadoc subpackages optional, which means that for some Java packages they could be disabled depending on maintainer decision.
So the maintainer gets to decide how much work that is for an individual package and if javadocs are worth building for that package? Sounds fine to me.
As far as my packages go, given how much work I had to put in to get just one of them to build javadocs, I think I will be dropping javadocs for most of mine :)
Thanks, Omair
On 02/20/2014 07:09 PM, Mikolaj Izdebski wrote:
Java 8 has a very strict parser for javadocs, and any error or nuisance causes build failure -- almost all packages fail to build with Java 8 due to various errors in javadocs.
In some cases we can probably fix javadoc problems and forward patches upstream, but we have many legacy packages for which we can't push any patches upstream. I don't see how in reality we can fix all packages we have. The only good solution I can think of is disabling javadocs.
+1 I agree that making javadocs optional is a good thing and way to go.
I did some testing with Java 8 and maven-javadoc-plugin and it seems like disabling doclint (-Dadditionalparam=-Xdoclint:none) can solve the problem for people who wants to keep javadoc subpackages as they are now and don't want to spend time fixing them.
Michal
My proposal is making javadoc subpackages optional, which means that for some Java packages they could be disabled depending on maintainer decision. Legacy packages with dead upstreams would be able to disable javadocs (no one should try to develop anything depending on such packages, so that's perfectly OK IMO). For packages which have active upstreams we can fix javadocs and forward patches, or disable javadoc packages, report the problem upstream and wait for them to fix it.
The main reasons for making javadoc optional are:
Java 8 problems, as explained above.
Storage. I took a typical set of 265 Java source packages. When
all binary RPMs were installed they took about 1.5 GB of storage. Javadocs themselves take 1.3 GB, everything else is just around 250 MB.
- Build time. Javadoc generation usually takes more time than
compilation. Javadoc tool needs a lot of memory, an can be very slow, especially on ARM or POWER where there is no JIT. There are cases where javadoc generation accounts for more than 90 % of build time.
I am looking to hear your opinion on this matter (positive or negative) and if there is some positive feedback then I would like to submit this proposal as a system-wide change for Fedora 21.
+1
javadoc on ARM is crushing.
So will new reviews require a detailed comment, much like some test disablement currently? i.e., a SHOULD step
\Pete
On 02/20/2014 01:09 PM, Mikolaj Izdebski wrote:
We'll have to move to Java 8 in Fedora sooner or later. I did some testing of Maven and Ant stacks regards that and most of things seem to be working well, except for javadoc.
Java 8 has a very strict parser for javadocs, and any error or nuisance causes build failure -- almost all packages fail to build with Java 8 due to various errors in javadocs.
In some cases we can probably fix javadoc problems and forward patches upstream, but we have many legacy packages for which we can't push any patches upstream. I don't see how in reality we can fix all packages we have. The only good solution I can think of is disabling javadocs.
My proposal is making javadoc subpackages optional, which means that for some Java packages they could be disabled depending on maintainer decision. Legacy packages with dead upstreams would be able to disable javadocs (no one should try to develop anything depending on such packages, so that's perfectly OK IMO). For packages which have active upstreams we can fix javadocs and forward patches, or disable javadoc packages, report the problem upstream and wait for them to fix it.
The main reasons for making javadoc optional are:
Java 8 problems, as explained above.
Storage. I took a typical set of 265 Java source packages. When
all binary RPMs were installed they took about 1.5 GB of storage. Javadocs themselves take 1.3 GB, everything else is just around 250 MB.
- Build time. Javadoc generation usually takes more time than
compilation. Javadoc tool needs a lot of memory, an can be very slow, especially on ARM or POWER where there is no JIT. There are cases where javadoc generation accounts for more than 90 % of build time.
I am looking to hear your opinion on this matter (positive or negative) and if there is some positive feedback then I would like to submit this proposal as a system-wide change for Fedora 21.
* Mikolaj Izdebski mizdebsk@redhat.com [2014-02-20 13:09]:
We'll have to move to Java 8 in Fedora sooner or later. I did some testing of Maven and Ant stacks regards that and most of things seem to be working well, except for javadoc.
Java 8 has a very strict parser for javadocs, and any error or nuisance causes build failure -- almost all packages fail to build with Java 8 due to various errors in javadocs.
In some cases we can probably fix javadoc problems and forward patches upstream, but we have many legacy packages for which we can't push any patches upstream. I don't see how in reality we can fix all packages we have. The only good solution I can think of is disabling javadocs.
My proposal is making javadoc subpackages optional, which means that for some Java packages they could be disabled depending on maintainer decision. Legacy packages with dead upstreams would be able to disable javadocs (no one should try to develop anything depending on such packages, so that's perfectly OK IMO). For packages which have active upstreams we can fix javadocs and forward patches, or disable javadoc packages, report the problem upstream and wait for them to fix it.
We (Red Hat's OpenJDK/Java team) have been talking about this for the past few days as well. One other solution that comes to mind is to disable doclint in the default OpenJDK8 build for Fedora.
This is really an issue that should be fixed in the upstream packages, and disabling javadocs is just masking the problem. So given that, how about we disable doclint for a year and give upstreams time to fix it? Whatever continues to fail after that can then be fixed either in our packages or javadocs for those can be disabled.
Thoughts?
Deepak
The main reasons for making javadoc optional are:
Java 8 problems, as explained above.
Storage. I took a typical set of 265 Java source packages. When
all binary RPMs were installed they took about 1.5 GB of storage. Javadocs themselves take 1.3 GB, everything else is just around 250 MB.
- Build time. Javadoc generation usually takes more time than
compilation. Javadoc tool needs a lot of memory, an can be very slow, especially on ARM or POWER where there is no JIT. There are cases where javadoc generation accounts for more than 90 % of build time.
I am looking to hear your opinion on this matter (positive or negative) and if there is some positive feedback then I would like to submit this proposal as a system-wide change for Fedora 21.
-- Mikolaj Izdebski -- java-devel mailing list java-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/java-devel
* Deepak Bhole dbhole@redhat.com [2014-02-26 13:12]:
We (Red Hat's OpenJDK/Java team) have been talking about this for the past few days as well. One other solution that comes to mind is to disable doclint in the default OpenJDK8 build for Fedora.
I have built a new version of java-1.8.0-openjdk that disables doclint: http://koji.fedoraproject.org/koji/taskinfo?taskID=6660421
It should be available in rawhide shortly and I will probably add it to F19 and F20 as well.
Thanks, Omair
java-devel@lists.fedoraproject.org