[jbosstools-issues] [JBoss JIRA] (JBIDE-19940) Detector of non-compatilbe JVMs may miss UnsupportedClassVersionError(s)

Alexey Kazakov (JIRA) issues at jboss.org
Tue Jul 7 15:35:02 EDT 2015


     [ https://issues.jboss.org/browse/JBIDE-19940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alexey Kazakov updated JBIDE-19940:
-----------------------------------
    Fix Version/s: 4.3.0.CR1
                       (was: 4.3.0.Beta2)


> Detector of non-compatilbe JVMs may miss UnsupportedClassVersionError(s)
> ------------------------------------------------------------------------
>
>                 Key: JBIDE-19940
>                 URL: https://issues.jboss.org/browse/JBIDE-19940
>             Project: Tools (JBoss Tools)
>          Issue Type: Bug
>          Components: common/jst/core
>    Affects Versions: 4.3.0.Beta1
>            Reporter: Alexey Kazakov
>            Assignee: Daniel Azarov
>             Fix For: 4.3.0.CR1
>
>
> When testing JBIDE-19500 (warn/inform users running on non-compatilbe JVMs they are loosing out on features) on some old workspaces I got a situation when Eclipse didn't report a usual error saying "Unresolved requirement: Require-Capability: osgi.ee; filter:="(&(osgi.ee=JavaSE)(version=1.8))" but I got UnsupportedClassVersionErrors like:
> {code}
> Caused by: java.lang.UnsupportedClassVersionError: org/jboss/tools/usage/event/UsageEventType : Unsupported major.minor version 52.0
> 	at java.lang.ClassLoader.defineClass1(Native Method)
> 	at java.lang.ClassLoader.defineClass(ClassLoader.java:800)
> 	at org.eclipse.osgi.internal.loader.ModuleClassLoader.defineClass(ModuleClassLoader.java:272)
> 	at org.eclipse.osgi.internal.loader.classpath.ClasspathManager.defineClass(ClasspathManager.java:632)
> 	at org.eclipse.osgi.internal.loader.classpath.ClasspathManager.findClassImpl(ClasspathManager.java:588)
> 	at org.eclipse.osgi.internal.loader.classpath.ClasspathManager.findLocalClassImpl(ClasspathManager.java:540)
> 	at org.eclipse.osgi.internal.loader.classpath.ClasspathManager.findLocalClass(ClasspathManager.java:527)
> 	at org.eclipse.osgi.internal.loader.ModuleClassLoader.findLocalClass(ModuleClassLoader.java:324)
> 	at org.eclipse.osgi.internal.loader.BundleLoader.findLocalClass(BundleLoader.java:327)
> 	at org.eclipse.osgi.internal.loader.sources.SingleSourcePackage.loadClass(SingleSourcePackage.java:36)
> 	at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:398)
> 	at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:352)
> 	at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:344)
> 	at org.eclipse.osgi.internal.loader.ModuleClassLoader.loadClass(ModuleClassLoader.java:160)
> 	at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
> 	at org.jboss.tools.forge.core.internal.ForgeCorePlugin.initializeUsageReporting(ForgeCorePlugin.java:48)
> 	at org.jboss.tools.forge.core.internal.ForgeCorePlugin.start(ForgeCorePlugin.java:44)
> 	at org.eclipse.osgi.internal.framework.BundleContextImpl$3.run(BundleContextImpl.java:771)
> 	at org.eclipse.osgi.internal.framework.BundleContextImpl$3.run(BundleContextImpl.java:1)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at org.eclipse.osgi.internal.framework.BundleContextImpl.startActivator(BundleContextImpl.java:764)
> {code}
> Maybe it's because I was running JBT from my dev eclipse environment and  Eclipse used some cashed Require-Capability's of load plugins and we won't have such problems in real world when problematic plugins are installed/updated but not modified in dev environment.
> But anyway, this is worth investigation.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


More information about the jbosstools-issues mailing list