Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Java] (JPMS) Add a maven plugin for compiling modules while retaining JDK8 support #39134

Closed
jduo opened this issue Dec 7, 2023 · 0 comments · Fixed by #39135
Closed

[Java] (JPMS) Add a maven plugin for compiling modules while retaining JDK8 support #39134

jduo opened this issue Dec 7, 2023 · 0 comments · Fixed by #39135

Comments

@jduo
Copy link
Member

jduo commented Dec 7, 2023

Describe the enhancement requested

The traditional method of compiling modules is to use -release 9 to compile everything in the module, then recompile everything except module-info.java using release 8. This conflicts with the use of Unsafe in JDK8.

Instead, we can write a plugin which does a purely syntactic compilation of module-info.java files.

Component(s)

Java

lidavidm pushed a commit that referenced this issue Dec 12, 2023
### Rationale for this change
Create and integrate a maven plugin for compiling module-info.java files without using maven-compiler-plugin
and release 9+. This is necessary for supporting Java 8 unsafe code, which has different than unsafe code
in JDK 9.

### What changes are included in this PR?
- Add the module-info-compiler-maven-plugin and utilize it in the codebase.
- Exclude module-info.java files from maven-compiler-plugin.

### Are these changes tested?
Yes, they generate valid module-info.class files in JARs and test JARs.

### Are there any user-facing changes?
No
* Closes: #39134

Authored-by: James Duong <james.duong@improving.com>
Signed-off-by: David Li <li.davidm96@gmail.com>
@lidavidm lidavidm added this to the 15.0.0 milestone Dec 12, 2023
mapleFU pushed a commit to mapleFU/arrow that referenced this issue Dec 13, 2023
### Rationale for this change
Create and integrate a maven plugin for compiling module-info.java files without using maven-compiler-plugin
and release 9+. This is necessary for supporting Java 8 unsafe code, which has different than unsafe code
in JDK 9.

### What changes are included in this PR?
- Add the module-info-compiler-maven-plugin and utilize it in the codebase.
- Exclude module-info.java files from maven-compiler-plugin.

### Are these changes tested?
Yes, they generate valid module-info.class files in JARs and test JARs.

### Are there any user-facing changes?
No
* Closes: apache#39134

Authored-by: James Duong <james.duong@improving.com>
Signed-off-by: David Li <li.davidm96@gmail.com>
lidavidm pushed a commit that referenced this issue Jan 10, 2024
…39011)

Depends on #39134 

### Rationale for this change
Part of modularizing Arrow. Allows these components to be used by tools that require JPMS modules such as jlink.

### What changes are included in this PR?
- Refactor memory modules so that all netty code is in netty-memory.
- All code being injected into Netty packages and have dependencies on Netty's package-private code go into a new module memory-netty-buffer-patch.
- The surefire command line has been changed to allow reflection on unsafe to be used by arrow-memory-core
- Add module-info files for arrow-memory-core and arrow-memory-unsafe

### Are these changes tested?
Yes, existing tests work when run with modules.

### Are there any user-facing changes?
Yes, users now need to put --add-opens=java.base/java.nio=org.apache.arrow.memory.core,ALL-UNNAMED on their java command line instead of --add-opens=java.base/java.nio=ALL-UNNAMED since memory-core is now a named module instead of unnamed.

 **This PR includes breaking changes to public APIs.** 
Yes, users now need to put --add-opens=java.base/java.nio=org.apache.arrow.memory.core,ALL-UNNAMED on their java command line instead of --add-opens=java.base/java.nio=ALL-UNNAMED since memory-core is now a named module instead of unnamed.
* Closes: #38998

Authored-by: James Duong <james.duong@improving.com>
Signed-off-by: David Li <li.davidm96@gmail.com>
clayburn pushed a commit to clayburn/arrow that referenced this issue Jan 23, 2024
### Rationale for this change
Create and integrate a maven plugin for compiling module-info.java files without using maven-compiler-plugin
and release 9+. This is necessary for supporting Java 8 unsafe code, which has different than unsafe code
in JDK 9.

### What changes are included in this PR?
- Add the module-info-compiler-maven-plugin and utilize it in the codebase.
- Exclude module-info.java files from maven-compiler-plugin.

### Are these changes tested?
Yes, they generate valid module-info.class files in JARs and test JARs.

### Are there any user-facing changes?
No
* Closes: apache#39134

Authored-by: James Duong <james.duong@improving.com>
Signed-off-by: David Li <li.davidm96@gmail.com>
clayburn pushed a commit to clayburn/arrow that referenced this issue Jan 23, 2024
…dules (apache#39011)

Depends on apache#39134 

### Rationale for this change
Part of modularizing Arrow. Allows these components to be used by tools that require JPMS modules such as jlink.

### What changes are included in this PR?
- Refactor memory modules so that all netty code is in netty-memory.
- All code being injected into Netty packages and have dependencies on Netty's package-private code go into a new module memory-netty-buffer-patch.
- The surefire command line has been changed to allow reflection on unsafe to be used by arrow-memory-core
- Add module-info files for arrow-memory-core and arrow-memory-unsafe

### Are these changes tested?
Yes, existing tests work when run with modules.

### Are there any user-facing changes?
Yes, users now need to put --add-opens=java.base/java.nio=org.apache.arrow.memory.core,ALL-UNNAMED on their java command line instead of --add-opens=java.base/java.nio=ALL-UNNAMED since memory-core is now a named module instead of unnamed.

 **This PR includes breaking changes to public APIs.** 
Yes, users now need to put --add-opens=java.base/java.nio=org.apache.arrow.memory.core,ALL-UNNAMED on their java command line instead of --add-opens=java.base/java.nio=ALL-UNNAMED since memory-core is now a named module instead of unnamed.
* Closes: apache#38998

Authored-by: James Duong <james.duong@improving.com>
Signed-off-by: David Li <li.davidm96@gmail.com>
dgreiss pushed a commit to dgreiss/arrow that referenced this issue Feb 19, 2024
### Rationale for this change
Create and integrate a maven plugin for compiling module-info.java files without using maven-compiler-plugin
and release 9+. This is necessary for supporting Java 8 unsafe code, which has different than unsafe code
in JDK 9.

### What changes are included in this PR?
- Add the module-info-compiler-maven-plugin and utilize it in the codebase.
- Exclude module-info.java files from maven-compiler-plugin.

### Are these changes tested?
Yes, they generate valid module-info.class files in JARs and test JARs.

### Are there any user-facing changes?
No
* Closes: apache#39134

Authored-by: James Duong <james.duong@improving.com>
Signed-off-by: David Li <li.davidm96@gmail.com>
dgreiss pushed a commit to dgreiss/arrow that referenced this issue Feb 19, 2024
…dules (apache#39011)

Depends on apache#39134 

### Rationale for this change
Part of modularizing Arrow. Allows these components to be used by tools that require JPMS modules such as jlink.

### What changes are included in this PR?
- Refactor memory modules so that all netty code is in netty-memory.
- All code being injected into Netty packages and have dependencies on Netty's package-private code go into a new module memory-netty-buffer-patch.
- The surefire command line has been changed to allow reflection on unsafe to be used by arrow-memory-core
- Add module-info files for arrow-memory-core and arrow-memory-unsafe

### Are these changes tested?
Yes, existing tests work when run with modules.

### Are there any user-facing changes?
Yes, users now need to put --add-opens=java.base/java.nio=org.apache.arrow.memory.core,ALL-UNNAMED on their java command line instead of --add-opens=java.base/java.nio=ALL-UNNAMED since memory-core is now a named module instead of unnamed.

 **This PR includes breaking changes to public APIs.** 
Yes, users now need to put --add-opens=java.base/java.nio=org.apache.arrow.memory.core,ALL-UNNAMED on their java command line instead of --add-opens=java.base/java.nio=ALL-UNNAMED since memory-core is now a named module instead of unnamed.
* Closes: apache#38998

Authored-by: James Duong <james.duong@improving.com>
Signed-off-by: David Li <li.davidm96@gmail.com>
zanmato1984 pushed a commit to zanmato1984/arrow that referenced this issue Feb 28, 2024
…dules (apache#39011)

Depends on apache#39134 

### Rationale for this change
Part of modularizing Arrow. Allows these components to be used by tools that require JPMS modules such as jlink.

### What changes are included in this PR?
- Refactor memory modules so that all netty code is in netty-memory.
- All code being injected into Netty packages and have dependencies on Netty's package-private code go into a new module memory-netty-buffer-patch.
- The surefire command line has been changed to allow reflection on unsafe to be used by arrow-memory-core
- Add module-info files for arrow-memory-core and arrow-memory-unsafe

### Are these changes tested?
Yes, existing tests work when run with modules.

### Are there any user-facing changes?
Yes, users now need to put --add-opens=java.base/java.nio=org.apache.arrow.memory.core,ALL-UNNAMED on their java command line instead of --add-opens=java.base/java.nio=ALL-UNNAMED since memory-core is now a named module instead of unnamed.

 **This PR includes breaking changes to public APIs.** 
Yes, users now need to put --add-opens=java.base/java.nio=org.apache.arrow.memory.core,ALL-UNNAMED on their java command line instead of --add-opens=java.base/java.nio=ALL-UNNAMED since memory-core is now a named module instead of unnamed.
* Closes: apache#38998

Authored-by: James Duong <james.duong@improving.com>
Signed-off-by: David Li <li.davidm96@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants