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

Bootstrap build and auto-fix JAR on Windows #11

Open
sormuras opened this issue Apr 2, 2017 · 7 comments
Open

Bootstrap build and auto-fix JAR on Windows #11

sormuras opened this issue Apr 2, 2017 · 7 comments

Comments

@sormuras
Copy link
Collaborator

sormuras commented Apr 2, 2017

When you drop an old JAR which needs to be fixed into ./deps folder and have code that refers to it already (like a new plugin), the module-fixer fails to transform the JAR into a module, as the compiler plugin(?) holds an handle to the JAR.

Workaround:

  • drop the JAR into deps
  • ./build (fixes the JAR) // without this call, the next build will fail
  • insert new plugin code requiring the new module
  • ./build
@forax
Copy link
Owner

forax commented Apr 2, 2017

Can you cut & paste the error message ?
It seems to be a Windows only error.

@sormuras
Copy link
Collaborator Author

sormuras commented Apr 2, 2017

Here you go:

C:\Dev\Github\sormuras\pro>build
[pro] registered plugins compiler, convention, linker, modulefixer, packager, resolver, runner, uberpackager
[modulefixer] fix junit.platform.console.standalone
java.nio.file.FileSystemException: C:\Dev\Github\sormuras\pro\deps\junit.platform.console.standalone-1.0.0_M4.jar: Der Prozess kann nicht auf die Datei zugreifen, da sie von einem anderen Prozess verwendet wird.

        at java.base/sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:92)
        at java.base/sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:103)
        at java.base/sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:108)
        at java.base/sun.nio.fs.WindowsFileCopy.move(WindowsFileCopy.java:373)
        at java.base/sun.nio.fs.WindowsFileSystemProvider.move(WindowsFileSystemProvider.java:288)
        at java.base/java.nio.file.Files.move(Files.java:1398)
        at jdk.jartool/sun.tools.jar.Main.validateAndClose(Main.java:454)
        at jdk.jartool/sun.tools.jar.Main.run(Main.java:360)
        at jdk.jartool/sun.tools.jar.JarToolProvider.run(JarToolProvider.java:37)
        at java.base/java.util.spi.ToolProvider.run(ToolProvider.java:137)
        at com.github.forax.pro.plugin.modulefixer/com.github.forax.pro.plugin.modulefixer.ModuleFixerPlugin.patchModularJar(ModuleFixerPlugin.java:193)
        at com.github.forax.pro.plugin.modulefixer/com.github.forax.pro.plugin.modulefixer.ModuleFixerPlugin.execute(ModuleFixerPlugin.java:185)
        at com.github.forax.pro/com.github.forax.pro.Pro.execute(Pro.java:267)
        at com.github.forax.pro/com.github.forax.pro.Pro.runAll(Pro.java:247)
        at com.github.forax.pro/com.github.forax.pro.Pro.run(Pro.java:237)
        at com.github.forax.pro.bootstrap/com.github.forax.pro.bootstrap.Bootstrap.main(Bootstrap.java:79)

@sormuras
Copy link
Collaborator Author

sormuras commented Apr 2, 2017

To reproduce, just add the line requires junit.platform.console.standalone; in one of your existing modules. I chose runner plugin:

module com.github.forax.pro.plugin.runner {
  requires com.github.forax.pro.api;
  requires com.github.forax.pro.helper;
  requires org.objectweb.asm.all.debug;
  requires junit.platform.console.standalone; // ***
  
  opens com.github.forax.pro.plugin.runner;
  
  provides com.github.forax.pro.api.Plugin
    with com.github.forax.pro.plugin.runner.RunnerPlugin;
}

If you remove the *** line, the module fixer does its job. After it is fixed, you can re-enter the requires line.

@forax
Copy link
Owner

forax commented Apr 2, 2017

Ok, it seems to be a bug of the JDK,
when i check each module, i use a ModuleFinder to read all ModuleDescriptor to know if i have to patch it or not. At that point, it seems that the ModuleFinder keep the jars of the modules open.
Then when i try to inject the new module-info.class, Windows (linux /macOs are fine) refuse to update the jar because the jar is still open.

I will try to create a small reproducible test and log a bug into the OpenJDK jira.

@sormuras sormuras changed the title Bootstrap build and auto-fix JAR Bootstrap build and auto-fix JAR on Windows Apr 16, 2017
@sormuras
Copy link
Collaborator Author

sormuras commented Jun 7, 2019

Alan Bateman wrote:
That said, it might be time to change the Windows sharing mode that JarFile/ZipFile uses to open JAR files. I'll create an issue for that.

http://mail.openjdk.java.net/pipermail/jigsaw-dev/2019-May/014228.html

Issue: https://bugs.openjdk.java.net/browse/JDK-8224794

@sormuras
Copy link
Collaborator Author

sormuras commented Jan 4, 2020

Hey Rémi,

shall we close this issue or keep it open to have "external integration test" for JDK-8224794?

@forax
Copy link
Owner

forax commented Jan 4, 2020

Given that the bug is still there, i don't see the point to close it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants