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 <efrem...@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-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
---------------------------------------------------------------------
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
