Patrick
We have this issue that you created
https://issues.apache.org/jira/browse/ZOOKEEPER-3696
I feel it is better to address the problem in 3.7 and not on 3.6.1
Do you agree?
Enrico
Il Ven 20 Mar 2020, 11:11 Norbert Kalmar <nkal...@cloudera.com.invalid> ha
scritto:
> I just saw the discussion here on ZOOKEEPER-3739, which I committed about a
> minute ago. But please do check if anyone is interested in it (we can
> always revert).
> My very short take on the issue: Removed an unsupported api class that use
> was *supposedly* to speed up file modification watch event on OSX systems.
>
> - Norbert
>
> On Fri, Mar 20, 2020 at 8:07 AM Christopher <ctubb...@apache.org> wrote:
>
> > Ted, please see the JIRA issue and linked PR for detailed answers to
> those
> > questions. My side issue has already hijacked this thread enough :) We
> can
> > continue in the forked thread that Enrico created, if you wish.
> >
> > On Fri, Mar 20, 2020 at 1:32 AM Ted Dunning <ted.dunn...@gmail.com>
> wrote:
> >
> > > 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
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
