Re: java.util.zip.CRC32C cannot be found on the system module path
On 04/04/2018 09:11 AM, Glenn Holmer wrote: > On 04/03/2018 06:08 PM, Efrem Mc wrote: >> I went to an existing Java Application, and switched it from JDK8 >> (default) to JDK10. I rebuild using Clean and Build >> I received no error message and was able to run the app without any errors. > >> I am not sure these are the steps mention. Please advise. > > It was when starting the profiler, but this morning I tried again after > deleting userdir, cache, and sample project, and couldn't reproduce it. > I'm assuming it had to do with changing source level and JDK version > repeatedly during testing. No wait, I just triggered it three times in a row. In the profiler test spec, do test suite 8 (Profiling Points), test case 1 (Stopwatch and Reset Results) under JDK 10. I see this on step 14, when the Anagram class is selected. Message is: Even though the source level of /home/cenbe/NetBeansProjects/AnagramGame/src:/home/cenbe/NetBeansProjects/AnagramGame/test is set to: 1.6, java.lang.AssertionError cannot be found on the bootclasspath: Changing source level to 1.3 This is with the AnagramGame project's source level set to JDK 6 (which it defaults to). Setting it to JDK 10 gives the following: Even though the source level of /home/cenbe/NetBeansProjects/AnagramGame/test:/home/cenbe/NetBeansProjects/AnagramGame/src is set to: 10, java.lang.AssertionError cannot be found on the bootclasspath: Changing source level to 1.3 Even though the source level of /home/cenbe/NetBeansProjects/AnagramGame/test:/home/cenbe/NetBeansProjects/AnagramGame/src is set to: 10, java.util.zip.CRC32C cannot be found on the system module path: Changing source level to 1.8 Even though the source level of /home/cenbe/NetBeansProjects/AnagramGame/test:/home/cenbe/NetBeansProjects/AnagramGame/src is set to: 10, java.util.zip.CRC32C cannot be found on the system module path: Changing source level to 1.8 >>> On Tue, Apr 3, 2018 at 5:33 PM, Glenn Holmer wrote: I'm also seeing this for java.lang.AssertionError (when starting the profiler against the Anagram Game sample project under JDK 10), with a message saying "Changing source level to 1.3" (looks like lines 970-977 of JavacParser). -- Glenn Holmer (Linux registered user #16682) "After the vintage season came the aftermath -- and Cenbe." - To unsubscribe, e-mail: users-unsubscr...@netbeans.apache.org For additional commands, e-mail: users-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: java.util.zip.CRC32C cannot be found on the system module path
On 04/03/2018 06:08 PM, Efrem Mc wrote: > I went to an existing Java Application, and switched it from JDK8 > (default) to JDK10. I rebuild using Clean and Build > I received no error message and was able to run the app without any errors. > I am not sure these are the steps mention. Please advise. It was when starting the profiler, but this morning I tried again after deleting userdir, cache, and sample project, and couldn't reproduce it. I'm assuming it had to do with changing source level and JDK version repeatedly during testing. >> On Tue, Apr 3, 2018 at 5:33 PM, Glenn Holmer wrote: >>> I'm also seeing this for java.lang.AssertionError (when starting the >>> profiler against the Anagram Game sample project under JDK 10), with a >>> message saying "Changing source level to 1.3" (looks like lines 970-977 >>> of JavacParser). -- Glenn Holmer (Linux registered user #16682) "After the vintage season came the aftermath -- and Cenbe." - To unsubscribe, e-mail: users-unsubscr...@netbeans.apache.org For additional commands, e-mail: users-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: java.util.zip.CRC32C cannot be found on the system module path
For me it is working running maven, too, but NetBeans is lowering the source
level to 1.8. Because of this all usages of Java 9 Syntax (the new try-catch
for example) are marked as invalid and compile-on-save is not working cleanly.
As noted, the code in JavacParser checks the variable bootClassPath for all
JDK versions up to 1.8, and the moduleBoot for 9+. But the warning message for
the missing CRC32C class is printing the bootClassPath even for 9+, so this
seems to be a bug in the logging code (Copy-paste from 1.8...)
In my case, if I change this logging to moduleBoot I see that moduleBoot is
empty, and so it is not able to find the CRC32C class and thinks it is running
on JDK 1.8. So either way I have configured something wrong so that the
moduleBoot is empty, NetBeans is not supporting OpenJDK and cannot detect the
moduleBoot cleanly, or the check routine in JavacParser needs to use the
bootClassPath for JDK 9+, too.
I do not know much about the new module system, is it possible that the
moduleBoot is empty because my project is not using modularization, so there
is no module-info?
Am Mittwoch, 4. April 2018, 01:08:09 CEST schrieb Efrem Mc:
> HI Glenn,
>
> I went to an existing Java Application, and switched it from JDK8
> (default) to JDK10. I rebuild using Clean and Build
> I received no error message and was able to run the app without any errors.
>
> Output:
>
> ant -f P:\\testing\\netcat9\\srctest\\projects\\JavaApplication19
> -Dnb.internal.action.name=rebuild clean jar
> init:
> deps-clean:
> Updating property file:
> P:\testing\netcat9\srctest\projects\JavaApplication19\build\built-clean.prop
> erties Deleting directory
> P:\testing\netcat9\srctest\projects\JavaApplication19\build clean:
> init:
> deps-jar:
> Created dir: P:\testing\netcat9\srctest\projects\JavaApplication19\build
> Updating property file:
> P:\testing\netcat9\srctest\projects\JavaApplication19\build\built-jar.proper
> ties Created dir:
> P:\testing\netcat9\srctest\projects\JavaApplication19\build\classes Created
> dir: P:\testing\netcat9\srctest\projects\JavaApplication19\build\empty
> Created dir:
> P:\testing\netcat9\srctest\projects\JavaApplication19\build\generated-sourc
> es\ap-source-output Compiling 1 source file to
> P:\testing\netcat9\srctest\projects\JavaApplication19\build\classes
> Copying 1 file to
> P:\testing\netcat9\srctest\projects\JavaApplication19\build\classes
> compile:
> Created dir: P:\testing\netcat9\srctest\projects\JavaApplication19\dist
> Copying 1 file to
> P:\testing\netcat9\srctest\projects\JavaApplication19\build Building jar:
> P:\testing\netcat9\srctest\projects\JavaApplication19\dist\JavaApplication1
> 9.jar deploy:
> jar:
> BUILD SUCCESSFUL (total time: 0 seconds)
>
>
> I am not sure these are the steps mention. Please advise.
>
> Thanks,
>
> Efrem McCrimon
> GUI Builder Tribe
> DB Tribe
>
> On Tue, Apr 3, 2018 at 6:50 PM, Efrem Mc wrote:
> > Hi all:
> >
> > Does it matter if you are using JDK8, JDK10, or OpenJDK > 8/9/10> that may contain this jar file?
> >
> > I noticed in the original report it had openjdk-# and it appears that
> > source file does some type of checking.
> >
> > What are the steps or the test case, I can run to see if I can reproduce
> > it?
> >
> > Thanks,
> >
> > Efrem McCrimon
> > GUI Builder Tribe
> > DB Tribe
> >
> > On Tue, Apr 3, 2018 at 5:33 PM, Glenn Holmer wrote:
> >> On 04/03/2018 03:56 AM, Marcel Witte wrote:
> >>> I checked the source for this error and found something interesting. In
> >>> JavacParser there is the check for the different JDK versions. Every
> >>> check up to 1.8 checks the bootClassPath for a specific JDK class, but
> >>> the check for 9 checks the moduleBoot. Sadly, the log output seems to
> >>> be copy-paste, as it still shows the bootClassPath. If I apply the
> >>> following patch:
> >>>
> >>> @@ -1005,7 +1000,7 @@ public class JavacParser extends Parser {
> >>>
> >>> LOGGER.log(warnLevel,
> >>>
> >>> "Even though the source level of {0} is
> >>> set
> >>>
> >>> to: {1}, java.util.zip.CRC32C cannot be found on the system module path:
> >>> {2} \n" + //NOI18N
> >>>
> >>> "Changing source level to 1.8",
> >>> //NOI18N
> >>>
> >>> - new Object[]{srcClassPath, sourceLevel,
> >>> bootClassPath}); //NOI18N
> >>> + new Object[]{srcClassPath, sourceLevel,
> >>> moduleBoot}); //NOI18N
> >>>
> >>> return SourceLevelUtils.JDK1_8;
> >>>
> >>> }
> >>> return source;
> >>>
> >>> then I get a log the same log output about changing back to 1.8
> >>
> >> I'm also seeing this for java.lang.AssertionError (when starting the
> >> profiler against the Anagram Game sample project under JDK 10), with a
> >> messag
Re: java.util.zip.CRC32C cannot be found on the system module path
This appears to be the same as I reported @ [NETBEANS-413].
In my case I was implementing jdk9 WebSocket. jdk8 WebSocket is entirely
different and does not show the error -- for whatever reason.
On Tue, Apr 3, 2018 at 4:08 PM, Efrem Mc wrote:
> HI Glenn,
>
> I went to an existing Java Application, and switched it from JDK8
> (default) to JDK10. I rebuild using Clean and Build
> I received no error message and was able to run the app without any errors.
>
> Output:
>
> ant -f P:\\testing\\netcat9\\srctest\\projects\\JavaApplication19
> -Dnb.internal.action.name=rebuild clean jar
> init:
> deps-clean:
> Updating property file:
> P:\testing\netcat9\srctest\projects\JavaApplication19\
> build\built-clean.properties
> Deleting directory P:\testing\netcat9\srctest\projects\JavaApplication19\
> build
> clean:
> init:
> deps-jar:
> Created dir: P:\testing\netcat9\srctest\projects\JavaApplication19\build
> Updating property file:
> P:\testing\netcat9\srctest\projects\JavaApplication19\
> build\built-jar.properties
> Created dir: P:\testing\netcat9\srctest\projects\JavaApplication19\
> build\classes
> Created dir: P:\testing\netcat9\srctest\projects\JavaApplication19\
> build\empty
> Created dir: P:\testing\netcat9\srctest\projects\JavaApplication19\
> build\generated-sources\ap-source-output
> Compiling 1 source file to
> P:\testing\netcat9\srctest\projects\JavaApplication19\build\classes
> Copying 1 file to
> P:\testing\netcat9\srctest\projects\JavaApplication19\build\classes
> compile:
> Created dir: P:\testing\netcat9\srctest\projects\JavaApplication19\dist
> Copying 1 file to P:\testing\netcat9\srctest\projects\JavaApplication19\
> build
> Building jar: P:\testing\netcat9\srctest\projects\JavaApplication19\
> dist\JavaApplication19.jar
> deploy:
> jar:
> BUILD SUCCESSFUL (total time: 0 seconds)
>
>
> I am not sure these are the steps mention. Please advise.
>
> Thanks,
>
> Efrem McCrimon
> GUI Builder Tribe
> DB Tribe
>
>
> On Tue, Apr 3, 2018 at 6:50 PM, Efrem Mc wrote:
> > Hi all:
> >
> > Does it matter if you are using JDK8, JDK10, or OpenJDK > 8/9/10> that may contain this jar file?
> >
> > I noticed in the original report it had openjdk-# and it appears that
> > source file does some type of checking.
> >
> > What are the steps or the test case, I can run to see if I can reproduce
> it?
> >
> > Thanks,
> >
> > Efrem McCrimon
> > GUI Builder Tribe
> > DB Tribe
> >
> >
> > On Tue, Apr 3, 2018 at 5:33 PM, Glenn Holmer wrote:
> >> On 04/03/2018 03:56 AM, Marcel Witte wrote:
> >>> I checked the source for this error and found something interesting. In
> >>> JavacParser there is the check for the different JDK versions. Every
> check up
> >>> to 1.8 checks the bootClassPath for a specific JDK class, but the
> check for 9
> >>> checks the moduleBoot. Sadly, the log output seems to be copy-paste,
> as it
> >>> still shows the bootClassPath. If I apply the following patch:
> >>>
> >>> @@ -1005,7 +1000,7 @@ public class JavacParser extends Parser {
> >>> LOGGER.log(warnLevel,
> >>> "Even though the source level of {0}
> is set
> >>> to: {1}, java.util.zip.CRC32C cannot be found on the system module
> path: {2}
> >>> \n" + //NOI18N
> >>> "Changing source level to 1.8",
> //NOI18N
> >>> - new Object[]{srcClassPath, sourceLevel,
> >>> bootClassPath}); //NOI18N
> >>> + new Object[]{srcClassPath, sourceLevel,
> >>> moduleBoot}); //NOI18N
> >>> return SourceLevelUtils.JDK1_8;
> >>> }
> >>> return source;
> >>>
> >>> then I get a log the same log output about changing back to 1.8
> >>
> >> I'm also seeing this for java.lang.AssertionError (when starting the
> >> profiler against the Anagram Game sample project under JDK 10), with a
> >> message saying "Changing source level to 1.3" (looks like lines 970-977
> >> of JavacParser).
> >>
> >> --
> >> Glenn Holmer (Linux registered user #16682)
> >> "After the vintage season came the aftermath -- and Cenbe."
> >>
> >> -
> >> To unsubscribe, e-mail: users-unsubscr...@netbeans.apache.org
> >> For additional commands, e-mail: users-h...@netbeans.apache.org
> >>
> >> For further information about the NetBeans mailing lists, visit:
> >> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
> >>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@netbeans.apache.org
> For additional commands, e-mail: users-h...@netbeans.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
Re: java.util.zip.CRC32C cannot be found on the system module path
HI Glenn,
I went to an existing Java Application, and switched it from JDK8
(default) to JDK10. I rebuild using Clean and Build
I received no error message and was able to run the app without any errors.
Output:
ant -f P:\\testing\\netcat9\\srctest\\projects\\JavaApplication19
-Dnb.internal.action.name=rebuild clean jar
init:
deps-clean:
Updating property file:
P:\testing\netcat9\srctest\projects\JavaApplication19\build\built-clean.properties
Deleting directory P:\testing\netcat9\srctest\projects\JavaApplication19\build
clean:
init:
deps-jar:
Created dir: P:\testing\netcat9\srctest\projects\JavaApplication19\build
Updating property file:
P:\testing\netcat9\srctest\projects\JavaApplication19\build\built-jar.properties
Created dir: P:\testing\netcat9\srctest\projects\JavaApplication19\build\classes
Created dir: P:\testing\netcat9\srctest\projects\JavaApplication19\build\empty
Created dir:
P:\testing\netcat9\srctest\projects\JavaApplication19\build\generated-sources\ap-source-output
Compiling 1 source file to
P:\testing\netcat9\srctest\projects\JavaApplication19\build\classes
Copying 1 file to
P:\testing\netcat9\srctest\projects\JavaApplication19\build\classes
compile:
Created dir: P:\testing\netcat9\srctest\projects\JavaApplication19\dist
Copying 1 file to P:\testing\netcat9\srctest\projects\JavaApplication19\build
Building jar:
P:\testing\netcat9\srctest\projects\JavaApplication19\dist\JavaApplication19.jar
deploy:
jar:
BUILD SUCCESSFUL (total time: 0 seconds)
I am not sure these are the steps mention. Please advise.
Thanks,
Efrem McCrimon
GUI Builder Tribe
DB Tribe
On Tue, Apr 3, 2018 at 6:50 PM, Efrem Mc wrote:
> Hi all:
>
> Does it matter if you are using JDK8, JDK10, or OpenJDK 8/9/10> that may contain this jar file?
>
> I noticed in the original report it had openjdk-# and it appears that
> source file does some type of checking.
>
> What are the steps or the test case, I can run to see if I can reproduce it?
>
> Thanks,
>
> Efrem McCrimon
> GUI Builder Tribe
> DB Tribe
>
>
> On Tue, Apr 3, 2018 at 5:33 PM, Glenn Holmer wrote:
>> On 04/03/2018 03:56 AM, Marcel Witte wrote:
>>> I checked the source for this error and found something interesting. In
>>> JavacParser there is the check for the different JDK versions. Every check
>>> up
>>> to 1.8 checks the bootClassPath for a specific JDK class, but the check for
>>> 9
>>> checks the moduleBoot. Sadly, the log output seems to be copy-paste, as it
>>> still shows the bootClassPath. If I apply the following patch:
>>>
>>> @@ -1005,7 +1000,7 @@ public class JavacParser extends Parser {
>>> LOGGER.log(warnLevel,
>>> "Even though the source level of {0} is set
>>> to: {1}, java.util.zip.CRC32C cannot be found on the system module path: {2}
>>> \n" + //NOI18N
>>> "Changing source level to 1.8", //NOI18N
>>> - new Object[]{srcClassPath, sourceLevel,
>>> bootClassPath}); //NOI18N
>>> + new Object[]{srcClassPath, sourceLevel,
>>> moduleBoot}); //NOI18N
>>> return SourceLevelUtils.JDK1_8;
>>> }
>>> return source;
>>>
>>> then I get a log the same log output about changing back to 1.8
>>
>> I'm also seeing this for java.lang.AssertionError (when starting the
>> profiler against the Anagram Game sample project under JDK 10), with a
>> message saying "Changing source level to 1.3" (looks like lines 970-977
>> of JavacParser).
>>
>> --
>> Glenn Holmer (Linux registered user #16682)
>> "After the vintage season came the aftermath -- and Cenbe."
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@netbeans.apache.org
>> For additional commands, e-mail: users-h...@netbeans.apache.org
>>
>> For further information about the NetBeans mailing lists, visit:
>> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>>
-
To unsubscribe, e-mail: users-unsubscr...@netbeans.apache.org
For additional commands, e-mail: users-h...@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: java.util.zip.CRC32C cannot be found on the system module path
Hi all:
Does it matter if you are using JDK8, JDK10, or OpenJDK that may contain this jar file?
I noticed in the original report it had openjdk-# and it appears that
source file does some type of checking.
What are the steps or the test case, I can run to see if I can reproduce it?
Thanks,
Efrem McCrimon
GUI Builder Tribe
DB Tribe
On Tue, Apr 3, 2018 at 5:33 PM, Glenn Holmer wrote:
> On 04/03/2018 03:56 AM, Marcel Witte wrote:
>> I checked the source for this error and found something interesting. In
>> JavacParser there is the check for the different JDK versions. Every check up
>> to 1.8 checks the bootClassPath for a specific JDK class, but the check for 9
>> checks the moduleBoot. Sadly, the log output seems to be copy-paste, as it
>> still shows the bootClassPath. If I apply the following patch:
>>
>> @@ -1005,7 +1000,7 @@ public class JavacParser extends Parser {
>> LOGGER.log(warnLevel,
>> "Even though the source level of {0} is set
>> to: {1}, java.util.zip.CRC32C cannot be found on the system module path: {2}
>> \n" + //NOI18N
>> "Changing source level to 1.8", //NOI18N
>> - new Object[]{srcClassPath, sourceLevel,
>> bootClassPath}); //NOI18N
>> + new Object[]{srcClassPath, sourceLevel,
>> moduleBoot}); //NOI18N
>> return SourceLevelUtils.JDK1_8;
>> }
>> return source;
>>
>> then I get a log the same log output about changing back to 1.8
>
> I'm also seeing this for java.lang.AssertionError (when starting the
> profiler against the Anagram Game sample project under JDK 10), with a
> message saying "Changing source level to 1.3" (looks like lines 970-977
> of JavacParser).
>
> --
> Glenn Holmer (Linux registered user #16682)
> "After the vintage season came the aftermath -- and Cenbe."
>
> -
> To unsubscribe, e-mail: users-unsubscr...@netbeans.apache.org
> For additional commands, e-mail: users-h...@netbeans.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
-
To unsubscribe, e-mail: users-unsubscr...@netbeans.apache.org
For additional commands, e-mail: users-h...@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: java.util.zip.CRC32C cannot be found on the system module path
On 04/03/2018 03:56 AM, Marcel Witte wrote:
> I checked the source for this error and found something interesting. In
> JavacParser there is the check for the different JDK versions. Every check up
> to 1.8 checks the bootClassPath for a specific JDK class, but the check for 9
> checks the moduleBoot. Sadly, the log output seems to be copy-paste, as it
> still shows the bootClassPath. If I apply the following patch:
>
> @@ -1005,7 +1000,7 @@ public class JavacParser extends Parser {
> LOGGER.log(warnLevel,
> "Even though the source level of {0} is set
> to: {1}, java.util.zip.CRC32C cannot be found on the system module path: {2}
> \n" + //NOI18N
> "Changing source level to 1.8", //NOI18N
> - new Object[]{srcClassPath, sourceLevel,
> bootClassPath}); //NOI18N
> + new Object[]{srcClassPath, sourceLevel,
> moduleBoot}); //NOI18N
> return SourceLevelUtils.JDK1_8;
> }
> return source;
>
> then I get a log the same log output about changing back to 1.8
I'm also seeing this for java.lang.AssertionError (when starting the
profiler against the Anagram Game sample project under JDK 10), with a
message saying "Changing source level to 1.3" (looks like lines 970-977
of JavacParser).
--
Glenn Holmer (Linux registered user #16682)
"After the vintage season came the aftermath -- and Cenbe."
-
To unsubscribe, e-mail: users-unsubscr...@netbeans.apache.org
For additional commands, e-mail: users-h...@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: java.util.zip.CRC32C cannot be found on the system module path
I checked the source for this error and found something interesting. In
JavacParser there is the check for the different JDK versions. Every check up
to 1.8 checks the bootClassPath for a specific JDK class, but the check for 9
checks the moduleBoot. Sadly, the log output seems to be copy-paste, as it
still shows the bootClassPath. If I apply the following patch:
@@ -1005,7 +1000,7 @@ public class JavacParser extends Parser {
LOGGER.log(warnLevel,
"Even though the source level of {0} is set
to: {1}, java.util.zip.CRC32C cannot be found on the system module path: {2}
\n" + //NOI18N
"Changing source level to 1.8", //NOI18N
- new Object[]{srcClassPath, sourceLevel,
bootClassPath}); //NOI18N
+ new Object[]{srcClassPath, sourceLevel,
moduleBoot}); //NOI18N
return SourceLevelUtils.JDK1_8;
}
return source;
then I get a log the same log output about changing back to 1.8, but now
without any searched classpaths, so the moduleBoot seems to be empty.
Is it wrong to check the moduleBoot here? Is something configured the wrong
way on my system? Where can I configure the moduleBoot paths?
BTW: Is JDK 10 missing here?
Am Sonntag, 25. März 2018, 13:37:46 CEST schrieb Emilian Bold:
> Are you sure CRC32C exists? Could you check which modules has it (I assume
> it would be java.base, but I can't check myself).
>
> --emi
>
> ‐‐‐ Original Message ‐‐‐
>
> On 23 March 2018 4:27 PM, Marcel Witte wrote:
> > I'm using the current netbeans jenkins build. After changing my project to
> > Java 9 (source level 9) I get a lot of messages like the following in the
> > netbeans log:
> >
> > Even though the source level of [...] is set to: 9, java.util.zip.CRC32C
> > cannot be found on the system module path:
> > nbjrt:file:/usr/lib64/jvm/java-9-openjdk/!/modules/atk.wrapper/:nbjrt:fil
> > e:/usr/lib64/jvm/java-9-openjdk/!/modules/icedtea.sound/:nbjrt:file:/usr/l
> > ib64/jvm/java-9-openjdk/!/modules/java.activation/:nbjrt:file:/usr/lib64/j
> > vm/java-9-openjdk/!/modules/java.base/:nbjrt:file:/usr/lib64/jvm/java-9-op
> > enjdk/!/modules/java.compiler/:nbjrt:file:/usr/lib64/jvm/java-9-openjdk/!/
> > modules/java.corba/:nbjrt:file:/usr/lib64/jvm/java-9-openjdk/!/modules/jav
> > a.datatransfer/:nbjrt:file:/usr/lib64/jvm/java-9-openjdk/!/modules/java.de
> > sktop/:nbjrt:file:/usr/lib64/jvm/java-9-openjdk/!/modules/java.instrument/
> > :nbjrt:file:/usr/lib64/jvm/java-9-openjdk/!/modules/java.logging/:nbjrt:fi
> > le:/usr/lib64/jvm/java-9-openjdk/!/modules/java.management/:nbjrt:file:/us
> > r/lib64/jvm/java-9-openjdk/!/modules/java.management.rmi/:nbjrt:file:/usr/
> > lib64/jvm/java-9-openjdk/!/modules/java.naming/:nbjrt:file:/usr/lib64/jvm/
> > java-9-openjdk/!/modules/java.prefs/:nbjrt:file:/usr/lib64/jvm/java-9-open
> > jdk/!/modules/java.rmi/:nbjrt:file:/usr/lib64/jvm/java-9-openjdk/!/modules
> > /java.scripting/:nbjrt:file:/usr/lib64/jvm/java-9-openjdk/!/modules/java.s
> > e/:nbjrt:file:/usr/lib64/jvm/java-9-openjdk/!/modules/java.se.ee/:nbjrt:fi
> > le:/usr/lib64/jvm/java-9-openjdk/!/modules/java.security.jgss/:nbjrt:file:
> > /usr/lib64/jvm/java-9-openjdk/!/modules/java.security.sasl/:nbjrt:file:/us
> > r/lib64/jvm/java-9-openjdk/!/modules/java.smartcardio/:nbjrt:file:/usr/lib
> > 64/jvm/java-9-openjdk/!/modules/java.sql/:nbjrt:file:/usr/lib64/jvm/java-9
> > -openjdk/!/modules/java.sql.rowset/:nbjrt:file:/usr/lib64/jvm/java-9-openj
> > dk/!/modules/java.transaction/:nbjrt:file:/usr/lib64/jvm/java-9-openjdk/!/
> > modules/java.xml/:nbjrt:file:/usr/lib64/jvm/java-9-openjdk/!/modules/java.
> > xml.bind/:nbjrt:file:/usr/lib64/jvm/java-9-openjdk/!/modules/java.xml.cryp
> > to/:nbjrt:file:/usr/lib64/jvm/java-9-openjdk/!/modules/java.xml.ws/:nbjrt:
> > file:/usr/lib64/jvm/java-9-openjdk/!/modules/java.xml.ws.annotation/:nbjrt
> > :file:/usr/lib64/jvm/java-9-openjdk/!/modules/jdk.accessibility/:nbjrt:fil
> > e:/usr/lib64/jvm/java-9-openjdk/!/modules/jdk.aot/:nbjrt:file:/usr/lib64/j
> > vm/java-9-openjdk/!/modules/jdk.attach/:nbjrt:file:/usr/lib64/jvm/java-9-o
> > penjdk/!/modules/jdk.charsets/:nbjrt:file:/usr/lib64/jvm/java-9-openjdk/!/
> > modules/jdk.compiler/:nbjrt:file:/usr/lib64/jvm/java-9-openjdk/!/modules/j
> > dk.crypto.cryptoki/:nbjrt:file:/usr/lib64/jvm/java-9-openjdk/!/modules/jdk
> > .crypto.ec/:nbjrt:file:/usr/lib64/jvm/java-9-openjdk/!/modules/jdk.dynalin
> > k/:nbjrt:file:/usr/lib64/jvm/java-9-openjdk/!/modules/jdk.editpad/:nbjrt:f
> > ile:/usr/lib64/jvm/java-9-openjdk/!/modules/jdk.hotspot.agent/:nbjrt:file:
> > /usr/lib64/jvm/java-9-openjdk/!/modules/jdk.httpserver/:nbjrt:file:/usr/li
> > b64/jvm/java-9-openjdk/!/modules/jdk.incubator.httpclient/:nbjrt:file:/usr
> > /lib64/jvm/java-9-openjdk/!/modules/jdk.internal.ed/:nbjrt:file:/usr/lib64
> > /jvm/java-9-openjdk/!/modules/jdk.internal.jvmstat/:nbjrt:f
Re: java.util.zip.CRC32C cannot be found on the system module path
I would say it is... grep -R CRC32C /usr/lib64/jvm/java-9-openjdk Übereinstimmungen in Binärdatei /usr/lib64/jvm/java-9-openjdk/lib/server/ libjvm.so Übereinstimmungen in Binärdatei /usr/lib64/jvm/java-9-openjdk/lib/modules Übereinstimmungen in Binärdatei /usr/lib64/jvm/java-9-openjdk/lib/src.zip Übereinstimmungen in Binärdatei /usr/lib64/jvm/java-9-openjdk/conf/server/ libjvm.so Übereinstimmungen in Binärdatei /usr/lib64/jvm/java-9-openjdk/conf/modules Übereinstimmungen in Binärdatei /usr/lib64/jvm/java-9-openjdk/conf/src.zip Übereinstimmungen in Binärdatei /usr/lib64/jvm/java-9-openjdk/jmods/ java.base.jmod But I have no clue how I can look into this new lib/modules file. Am Sonntag, 25. März 2018, 13:37:46 CEST schrieb Emilian Bold: > Are you sure CRC32C exists? Could you check which modules has it (I assume > it would be java.base, but I can't check myself). > > --emi > > ‐‐‐ Original Message ‐‐‐ > > On 23 March 2018 4:27 PM, Marcel Witte wrote: > > I'm using the current netbeans jenkins build. After changing my project to > > Java 9 (source level 9) I get a lot of messages like the following in the > > netbeans log: > > > > Even though the source level of [...] is set to: 9, java.util.zip.CRC32C > > cannot be found on the system module path: > > nbjrt:file:/usr/lib64/jvm/java-9-openjdk/!/modules/atk.wrapper/:nbjrt:fil > > e:/usr/lib64/jvm/java-9-openjdk/!/modules/icedtea.sound/:nbjrt:file:/usr/l > > ib64/jvm/java-9-openjdk/!/modules/java.activation/:nbjrt:file:/usr/lib64/j > > vm/java-9-openjdk/!/modules/java.base/:nbjrt:file:/usr/lib64/jvm/java-9-op > > enjdk/!/modules/java.compiler/:nbjrt:file:/usr/lib64/jvm/java-9-openjdk/!/ > > modules/java.corba/:nbjrt:file:/usr/lib64/jvm/java-9-openjdk/!/modules/jav > > a.datatransfer/:nbjrt:file:/usr/lib64/jvm/java-9-openjdk/!/modules/java.de > > sktop/:nbjrt:file:/usr/lib64/jvm/java-9-openjdk/!/modules/java.instrument/ > > :nbjrt:file:/usr/lib64/jvm/java-9-openjdk/!/modules/java.logging/:nbjrt:fi > > le:/usr/lib64/jvm/java-9-openjdk/!/modules/java.management/:nbjrt:file:/us > > r/lib64/jvm/java-9-openjdk/!/modules/java.management.rmi/:nbjrt:file:/usr/ > > lib64/jvm/java-9-openjdk/!/modules/java.naming/:nbjrt:file:/usr/lib64/jvm/ > > java-9-openjdk/!/modules/java.prefs/:nbjrt:file:/usr/lib64/jvm/java-9-open > > jdk/!/modules/java.rmi/:nbjrt:file:/usr/lib64/jvm/java-9-openjdk/!/modules > > /java.scripting/:nbjrt:file:/usr/lib64/jvm/java-9-openjdk/!/modules/java.s > > e/:nbjrt:file:/usr/lib64/jvm/java-9-openjdk/!/modules/java.se.ee/:nbjrt:fi > > le:/usr/lib64/jvm/java-9-openjdk/!/modules/java.security.jgss/:nbjrt:file: > > /usr/lib64/jvm/java-9-openjdk/!/modules/java.security.sasl/:nbjrt:file:/us > > r/lib64/jvm/java-9-openjdk/!/modules/java.smartcardio/:nbjrt:file:/usr/lib > > 64/jvm/java-9-openjdk/!/modules/java.sql/:nbjrt:file:/usr/lib64/jvm/java-9 > > -openjdk/!/modules/java.sql.rowset/:nbjrt:file:/usr/lib64/jvm/java-9-openj > > dk/!/modules/java.transaction/:nbjrt:file:/usr/lib64/jvm/java-9-openjdk/!/ > > modules/java.xml/:nbjrt:file:/usr/lib64/jvm/java-9-openjdk/!/modules/java. > > xml.bind/:nbjrt:file:/usr/lib64/jvm/java-9-openjdk/!/modules/java.xml.cryp > > to/:nbjrt:file:/usr/lib64/jvm/java-9-openjdk/!/modules/java.xml.ws/:nbjrt: > > file:/usr/lib64/jvm/java-9-openjdk/!/modules/java.xml.ws.annotation/:nbjrt > > :file:/usr/lib64/jvm/java-9-openjdk/!/modules/jdk.accessibility/:nbjrt:fil > > e:/usr/lib64/jvm/java-9-openjdk/!/modules/jdk.aot/:nbjrt:file:/usr/lib64/j > > vm/java-9-openjdk/!/modules/jdk.attach/:nbjrt:file:/usr/lib64/jvm/java-9-o > > penjdk/!/modules/jdk.charsets/:nbjrt:file:/usr/lib64/jvm/java-9-openjdk/!/ > > modules/jdk.compiler/:nbjrt:file:/usr/lib64/jvm/java-9-openjdk/!/modules/j > > dk.crypto.cryptoki/:nbjrt:file:/usr/lib64/jvm/java-9-openjdk/!/modules/jdk > > .crypto.ec/:nbjrt:file:/usr/lib64/jvm/java-9-openjdk/!/modules/jdk.dynalin > > k/:nbjrt:file:/usr/lib64/jvm/java-9-openjdk/!/modules/jdk.editpad/:nbjrt:f > > ile:/usr/lib64/jvm/java-9-openjdk/!/modules/jdk.hotspot.agent/:nbjrt:file: > > /usr/lib64/jvm/java-9-openjdk/!/modules/jdk.httpserver/:nbjrt:file:/usr/li > > b64/jvm/java-9-openjdk/!/modules/jdk.incubator.httpclient/:nbjrt:file:/usr > > /lib64/jvm/java-9-openjdk/!/modules/jdk.internal.ed/:nbjrt:file:/usr/lib64 > > /jvm/java-9-openjdk/!/modules/jdk.internal.jvmstat/:nbjrt:file:/usr/lib64/ > > jvm/java-9-openjdk/!/modules/jdk.internal.le/:nbjrt:file:/usr/lib64/jvm/ja > > va-9-openjdk/!/modules/jdk.internal.opt/:nbjrt:file:/usr/lib64/jvm/java-9- > > openjdk/!/modules/jdk.internal.vm.ci/:nbjrt:file:/usr/lib64/jvm/java-9-ope > > njdk/!/modules/jdk.internal.vm.compiler/:nbjrt:file:/usr/lib64/jvm/java-9- > > openjdk/!/modules/jdk.jartool/:nbjrt:file:/usr/lib64/jvm/java-9-openjdk/!/ > > modules/jdk.javadoc/:nbjrt:file:/usr/lib64/jvm/java-9-openjdk/!/modules/jd > > k.jcmd/:nbjrt:file:/usr/lib64/jvm/java-9-openjdk/!/modules/jdk.jconsole/:n > > bjrt:file:/usr/lib64/jvm/java-9-openjdk/!/modules/jdk.jdeps/:nbjrt:file:/u > >
Re: java.util.zip.CRC32C cannot be found on the system module path
Are you sure CRC32C exists? Could you check which modules has it (I assume it would be java.base, but I can't check myself). --emi ‐‐‐ Original Message ‐‐‐ On 23 March 2018 4:27 PM, Marcel Witte wrote: > I'm using the current netbeans jenkins build. After changing my project to > Java 9 (source level 9) I get a lot of messages like the following in the > netbeans log: > > Even though the source level of [...] is set to: 9, java.util.zip.CRC32C > cannot be found on the system module path: > nbjrt:file:/usr/lib64/jvm/java-9-openjdk/!/modules/atk.wrapper/:nbjrt:file:/usr/lib64/jvm/java-9-openjdk/!/modules/icedtea.sound/:nbjrt:file:/usr/lib64/jvm/java-9-openjdk/!/modules/java.activation/:nbjrt:file:/usr/lib64/jvm/java-9-openjdk/!/modules/java.base/:nbjrt:file:/usr/lib64/jvm/java-9-openjdk/!/modules/java.compiler/:nbjrt:file:/usr/lib64/jvm/java-9-openjdk/!/modules/java.corba/:nbjrt:file:/usr/lib64/jvm/java-9-openjdk/!/modules/java.datatransfer/:nbjrt:file:/usr/lib64/jvm/java-9-openjdk/!/modules/java.desktop/:nbjrt:file:/usr/lib64/jvm/java-9-openjdk/!/modules/java.instrument/:nbjrt:file:/usr/lib64/jvm/java-9-openjdk/!/modules/java.logging/:nbjrt:file:/usr/lib64/jvm/java-9-openjdk/!/modules/java.management/:nbjrt:file:/usr/lib64/jvm/java-9-openjdk/!/modules/java.management.rmi/:nbjrt:file:/usr/lib64/jvm/java-9-openjdk/!/modules/java.naming/:nbjrt:file:/usr/lib64/jvm/java-9-openjdk/!/modules/java.prefs/:nbjrt:file:/usr/lib64/jvm/java-9-openjdk/!/modules/java.rmi/:nbjrt:file:/usr/lib64/jvm/java-9-openjdk/!/modules/java.scripting/:nbjrt:file:/usr/lib64/jvm/java-9-openjdk/!/modules/java.se/:nbjrt:file:/usr/lib64/jvm/java-9-openjdk/!/modules/java.se.ee/:nbjrt:file:/usr/lib64/jvm/java-9-openjdk/!/modules/java.security.jgss/:nbjrt:file:/usr/lib64/jvm/java-9-openjdk/!/modules/java.security.sasl/:nbjrt:file:/usr/lib64/jvm/java-9-openjdk/!/modules/java.smartcardio/:nbjrt:file:/usr/lib64/jvm/java-9-openjdk/!/modules/java.sql/:nbjrt:file:/usr/lib64/jvm/java-9-openjdk/!/modules/java.sql.rowset/:nbjrt:file:/usr/lib64/jvm/java-9-openjdk/!/modules/java.transaction/:nbjrt:file:/usr/lib64/jvm/java-9-openjdk/!/modules/java.xml/:nbjrt:file:/usr/lib64/jvm/java-9-openjdk/!/modules/java.xml.bind/:nbjrt:file:/usr/lib64/jvm/java-9-openjdk/!/modules/java.xml.crypto/:nbjrt:file:/usr/lib64/jvm/java-9-openjdk/!/modules/java.xml.ws/:nbjrt:file:/usr/lib64/jvm/java-9-openjdk/!/modules/java.xml.ws.annotation/:nbjrt:file:/usr/lib64/jvm/java-9-openjdk/!/modules/jdk.accessibility/:nbjrt:file:/usr/lib64/jvm/java-9-openjdk/!/modules/jdk.aot/:nbjrt:file:/usr/lib64/jvm/java-9-openjdk/!/modules/jdk.attach/:nbjrt:file:/usr/lib64/jvm/java-9-openjdk/!/modules/jdk.charsets/:nbjrt:file:/usr/lib64/jvm/java-9-openjdk/!/modules/jdk.compiler/:nbjrt:file:/usr/lib64/jvm/java-9-openjdk/!/modules/jdk.crypto.cryptoki/:nbjrt:file:/usr/lib64/jvm/java-9-openjdk/!/modules/jdk.crypto.ec/:nbjrt:file:/usr/lib64/jvm/java-9-openjdk/!/modules/jdk.dynalink/:nbjrt:file:/usr/lib64/jvm/java-9-openjdk/!/modules/jdk.editpad/:nbjrt:file:/usr/lib64/jvm/java-9-openjdk/!/modules/jdk.hotspot.agent/:nbjrt:file:/usr/lib64/jvm/java-9-openjdk/!/modules/jdk.httpserver/:nbjrt:file:/usr/lib64/jvm/java-9-openjdk/!/modules/jdk.incubator.httpclient/:nbjrt:file:/usr/lib64/jvm/java-9-openjdk/!/modules/jdk.internal.ed/:nbjrt:file:/usr/lib64/jvm/java-9-openjdk/!/modules/jdk.internal.jvmstat/:nbjrt:file:/usr/lib64/jvm/java-9-openjdk/!/modules/jdk.internal.le/:nbjrt:file:/usr/lib64/jvm/java-9-openjdk/!/modules/jdk.internal.opt/:nbjrt:file:/usr/lib64/jvm/java-9-openjdk/!/modules/jdk.internal.vm.ci/:nbjrt:file:/usr/lib64/jvm/java-9-openjdk/!/modules/jdk.internal.vm.compiler/:nbjrt:file:/usr/lib64/jvm/java-9-openjdk/!/modules/jdk.jartool/:nbjrt:file:/usr/lib64/jvm/java-9-openjdk/!/modules/jdk.javadoc/:nbjrt:file:/usr/lib64/jvm/java-9-openjdk/!/modules/jdk.jcmd/:nbjrt:file:/usr/lib64/jvm/java-9-openjdk/!/modules/jdk.jconsole/:nbjrt:file:/usr/lib64/jvm/java-9-openjdk/!/modules/jdk.jdeps/:nbjrt:file:/usr/lib64/jvm/java-9-openjdk/!/modules/jdk.jdi/:nbjrt:file:/usr/lib64/jvm/java-9-openjdk/!/modules/jdk.jdwp.agent/:nbjrt:file:/usr/lib64/jvm/java-9-openjdk/!/modules/jdk.jlink/:nbjrt:file:/usr/lib64/jvm/java-9-openjdk/!/modules/jdk.jshell/:nbjrt:file:/usr/lib64/jvm/java-9-openjdk/!/modules/jdk.jsobject/:nbjrt:file:/usr/lib64/jvm/java-9-openjdk/!/modules/jdk.jstatd/:nbjrt:file:/usr/lib64/jvm/java-9-openjdk/!/modules/jdk.localedata/:nbjrt:file:/usr/lib64/jvm/java-9-openjdk/!/modules/jdk.management/:nbjrt:file:/usr/lib64/jvm/java-9-openjdk/!/modules/jdk.management.agent/:nbjrt:file:/usr/lib64/jvm/java-9-openjdk/!/modules/jdk.naming.dns/:nbjrt:file:/usr/lib64/jvm/java-9-openjdk/!/modules/jdk.naming.rmi/:nbjrt:file:/usr/lib64/jvm/java-9-openjdk/!/modules/jdk.net/:nbjrt:file:/usr/lib64/jvm/java-9-openjdk/!/modules/jdk.pack/:nbjrt:file:/usr/lib64/jvm/java-9-openjdk/!/modules/jdk.policytool/:nbjrt:file:/usr/lib64/jvm/java-9-openjdk/!/modules/jdk.rmic/:nbjrt:file:/usr/lib64/jvm/java-9-openjdk/!/modules/
