You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@netbeans.apache.org by Marcel Witte <wi...@gmail.com> on 2018/04/03 08:56:40 UTC

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 <wi...@gmail.com> 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
> > sr/lib64/jvm/java-9-openjdk/!/modules/jdk.jdi/:nbjrt:file:/usr/lib64/jvm/j
> > ava-9-openjdk/!/modules/jdk.jdwp.agent/:nbjrt:file:/usr/lib64/jvm/java-9-o
> > penjdk/!/modules/jdk.jlink/:nbjrt:file:/usr/lib64/jvm/java-9-openjdk/!/mod
> > ules/jdk.jshell/:nbjrt:file:/usr/lib64/jvm/java-9-openjdk/!/modules/jdk.js
> > object/:nbjrt:file:/usr/lib64/jvm/java-9-openjdk/!/modules/jdk.jstatd/:nbj
> > rt:file:/usr/lib64/jvm/java-9-openjdk/!/modules/jdk.localedata/:nbjrt:file
> > :/usr/lib64/jvm/java-9-openjdk/!/modules/jdk.management/:nbjrt:file:/usr/l
> > ib64/jvm/java-9-openjdk/!/modules/jdk.management.agent/:nbjrt:file:/usr/li
> > b64/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/!/mod
> > ules/jdk.pack/:nbjrt:file:/usr/lib64/jvm/java-9-openjdk/!/modules/jdk.poli
> > cytool/:nbjrt:file:/usr/lib64/jvm/java-9-openjdk/!/modules/jdk.rmic/:nbjrt
> > :file:/usr/lib64/jvm/java-9-openjdk/!/modules/jdk.scripting.nashorn/:nbjrt
> > :file:/usr/lib64/jvm/java-9-openjdk/!/modules/jdk.scripting.nashorn.shell/
> > :nbjrt:file:/usr/lib64/jvm/java-9-openjdk/!/modules/jdk.sctp/:nbjrt:file:/
> > usr/lib64/jvm/java-9-openjdk/!/modules/jdk.security.auth/:nbjrt:file:/usr/
> > lib64/jvm/java-9-openjdk/!/modules/jdk.security.jgss/:nbjrt:file:/usr/lib6
> > 4/jvm/java-9-openjdk/!/modules/jdk.unsupported/:nbjrt:file:/usr/lib64/jvm/
> > java-9-openjdk/!/modules/jdk.xml.bind/:nbjrt:file:/usr/lib64/jvm/java-9-op
> > enjdk/!/modules/jdk.xml.dom/:nbjrt:file:/usr/lib64/jvm/java-9-openjdk/!/mo
> > dules/jdk.xml.ws/:nbjrt:file:/usr/lib64/jvm/java-9-openjdk/!/modules/jdk.z
> > ipfs/
> > 
> > Changing source level to 1.8
> > 
> > Java 9 is installed using the package manager on openSUSE Tumbleweed and
> > is working without problems besides this Netbeans problem.
> > 
> > Why is Netbeans unable to find CRC32C and changing my source level back to
> > 1.8?
> > 
> > 
> > --------------------------------------------------------------------------
> > --------------------------------------------------------------------------
> > --------------------------------------------------------------------------
> > --------------------------------------------------------------------------
> > --------------------------------------------------------------------------
> > --------------------------------------------------------------------------
> > --------------------------------------------------------------------------
> > --------------------------------------------------------------------------
> > --------------------------------------------------------------------------
> > --------------------------------------------------------------------------
> > --------------------------------------------------------------------------
> > --------------------------------------------------------------------------
> > --------------------------------------------------------------------------
> > --------------------------------------------------------------------------
> > --------------------------------------------------------------------------
> > --------------------------------------------------------------------------
> > --------------------------------------------------------------------------
> > --------------------------------------------------------------------------
> > --------------------------------------------------------------------------
> > --------------------------------------------------------------------------
> > --------------------------------------------------------------------------
> > --------------------------------------------------------------------------
> > --------------------------------------------------------------------------
> > --------------------------------------------------------------------------
> > --------------------------------------------------------------------------
> > --------------------------------------------------------------------------
> > --------------------------------------------------------------------------
> > --------------------------------------------------------------------------
> > --------------------------------------------------------------------------
> > --------------------------------------------------------------------------
> > --------------------------------------------------------------------------
> > --------------------------------------------------------------------------
> > --------------------------------------------------------------------------
> > --------------------------------------------------------------------------
> > --------------------------------------------------------------------------
> > --------------------------------------------------------------------------
> > --------------------------------------------------------------------------
> > --------------------------------------------------------------------------
> > --------------------------------------------------------------------------
> > --------------------------------------------------------------------------
> > --------------------------------------------------------------------------
> > --------------------------------------------------------------------------
> > --------------------------------------------------------------------------
> > --------------------------------------------------------------------------
> > --------------------------------------------------------------------------
> > --------------------------------------------------------------------------
> > --------------------------------------------------------------------------
> > --------------------------------------------------------------------------
> > --------------------------------------------------------------------------
> > --------------------------------------------------------------------------
> > --------------------------------------------------------------------------
> > --------------------------------------------------------------------------
> > --------------------------------------------------------------------------
> > --------------------------------------------------------------------------
> > --------------------------------------------------------------------------
> > --------------------------------------------------------------------------
> > --------------------------------------------------------------------------
> > --------------------------------------------------------------------------
> > --------------------------------------------------------------------------
> > --------------------------------------------------------------------------
> > --------------------------------------------------------------------------
> > --------------------------------------------------------------------------
> > --------------------------------------------------------------------------
> > --------------------------------------------------------------------------
> > --------------------------------------------------------------------------
> > --------------------------------------------------------------------------
> > --------------------------------------------------------------------------
> > --------------------------------------------------------------------------
> > --------------------------------------------------------------------------
> > --------------------------------------------------------------------------
> > --------------------------------------------------------------------------
> > --------------------------------------------------------------------------
> > --------------------------------------------------------------------------
> > --------------------------------------------------------------------------
> > --------------------------------------------------------------------------
> > --------------------------------------------------------------------------
> > --------------
> > 
> > To unsubscribe, e-mail: users-unsubscribe@netbeans.apache.org
> > 
> > For additional commands, e-mail: users-help@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-unsubscribe@netbeans.apache.org
For additional commands, e-mail: users-help@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

Posted by Marcel Witte <wi...@gmail.com>.
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 <ef...@gmail.com> wrote:
> > Hi all:
> > 
> > Does it matter if you are using JDK8, JDK10, or OpenJDK <version
> > 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 <ce...@kolabnow.com> 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-unsubscribe@netbeans.apache.org
> >> For additional commands, e-mail: users-help@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-unsubscribe@netbeans.apache.org
> For additional commands, e-mail: users-help@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-unsubscribe@netbeans.apache.org
For additional commands, e-mail: users-help@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

Posted by Glenn Holmer <ce...@kolabnow.com>.
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 <ce...@kolabnow.com> 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-unsubscribe@netbeans.apache.org
For additional commands, e-mail: users-help@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

Posted by Glenn Holmer <ce...@kolabnow.com>.
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 <ce...@kolabnow.com> 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-unsubscribe@netbeans.apache.org
For additional commands, e-mail: users-help@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

Posted by Chuck Davis <cj...@gmail.com>.
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 <ef...@gmail.com> 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 <ef...@gmail.com> wrote:
> > Hi all:
> >
> > Does it matter if you are using JDK8, JDK10, or OpenJDK <version
> > 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 <ce...@kolabnow.com> 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-unsubscribe@netbeans.apache.org
> >> For additional commands, e-mail: users-help@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-unsubscribe@netbeans.apache.org
> For additional commands, e-mail: users-help@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

Posted by Efrem Mc <ef...@gmail.com>.
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 <ef...@gmail.com> wrote:
> Hi all:
>
> Does it matter if you are using JDK8, JDK10, or OpenJDK <version
> 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 <ce...@kolabnow.com> 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-unsubscribe@netbeans.apache.org
>> For additional commands, e-mail: users-help@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-unsubscribe@netbeans.apache.org
For additional commands, e-mail: users-help@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

Posted by Efrem Mc <ef...@gmail.com>.
Hi all:

Does it matter if you are using JDK8, JDK10, or OpenJDK <version
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 <ce...@kolabnow.com> 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-unsubscribe@netbeans.apache.org
> For additional commands, e-mail: users-help@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-unsubscribe@netbeans.apache.org
For additional commands, e-mail: users-help@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

Posted by Glenn Holmer <ce...@kolabnow.com>.
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-unsubscribe@netbeans.apache.org
For additional commands, e-mail: users-help@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists