Hi! It turned out that it is always just a bit more complicated. Romain detected that building OpenWebBeans with Java8 did lead to bytecode which does not work on ANY older JVM. The reason is that methods of ConcurrentHashMap (and possibly other) has been moved to an Interface. See OWB-952 [1] for more info.
This is ok and a known aspect from a general JVM perspective [2] but needs some caution on our side. Which also means that any TCK, unit tests whatever are NOT sufficient to prove backward compat with older platforms nor that it works on newer platforms. My personal summary is that if we like to support java6 in commons-jcs, then we should really run the release with a jdk-1.6. LieGrue, strub [1] https://issues.apache.org/jira/browse/OWB-952 [2] https://blogs.oracle.com/darcy/entry/how_to_cross_compile_for > On Thursday, 1 May 2014, 18:27, Bernd Eckenfels <e...@zusammenkunft.net> > wrote: > > Am Thu, 1 May 2014 11:01:32 -0500 > schrieb Paul Benedict <pbened...@apache.org>: > >> Wrong syntax is different than missing syntax. The former affects >> readability while the other just affects usability. Glad you found a >> way to catch the former but ignore the latter. > > I agree with the "missing should be warning", but I don't see a > need to > change the configuration. I just fixes the "self-closed" errors in > VFS2 > with javadoc8 and it now builds with no errors. It soes show missing > @param @return and @throws but they are all warnings. > > It is using commons-vfs2-project:2.1-SNAPSHOT which is using > commons-parent:32 and none of those define Javadoc lint options (only > quiet=true). > > So I am not sure why you need to change the parents? > > > I do see a problem with additional @todo tags. They are configured in > the project parent, but it seems from the effective pom that they are > not used in all invocations, at least they made the build fail (and I > wrongly corrected them). > > Bernd > > >> >> >> On Thu, May 1, 2014 at 5:22 AM, Mark Struberg <strub...@yahoo.de> >> wrote: >> >> > Actually the ',' causes a bug in the maven-javadoc-plugin. > What >> > seems to work is to split it into 2 parts: >> > >> > <additionalparam>-Xdoclint:all > -Xdoclint:-missing</additionalparam> >> > >> > Already started a discussion about adding it to apache-parent over >> > in maven-dev. >> > >> > LieGrue, >> > strub >> > >> > >> > >> > >> > >> > >> > >> > > On Thursday, 1 May 2014, 11:05, Mark Struberg > <strub...@yahoo.de> >> > > wrote: >> > > >> I would prefer it if the reports were warnings rather > than >> > > >> errors, but >> > >> generally they seem sensible. >> > > >> > > >> > > Allow me to disagree. Breaking the javadoc just because a @param >> > > is >> > missing is >> > > imo plain wrong. >> > > >> > > Usually parameters should be self-explaining. I personally only >> > > document interfaces and methods where it is *not* clear what the >> > > params intend. >> > > >> > > >> > > Please don't let us end up with tons of unnecessary (because >> > > obvious) Javadocs just to make java8 happy. >> > > >> > > I've done some research and asked some Java8 devs I know. > Seems >> > > >> > > > <additionalparam>-Xdoclint:all,-missing</additionalparam> >> > > >> > > could do the trick. Still need to test it though. >> > > >> > > We should btw add this to the apache-parent pom and not only to >> > commons-parent. >> > > >> > > LieGrue, >> > > strub >> > > >> > > >> > > >> > > >> > > >> > > On Wednesday, 16 April 2014, 20:51, sebb <seb...@gmail.com> > wrote: >> > > >> > > On 16 April 2014 19:32, Gary Gregory > <garydgreg...@gmail.com> >> > > wrote: >> > >>> I personally like the default Java 8 behavior and I > would not >> > >>> want to disable it. >> > >> >> > >> I would prefer it if the reports were warnings rather than >> > >> errors, but generally they seem sensible. >> > >> >> > >> -1 to adding it to the parent POM as a default. >> > >> It might have been OK to do so if it were possible to > activate >> > >> it only when Java 8 is being used to a component that targets >> > >> Java 5,6,7. But suppressing DocLint for source that targets > Java >> > >> 8 seems a very bad >> > > idea. >> > >> Unfortunately ANDed activation conditions for profiles are >> > >> borked and have been for ages. >> > >> >> > >> I think it's OK to use in component POMs because each > component >> > >> will be different. >> > >> And it can be easily removed when the source has been > updated. >> > >> >> > >>> Gary >> > >>> >> > >>> >> > >>> On Wed, Apr 16, 2014 at 1:06 PM, Matt Benson >> > > <gudnabr...@gmail.com> wrote: >> > >>> >> > >>>> I think the implication was that adding it to the > parent POM >> > >>>> would >> > > not >> > >>>> encourage us to actually *solve* the underlying > issue. ;) >> > >>>> >> > >>>> Matt >> > >>>> >> > >>>> >> > >>>> On Wed, Apr 16, 2014 at 12:02 PM, Emmanuel Bourg >> > > <ebo...@apache.org> >> > >>>> wrote: >> > >>>> >> > >>>> > Le 16/04/2014 18:41, sebb AT ASF a écrit : >> > >>>> > > See below for one way to automatically > suppress Javadoc >> > > errors when >> > >>>> > > running under Java 8 >> > >>>> > > >> > >>>> > > It should not be adopted as a permanent > measure, but may >> > > be useful >> > >>>> > > whilst Javadoc is being fixed. >> > >>>> > >> > >>>> > Can we add that to the parent pom? >> > >>>> > >> > >>>> > Emmanuel Bourg >> > >>>> > >> > >>>> > >> > >>>> > >> > > > --------------------------------------------------------------------- >> > >>>> > To unsubscribe, e-mail: > dev-unsubscr...@commons.apache.org >> > >>>> > For additional commands, e-mail: > dev-h...@commons.apache.org >> > >>>> > >> > >>>> > >> > >>>> >> > >>> >> > >>> >> > >>> >> > >>> -- >> > >>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org >> > >>> Java Persistence with Hibernate, Second >> > > Edition<http://www.manning.com/bauer3/> >> > >>> JUnit in Action, Second Edition >> > > <http://www.manning.com/tahchiev/> >> > >>> Spring Batch in Action > <http://www.manning.com/templier/> >> > >>> Blog: http://garygregory.wordpress.com >> > >>> Home: http://garygregory.com/ >> > >>> Tweet! http://twitter.com/GaryGregory > >> > > >> > >> >> > >> >> > >> > --------------------------------------------------------------------- >> > >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> > >> For additional commands, e-mail: dev-h...@commons.apache.org >> > >> >> > >> >> > >> >> > > >> > > > --------------------------------------------------------------------- >> > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> > > For additional commands, e-mail: dev-h...@commons.apache.org >> > > >> > >> > --------------------------------------------------------------------- >> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> > For additional commands, e-mail: dev-h...@commons.apache.org >> > >> > >> >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
