building the JDK on Windows using Cygwin
(changed Subject line. was: Is anyone able to build the JDK on Windows using VirtualBox to host Ubuntu?) I downloaded and unzipped openjdk. $ ls jdk jdk-22.0.1 openjdk-22.0.1_windows-x64_bin.zip but still I get the same error message configure: Could not find a valid Boot JDK. OpenJDK distributions are > available at http://jdk.java.net/. > configure: This might be fixed by explicitly setting --with-boot-jdk > configure: error: Cannot continue > configure exiting with result code 1 I am wondering if I should *not *install the Open JDK in the directory created by Cygwin (/c/Users/Anil/OpenJDK) but install it in the /cygdrive Windows folders? (I observe that the folder created in Cygwin is not visible outside, in Windows even after rebooting the laptop). Can someone please confirm? thanks, Anil On Fri, Jun 28, 2024 at 6:48 PM Anil <1dropafl...@gmail.com> wrote: > Thank you. I installed Cygwin on my Windows 11 laptop, and after > overcoming some minor blocks, ran 'bash configure'. > Am I correct in assuming that I also need to have Open JDK installed, not > the Oracle JDK? > I have Java 17 from Oracle installed. > > configure: Found potential Boot JDK using JAVA_HOME > configure: Potential Boot JDK found at > /cygdrive/c/progra~1/java/jdk-17.0.4.1 is); ignoringot(TM) 64-Bit Server VM > (build 17.0.4.1+1-LTS-2, mixed mode, sharing) > configure: (Your Boot JDK version must be one of: 22 23 24) > checking for javac... > /cygdrive/c/progra~1/common~1/oracle/java/javapath/javac.exe > checking for java... > /cygdrive/c/progra~1/common~1/oracle/java/javapath/java.exe > configure: Found potential Boot JDK using well-known locations (in > /cygdrive/c/progra~1/java/jdk-17.0.4.1) > configure: Potential Boot JDK found at > /cygdrive/c/progra~1/java/jdk-17.0.4.1 is); ignoringot(TM) 64-Bit Server VM > (build 17.0.4.1+1-LTS-2, mixed mode, sharing) > configure: (Your Boot JDK version must be one of: 22 23 24) > configure: Found potential Boot JDK using well-known locations (in > /cygdrive/c/progra~1/java/jdk-11.0.10) > configure: Potential Boot JDK found at > /cygdrive/c/progra~1/java/jdk-11.0.10 is ); ignoringot(TM) 64-Bit Server VM > 18.9 (build 11.0.10+8-LTS-162, mixed mode) > configure: (Your Boot JDK version must be one of: 22 23 24) > configure: Found potential Boot JDK using well-known locations (in > /cygdrive/c/progra~1/java/javafx-sdk-11.0.2) > configure: Potential Boot JDK found at > /cygdrive/c/progra~1/java/javafx-sdk-11.0.2 did not contain bin/java; > ignoring > configure: Found potential Boot JDK using well-known locations (in > /cygdrive/c/progra~1/java/jdk-17.0.4.1) > configure: Potential Boot JDK found at > /cygdrive/c/progra~1/java/jdk-17.0.4.1 is); ignoringot(TM) 64-Bit Server VM > (build 17.0.4.1+1-LTS-2, mixed mode, sharing) > configure: (Your Boot JDK version must be one of: 22 23 24) > configure: Found potential Boot JDK using well-known locations (in > /cygdrive/c/progra~1/java/jdk-11.0.10) > configure: Potential Boot JDK found at > /cygdrive/c/progra~1/java/jdk-11.0.10 is ); ignoringot(TM) 64-Bit Server VM > 18.9 (build 11.0.10+8-LTS-162, mixed mode) > configure: (Your Boot JDK version must be one of: 22 23 24) > configure: Found potential Boot JDK using well-known locations (in > /cygdrive/c/progra~1/java/javafx-sdk-11.0.2) > configure: Potential Boot JDK found at > /cygdrive/c/progra~1/java/javafx-sdk-11.0.2 did not contain bin/java; > ignoring > configure: Found potential Boot JDK using well-known locations (in > /cygdrive/c/Program Files/Java/jdk-17.0.4.1) > configure: Potential Boot JDK found at /cygdrive/c/Program > Files/Java/jdk-17.0.4); ignoringot(TM) 64-Bit Server VM (build > 17.0.4.1+1-LTS-2, mixed mode, sharing) > configure: (Your Boot JDK version must be one of: 22 23 24) > configure: Found potential Boot JDK using well-known locations (in > /cygdrive/c/Program Files/Java/jdk-11.0.10) > configure: Potential Boot JDK found at /cygdrive/c/Program > Files/Java/jdk-11.0.1); ignoringot(TM) 64-Bit Server VM 18.9 (build > 11.0.10+8-LTS-162, mixed mode) > configure: (Your Boot JDK version must be one of: 22 23 24) > configure: Found potential Boot JDK using well-known locations (in > /cygdrive/c/Program Files/Java/javafx-sdk-11.0.2) > configure: Potential Boot JDK found at /cygdrive/c/Program > Files/Java/javafx-sdk-11.0.2 did not contain bin/java; ignoring > configure: Could not find a valid Boot JDK. OpenJDK distributions are > available at http://jdk.java.net/. > configure: This might be fixed by explicitly setting --with-boot-jdk > configure: error: Cannot continue > configure exiting with result code 1 > > > On Thu, Jun 27, 2024 at 9:06 AM wrote: > >> Hello Anil, >> >> Building in a VM on a laptop should be doable, but given how resource >> intensive the JDK build is, you could run into problems like you describe. >> You are most likely to get the best build performance running natively on >> the machine and OS you have, so my recommendation is to build for Windows >> in your
Re: Is anyone able to build the JDK on Windows using VirtualBox to host Ubuntu?
Thank you. I installed Cygwin on my Windows 11 laptop, and after overcoming some minor blocks, ran 'bash configure'. Am I correct in assuming that I also need to have Open JDK installed, not the Oracle JDK? I have Java 17 from Oracle installed. configure: Found potential Boot JDK using JAVA_HOME configure: Potential Boot JDK found at /cygdrive/c/progra~1/java/jdk-17.0.4.1 is); ignoringot(TM) 64-Bit Server VM (build 17.0.4.1+1-LTS-2, mixed mode, sharing) configure: (Your Boot JDK version must be one of: 22 23 24) checking for javac... /cygdrive/c/progra~1/common~1/oracle/java/javapath/javac.exe checking for java... /cygdrive/c/progra~1/common~1/oracle/java/javapath/java.exe configure: Found potential Boot JDK using well-known locations (in /cygdrive/c/progra~1/java/jdk-17.0.4.1) configure: Potential Boot JDK found at /cygdrive/c/progra~1/java/jdk-17.0.4.1 is); ignoringot(TM) 64-Bit Server VM (build 17.0.4.1+1-LTS-2, mixed mode, sharing) configure: (Your Boot JDK version must be one of: 22 23 24) configure: Found potential Boot JDK using well-known locations (in /cygdrive/c/progra~1/java/jdk-11.0.10) configure: Potential Boot JDK found at /cygdrive/c/progra~1/java/jdk-11.0.10 is ); ignoringot(TM) 64-Bit Server VM 18.9 (build 11.0.10+8-LTS-162, mixed mode) configure: (Your Boot JDK version must be one of: 22 23 24) configure: Found potential Boot JDK using well-known locations (in /cygdrive/c/progra~1/java/javafx-sdk-11.0.2) configure: Potential Boot JDK found at /cygdrive/c/progra~1/java/javafx-sdk-11.0.2 did not contain bin/java; ignoring configure: Found potential Boot JDK using well-known locations (in /cygdrive/c/progra~1/java/jdk-17.0.4.1) configure: Potential Boot JDK found at /cygdrive/c/progra~1/java/jdk-17.0.4.1 is); ignoringot(TM) 64-Bit Server VM (build 17.0.4.1+1-LTS-2, mixed mode, sharing) configure: (Your Boot JDK version must be one of: 22 23 24) configure: Found potential Boot JDK using well-known locations (in /cygdrive/c/progra~1/java/jdk-11.0.10) configure: Potential Boot JDK found at /cygdrive/c/progra~1/java/jdk-11.0.10 is ); ignoringot(TM) 64-Bit Server VM 18.9 (build 11.0.10+8-LTS-162, mixed mode) configure: (Your Boot JDK version must be one of: 22 23 24) configure: Found potential Boot JDK using well-known locations (in /cygdrive/c/progra~1/java/javafx-sdk-11.0.2) configure: Potential Boot JDK found at /cygdrive/c/progra~1/java/javafx-sdk-11.0.2 did not contain bin/java; ignoring configure: Found potential Boot JDK using well-known locations (in /cygdrive/c/Program Files/Java/jdk-17.0.4.1) configure: Potential Boot JDK found at /cygdrive/c/Program Files/Java/jdk-17.0.4); ignoringot(TM) 64-Bit Server VM (build 17.0.4.1+1-LTS-2, mixed mode, sharing) configure: (Your Boot JDK version must be one of: 22 23 24) configure: Found potential Boot JDK using well-known locations (in /cygdrive/c/Program Files/Java/jdk-11.0.10) configure: Potential Boot JDK found at /cygdrive/c/Program Files/Java/jdk-11.0.1); ignoringot(TM) 64-Bit Server VM 18.9 (build 11.0.10+8-LTS-162, mixed mode) configure: (Your Boot JDK version must be one of: 22 23 24) configure: Found potential Boot JDK using well-known locations (in /cygdrive/c/Program Files/Java/javafx-sdk-11.0.2) configure: Potential Boot JDK found at /cygdrive/c/Program Files/Java/javafx-sdk-11.0.2 did not contain bin/java; ignoring configure: Could not find a valid Boot JDK. OpenJDK distributions are available at http://jdk.java.net/. configure: This might be fixed by explicitly setting --with-boot-jdk configure: error: Cannot continue configure exiting with result code 1 On Thu, Jun 27, 2024 at 9:06 AM wrote: > Hello Anil, > > Building in a VM on a laptop should be doable, but given how resource > intensive the JDK build is, you could run into problems like you describe. > You are most likely to get the best build performance running natively on > the machine and OS you have, so my recommendation is to build for Windows > in your case. If you still prefer to build for Linux, I think the best > option is to use WSL. See doc/building.md for instructions on how to build > for Linux in WSL. To build for Windows, I recommend installing Cygwin as > the most straightforward and well tested option for a POSIX support layer > on Windows. Once installed, you won't need to run any Windows commands as > Cygwin emulates a Linux/Unix environment. Again see doc/building.md for > instructions on how to install a build environment on Windows. > > /Erik > On 6/27/24 04:51, Anil wrote: > > I want to try out a small contribution to the JDK and want to build the > JDK first. > I have a Windows 11 laptop. > > I am not comfortable with the Windows commands and someone mentioned in > this forum that most of the building is done on Linux. > So I installed VirtualBox 7.0.18 and Ubuntu 24.04. however I was getting > black screens and freezing. I downgraded the Ubuntu to 222.04 and still got > black screens. I don't know why this is happening. > Any advice appreciated. >
Re: RFR: 8317611: Add a tool like jdeprscan to find usage of restricted methods [v10]
On Fri, 28 Jun 2024 19:43:36 GMT, Jorn Vernee wrote:
>> This PR adds a new JDK tool, called `jnativescan`, that can be used to find
>> code that accesses native functionality. Currently this includes `native`
>> method declarations, and methods marked with `@Restricted`.
>>
>> The tool accepts a list of class path and module path entries through
>> `--class-path` and `--module-path`, and a set of root modules through
>> `--add-modules`, as well as an optional target release with `--release`.
>>
>> The default mode is for the tool to report all uses of `@Restricted`
>> methods, and `native` method declaration in a tree-like structure:
>>
>>
>> app.jar (ALL-UNNAMED):
>> main.Main:
>> main.Main::main(String[])void references restricted methods:
>> java.lang.foreign.MemorySegment::reinterpret(long)MemorySegment
>> main.Main::m()void is a native method declaration
>>
>>
>> The `--print-native-access` option can be used print out all the module
>> names of modules doing native access in a comma separated list. For class
>> path code, this will print out `ALL-UNNAMED`.
>>
>> Testing:
>> - `langtools_jnativescan` tests.
>> - Running the tool over jextract's libclang bindings, which use the FFM API,
>> and thus has a lot of references to `@Restricted` methods.
>> - tier 1-3
>
> Jorn Vernee has updated the pull request incrementally with one additional
> commit since the last revision:
>
> use instance resolveAndBind + use junit in tests
src/jdk.jdeps/share/classes/com/sun/tools/jnativescan/MethodRef.java line 38:
> 36: }
> 37:
> 38: public static MethodRef ofMemberRefEntry(MemberRefEntry method) {
I recommend to change this to `ofInvokeInstruction`:
public static MethodRef ofInvokeInstruction(InvokeInstruction instruction) {
return new MethodRef(instruction.owner().asSymbol(),
instruction.name().stringValue(), instruction.typeSymbol());
}
-
PR Review Comment: https://git.openjdk.org/jdk/pull/19774#discussion_r1659345527
Re: RFR: 8317611: Add a tool like jdeprscan to find usage of restricted methods [v9]
On Fri, 28 Jun 2024 16:47:27 GMT, Alan Bateman wrote:
>> Jorn Vernee has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> de-dupe on path, not module name
>
> src/jdk.jdeps/share/classes/com/sun/tools/jnativescan/JNativeScanTask.java
> line 105:
>
>> 103: for (String classPathEntry : classPathAttribute) {
>> 104: Path otherJar = parentDir != null
>> 105: ? parentDir.resolve(classPathEntry)
>
> We'lll need to create a follow on issue to re-examine this as the value of a
> Class-Path attribute aren't sequence of relative URIs (with an optional
> "file" URI scheme) rather than file paths. Treating it as a file path may
> work in some cases but won't work once you encounter cases that use escaping.
Okay, it seems that I didn't read the spec careful enough, and filtering valid
URLs in the Class-Path attribute is actually a bit tricky. Let's handle this in
a follow up.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/19774#discussion_r1659242843
Re: RFR: 8317611: Add a tool like jdeprscan to find usage of restricted methods [v10]
> This PR adds a new JDK tool, called `jnativescan`, that can be used to find > code that accesses native functionality. Currently this includes `native` > method declarations, and methods marked with `@Restricted`. > > The tool accepts a list of class path and module path entries through > `--class-path` and `--module-path`, and a set of root modules through > `--add-modules`, as well as an optional target release with `--release`. > > The default mode is for the tool to report all uses of `@Restricted` methods, > and `native` method declaration in a tree-like structure: > > > app.jar (ALL-UNNAMED): > main.Main: > main.Main::main(String[])void references restricted methods: > java.lang.foreign.MemorySegment::reinterpret(long)MemorySegment > main.Main::m()void is a native method declaration > > > The `--print-native-access` option can be used print out all the module names > of modules doing native access in a comma separated list. For class path > code, this will print out `ALL-UNNAMED`. > > Testing: > - `langtools_jnativescan` tests. > - Running the tool over jextract's libclang bindings, which use the FFM API, > and thus has a lot of references to `@Restricted` methods. > - tier 1-3 Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: use instance resolveAndBind + use junit in tests - Changes: - all: https://git.openjdk.org/jdk/pull/19774/files - new: https://git.openjdk.org/jdk/pull/19774/files/40ca91ed..c597f247 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk=19774=09 - incr: https://webrevs.openjdk.org/?repo=jdk=19774=08-09 Stats: 68 lines in 5 files changed: 1 ins; 1 del; 66 mod Patch: https://git.openjdk.org/jdk/pull/19774.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19774/head:pull/19774 PR: https://git.openjdk.org/jdk/pull/19774
Re: RFR: 8317611: Add a tool like jdeprscan to find usage of restricted methods [v9]
On Mon, 24 Jun 2024 12:57:39 GMT, Jorn Vernee wrote: >> This PR adds a new JDK tool, called `jnativescan`, that can be used to find >> code that accesses native functionality. Currently this includes `native` >> method declarations, and methods marked with `@Restricted`. >> >> The tool accepts a list of class path and module path entries through >> `--class-path` and `--module-path`, and a set of root modules through >> `--add-modules`, as well as an optional target release with `--release`. >> >> The default mode is for the tool to report all uses of `@Restricted` >> methods, and `native` method declaration in a tree-like structure: >> >> >> app.jar (ALL-UNNAMED): >> main.Main: >> main.Main::main(String[])void references restricted methods: >> java.lang.foreign.MemorySegment::reinterpret(long)MemorySegment >> main.Main::m()void is a native method declaration >> >> >> The `--print-native-access` option can be used print out all the module >> names of modules doing native access in a comma separated list. For class >> path code, this will print out `ALL-UNNAMED`. >> >> Testing: >> - `langtools_jnativescan` tests. >> - Running the tool over jextract's libclang bindings, which use the FFM API, >> and thus has a lot of references to `@Restricted` methods. >> - tier 1-3 > > Jorn Vernee has updated the pull request incrementally with one additional > commit since the last revision: > > de-dupe on path, not module name src/jdk.jdeps/share/classes/com/sun/tools/jnativescan/JNativeScanTask.java line 69: > 67: } > 68: Configuration config = Configuration.resolveAndBind(moduleFinder, > List.of(systemConfiguration()), > 69: ModuleFinder.of(), rootModules); I think the module path should work like other tools so the "moduleFinder" should be "after" finder, not the "before" finder. In other words, the modules that are observable on the application module path don't override the system modules. If you want you can use an instance method here, like this: `systemConfiguration().resovleAndBind(ModuleFinder.of(), moduleFinder, rootModules)` - PR Review Comment: https://git.openjdk.org/jdk/pull/19774#discussion_r1659028434
Re: RFR: 8317611: Add a tool like jdeprscan to find usage of restricted methods [v9]
On Mon, 24 Jun 2024 12:57:39 GMT, Jorn Vernee wrote:
>> This PR adds a new JDK tool, called `jnativescan`, that can be used to find
>> code that accesses native functionality. Currently this includes `native`
>> method declarations, and methods marked with `@Restricted`.
>>
>> The tool accepts a list of class path and module path entries through
>> `--class-path` and `--module-path`, and a set of root modules through
>> `--add-modules`, as well as an optional target release with `--release`.
>>
>> The default mode is for the tool to report all uses of `@Restricted`
>> methods, and `native` method declaration in a tree-like structure:
>>
>>
>> app.jar (ALL-UNNAMED):
>> main.Main:
>> main.Main::main(String[])void references restricted methods:
>> java.lang.foreign.MemorySegment::reinterpret(long)MemorySegment
>> main.Main::m()void is a native method declaration
>>
>>
>> The `--print-native-access` option can be used print out all the module
>> names of modules doing native access in a comma separated list. For class
>> path code, this will print out `ALL-UNNAMED`.
>>
>> Testing:
>> - `langtools_jnativescan` tests.
>> - Running the tool over jextract's libclang bindings, which use the FFM API,
>> and thus has a lot of references to `@Restricted` methods.
>> - tier 1-3
>
> Jorn Vernee has updated the pull request incrementally with one additional
> commit since the last revision:
>
> de-dupe on path, not module name
src/jdk.jdeps/share/classes/com/sun/tools/jnativescan/JNativeScanTask.java line
105:
> 103: for (String classPathEntry : classPathAttribute) {
> 104: Path otherJar = parentDir != null
> 105: ? parentDir.resolve(classPathEntry)
We'lll need to create a follow on issue to re-examine this as the value of a
Class-Path attribute aren't sequence of relative URIs (with an optional "file"
URI scheme) rather than file paths. Treating it as a file path may work in some
cases but won't work once you encounter cases that use escaping.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/19774#discussion_r1659018308
Re: RFR: 8317611: Add a tool like jdeprscan to find usage of restricted methods [v9]
On Mon, 24 Jun 2024 12:57:39 GMT, Jorn Vernee wrote: >> This PR adds a new JDK tool, called `jnativescan`, that can be used to find >> code that accesses native functionality. Currently this includes `native` >> method declarations, and methods marked with `@Restricted`. >> >> The tool accepts a list of class path and module path entries through >> `--class-path` and `--module-path`, and a set of root modules through >> `--add-modules`, as well as an optional target release with `--release`. >> >> The default mode is for the tool to report all uses of `@Restricted` >> methods, and `native` method declaration in a tree-like structure: >> >> >> app.jar (ALL-UNNAMED): >> main.Main: >> main.Main::main(String[])void references restricted methods: >> java.lang.foreign.MemorySegment::reinterpret(long)MemorySegment >> main.Main::m()void is a native method declaration >> >> >> The `--print-native-access` option can be used print out all the module >> names of modules doing native access in a comma separated list. For class >> path code, this will print out `ALL-UNNAMED`. >> >> Testing: >> - `langtools_jnativescan` tests. >> - Running the tool over jextract's libclang bindings, which use the FFM API, >> and thus has a lot of references to `@Restricted` methods. >> - tier 1-3 > > Jorn Vernee has updated the pull request incrementally with one additional > commit since the last revision: > > de-dupe on path, not module name test/langtools/tools/jnativescan/TestJNativeScan.java line 33: > 31: * cases.classpath.app.App > 32: * cases.classpath.unnamed_package.UnnamedPackage > 33: * @run testng TestJNativeScan We've using JUnit rather than in TestNG for new tests, this one looks strange forward to move if we want. - PR Review Comment: https://git.openjdk.org/jdk/pull/19774#discussion_r1659011377
Re: RFR: 8317611: Add a tool like jdeprscan to find usage of restricted methods [v5]
On Thu, 20 Jun 2024 19:37:23 GMT, Jorn Vernee wrote: > It looks like it's possible to get even more custom by using a custom > `HelpFormatter` as well, if we wanted. I think what you have is okay for the first integration, just looks odd to have the help/usage say "String" and "Path". Using a help formatter can be something for a follow-up issue, assuming it feasible. - PR Comment: https://git.openjdk.org/jdk/pull/19774#issuecomment-2197088172
Re: RFR: 8329816: Add SLEEF version 3.6.1
On Thu, 27 Jun 2024 21:59:30 GMT, Mikael Vidstedt wrote: >> In case you need it and avoid to generate yourself, I've generated sleef >> inline header of 3.6.1 for riscv, it's at >> https://github.com/openjdk/jdk/pull/18605/commits/c279a3c290554892939267d9ebe88198988d31a4 > > @Hamlin-Li I have generated the header files (two aarch64 and the new one for > riscv64) using SLEEF 3.6.1. Please make sure they match your expectations! @vidmik Thanks for updating, I think I'd better to verify it in case we need uncessary further changes. Will update when I finish. - PR Comment: https://git.openjdk.org/jdk/pull/19185#issuecomment-2196492518
