[ 
https://issues.apache.org/jira/browse/MCOMPILER-550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17778410#comment-17778410
 ] 

ASF GitHub Bot commented on MCOMPILER-550:
------------------------------------------

gnodet commented on PR #202:
URL: 
https://github.com/apache/maven-compiler-plugin/pull/202#issuecomment-1774114724

   I think the same change should Apple to the test compile mono.
   @bmarwell  




> Make 'outputDirectory' writeable
> --------------------------------
>
>                 Key: MCOMPILER-550
>                 URL: https://issues.apache.org/jira/browse/MCOMPILER-550
>             Project: Maven Compiler Plugin
>          Issue Type: Improvement
>            Reporter: Benjamin Marwell
>            Assignee: Benjamin Marwell
>            Priority: Major
>             Fix For: 3.12.0
>
>
> h2. Description of Improvement
> Currently, the property 'outputDirectory' is not writeable, i.e. not meant to 
> be modified.
> However, making it writeable  has at least two major advantages.
> h2. Use case one -- variable is already used
> Some Tutorials (e.g. https://www.baeldung.com/maven-multi-release-jars) 
> already make use of rewriting the variable.
> h2. Use case two: MR-Jars with different bytecode level.
> Another use case is Multi-Release-Jars. Currently, they can officially only 
> be controlled by setting the {{release}} property. That will not only require 
> a suitable JDK or Toolchain-JDK, it will also require the bytecode for that 
> version to be the bytecode of that version.
> E.g. using {{release}} and {{multiReleaseOutput}}, the bytecode in 
> {{META-INF/version/java9}} MUST be exactly Java 9 bytecode.
> However, the JDK does not know of such restrictions.
> Using {{outputDirectory}}, you can now create Java 8 bytecode to run in e.g. 
> Java 24. Here is an example use case: 
> https://github.com/groovy/GMavenPlus/pull/287
> Granted, this could also be done differently, but this way it seems a little 
> more elegant.
> The actual advantage is, that some developers can now plan ahead. For 
> example, the SecurityManager is not just deprecated, it is deprecated for 
> removal. The moment we know which Java version it is, we can create a MR-Jar 
> for e.g. Java 30, even though Java 30 SDKs are not available then (currently 
> we have Java 21 GA).
> h2. Proposed solution
> Make variable writeable as suggested in Slack.
> PR available locally.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to