I have to strongly disagree. If Maven wants to remain relevant it needs
to be using a relatively modern JDK and language that is available to
open source developers and interesting to work on.
Nobody wants to work on Java 8 code.
Ultimately the committers and project maintainers can vote and move on
as desired. You can always use an old version of Maven or switch to some
other build system that works with Java 8.
Personally I will certainly vote for the current LTS release of Java
(17) .. and would in the future also vote for the next current LTS very
soon. And I would vote against staying with an outdated version that
reached EOL years ago.
Manfred
On 2023-06-05 15:31, Hunter C Payne wrote:
Other projects have tried to do that (given they are different types of
projects) and it turned out that keeping JVM8 support going when not compiling
on JDK8 proved difficult and when push came to shove, it was JVM 8 support that
was dropped. I know that's not you or this project, but human nature is what
it is and patterns tend to repeat. So while I understand what you are saying,
I have my doubts based upon past projects I have seen do this.
On the other hand, the reasons for the upgrade are always a bit weak and the
upgrade really only created lots of support work for the devs and users (the
security model is especially an issue) and yes they thought it would be
seem-less too. Writing code in any other JVM language would accomplish what
you want far more effectively. Instead you want to put lipstick on the pig and
act like Java 21 is somehow like more modern languages (it isn't, it never will
be). Just because you can pass a function in Java, doesn't make it a FP
language. It has no currying, no function composition, it lacks a self-type,
there are no concepts of co or contra variance in the types and that's just a
short list off the top of my head. That's the direction you are pushing with
what you are asking about but Java 21 isn't the answer there as it has none of
these things, while almost all of them would be useful in Maven itself.
So from my perspective, you are proposing a solution to a problem that doesn't
exist while at the same time the solution you propose doesn't truly give you
what you want. Nobody wanting to a new language on their CV is going to need
that language to be Java. If they are joining the Maven project, it is likely
because they want to contribute to Maven, not because Maven uses JDK 21. And
your users just don't want to be bothered and want their build system to work.
It is hardly ideal and I have sympathy but it doesn't make dropping building of
Maven by javac8 the right call.
Hunter
On Monday, June 5, 2023 at 02:22:59 PM PDT, Delany
<delany.middle...@gmail.com> wrote:
Your inclination to ignore points of the debate doesn't do your own
arguments any justice.
Multiple times it's been explained that raising the required runtime JDK in
Maven 4 will not prevent you from
- building with a lower JDK (via toolchains)
- targeting a lower JDK (via the release property)
- building with Maven 3
This is the main point of the debate, not the language.
On Mon, 5 Jun 2023 at 21:42, Hunter C Payne
<hunterpayne2...@yahoo.com.invalid> wrote:
* Attract devsAbsolutely not. If you want to attract devs, switch to a
language that is actually growing (no I'm advocating for this). That isn't
Java. If anything, this will lose you devs. The company I work for will
be leaving Maven if you stop supporting Java8. That's 300 users you lose
right there. That's just 1 company. You will lose users in droves if you
stop Java8 support. Many companies don't have/put enough resources into
this type of upgrade. Its hard to justify to the business and it makes
lots of work for devs (expensive). If it is cheaper to switch build
systems that to upgrade the JVM, that's exactly what folks will do. My
company certainly will (not my decision so don't try to convince me, I'm
not the one you have to convince).
* CDS for non-OpenJ9-usersI'm not sure this is something that is really
taken advantage of by Maven. Perhaps I am wrong.
* Better clarity of code (yes, I mean that)That you say that you actually
mean this says it all. Clearly this is something that isn't agreed upon
universally. Your personal taste shouldn't decide the future of a project
used by so many others.
* No additional work (we don't need to migrate, just use the features when
modifying a line for a bug/feature anyway)This is simply not true. There
have been comments by devs on this very list, in this very discussion that
disprove this point. It isn't OK to just ignore their input because you
really want to use lambdas.
* We leave no one behind b/c of Maven 3.8/3.9, thus no drawbacks.You have
that backwards. If you leave Java8, you leave behind everyone who can't
upgrade their source base. It seems to me that the size of the group of
Java8 folks you will leave behind is quite large. So your argument about
no drawbacks isn't credible. There are no drawbacks for you, that isn't
the same as there being no drawbacks for the entire user base.
* By the time Maven 4 final is out, your views might have changed!I write
most of my code in Scala so I doubt it seriously.
Your points are not nearly as strong as you imply with your tone. Some of
them indicate a lack of understanding of some more advanced parts of FP
which is understandable for Java devs but doesn't make your points
correct. And your analysis of the impact on the userbase is just plain
wrong. If you want people to bomb this list with complains, drop Java 8
support and enjoy the rage postings you get from 100s to 1000s of devs who
work for companies and projects that don't have to resources to upgrade.
Hunter
PS Lambdas are only useful if there is function composition and currying.
Java lacks both. So the debate over lambdas is pretty amusing to me. It
is just syntactic sugar. It doesn't actually give you the ability to do
other things like in Scala or Kotlin. So I don't really understand why you
want to use them so much. Are for loops really that hard to write? I mean
there is already so much ceremony in Java that saving 3 or 4 keystrokes per
loop doesn't really make any difference.
On Monday, June 5, 2023 at 11:52:16 AM PDT, Tamás Cservenák <
ta...@cservenak.net> wrote:
Seems people missed this (somewhat related) thread:
https://lists.apache.org/thread/kpsrb28nst84vtohwngy3140g1r0ydd4
Thanks
On Mon, Jun 5, 2023, 20:40 Hunter C Payne <hunterpayne2...@yahoo.com
.invalid>
wrote:
Hi, Karl, I'm not sure I agree you have "stated a benefit" so far.
There have been plenty of hand-wavy arguments but nothing really solid.
That's why you are getting so much push back. Point to a specific
feature
you need or some other thing that would help the project in some
significant way. At the moment, the argument is basically, "its newer so
its better", I'm sorry but that simply is not true. Make a better case
and
you will get less pushback.
Hunter
On Monday, June 5, 2023 at 06:03:26 AM PDT, Karl Heinz Marbaise <
khmarba...@gmx.de> wrote:
Hi,
On 03.06.23 11:46, Hervé Boutemy wrote:
+1
I really don't what benefit we get from going to Java 17
which was already part of the email:
> Based on the argument we don't need features of JDK17+ I see a number
> of things which could make our handling/maintenance easier for example
> using sealed classes to prevent exposing internal things to public
which
> could be used etc. also some other small features (`var` for example;
> Text-Blocks in Tests etc) or using records in some situation (really
immutability)..
>
>
Kind regards
Karl Heinz Marbaise
I perfectly see the impact we'll have on our users: for what benefit?
notice that this will also impact all plugins: and given the few work
done on
plugins to clearly show what plugin version remains compatible with a
JDK
release, I feel we're not taking the topic the right way
Le vendredi 2 juin 2023, 01:50:53 CEST Hunter C Payne a écrit :
I'm not sure I would worry too much about that David. I think most
devs
who want better syntax moved from Java sometime ago. They might still
be
on the JVM just not writing Java. Also, Maven is a mature project. I
don't think devs considering contributing to it are thinking about
using
the latest and greatest version of Java. Compatibility is probably a
bigger concern for the user base. Just my opinion.
Hunter
On Thursday, June 1, 2023 at 04:17:26 PM PDT, David Jencks
<david.a.jen...@gmail.com> wrote:
I wonder if having maven require java 8 syntax discourages any
potential
contributors who are used to coding using more recent developments. I
have
no idea how to tell, but maybe someone else does.
David Jencks
On Jun 1, 2023, at 3:02 PM, Karl Heinz Marbaise <khmarba...@gmx.de>
wrote:
Hi,
my clear opinion is to go with most recent JDK LTS version for the
release point of Maven 4.0.0 which I assume will be JDK 21...
That means clear the build time requirement which is completely
different from runtime of an application.
Older JDK's are supported by some vendors by having particular
special
support which most of the time requires special contracts (means also
paying money for it)..some of them offering builds without paying
money
yes..
Older runtime target are supported with different approaches like
Toolchain or via `--release XX` which exists since JDK9+.
Furthermore if someone is not capable of upgrading the build
environment
to JDK9+ they can continue to use Maven 3.8.X or Maven 3.9.X...
If it would be requirement to port things back to 3.8.X or 3.9.X it
could be handled by someone who has the time etc. to do that ... if
not,
those people might think of paying someone to do that work...
The given argument about JPMS for migration causes issues is from my
point of view false-positive because migration to newer JDK versions
does not require JPMS usage...
Even platforms like AWS support JDK17 in the meantime which is the
runtime...
Based on the maintenance part it would mean in consequence to
downgrade
to even JDK7... (or even lower) because you can get support for older
JDK version in some ways... (JDK7 from azul for example)
Kind regards
Karl Heinz Marbaise
[1]
https://www.oracle.com/java/technologies/java-se-support-roadmap.html
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
