What internal class?
Where is it used?
Why are others using JDK 13 not seeing the problem that you described?
On Thu, Mar 19, 2020 at 8:58 PM Christopher <ctubb...@apache.org> wrote:
> 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 <eolive...@gmail.com>
> wrote:
>
> > Il Gio 19 Mar 2020, 20:11 Christopher <ctubb...@apache.org> 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 <ph...@apache.org>
> wrote:
> > >
> > > > Great idea, thanks Enrico!
> > > >
> > > > Patrick
> > > >
> > > > On Thu, Mar 19, 2020 at 4:58 AM Enrico Olivelli <eolive...@gmail.com
> >
> > > > 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
> > > > >
> > > >
> > >
> >
>
