Apologies, but it's a bit hard for me to explain briefly. Here's an attempt
to be as brief as I can:
Newer JDKs add a `-release` option to cross-compile with strict
compatibility enforced. When this flag is enabled, as my PR does
automatically with the profiles (when it detects building with a newer JDK
or in m2e Eclipse), the compiler identifies the use of a class that is not
strictly compatible with Java 8. My PR removes this not strictly compatible
class. The use of this class should be considered a bug because it will
cause a failure in some JDKs (those without the com.sun class)... a bug
that is caught by the strict compatibility checks of the `-release` flag in
newer JDKs.
The problem with the class is that it only is available on some versions of
Java (those with com.sun internals). It is not only not strictly compatible
with Java 8 ("not guaranteed to work"), it is specifically "guaranteed to
not work" in future Java versions, because it is planned for explicit
removal. It already causes problems in current versions if you have an
application that uses modules and depends on ZooKeeper, because the
unsupported class is hidden away in an internal module.
What you say about ensuring that releases are built with JDK8 is actually
not necessary any longer with the use of the `-release` flag. Newer JDKs
enforce cross-compilation compatibility better. This release flag option
eliminates the need to hold yourself back, doing release builds on an older
end-of-life JDK to retain compatibility. Now, you can build with a newer
JDK (taking advantage of newer Maven plugins, etc.), avoid complex uses of
Maven toolchains, the annoying `-bootclasspath`, or the
maven-enforcer-plugin's animal-sniffer rule. The cross-compilation strict
compatibility is now enforced as a built in feature of newer JDKs.
Sorry I couldn't explain more briefly... it's a very tiny change, but
there's a lot of backstory to communicate why it matters.
Incidentally, you can probably get rid of a few build jobs in Jenkins if
you were to use the maven-enforcer-plugin to *only* support builds on newer
JDKs (but still using the release flag to target Java 8, of course). This
is what Apache Accumulo does for the stuff that we want to be compatible
with Java 8: we require the build to use at least 11, but cross-compile to
8, because some of the Maven plugins we use for quality control checks are
now starting to require Java 11.
On Thu, Mar 19, 2020 at 3:32 PM Enrico Olivelli <[email protected]> wrote:
> Il Gio 19 Mar 2020, 20:11 Christopher <[email protected]> ha scritto:
>
> > I would very much like my pull request in
> > https://issues.apache.org/jira/browse/ZOOKEEPER-3739 to be merged in
> 3.6.1
> > and newer, because it helps ensure newer java APIs don't leak into pull
> > requests/patches when developing stuff to contribute using a newer JDK,
> by
> > leveraging the "release" flag of newer JDKs. However, in order to do so,
> it
> > needs to remove the use of an internal com.sun API which is not supported
> > in newer JDKs. I would like it included, because it makes it easier for
> me
> > (and others using newer JDKs) to contribute.
> >
>
> I usually use jdk13 for my applications and while I work on ZK code.
> What problems are you facing?
>
> It is important to remember to build with jdk8 while making releases. But
> for dev it is not needed.
>
> Maybe we can merge that patch on master but I don't feel it is so important
> at the moment. (With jdk13)
>
> Enrico
>
>
> > The patch is currently pending additional reviewers.
> >
> > On Thu, Mar 19, 2020 at 11:17 AM Patrick Hunt <[email protected]> wrote:
> >
> > > Great idea, thanks Enrico!
> > >
> > > Patrick
> > >
> > > On Thu, Mar 19, 2020 at 4:58 AM Enrico Olivelli <[email protected]>
> > > wrote:
> > >
> > > > Hi folks,
> > > > after a couple of weeks after the release of 3.6.0 we are seeing a
> few
> > > > blocker issues related to the upgrade from 3.5.
> > > >
> > > > There is already a good list of issues already ported to 3.6 and a
> few
> > > > pending PRs that fix problems reported by users.
> > > >
> > > > You can find the list here, I have already did some clean up and left
> > > > comments to "reporters" in order to remove a few issues that are
> > > > tagged 3.6.1 but they don't have an active contributor working on it.
> > > > I have also created 3.6.2 release in order to ease moving those
> issues
> > > >
> > > >
> > > >
> > >
> >
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20ZOOKEEPER%20AND%20fixVersion%20%3D%203.6.1%20ORDER%20BY%20resolution%20DESC
> > > >
> > > > My proposal:
> > > > - commit pending blocker patches related to the upgrade
> > > > - start a release within a couple of weeks, in the beginning of April
> > > >
> > > > I volunteer to do the release, this way I can finish the "new release
> > > > procedure" based on the Maven Release Plugin
> > > >
> > > > Enrico
> > > >
> > >
> >
>
