InternalError on Class.getPackage()

Tue Oct 20 22:09:39 UTC 2015

Hi Kevin,

The last couple of Jigsaw EA builds have worked fine for me on OSX but
with Debian 7 (Wheezy) it fails to find the JavaFX .so binaries. I've not
filed this yet as I suspected it could be Debian's older libs are now
below the required versions for FX.

Will test again tomorrow and post some details.

Kind regards,

Chris

On Tue, October 20, 2015 22:46, Kevin Rushforth wrote:
> What Jake / JavaFX issues are you running into that prevent you from
> running JavaFX using the modules from the JDK Jigsaw early access build
> itself? Is there a bug filed?
>
> Btw, as a "hack" you might be able to get away with what you are doing,
> but I would not expect JavaFX from JDK 8u60 to work with JDK 9 in general,
> especially with Jigsaw.
>
> -- Kevin
>
>
>
> Chris Newland wrote:
>
>> Hi Alan, Mandy, Lois,
>>
>>
>> I've modified the JITWatch maven pom to use a jfxrt.jar from
>> jdk1.8.0_60 to get around the jake / JavaFX issues.
>>
>> With the Jigsaw EA b83 I still get this exception during junit tests:
>>
>>
>> -------------------------------------------------------
>> T E S T S
>> -------------------------------------------------------
>> Running org.adoptopenjdk.jitwatch.test.TestAssemblyLabels
>> Failed to instantiate [ch.qos.logback.classic.LoggerContext]
>> Reported exception:
>> java.lang.InternalError: unnamed package in named module java.base
>> at
>> jdk.internal.misc.BuiltinClassLoader.definePackage(java.base at 9.0/Builti
>> nClassLoader.java:569)
>> at
>> jdk.internal.misc.BootLoader.definePackage(java.base at 9.0/BootLoader.jav
>> a:123)
>> at java.lang.Class.getPackage(java.base at 9.0/Class.java:917) at
>> ch.qos.logback.core.joran.util.StringToObjectConverter.canBeBuiltFromSi
>> mpleString(StringToObjectConverter.java:34)
>> at
>> ch.qos.logback.core.joran.util.PropertySetter.computeRawAggregationType
>> (PropertySetter.java:233)
>> at
>> ch.qos.logback.core.joran.util.PropertySetter.computeAggregationType(Pr
>> opertySetter.java:194)
>> at
>> ch.qos.logback.core.joran.action.NestedComplexPropertyIA.isApplicable(N
>> estedComplexPropertyIA.java:61)
>> at
>> ch.qos.logback.core.joran.spi.Interpreter.lookupImplicitAction(Interpre
>> ter.java:237)
>> at
>> ch.qos.logback.core.joran.spi.Interpreter.getApplicableActionList(Inter
>> preter.java:256)
>> at
>> ch.qos.logback.core.joran.spi.Interpreter.startElement(Interpreter.java
>> :144)
>> at
>> ch.qos.logback.core.joran.spi.Interpreter.startElement(Interpreter.java
>> :129)
>> at ch.qos.logback.core.joran.spi.EventPlayer.play(EventPlayer.java:50) at
>>
>> ch.qos.logback.core.joran.GenericConfigurator.doConfigure(GenericConfig
>> urator.java:149)
>> at
>> ch.qos.logback.core.joran.GenericConfigurator.doConfigure(GenericConfig
>> urator.java:135)
>> at
>> ch.qos.logback.core.joran.GenericConfigurator.doConfigure(GenericConfig
>> urator.java:99)
>> at
>> ch.qos.logback.core.joran.GenericConfigurator.doConfigure(GenericConfig
>> urator.java:49)
>> at
>> ch.qos.logback.classic.util.ContextInitializer.configureByResource(Cont
>> extInitializer.java:75)
>> at
>> ch.qos.logback.classic.util.ContextInitializer.autoConfig(ContextInitia
>> lizer.java:150)
>> at org.slf4j.impl.StaticLoggerBinder.init(StaticLoggerBinder.java:85) at
>> org.slf4j.impl.StaticLoggerBinder.<clinit>(StaticLoggerBinder.java:55)
>> at org.slf4j.LoggerFactory.bind(LoggerFactory.java:129) at
>> org.slf4j.LoggerFactory.performInitialization(LoggerFactory.java:108)
>> at org.slf4j.LoggerFactory.getILoggerFactory(LoggerFactory.java:302) at
>> org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:276)
>> at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:288) at
>> org.adoptopenjdk.jitwatch.model.assembly.AssemblyInstruction.<clinit>(A
>> ssemblyInstruction.java:39)
>> at
>> org.adoptopenjdk.jitwatch.test.TestAssemblyLabels.testFormatAddressJump
>> Foreign(TestAssemblyLabels.java:108)
>> at sun.reflect.NativeMethodAccessorImpl.invoke0(java.base at 9.0/Native
>> Method)
>> at
>> sun.reflect.NativeMethodAccessorImpl.invoke(java.base at 9.0/NativeMethodA
>> ccessorImpl.java:62)
>> at
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(java.base at 9.0/Delegatin
>> gMethodAccessorImpl.java:43)
>> at java.lang.reflect.Method.invoke(java.base at 9.0/Method.java:530) at
>> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMe
>> thod.java:47)
>> at
>> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCalla
>> ble.java:12)
>> at
>> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMeth
>> od.java:44)
>> at
>> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMetho
>> d.java:17)
>> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271) at
>> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunne
>> r.java:70)
>> at
>> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunne
>> r.java:50)
>> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238) at
>> org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
>> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236) at
>> org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
>> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229) at
>> org.junit.runners.ParentRunner.run(ParentRunner.java:309)
>> at
>> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.
>> java:264)
>> at
>> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Pr
>> ovider.java:153)
>> at
>> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.j
>> ava:124)
>> at
>> org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClass
>> Loader(ForkedBooter.java:200)
>> at
>> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(Forked
>> Booter.java:153)
>> at
>> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:10
>> 3)
>>
>>
>> But with the jimages JDK built from the tip of jake I get no exception
>> during mvn test so perhaps the bug has been fixed between b83 and the
>> tip?
>>
>> Not sure if you're familiar with SLF4J but it does some clever
>> classpath stuff so that you don't declare the concrete logger
>> implementation in config. Instead you just put the slf4j jar and any of
>> the supported implementation jars in your classpath.
>>
>> If you could let me know how to pull the source tree snapshot used to
>> make EA b83 then I could try Mandy's patch without all the other fixes
>> in the tip?
>>
>> Kind regards,
>>
>>
>> Chris
>>
>>
>>
>> On Tue, October 20, 2015 16:01, Alan Bateman wrote:
>>
>>
>>
>>
>>> On 20/10/2015 15:53, Chris Newland wrote:
>>>
>>>
>>>
>>>> Caused by: java.lang.IllegalAccessError: class
>>>> com.sun.javafx.util.Logging (in module: Unnamed Module) cannot
>>>> access class sun.util.logging.PlatformLogger (in module: java.base),
>>>>  sun.util.logging is not exported to Unnamed Module
>>>>
>>>>
>>> This must be FX on the class path rather than linking it in as
>>> modules. In that case, you'll need to use
>>> -XaddExports:java.base/sun.util.loggging=ALL-UNNAMED . There might be
>>> other exports needed too.
>>>
>>> -Alan
>>>
>>>
>>>
>>>
>>
>>
>>
>