Hi Jeremy. We're talking about the possibility of a drop-in replacement. But what you're suggesting requires alterations to the code, and having struggled with JAXB and its many unofficial plugins I can vouch for the difficulty in doing that. Perhaps it would have been easier if OpenJDK took responsibility for providing the packages and the plugin and setup a nice document somewhere to explain, but that's not what I found.
Anyway, today I'm sitting with a version of izpack that depends on the Pack200 compression class removed from JDK17. Ok, so just add https://github.com/pack200/pack200 right? Oh, but izpack expects java.util.jar.Pack200 not io.pack200.Pack200. Should I update izpack? Yeah, and I've tried twice already, and will try again. Also tried rebuilding the izpack version from source, but it doesn't match with what was released. Next I'll try shading, etc, etc. Suffice to say there are issues. Delany On Tue, 6 Jun 2023 at 14:34, Jeremy Landis <jeremylan...@hotmail.com> wrote: > Delany, > > "You need toolchains if your code needs the JAXB classes removed in JDK11. > Delany" > > That isn't accurate. You do not need toolchains for jaxb. You need to > add the correct libraries. I can understand that statement from a dev that > doesn't quite understand the history of EE inside java but its 100% easy to > do without adding toolchains. > > Jeremy > > -----Original Message----- > From: Delany <delany.middle...@gmail.com> > Sent: Tuesday, June 6, 2023 1:33 AM > To: Maven Developers List <dev@maven.apache.org> > Subject: Re: Question - JDK Minimum of future Apache Maven 4.0.0 > > You need toolchains if your code needs the JAXB classes removed in JDK11. > Delany > > > On Tue, 6 Jun 2023 at 01:54, Henning Schmiedehausen < > henn...@schmiedehausen.org> wrote: > > > To get this discussion a bit more back to actual substance: > > > > Do you still need toolchains with JDK 11/17? I set the release version > > to "8" (or anything else) in my builds, ripped out all the toolchains > > and it "just works". We have done this for Jdbi for ages (require Java > > 11+ as the build JDK; we even enforce "latest LTS" for releases) and > > compile to Java 8 bytecode. So far, we had zero complaints from users > > that the resulting releases do not work / cause problems on JDK 8. > > > > It seems to me that toolchains are only relevant if you need to > > compile to Java 1.6 or lower (shudder). The current LTS supports any > > version post-7 as release target. > > > > Am I missing something? > > > > Oh, I am totally cool with Maven 4 requiring Java 17 to run. In fact, > > this will give us an opportunity to actually use java 17 code to > > *write* maven, which in turn will collapse all of those thousand > > little domain objects into single line records. Can't wait for that. > > :-) > > > > The challenge for plugin writers will be to support Maven 3.x (mostly > > 3.8, > > 3.9) and 4 evenly. The current set of available modules and libraries > > makes that hard. A page with "use this to be compatible with that" > > would be helpful. > > > > -h > > > > > > > > > > On Mon, Jun 5, 2023 at 2:23 PM 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://l/ > > > > ists.apache.org%2Fthread%2Fkpsrb28nst84vtohwngy3140g1r0ydd4&data=0 > > > > 5%7C01%7C%7Cfb40fc3fc64e4a82761708db664fa4cf%7C84df9e7fe9f640afb43 > > > > 5aaaaaaaaaaaa%7C1%7C0%7C638216264486404797%7CUnknown%7CTWFpbGZsb3d > > > > 8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3 > > > > D%7C3000%7C%7C%7C&sdata=E1edIICCiPIKLDyysEEehIxEgA1zL09VYb53duEoB8 > > > > 4%3D&reserved=0 > > > > > > > > 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.o/ > > racle.com%2Fjava%2Ftechnologies%2Fjava-se-support-roadmap.html&data=05 > > %7C01%7C%7Cfb40fc3fc64e4a82761708db664fa4cf%7C84df9e7fe9f640afb435aaaa > > aaaaaaaa%7C1%7C0%7C638216264486404797%7CUnknown%7CTWFpbGZsb3d8eyJWIjoi > > MC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7 > > C%7C&sdata=s92AGcmmP%2BxmWuUWMdvqOEOPhZQARF6jT4gSsMY8lRI%3D&reserved=0 > > > > > > > > > > > > > > > ---------------------------------------------------------------- > > > > > ----- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > > > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > > > > > > > > > > > > > > > > >
