Skip to content
This repository has been archived by the owner on May 7, 2020. It is now read-only.

Test ESH with Java 9/10/11 #4369

Open
kaikreuzer opened this issue Oct 3, 2017 · 16 comments
Open

Test ESH with Java 9/10/11 #4369

kaikreuzer opened this issue Oct 3, 2017 · 16 comments

Comments

@kaikreuzer
Copy link
Contributor

Just as a reminder to ourselves: Now that Java 9 is out, we should make sure that ESH runs smoothly on it as well. (Note that this does not mean that we will move the code base from 8 to 9 any time soon - we should simply try to increase the number of JVMs that ESH can run on).

@lewie
Copy link

lewie commented Oct 3, 2017

A nightly Build openHAB 2.2, started in Debian 7 jessie with oracle 9 SDK:

root@core ~# sh /data/OH/start.sh
Launching the openHAB runtime...
/data/OH/runtime/bin/karaf: 198: [: Illegal number:
/data/OH/runtime/bin/karaf: 198: [: Illegal number:

                          __  _____    ____
  ____  ____  ___  ____  / / / /   |  / __ )
 / __ \/ __ \/ _ \/ __ \/ /_/ / /| | / __  |
/ /_/ / /_/ /  __/ / / / __  / ___ |/ /_/ /
\____/ .___/\___/_/ /_/_/ /_/_/  |_/_____/
    /_/                        2.2.0-SNAPSHOT
                               Build #1054

Hit '<tab>' for a list of available commands
and '[cmd] --help' for help on a specific command.
Hit '<ctrl-d>' or type 'system:shutdown' or 'logout' to shutdown openHAB.

openhab> 
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by org.eclipse.jetty.util.BufferUtil (file:/data/OH22/userdata/cache/org.eclipse.osgi/87/0/bundleFile) to field java.nio.MappedByteBuffer.fd
WARNING: Please consider reporting this to the maintainers of org.eclipse.jetty.util.BufferUtil
WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
WARNING: All illegal access operations will be denied in a future release
log:tail
18:44:57.923 [INFO ] [i.dashboard.internal.DashboardService] - Started dashboard at http://192.168.0.174:8080
18:44:57.936 [INFO ] [i.dashboard.internal.DashboardService] - Started dashboard at https://192.168.0.174:8443
18:44:58.059 [INFO ] [.basic.internal.servlet.WebAppServlet] - Started Basic UI at /basicui/app
18:44:58.072 [INFO ] [marthome.ui.paper.internal.PaperUIApp] - Started Paper UI at /paperui
18:44:58.107 [INFO ] [bpanel.internal.HABPanelDashboardTile] - Started HABPanel at /habpanel

Nothing extraordinary happens in the log files.

@kaikreuzer
Copy link
Contributor Author

kaikreuzer commented Oct 3, 2017

@lewie, we have to keep ESH separate from openHAB.

openHAB clearly isn't yet ready, due to lacking Java 9 support in Karaf - we should track that rather in openhab-distro.

For ESH, it all looks better. The exception in the log above is from Jetty, which we also use in the ESH IDE for development - version 9.3.16 has this fixed, so it might be worth to update this on the ESH targetplatform.

@kaikreuzer
Copy link
Contributor Author

FTR, @wborn made some tests with openHAB (using Karaf 4.2.1) on Java 9+10 in openhab/openhab-distro#761.

The only issue that came up so far wrt ESH is x-stream/xstream#101. I am not clear whether there is anything we could change in our use of Xstream (probably not?) or if we will have to live with JVM arguments to simply allow such illegal accesses (not clean).

@maggu2810
Copy link
Contributor

FTR: I tested an ESH based solution with Java 9, too. Till now it is working.

@kaikreuzer
Copy link
Contributor Author

How do you avoid the warnings that are caused by Xstream?

@maggu2810
Copy link
Contributor

I assume you refer to this one:

WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by com.thoughtworks.xstream.core.util.Fields (jar:bundle://202.0:0/!/) to field java.lang.reflect.Proxy.h
WARNING: Please consider reporting this to the maintainers of com.thoughtworks.xstream.core.util.Fields
WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
WARNING: All illegal access operations will be denied in a future release

I just don't care about that warning as it still works.

@kaikreuzer
Copy link
Contributor Author

I just don't care about that warning as it still works.

🙄

Do you proceed that way with all warnings that you come across...?

@kaikreuzer
Copy link
Contributor Author

I assume you refer to this one

Yes, I refer to the one that I had mentioned just above your comment: #4369 (comment):

The only issue that came up so far wrt ESH is x-stream/xstream#101

@maggu2810
Copy link
Contributor

maggu2810 commented Sep 12, 2018

Do you proceed that way with all warnings that you come across...?

WARNING: All illegal access operations will be denied in a future release

The warning states that the access operation will be denied in a future release.
As long as it works with Java 9, why can't it be ignored by that specific product (if it ever will change the JVM version to 9 and as long as the warning will not be visible for anyone that use that product).

AFAIK and as you comment in the linked commit for another warning:

so the easiest way to address this might be to configure the logger to swallow messages from this class.

you just don't show the warning to the user which is very similar then ignoring it.

@kaikreuzer kaikreuzer changed the title Test ESH with Java 9 Test ESH with Java 11 Sep 12, 2018
@kaikreuzer kaikreuzer changed the title Test ESH with Java 11 Test ESH with Java 9/10/11 Sep 12, 2018
@kaikreuzer
Copy link
Contributor Author

As long as it works with Java 9, why can't it be ignored by that specific product

Ok, I have updated the title 😛 . Actually, Java 9 is EOL since 6 months already and support for Java 10 will cease end of this month. So what we should be looking at is actually Java 11. Hence I don't think we should simply ignore such warnings.

you just don't show the warning to the user which is very similar then ignoring it.

Because this warning is evaluated and accepted by the solution provider. Thus the solution users should not be bothered. Same situation here: If we say we are ok with the way it runs on Java 9, we would not want to bother our users with that warning - as they might be alarmed and enter issues about it.

@maggu2810
Copy link
Contributor

Because this warning is evaluated and accepted by the solution provider.
Thus the solution users should not be bothered.

Same is true for the product I referred.
The solution user will never see that warning.

@kaikreuzer
Copy link
Contributor Author

You lucky one ;-)

@htreu
Copy link
Contributor

htreu commented Oct 31, 2018

I tested Eclipse SmartHome running with JDK 11 in the IDE. Here are the current issues that I found:

With --illegal-access=warn we get all illegal reflective access warnings:

  • from jetty:
    • WARNING: Illegal reflective access by org.eclipse.jetty.util.BufferUtil (file:...) to field java.nio.MappedByteBuffer.fd
  • from xstream*
    • WARNING: Illegal reflective access by com.thoughtworks.xstream.core.util.Fields (file:xstream-1.4.7.jar) to field java.util.TreeMap.comparator
    • WARNING: Illegal reflective access by com.thoughtworks.xstream.core.util.Fields (file:xstream-1.4.7.jar) to field java.util.TreeSet.m
    • WARNING: Illegal reflective access by com.thoughtworks.xstream.core.util.Fields (file:xstream-1.4.7.jar) to field java.util.Properties.defaults
    • WARNING: Illegal reflective access by com.thoughtworks.xstream.core.util.Fields (file:xstream-1.4.7.jar) to field java.lang.reflect.Proxy.h
    • WARNING: Illegal reflective access by com.thoughtworks.xstream.converters.reflection.AbstractAttributedCharacterIteratorAttributeConverter (file:xstream-1.4.7.jar) to method java.text.AttributedCharacterIterator$Attribute.getName()
    • WARNING: Illegal reflective access by com.thoughtworks.xstream.core.util.Fields (file:xstream-1.4.7.jar) to field java.awt.font.TextAttribute.instanceMap
    • WARNING: Illegal reflective access by com.thoughtworks.xstream.core.util.Fields (file:xstream-1.4.7.jar) to field java.util.EnumSet.elementType
    • WARNING: Illegal reflective access by com.thoughtworks.xstream.core.util.Fields (file:xstream-1.4.7.jar) to field java.util.EnumMap.keyType

@htreu
Copy link
Contributor

htreu commented Oct 31, 2018

Furthermore there are a lot of WARNINGS coming from jersey, probably because javax.activation and javax.xml packages are not available.

The REST interface however performs just normal. So I'm not sure how severe those warnings are. HK2 dependency injection seems to be the root of this. AFAIK it's not meant to be disabled in jersey.

Oct 31, 2018 10:43:11 AM org.glassfish.jersey.internal.Errors logErrors
WARNING: The following warnings have been detected: WARNING: HK2 service reification failed for [org.glassfish.jersey.message.internal.DataSourceProvider] with an exception:
MultiException stack 1 of 2
java.lang.NoClassDefFoundError: javax/activation/DataSource
	at java.base/java.lang.Class.getDeclaredConstructors0(Native Method)
	at java.base/java.lang.Class.privateGetDeclaredConstructors(Class.java:3138)
	at java.base/java.lang.Class.getDeclaredConstructors(Class.java:2358)
	at org.jvnet.hk2.internal.Utilities$3.run(Utilities.java:1310)
	at org.jvnet.hk2.internal.Utilities$3.run(Utilities.java:1306)
	at java.base/java.security.AccessController.doPrivileged(Native Method)
	at org.jvnet.hk2.internal.Utilities.getAllConstructors(Utilities.java:1306)
	at org.jvnet.hk2.internal.Utilities.findProducerConstructor(Utilities.java:1249)
	at org.jvnet.hk2.internal.DefaultClassAnalyzer.getConstructor(DefaultClassAnalyzer.java:83)
	at org.glassfish.jersey.internal.inject.JerseyClassAnalyzer.getConstructor(JerseyClassAnalyzer.java:144)
	at org.jvnet.hk2.internal.Utilities.getConstructor(Utilities.java:178)
	at org.jvnet.hk2.internal.ClazzCreator.initialize(ClazzCreator.java:128)
	at org.jvnet.hk2.internal.ClazzCreator.initialize(ClazzCreator.java:179)
	at org.jvnet.hk2.internal.SystemDescriptor.internalReify(SystemDescriptor.java:723)
	at org.jvnet.hk2.internal.SystemDescriptor.reify(SystemDescriptor.java:678)
	at org.jvnet.hk2.internal.ServiceLocatorImpl.reifyDescriptor(ServiceLocatorImpl.java:458)
	at org.jvnet.hk2.internal.ServiceLocatorImpl.narrow(ServiceLocatorImpl.java:2205)
	at org.jvnet.hk2.internal.ServiceLocatorImpl.access$1200(ServiceLocatorImpl.java:122)
	at org.jvnet.hk2.internal.ServiceLocatorImpl$9.compute(ServiceLocatorImpl.java:1350)
	at org.jvnet.hk2.internal.ServiceLocatorImpl$9.compute(ServiceLocatorImpl.java:1345)
	at org.glassfish.hk2.utilities.cache.internal.WeakCARCacheImpl.compute(WeakCARCacheImpl.java:116)
	at org.jvnet.hk2.internal.ServiceLocatorImpl.internalGetAllServiceHandles(ServiceLocatorImpl.java:1407)
	at org.jvnet.hk2.internal.ServiceLocatorImpl.getAllServiceHandles(ServiceLocatorImpl.java:1332)
	at org.jvnet.hk2.internal.ServiceLocatorImpl.getAllServiceHandles(ServiceLocatorImpl.java:1321)
	at org.glassfish.jersey.internal.inject.Providers.getServiceHandles(Providers.java:354)
	at org.glassfish.jersey.internal.inject.Providers.getCustomProviders(Providers.java:201)
	at org.glassfish.jersey.message.internal.MessageBodyFactory.<init>(MessageBodyFactory.java:221)
	at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
	at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
	at java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
	at java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:490)
	at org.glassfish.hk2.utilities.reflection.ReflectionHelper.makeMe(ReflectionHelper.java:1350)
	at org.jvnet.hk2.internal.ClazzCreator.createMe(ClazzCreator.java:271)
	at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:365)
	at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:471)
	at org.jvnet.hk2.internal.SingletonContext$1.compute(SingletonContext.java:83)
	at org.jvnet.hk2.internal.SingletonContext$1.compute(SingletonContext.java:71)
	at org.glassfish.hk2.utilities.cache.Cache$OriginThreadAwareFuture$1.call(Cache.java:97)
	at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
	at org.glassfish.hk2.utilities.cache.Cache$OriginThreadAwareFuture.run(Cache.java:154)
	at org.glassfish.hk2.utilities.cache.Cache.compute(Cache.java:199)
	at org.jvnet.hk2.internal.SingletonContext.findOrCreate(SingletonContext.java:122)
	at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2022)
	at org.jvnet.hk2.internal.ServiceLocatorImpl.internalGetService(ServiceLocatorImpl.java:765)
	at org.jvnet.hk2.internal.ServiceLocatorImpl.getService(ServiceLocatorImpl.java:704)
	at org.glassfish.jersey.server.model.ComponentModelValidator.<init>(ComponentModelValidator.java:97)
	at org.glassfish.jersey.server.ApplicationHandler.initialize(ApplicationHandler.java:549)
	at org.glassfish.jersey.server.ApplicationHandler.access$500(ApplicationHandler.java:184)
	at org.glassfish.jersey.server.ApplicationHandler$3.call(ApplicationHandler.java:350)
	at org.glassfish.jersey.server.ApplicationHandler$3.call(ApplicationHandler.java:347)
	at org.glassfish.jersey.internal.Errors.process(Errors.java:315)
	at org.glassfish.jersey.internal.Errors.process(Errors.java:297)
	at org.glassfish.jersey.internal.Errors.processWithException(Errors.java:255)
	at org.glassfish.jersey.server.ApplicationHandler.<init>(ApplicationHandler.java:347)
	at org.glassfish.jersey.servlet.WebComponent.<init>(WebComponent.java:392)
	at org.glassfish.jersey.servlet.ServletContainer.init(ServletContainer.java:177)
	at org.glassfish.jersey.servlet.ServletContainer.init(ServletContainer.java:369)
	at javax.servlet.GenericServlet.init(GenericServlet.java:244)
	at com.eclipsesource.jaxrs.publisher.internal.ServletContainerBridge.run(ServletContainerBridge.java:50)
	at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
	at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
	at java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
	at java.base/java.lang.Thread.run(Thread.java:834)
Caused by: java.lang.ClassNotFoundException: javax.activation.DataSource cannot be found by com.eclipsesource.jaxrs.jersey-min_2.22.2
	at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:433)
	at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:395)
	at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:387)
	at org.eclipse.osgi.internal.loader.ModuleClassLoader.loadClass(ModuleClassLoader.java:150)
	at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
	... 65 more
MultiException stack 2 of 2
java.lang.IllegalArgumentException: Errors were discovered while reifying SystemDescriptor(
	implementation=org.glassfish.jersey.message.internal.DataSourceProvider
	contracts={javax.ws.rs.ext.MessageBodyReader,javax.ws.rs.ext.MessageBodyWriter}
	scope=javax.inject.Singleton
	qualifiers={}
	descriptorType=CLASS
	descriptorVisibility=NORMAL
	metadata=
	rank=0
	loader=org.glassfish.hk2.utilities.binding.AbstractBinder$2@2f0ee98
	proxiable=null
	proxyForSameScope=null
	analysisName=null
	id=51
	locatorId=1
	identityHashCode=694455112
	reified=false)
	at org.jvnet.hk2.internal.SystemDescriptor.reify(SystemDescriptor.java:689)
	at org.jvnet.hk2.internal.ServiceLocatorImpl.reifyDescriptor(ServiceLocatorImpl.java:458)
	at org.jvnet.hk2.internal.ServiceLocatorImpl.narrow(ServiceLocatorImpl.java:2205)
	at org.jvnet.hk2.internal.ServiceLocatorImpl.access$1200(ServiceLocatorImpl.java:122)
	at org.jvnet.hk2.internal.ServiceLocatorImpl$9.compute(ServiceLocatorImpl.java:1350)
	at org.jvnet.hk2.internal.ServiceLocatorImpl$9.compute(ServiceLocatorImpl.java:1345)
	at org.glassfish.hk2.utilities.cache.internal.WeakCARCacheImpl.compute(WeakCARCacheImpl.java:116)
	at org.jvnet.hk2.internal.ServiceLocatorImpl.internalGetAllServiceHandles(ServiceLocatorImpl.java:1407)
	at org.jvnet.hk2.internal.ServiceLocatorImpl.getAllServiceHandles(ServiceLocatorImpl.java:1332)
	at org.jvnet.hk2.internal.ServiceLocatorImpl.getAllServiceHandles(ServiceLocatorImpl.java:1321)
	at org.glassfish.jersey.internal.inject.Providers.getServiceHandles(Providers.java:354)
	at org.glassfish.jersey.internal.inject.Providers.getCustomProviders(Providers.java:201)
	at org.glassfish.jersey.message.internal.MessageBodyFactory.<init>(MessageBodyFactory.java:221)
	at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
	at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
	at java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
	at java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:490)
	at org.glassfish.hk2.utilities.reflection.ReflectionHelper.makeMe(ReflectionHelper.java:1350)
	at org.jvnet.hk2.internal.ClazzCreator.createMe(ClazzCreator.java:271)
	at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:365)
	at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:471)
	at org.jvnet.hk2.internal.SingletonContext$1.compute(SingletonContext.java:83)
	at org.jvnet.hk2.internal.SingletonContext$1.compute(SingletonContext.java:71)
	at org.glassfish.hk2.utilities.cache.Cache$OriginThreadAwareFuture$1.call(Cache.java:97)
	at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
	at org.glassfish.hk2.utilities.cache.Cache$OriginThreadAwareFuture.run(Cache.java:154)
	at org.glassfish.hk2.utilities.cache.Cache.compute(Cache.java:199)
	at org.jvnet.hk2.internal.SingletonContext.findOrCreate(SingletonContext.java:122)
	at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2022)
	at org.jvnet.hk2.internal.ServiceLocatorImpl.internalGetService(ServiceLocatorImpl.java:765)
	at org.jvnet.hk2.internal.ServiceLocatorImpl.getService(ServiceLocatorImpl.java:704)
	at org.glassfish.jersey.server.model.ComponentModelValidator.<init>(ComponentModelValidator.java:97)
	at org.glassfish.jersey.server.ApplicationHandler.initialize(ApplicationHandler.java:549)
	at org.glassfish.jersey.server.ApplicationHandler.access$500(ApplicationHandler.java:184)
	at org.glassfish.jersey.server.ApplicationHandler$3.call(ApplicationHandler.java:350)
	at org.glassfish.jersey.server.ApplicationHandler$3.call(ApplicationHandler.java:347)
	at org.glassfish.jersey.internal.Errors.process(Errors.java:315)
	at org.glassfish.jersey.internal.Errors.process(Errors.java:297)
	at org.glassfish.jersey.internal.Errors.processWithException(Errors.java:255)
	at org.glassfish.jersey.server.ApplicationHandler.<init>(ApplicationHandler.java:347)
	at org.glassfish.jersey.servlet.WebComponent.<init>(WebComponent.java:392)
	at org.glassfish.jersey.servlet.ServletContainer.init(ServletContainer.java:177)
	at org.glassfish.jersey.servlet.ServletContainer.init(ServletContainer.java:369)
	at javax.servlet.GenericServlet.init(GenericServlet.java:244)
	at com.eclipsesource.jaxrs.publisher.internal.ServletContainerBridge.run(ServletContainerBridge.java:50)
	at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
	at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
	at java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
	at java.base/java.lang.Thread.run(Thread.java:834)

@maggu2810
Copy link
Contributor

@kaikreuzer Why using XStream at all?
Wouldn't javax.xml.parsers.SAXParser do its job?
It is part of CP2.

@kaikreuzer
Copy link
Contributor Author

@maggu2810 I cannot remember the details of the decision, this contribution is already very long ago...
Afair, there was an extensive evaluation of the options that were available at that time and XStream was clearly the best one wrt performance and size for embedded use.
Might be that things have changed and that ' javax.xml' might be a better choice by now - but I guess that would be a huge refactoring to do...

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants