Le jeu. 3 oct. 2019 à 20:22, Tibor Digana <tibordig...@apache.org> a écrit :

> The topic related to TLS is only related to runtime, means JDK, which is
> under the control of the particular user or CI.
> I guess the user can easily find the answer:
>
> https://stackoverflow.com/questions/50824789/why-am-i-getting-received-fatal-alert-protocol-version-or-peer-not-authentic
>
> The thing is that we need to specify:
> + advantages of Java 1.8 in code (Lambda, brief code, maybe)
> + disadvantages of Java 1.8 in code (Streams performance when/how/what
> approach???)
>

There is also a not technical view, any previous jdk is not maintained so
its support is no more needed since we are far from any acceptable
migration for projects which would migrate.



> Write notices for developers on the internal Wiki:
> + toolchains
> + limitations and solutions for disadvantages
> + conditions when and how to migrate from J7 to J8
>


Or the most common option: stick to current mvn version.

We can still get fixes releases on need backporting small fixes. It is how
asf works after all.

I wouldnt bother users with toolchain, it is only needed for libs and the
active ones almost all migrated to j8 ;).


> and then we should Vote for J8.
>
> And there are users who is has J6 and J7 and they may require us to
> maintain the old version 3.6.x.
> What to do in this case?
> Is the toolchain enough? Usually it is in ordinal projects!
>
> Cheers
> T
>
>
> On Thu, Oct 3, 2019 at 5:52 PM Stephen Connolly <
> stephen.alan.conno...@gmail.com> wrote:
>
> > On Thu, 3 Oct 2019 at 16:49, Karl Heinz Marbaise <khmarba...@gmx.de>
> > wrote:
> >
> > > Hi,
> > >
> > > On 03.10.19 17:03, Tibor Digana wrote:
> > > > This is not very serious discussion since we saw users on our mailing
> > > > list who said that he is using Java 1.6 compiler and JDK7 in Maven.
> > >
> > > Would that change anything? Using JDK 8 for Maven and using JDK 6 for
> > > compiling/test...
> > >
> > >
> > > > Serious discussion would uncover pros/cons and impact analysis.
> > > >
> > > > I would have a problem with Java 1.8 in target and source code but I
> > > > have problem that we excluded our users from the VOTE.
> > >
> > > > Regarding Java 1.7 we clearly uncovered the migration plan, versions
> of
> > > > plugins, core etc. Here nothing like that exists - only that somebody
> > > > created a Jira ticket.
> > >
> > > Hm...all plugins etc. running on JDK 7+...so in the first step we just
> > > upgrade the minimum for Maven Core only (3.7.0)... (Apart from having a
> > > plugin which is JDK8 minimum already).
> > >
> > > Plugins can upgrade to JDK 8 minimum as needed/wished afterwards (may
> be
> > > we could do a version identification...but at the moment I don't see a
> > > need for that cause they work on JDK7+).
> > >
> >
> > Also, to my mind, unless the plugin specifically needs features in Maven
> > 3.7.0 there is added reason for the plugin to stay on JDK7 until it bumps
> > the core version of Maven it depends on (or it finds a use-case requiring
> > Java 8)
> >
> > Finally, upgrading to Java 8 is basically a must have for easier TLS
> > certificate validation as the JDK7 distributions do not all have good
> > current TLS root certs
> >
> >
> > > Kind regards
> > > Karl Heinz Marbaise
> > >
> > > >
> > > > Technically I would be interested if somebody could explain what NEW
> > > > Security API is in Java 1.8 and performance impact of Streams API.
> > > > That's the impact in the source code.
> > > > Somebody has other questions too.
> > > > Then we can write Wiki as well as rules, conditions and plan.
> > > >
> > > > Cheers
> > > > Tibor17
> > > >
> > > > On Thu, Oct 3, 2019 at 4:55 PM Karl Heinz Marbaise <
> khmarba...@gmx.de
> > > > <mailto:khmarba...@gmx.de>> wrote:
> > > >
> > > >     On 03.10.19 14:15, Elliotte Rusty Harold wrote:
> > > >      > Strong -1 on Java 8 as the minimum version. Google Cloud
> > Platform
> > > has
> > > >      > lots of products and customers that still require Java 7. If
> > Maven
> > > >      > requires Java 8, we'd have to stick to the latest of whichever
> > > >     release
> > > >      > does support Java 7 for at least a year and I'm guessing
> longer.
> > > >
> > > >     Hm.. first Java 7 is out for eight years now (2011) (End of live)
> > and
> > > >     has no public updates for security/bug fixes etc. since 2015
> > > >
> > > >     Furthermore Java 8 is out for five years (2014) so to be honest I
> > > >     wouldn't trust an environment which is not upgrading etc. in
> > > particular
> > > >     in a clould environment...
> > > >
> > > >     Why hadn't started Google to update their environment over the
> time
> > > to
> > > >     JDK 8 etc. (I think they have much more resources than anyone).
> > > >
> > > >
> > > >     One more thing is:
> > > >        There is a difference between running Maven to build for
> example
> > > >        with JDK 8 and running your resulting artifacts (see toolchain
> > > >     comment
> > > >        from Stephen Connolly..
> > > >
> > > >     Kind regards
> > > >     Karl Heinz Marbaise
> > > >
> > > >
> > > >     [1]:
> > > >
> > https://www.oracle.com/technetwork/java/java-se-support-roadmap.html
> > > >
> > > >
> > > >      >
> > > >      > On Sat, Sep 28, 2019 at 8:04 AM Robert Scholte
> > > >     <rfscho...@apache.org <mailto:rfscho...@apache.org>> wrote:
> > > >      >>
> > > >      >> Hi,
> > > >      >>
> > > >      >> TLDR; introduce maven.experimental.buildconsumer and push
> Java
> > > >     requirement
> > > >      >> to Java 8
> > > >      >>
> > > >      >> now that Maven 3.6.2 is out for a couple of weeks, it seems
> > like
> > > >     we didn't
> > > >      >> face real regressions.
> > > >      >> The only one might be tricky is the issue related to Tycho.
> > > >      >>
> > > >      >> However, I think we're ready to push Maven to the next level.
> > > >      >>
> > > >      >> For those actively reading this list, they should recognize
> the
> > > >     need for
> > > >      >> splitting up the pom as it is on the local system versus the
> > pom
> > > >     being
> > > >      >> uploaded. Once we truly control this mechanism we can think
> of
> > > >      >> improvements on model 5.0.0 and new fileformats.
> > > >      >>
> > > >      >> I've created and implemented MNG-6656[1]. It also contains a
> > zip
> > > >     with an
> > > >      >> example (original, patched, README) to understand what's
> > > happening.
> > > >      >>
> > > >      >> In order to make this successful, we need IDEs and CI Servers
> > to
> > > >      >> understand and support these changes. The likely need to
> > > >     implement one of
> > > >      >> the interfaces[2].
> > > >      >> The new interface uses Java8 Functions (and especially
> > > >     SAXEventFactory is
> > > >      >> way easier to read+maintain with Java 8). I've tried to keep
> > > >     Maven Java 7
> > > >      >> compatible, but that was too hard to do.
> > > >      >> So I'd like to use this opportunity to move Maven forward and
> > > start
> > > >      >> requiring Java 8.
> > > >      >>
> > > >      >> There are some other improvements I'd like to add (those
> > > >     messages will
> > > >      >> follow), so this will imply that it will take some time
> before
> > > >     we do a new
> > > >      >> release.
> > > >      >>
> > > >      >> WDTY,
> > > >      >> Robert
> > > >      >>
> > > >      >> [1] https://issues.apache.org/jira/browse/MNG-6656
> > > >      >> [2]
> https://github.com/apache/maven/compare/MNG-6656?expand=1
> > > >      >>
> > > >      >>
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: dev-h...@maven.apache.org
> > >
> > >
> >
>

Reply via email to