Hi,
On 23.07.22 10:13, Delany wrote:
I tried toolchains but dropped it because of the exorbitant performance
costs.
A multi-module build that normally built in 3:50 took 10:34, and that's
with toolchaining only maven-compiler-plugin.
Delany
Can you tell when you have tested that? How many modules do you have
have? What kind of project ?
Do you have an example of that? Have you configured to fork of compiler
plugin..please give much much more information so we need to analyze this?
Kind regards
Karl Heinz Marbaise
On Sat, 23 Jul 2022 at 00:21, Benjamin Marwell <bmarw...@apache.org> wrote:
KH just released a video on toolchains.
It's much easier than I remembered.
I'm changing my vote to 17. I don't see a reason to use 11 which will be
out of support soon. It's really just two properties used three times.
https://github.com/khmarbaise/youtube-videos/blob/main/episode-toolchains/pom.xml
https://youtu.be/-KbDcJcglPc
Thanks Karl Heinz for sorting this out.
We should really promote toolchains.
+1 for 17.
- Ben
On Fri, 22 Jul 2022, 21:33 Arnaud Héritier, <aherit...@gmail.com> wrote:
I would say java 11 for maven 4 and 17 for maven 5 with the hope that it
won’t be here in many years
Le jeu. 21 juil. 2022 à 18:53, Benjamin Marwell <bmarw...@apache.org> a
écrit :
I was going to answer: go for 17.
But running the tests on the same language level is really a good
argument.
So much changed: HttpClient, TLS and cipher suites, DNS resolution
(starting with Java 18 it will be pluggable!) etc.
Yes, in theory it should not fail. But this is (sadly) a strong
argument
against using Java 11+.
If it's just for language features, we could also use kotlin, groovy or
just a library like javaslang (now vavr.io) to receive some amount of
what
you would like to see. Groovy is even an Apache project and kotlin has
excellent support. Both can mimic sealed classes, have advanced
features
like traits etc.
Not saying I'm a big fan of this myself, but it *might* be an option to
think about.
Of course we could scare devs away or attract them. Who knows.
So, I deeply regret it, but I'd say go for 8 and make an early Maven 5
release with Java 17, then make all the major changes (new pom etc) in
Maven 6 instead of Maven 5.
On Wed, 20 Jul 2022, 17:08 Jorge Solórzano, <jor...@gmail.com> wrote:
Yes, I agree with Romain (and also many others that have the same
concerns), expecting that the behavior of testing with one JDK that
targets a lower JDK will "just works" is naive.
There are differences at bytecode level, just compile a class with
JDK17 --release 11 and the same class with JDK11 --release 11 and
then
compare with diffoscope to see them, this is one of the reasons that
you need to use the same major JDK version to get Reproducible
Builds,
you can't expect a build to be reproducible even if you target to the
same release.
I don't expect the bytecode differences to be a real issue, yet
without proper testing (using the same runtime that you target) you
can't be sure.
The HttpClient is one example where you have things like this bug:
https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8245245, fixed
only in Java 16+, meaning that while it *works* on Java 17, it will
fail on Java 11.
We all agree that Toolchains is the way to go for this kind of thing,
but it's important to mention that Toolchains create some friction
for
end users and a more involved setup.
And please don't get me wrong, I'm all for using JDK 17, but user
experience is also important.
On Wed, Jul 20, 2022 at 4:23 PM Romain Manni-Bucau
<rmannibu...@gmail.com> wrote:
Was more due to tests failling but there is no guarantee there is
no
difference in the bytecode on one side and the most important IMHO
is
the
fact the run behavior can be different so at the end of the day you
cant
assume that because your build with java17 -release 8 worked that
it
will
run on your prod.
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <
https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<
https://www.packtpub.com/application-development/java-ee-8-high-performance
Le mer. 20 juil. 2022 à 16:16, Tomo Suzuki
<suzt...@google.com.invalid
a
écrit :
Hi Romain,
the while loop was not exactly the same
Did you observe the difference in the while loop bytecode cause
an
issue in
Java 8 users?
Regards,
Tomo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
