actually if it can, just upgrading to 17 seems a good idea... as spring's latest is for 17, maybe we can join forces to make the market to 17... (however I somehow love fiber so if people wanna 21 I just.... well be happy) I always think toolchains shall not be somehow public slaves for every repo, and fulfil every of their requirements... instead should become somehow master to force some outdated repo move on. And as for the repos who wanna stay at 8, just let them use old toolchain versions, and die out slowly, why should we even care for them and must make sure they be able to use the latest maven version to build? We are not slaves nor babysitters for kids after all. If they want third party maintenance they can just pay for that, or hire some group, I just don't think it that hard. like just what azul or jetbrains jbm do...
Xeno Amess <xenoam...@gmail.com> 于2024年2月21日周三 13:41写道： > You are not the only one who hates jigsaw. > > As a real joke, about 4-6 years ago in a jackson mailing list, an [oracle > employee] ask for them to delete module-info in the jars to make it > runnable at lower jdk version, so yes even people in oracle (at least one) > seems don't really agree with jigsaw... > > Gary Gregory <garydgreg...@gmail.com> 于2024年2月7日周三 07:38写道： > >> I have no use for JPMS today, I just don't want it to get in the way, >> which >> is impossible since there is no --dont-bother-me-jpms flag... >> >> Gary >> >> On Tue, Feb 6, 2024, 6:34 PM Martin Desruisseaux < >> martin.desruisse...@geomatys.com> wrote: >> >> > Hello >> > >> > Le 2024-02-06 à 16 h 11, Hunter C Payne a écrit : >> > >> > > Nobody wants Jigsaw and the API improvements aren't enough to get >> > > people to upgrade. >> > > >> > I cannot debate on whether a small minority, or a big minority, or a >> > majority of developers want JPMS (a.k.a. Jigsaw), because I have no data >> > for backing my claims. However, I have not see someone else providing >> > reliable data (e.g. a serious study) for backing opposite claims >> > neither. But one thing sure is that it is not "nobody wants Jigsaw", >> > since at least two persons have expressed interest on this mailing list. >> > >> > Opinions based on personal experience are indicative of a market segment >> > at best. Some peoples may base their opinions on their experience with >> > Google or Amazon. My own personal experience is with space agencies, >> > meteorological/oceanographical agencies, international standardization >> > organizations, etc. They have different consumers, different >> > constraints, different priorities. No consumer said directly "I want >> > JPMS". But they do said "I want faster / more secure / more reliable >> > software", and JPMS is one tool among others for achieving those goals. >> > Not a panacea, but a significant help. For example, JPMS improves >> > security by blocking at the JVM level all unauthorized accesses to >> > internal packages. I'm not aware of any other non-deprecated solution >> > providing this security at the JVM level. The few times that I spoke to >> > peoples working in defence, they were very receptive to that kind of >> > argument. >> > >> > My opinion is that as long as JPMS is so difficult to use in a >> > non-trivial Maven or Gradle project, we cannot know if a relatively low >> > adoption is really because of a lack of interest. Even if some >> > communities are still not interested by JPMS no matter how easy, no >> > personal experience can be generalized to the whole market. If a tool >> > improving software security exists, I think it is a responsibility to >> > make that tool accessible to developers who want to use it (again, I >> > know that JPMS is not a panacea. But it helps). >> > >> > On the larger topic of API improvements in newer Java versions, Panama >> > (coming final in Java 22) is a big feature given the important native >> > libraries out there (e.g. for Artificial Intelligence). It may be of >> > interest to Maven itself, e.g. for accessing C/C++ or Python build >> tools. >> > >> > Martin >> > >> > >> >
