[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [jdt-core-dev] Java9 Beta Branch
|
Hi,
As an (early) adopter what I take from all this is that JDT9-Branch only
supports a very specific JDT9-Build at the moment (the more Java9
stabilizes the less likely such breaking changes will hopefully get).
Wouldn't it make sense to provide the user some informations about what
JDK-9 build is supported? Not everyone giving JDT9-Builds a spin are
subscribed to this mailing list and will post such findings. They'll get
frustrated and probably share this frustration on Twitter, Facebook,
Blog, ... .
Tom
On 18.01.17 07:17, Sasikanth B Ammanamanchi wrote:
> Yes, I have noted more changes in the class file format since b149.
> There are two new entries in the module attribute
> module_version_index and requires_version_index. Time to go back and
> thoroughly read the doc. I have made a few notes in the bug
>
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=500636
>
> Regards
> Sasikanth
>
> -----jdt-core-dev-bounces@xxxxxxxxxxx
> <mailto:-----jdt-core-dev-bounces@xxxxxxxxxxx> wrote: -----
> To: jdt-core-dev@xxxxxxxxxxx <mailto:jdt-core-dev@xxxxxxxxxxx>
> From: Stephan Herrmann
> Sent by: jdt-core-dev-bounces@xxxxxxxxxxx
> <mailto:jdt-core-dev-bounces@xxxxxxxxxxx>
> Date: 01/17/2017 06:37PM
> Subject: Re: [jdt-core-dev] Java9 Beta Branch
>
> FWIW: I observe ClassFormatException triggered by AIOOBE using latest
> Y-build
> plus HEAD of BETA_JAVA9 of JDT/Core running on and with jdk build 152.
> Perhaps there are several subsequent changes in the class format?
>
> This exception is caught, and after printStackTrace()
> ClasspathJrt$2.visitModule()
> simply continues like normal.
>
> I'm also seeing an NPE in ClassFile.generateModuleAttribute()
>
> What's the current bug to track class format changes and related exceptions?
>
> Stephan
>
>
>
> On 01/17/2017 06:36 AM, Sasikanth B Ammanamanchi wrote:
>> Yes, the class file format changed for module-info and we noted this
> with b149 and adjusted accordingly.
>> The latest patch should be able to handle b 149 and later (untested)
>> Did you install the latest patch from the market place? And all
> earlier versions of jdk9 need to be removed from the
>> installed JREs as well.
>>
>> Regards
>> Sasikanth
>>
>> -----jdt-core-dev-bounces@xxxxxxxxxxx
> <mailto:-----jdt-core-dev-bounces@xxxxxxxxxxx>
> <mailto:-----jdt-core-dev-bounces@xxxxxxxxxxx> wrote: -----
>> To: jdt-core-dev@xxxxxxxxxxx <mailto:jdt-core-dev@xxxxxxxxxxx>
> <mailto:jdt-core-dev@xxxxxxxxxxx>
>> From: Stephan Herrmann
>> Sent by: jdt-core-dev-bounces@xxxxxxxxxxx
> <mailto:jdt-core-dev-bounces@xxxxxxxxxxx>
> <mailto:jdt-core-dev-bounces@xxxxxxxxxxx>
>> Date: 01/17/2017 06:04AM
>> Subject: Re: [jdt-core-dev] Java9 Beta Branch
>>
>> Mh, the original exception appears to be AIOOBE trying to retrieve the
> class name
>> from module-info.class. Has the class file format for module-info change?
>>
>>
>> Closest I could find at a quick scan:
>>
> http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-December/010383.html
>>
>> Here Remi is only reacting to a class file change, but indeed he mentions
>> "setting the class name to null instead of 'module-info'"
>> Mh, he says NPE, I see AIOOBE <shrug>
>>
>> What's the origin of that change? I don't know.
>> Stephan
>>
>>
>> On 01/16/2017 11:33 PM, Tom Schindl wrote:
>>> Hi,
>>>
>>> What is the recommanded JDK9 build to give the Java9 support a try? I
>>> gave b152 a shot but too me it looks like JDT is unable to process the
>>> classfile because I see many many Exceptions like this
>>>
>>>> org.eclipse.jdt.internal.compiler.classfmt.ClassFormatException
>>>> at
> org.eclipse.jdt.internal.compiler.classfmt.ClassFileReader.<init>(ClassFileReader.java:449)
>>>> at
> org.eclipse.jdt.internal.compiler.classfmt.ClassFileReader.<init>(ClassFileReader.java:178)
>>>> at
> org.eclipse.jdt.internal.core.builder.ClasspathJrt.acceptModule(ClasspathJrt.java:173)
>>>> at
> org.eclipse.jdt.internal.core.builder.ClasspathJrt$2.visitModule(ClasspathJrt.java:152)
>>>> at
> org.eclipse.jdt.internal.core.builder.ClasspathJrt$2.visitModule(ClasspathJrt.java:1)
>>>> at
> org.eclipse.jdt.internal.compiler.util.JrtFileSystem$1.preVisitDirectory(JRTUtil.java:343)
>>>> at
> org.eclipse.jdt.internal.compiler.util.JrtFileSystem$1.preVisitDirectory(JRTUtil.java:1)
>>>> at java.base/java.nio.file.Files.walkFileTree(Files.java:2702)
>>>> at java.base/java.nio.file.Files.walkFileTree(Files.java:2767)
>>>> at
> org.eclipse.jdt.internal.compiler.util.JrtFileSystem.walkModuleImage(JRTUtil.java:331)
>>>> at
> org.eclipse.jdt.internal.compiler.util.JRTUtil.walkModuleImage(JRTUtil.java:147)
>>>> at
> org.eclipse.jdt.internal.core.builder.ClasspathJrt.loadModules(ClasspathJrt.java:132)
>>>> at
> org.eclipse.jdt.internal.core.builder.ClasspathJrt.<init>(ClasspathJrt.java:74)
>>>> at
> org.eclipse.jdt.internal.core.builder.ClasspathLocation.forLibrary(ClasspathLocation.java:60)
>>>> at
> org.eclipse.jdt.internal.core.builder.ClasspathLocation.forLibrary(ClasspathLocation.java:66)
>>>> at
> org.eclipse.jdt.internal.core.builder.NameEnvironment.computeClasspathLocations(NameEnvironment.java:233)
>>>> at
> org.eclipse.jdt.internal.core.builder.NameEnvironment.<init>(NameEnvironment.java:56)
>>>> at
> org.eclipse.jdt.internal.core.builder.JavaBuilder.initializeBuilder(JavaBuilder.java:604)
>>>> at
> org.eclipse.jdt.internal.core.builder.JavaBuilder.build(JavaBuilder.java:169)
>>>> at
> org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:735)
>>>> at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
>>>> at
> org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:206)
>>>> at
> org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:246)
>>>> at
> org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:301)
>>>> at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
>>>> at
> org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:304)
>>>> at
> org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:360)
>>>> at
> org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:383)
>>>> at
> org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBuildJob.java:142)
>>>> at
> org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJob.java:232)
>>>> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:56)
>>>
>>> and a simple HelloWorld class does not compile :-(
>>>
>>> Tom
>>>
>>
>> _______________________________________________
>> jdt-core-dev mailing list
>> jdt-core-dev@xxxxxxxxxxx <mailto:jdt-core-dev@xxxxxxxxxxx>
> <mailto:jdt-core-dev@xxxxxxxxxxx>
>> To change your delivery options, retrieve your password, or
> unsubscribe from this list, visit
>> https://dev.eclipse.org/mailman/listinfo/jdt-core-dev
>>
>>
>>
>>
>> _______________________________________________
>> jdt-core-dev mailing list
>> jdt-core-dev@xxxxxxxxxxx <mailto:jdt-core-dev@xxxxxxxxxxx>
>> To change your delivery options, retrieve your password, or
> unsubscribe from this list, visit
>> https://dev.eclipse.org/mailman/listinfo/jdt-core-dev
>>
>
> _______________________________________________
> jdt-core-dev mailing list
> jdt-core-dev@xxxxxxxxxxx <mailto:jdt-core-dev@xxxxxxxxxxx>
> To change your delivery options, retrieve your password, or unsubscribe
> from this list, visit
> https://dev.eclipse.org/mailman/listinfo/jdt-core-dev
>
>
>
>
> _______________________________________________
> jdt-core-dev mailing list
> jdt-core-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
> https://dev.eclipse.org/mailman/listinfo/jdt-core-dev
>
--
Thomas Schindl, CTO
BestSolution.at EDV Systemhaus GmbH
Eduard-Bodem-Gasse 5-7, A-6020 Innsbruck
http://www.bestsolution.at/
Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck