search

javacc / javacc

JavaCC - a parser generator for building parsers from grammars. It can generate code in Java, C++ and C#.
https://javacc.org
BSD 3-Clause "New" or "Revised" License
1.19k stars 248 forks source link

Remove spurious toolchain deps #290

Open kaikalur opened 2 months ago

kaikalur commented 2 months ago

JavaCC never needed a specific version of java. So we should remove things like toolchain and cobertura from deps so anyone can just build it.

CC: @MarcMazas

kaikalur commented 2 months ago

If needed we can set source and class file versions in the javac options. But requiring specific runtime should never happen for javacc.

MarcMazas commented 2 months ago

Well:

So let's discuss about the different subjects:

  1. java source file version levels in the java part of the user grammars
  2. java source & class file version levels for the generated users parsers
  3. jvm & jdk version levels for running the generated users parsers
  4. jdk version levels for the command line, the ant scripts and the maven plugins (and may be gradle plugins) for building new javacc releases

For 1, it would be nice to allow to use up to the last java version (i.e. 22 today), but this implies either to have a java grammar up to date (currently javacc7 does not support even full java 1.7 - I have a java 1.8 version, which I have not published, reserving it to javacc-8), or have a javacc grammar that does not parse java parts and see them as black boxes (which we do not have).

For 2, I think that sooner or later we shall have to allow to generate parsers complying with jdk > 8 features, like modules..., or taking advantage of improvements of jdk > 8 features, like templates, performance related features...; I don't know if we'll have the resources for developping / maintaining code generators that will generate different code for different java target version levels; for the moment it would be nice to check that we allow to use custom templates customized to any source file version level up to the last java version.

For 3, the user should be able to use a jvm & jdk version level compatible with its generated parser; and I'm 100% ok for embedding no third party (dependent) library in the generated parser.

For 4, only the javac maintainers and contributors are concerned, not all the end users. That people have a large set of development environments and habits: no IDE / Eclipse / IntelliJ / ...,, many different JDK installed and JAVA_HOME may be pointing to anyone of them, many maven versions installed and MAVEN_HOME/M2_HOME pointing to anyone of them, all this because they work on different projects, they build (with ant or maven) inside or outside their IDE... That's why we choosed to use the toolchains mechanism, which avoids the user to have to change its JAVA_HOME / MAVEN_HOME for each project and avoids nightmares to configure each plugin. As said above, I'll try to find a way to rely on these environment variables if toolchain is not configured. Also it appeared, when upgrading the poms plugins to their last versions for javacc-8, that some require a JVM > 1.8 to run them, that's why I set it to 11. But the (generated) javacc binary should require JDK 1.8, not 11. I have to check. So note that if you do not configure toolchains and set JAVA_HOME to JDK 1.8 and that you use a maven plugin that requires JDK 11, your build will fail. So a question is: can you afford to use JDK 11 for building a new javacc snapshot/release (while keeping the generated parser to source & class files versions levels to 1.8?

kaikalur commented 2 months ago

With javacc 8 we do not need any of those! We just need to keep the source level and generate source that's compatible with that. All other stuff is upto users. So let's not spend time anything else. Just get rid of the corbetura dep and we are good.

From: Marc MAZAS @.> Sent: Friday, August 23, 2024 3:00 AM To: javacc/javacc @.> Cc: Sreeni Viswanadha @.>; Author @.> Subject: Re: [javacc/javacc] Remove spurious toolchain deps (Issue #290)

Well: we introduced toolchains with Francis when I started maintenance; it is a solution for the maven builds (see further), it is not something that javacc itself is dependent on; we had not checked that one could build a full new release or

Well:

So let's discuss about the different subjects:

  1. java source file version levels in the java part of the user grammars
  2. java source & class file version levels for the generated users parsers
  3. jvm & jdk version levels for running the generated users parsers
  4. jdk version levels for the command line, the ant scripts and the maven plugins (and may be gradle plugins) for building new javacc releases

For 1, it would be nice to allow to use up to the last java version (i.e. 22 today), but this implies either to have a java grammar up to date (currently javacc7 does not support even full java 1.7 - I have a java 1.8 version, which I have not published, reserving it to javacc-8), or have a javacc grammar that does not parse java parts and see them as black boxes (which we do not have).

For 2, I think that sooner or later we shall have to allow to generate parsers complying with jdk > 8 features, like modules..., or taking advantage of improvements of jdk > 8 features, like templates, performance related features...; I don't know if we'll have the resources for developping / maintaining code generators that will generate different code for different java target version levels; for the moment it would be nice to check that we allow to use custom templates customized to any source file version level up to the last java version.

For 3, the user should be able to use a jvm & jdk version level compatible with its generated parser; and I'm 100% ok for embedding no third party (dependent) library in the generated parser.

For 4, only the javac maintainers and contributors are concerned, not all the end users. That people have a large set of development environments and habits: no IDE / Eclipse / IntelliJ / ...,, many different JDK installed and JAVA_HOME may be pointing to anyone of them, many maven versions installed and MAVEN_HOME/M2_HOME pointing to anyone of them, all this because they work on different projects, they build (with ant or maven) inside or outside their IDE... That's why we choosed to use the toolchains mechanism, which avoids the user to have to change its JAVA_HOME / MAVEN_HOME for each project and avoids nightmares to configure each plugin. As said above, I'll try to find a way to rely on these environment variables if toolchain is not configured. Also it appeared, when upgrading the poms plugins to their last versions for javacc-8, that some require a JVM > 1.8 to run them, that's why I set it to 11. But the (generated) javacc binary should require JDK 1.8, not 11. I have to check. So note that if you do not configure toolchains and set JAVA_HOME to JDK 1.8 and that you use a maven plugin that requires JDK 11, your build will fail. So a question is: can you afford to use JDK 11 for building a new javacc snapshot/release (while keeping the generated parser to source & class files versions levels to 1.8?

— Reply to this email directly, view it on GitHubhttps://github.com/javacc/javacc/issues/290#issuecomment-2306742358, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AAPNYANGTYEUESOVBIMVHQ3ZS4B27AVCNFSM6AAAAABM6LBLJGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMBWG42DEMZVHA. You are receiving this because you authored the thread.Message ID: @.***>

new-javacc commented 2 months ago

I meant to say we should completely stop processing the user actions with javacc 8 they will get compiler error later if they have problems in their actions. We can leave some breadcrumbs in the code for ease of locating errors back to grammar

MarcMazas commented 2 months ago

Commit 7f6d982c0b5e8d299bc280cee8c03be3f002ad24 removed the cobertura plugin and moved the toolchains plugin in a profile.