[JBoss JIRA] (DROOLS-1169) Running drools with OpenJDK9 (10 May 2016) gives "type java.lang.Object cannot be resolved" and "java.io.Serializable cannot be resolved" due to ECJ 2.5
by Geoffrey De Smet (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1169?page=com.atlassian.jira.plugi... ]
Geoffrey De Smet updated DROOLS-1169:
-------------------------------------
Summary: Running drools with OpenJDK9 (10 May 2016) gives "type java.lang.Object cannot be resolved" and "java.io.Serializable cannot be resolved" due to ECJ 2.5 (was: Running drools with OpenJDK9 (10 May 2016) gives "type java.lang.Object cannot be resolved" and "java.io.Serializable cannot be resolved" due to ECJ)
> Running drools with OpenJDK9 (10 May 2016) gives "type java.lang.Object cannot be resolved" and "java.io.Serializable cannot be resolved" due to ECJ 2.5
> --------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DROOLS-1169
> URL: https://issues.jboss.org/browse/DROOLS-1169
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Reporter: Geoffrey De Smet
> Assignee: Mario Fusco
> Labels: java9
>
> The code below runs perfectly with OpenJDK 8 (and even 6 and 7).
> To reproduce, use JDK 9 ( https://jdk9.java.net/download/ ) and in optaplanner-core, run XStreamXmlSolverFactoryTest [1] (or mostly any other test that builds a DRL file) to get this error:
> {code}
> 15:56:40.229 [main] ERROR o.d.c.k.b.impl.AbstractKieModule - Unable to build KieBaseModel:defaultKieBase
> Rule Compilation error : [Rule name='Conflict']
> org/optaplanner/core/api/solver/Rule_Conflict903142795.java (1:0) : The type java.lang.Object cannot be resolved. It is indirectly referenced from required .class files
> org/optaplanner/core/api/solver/Rule_Conflict903142795.java (1:0) : The type java.io.Serializable cannot be resolved. It is indirectly referenced from required .class files
> org/optaplanner/core/api/solver/Rule_Conflict903142795.java (3:337) : Implicit super constructor Object() is undefined for default constructor. Must define an explicit constructor
> org/optaplanner/core/api/solver/Rule_Conflict903142795.java (6:569) : java.lang.Exception cannot be resolved to a type
> java.lang.IllegalStateException: There are errors in a score DRL:
> Error Messages:
> Message [id=1, level=ERROR, path=org/optaplanner/core/api/solver/testdataScoreRules.drl, line=31, column=0
> text=Rule Compilation error The type java.lang.Object cannot be resolved. It is indirectly referenced from required .class files
> The type java.io.Serializable cannot be resolved. It is indirectly referenced from required .class files
> Implicit super constructor Object() is undefined for default constructor. Must define an explicit constructor
> java.lang.Exception cannot be resolved to a type]
> {code}
> That tests builds this DRL:
> {code}
> package org.optaplanner.core.api.solver;
> dialect "java"
> import org.optaplanner.core.api.score.buildin.simple.SimpleScoreHolder;
> import org.optaplanner.core.impl.testdata.domain.TestdataValue;
> import org.optaplanner.core.impl.testdata.domain.TestdataEntity;
> global SimpleScoreHolder scoreHolder;
> // ############################################################################
> // Constraints
> // ############################################################################
> rule "Conflict"
> when
> TestdataEntity(value != null, $leftValue : value)
> TestdataEntity(value == $leftValue)
> then
> scoreHolder.addConstraintMatch(kcontext, -1);
> end
> {code}
> Not sure where the Object constructor reference comes from... This might be a JDK 9 upstream issue.
> Note: don't build drools with OpenJDK9 as that will fail sooner :)
> [1] https://github.com/droolsjbpm/optaplanner/blob/master/optaplanner-core/sr...
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 8 months
[JBoss JIRA] (WFCORE-1962) Deprecate ParameterValidator.validateResolvedParameter, try and get rid of uses of it
by Brian Stansberry (JIRA)
Brian Stansberry created WFCORE-1962:
----------------------------------------
Summary: Deprecate ParameterValidator.validateResolvedParameter, try and get rid of uses of it
Key: WFCORE-1962
URL: https://issues.jboss.org/browse/WFCORE-1962
Project: WildFly Core
Issue Type: Task
Components: Domain Management
Reporter: Brian Stansberry
Fix For: 3.0.0.Beta1
The ParameterValidator.validateResolvedParameter method specifies the impl should call ModelNode.resolve() and then validate that. This is a broken contract as ModelNode.resolve() is not the expression resolution mechanism of WildFly.
This code is only used in a few places. The normal way resolution + validation happens is outside code (e.g. AttributeDefinition) resolves the value and then calls the normal ParameterValidator.validateParameter method.
So, task here is to look into the few uses of this method in core and full, determine they can be changed to no longer use it, change them, then deprecate this method.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 8 months
[JBoss JIRA] (DROOLS-355) Do not import com.sun.tools.xjc in drools-core and drools-compiler to fix drools on Karaff/Fuse and/or Java 9
by Geoffrey De Smet (JIRA)
[ https://issues.jboss.org/browse/DROOLS-355?page=com.atlassian.jira.plugin... ]
Geoffrey De Smet commented on DROOLS-355:
-----------------------------------------
Discussed with Mario.
The OSGi issue should be fixed with this PR: https://github.com/droolsjbpm/drools/pull/1000
In JDK 9 there is no issue because com.sun.tools.xjc isn't part of the JDK but part of a dependency called jaxb-xjc, this is also why there are no trouble on IBM.
> Do not import com.sun.tools.xjc in drools-core and drools-compiler to fix drools on Karaff/Fuse and/or Java 9
> -------------------------------------------------------------------------------------------------------------
>
> Key: DROOLS-355
> URL: https://issues.jboss.org/browse/DROOLS-355
> Project: Drools
> Issue Type: Task
> Affects Versions: 6.0.0.Final
> Reporter: Geoffrey De Smet
> Assignee: Mario Fusco
> Priority: Blocker
>
> By importing com.sun.tools.xjc, 3 problems arise:
> * OSGi and Karaf trip over it.
> {code}
> [WARNING] No export found to match com.sun.tools.xjc (imported by mvn:org.drools/drools-core/6.0.0.Final)
> {code}
> * JDK 9 will break any java app that uses com.sun.* classes. See Mark Reinhold's Jigsaw presentation at devoxxBE 2013. But XJC is an exception because it's not part of the JDK, it's a separate jar?
> * IBM JDK's etc don't have com.sun.* classes. Why don't they trip over this?
> Why do we have those imports in the first place? Looks like code for old JAXB code - which is hopefully stale now.
> Where do we use it?
> {code}
> Targets
> String 'com.sun.tools.xjc'
> Found usages (38 usages found)
> drools-compiler (7 usages found)
> /home/gdesmet/projects/jboss/droolsjbpm/drools/drools-compiler (1 usage found)
> pom.xml (1 usage found)
> (246: 15) com.sun.tools.xjc.*;resolution:=optional,
> org.drools.compiler.builder.impl (1 usage found)
> KnowledgeBuilderFactoryServiceImpl.java (1 usage found)
> (18: 8) import com.sun.tools.xjc.Options;
> org.drools.compiler.runtime.pipeline.impl (5 usages found)
> DroolsJaxbHelperProviderImpl.java (5 usages found)
> (77: 8) import com.sun.tools.xjc.BadCommandLineException;
> (78: 8) import com.sun.tools.xjc.ErrorReceiver;
> (79: 8) import com.sun.tools.xjc.ModelLoader;
> (80: 8) import com.sun.tools.xjc.Options;
> (81: 8) import com.sun.tools.xjc.model.Model;
> drools-core (2 usages found)
> org.drools.core.builder.conf.impl (2 usages found)
> JaxbConfigurationImpl.java (2 usages found)
> (28: 8) import com.sun.tools.xjc.Language;
> (34: 8) import com.sun.tools.xjc.Options;
> kie-internal (6 usages found)
> /home/gdesmet/projects/jboss/droolsjbpm/droolsjbpm-knowledge/kie-internal (1 usage found)
> pom.xml (1 usage found)
> (27: 15) com.sun.tools.xjc;resolution:=optional,
> org.kie.internal.builder (3 usages found)
> JaxbConfiguration.java (1 usage found)
> (23: 8) import com.sun.tools.xjc.Options;
> KnowledgeBuilderFactory.java (1 usage found)
> (24: 8) import com.sun.tools.xjc.Options;
> KnowledgeBuilderFactoryService.java (1 usage found)
> (24: 8) import com.sun.tools.xjc.Options;
> org.kie.internal.builder.help (2 usages found)
> DroolsJaxbHelperProvider.java (1 usage found)
> (29: 8) import com.sun.tools.xjc.Options;
> KnowledgeBuilderHelper.java (1 usage found)
> (30: 8) import com.sun.tools.xjc.Options;
> knowledge-api (8 usages found)
> org.drools.builder (3 usages found)
> JaxbConfiguration.java (1 usage found)
> (21: 8) import com.sun.tools.xjc.Options;
> KnowledgeBuilderFactory.java (1 usage found)
> (24: 8) import com.sun.tools.xjc.Options;
> KnowledgeBuilderFactoryService.java (1 usage found)
> (24: 8) import com.sun.tools.xjc.Options;
> org.drools.builder.help (3 usages found)
> DroolsJaxbHelperProvider.java (1 usage found)
> (29: 8) import com.sun.tools.xjc.Options;
> KnowledgeBuilderHelper.java (2 usages found)
> (32: 8) import com.sun.tools.xjc.Language;
> (33: 8) import com.sun.tools.xjc.Options;
> org.drools.impl (1 usage found)
> KnowledgeBuilderFactoryServiceImpl.java (1 usage found)
> (16: 8) import com.sun.tools.xjc.Options;
> org.drools.impl.adapters (1 usage found)
> JaxbConfigurationAdapter.java (1 usage found)
> (3: 8) import com.sun.tools.xjc.Options;
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 8 months
[JBoss JIRA] (DROOLS-1169) Running drools with OpenJDK9 (10 May 2016) gives "type java.lang.Object cannot be resolved" and "java.io.Serializable cannot be resolved" due to ECJ
by Geoffrey De Smet (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1169?page=com.atlassian.jira.plugi... ]
Geoffrey De Smet commented on DROOLS-1169:
------------------------------------------
ECJ 4.6.1 has been released, that potentially fixes the issue? Needs to be tried.
> Running drools with OpenJDK9 (10 May 2016) gives "type java.lang.Object cannot be resolved" and "java.io.Serializable cannot be resolved" due to ECJ
> ----------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DROOLS-1169
> URL: https://issues.jboss.org/browse/DROOLS-1169
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Reporter: Geoffrey De Smet
> Assignee: Mario Fusco
> Labels: java9
>
> The code below runs perfectly with OpenJDK 8 (and even 6 and 7).
> To reproduce, use JDK 9 ( https://jdk9.java.net/download/ ) and in optaplanner-core, run XStreamXmlSolverFactoryTest [1] (or mostly any other test that builds a DRL file) to get this error:
> {code}
> 15:56:40.229 [main] ERROR o.d.c.k.b.impl.AbstractKieModule - Unable to build KieBaseModel:defaultKieBase
> Rule Compilation error : [Rule name='Conflict']
> org/optaplanner/core/api/solver/Rule_Conflict903142795.java (1:0) : The type java.lang.Object cannot be resolved. It is indirectly referenced from required .class files
> org/optaplanner/core/api/solver/Rule_Conflict903142795.java (1:0) : The type java.io.Serializable cannot be resolved. It is indirectly referenced from required .class files
> org/optaplanner/core/api/solver/Rule_Conflict903142795.java (3:337) : Implicit super constructor Object() is undefined for default constructor. Must define an explicit constructor
> org/optaplanner/core/api/solver/Rule_Conflict903142795.java (6:569) : java.lang.Exception cannot be resolved to a type
> java.lang.IllegalStateException: There are errors in a score DRL:
> Error Messages:
> Message [id=1, level=ERROR, path=org/optaplanner/core/api/solver/testdataScoreRules.drl, line=31, column=0
> text=Rule Compilation error The type java.lang.Object cannot be resolved. It is indirectly referenced from required .class files
> The type java.io.Serializable cannot be resolved. It is indirectly referenced from required .class files
> Implicit super constructor Object() is undefined for default constructor. Must define an explicit constructor
> java.lang.Exception cannot be resolved to a type]
> {code}
> That tests builds this DRL:
> {code}
> package org.optaplanner.core.api.solver;
> dialect "java"
> import org.optaplanner.core.api.score.buildin.simple.SimpleScoreHolder;
> import org.optaplanner.core.impl.testdata.domain.TestdataValue;
> import org.optaplanner.core.impl.testdata.domain.TestdataEntity;
> global SimpleScoreHolder scoreHolder;
> // ############################################################################
> // Constraints
> // ############################################################################
> rule "Conflict"
> when
> TestdataEntity(value != null, $leftValue : value)
> TestdataEntity(value == $leftValue)
> then
> scoreHolder.addConstraintMatch(kcontext, -1);
> end
> {code}
> Not sure where the Object constructor reference comes from... This might be a JDK 9 upstream issue.
> Note: don't build drools with OpenJDK9 as that will fail sooner :)
> [1] https://github.com/droolsjbpm/optaplanner/blob/master/optaplanner-core/sr...
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 8 months
[JBoss JIRA] (WFLY-7526) Revisit the "jboss.naming.client.ejb.context" property and its use in the DatabaseTimerServiceMultiNode*TestCases
by Farah Juma (JIRA)
Farah Juma created WFLY-7526:
--------------------------------
Summary: Revisit the "jboss.naming.client.ejb.context" property and its use in the DatabaseTimerServiceMultiNode*TestCases
Key: WFLY-7526
URL: https://issues.jboss.org/browse/WFLY-7526
Project: WildFly
Issue Type: Bug
Reporter: Farah Juma
Assignee: Farah Juma
Both {{DatabaseTimerServiceMultiNodeExecutionDisabledTestCase}} and {{DatabaseTimerServiceMultiNodeTestCase}} rely on specifying the {{jboss.naming.client.ejb.context}} property during {{InitialContext}} creation in order to ensure that an {{EJBClientContext}} will get set up properly with an appropriate {{EJBReceiver}}. Since the new WildFly naming client doesn't currently handle this property, we need to manually set the {{EJBClientConfiguration}} in this test for now. We need to revisit this modification when the new WildFly naming client and EJB client are being integrated. Note that without this modification, the tests fail with the following error:
{code}
java.lang.IllegalStateException: EJBCLIENT000025: No EJB receiver available for handling [appName:, moduleName:testTimerServiceSimple, distinctName:] combination for invocation context org.jboss.ejb.client.EJBClientInvocationContext@6548bb7d
at org.jboss.ejb.client.EJBClientContext.requireEJBReceiver(EJBClientContext.java:774)
at org.jboss.ejb.client.ReceiverInterceptor.handleInvocation(ReceiverInterceptor.java:128)
at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:186)
at org.jboss.ejb.client.EJBInvocationHandler.sendRequestWithPossibleRetries(EJBInvocationHandler.java:255)
at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:200)
at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:183)
at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:146)
at com.sun.proxy.$Proxy24.scheduleTimer(Unknown Source)
at org.jboss.as.test.multinode.ejb.timer.database.DatabaseTimerServiceMultiNodeExecutionDisabledTestCase.testEjbTimeoutOnOtherNode(DatabaseTimerServiceMultiNodeExecutionDisabledTestCase.java:197)
{code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 8 months
[JBoss JIRA] (DROOLS-355) Do not import com.sun.tools.xjc in drools-core and drools-compiler to fix drools on Karaff/Fuse and/or Java 9
by Geoffrey De Smet (JIRA)
[ https://issues.jboss.org/browse/DROOLS-355?page=com.atlassian.jira.plugin... ]
Geoffrey De Smet updated DROOLS-355:
------------------------------------
Description:
By importing com.sun.tools.xjc, 3 problems arise:
* OSGi and Karaf trip over it.
{code}
[WARNING] No export found to match com.sun.tools.xjc (imported by mvn:org.drools/drools-core/6.0.0.Final)
{code}
* JDK 9 will break any java app that uses com.sun.* classes. See Mark Reinhold's Jigsaw presentation at devoxxBE 2013. But XJC is an exception because it's not part of the JDK, it's a separate jar?
* IBM JDK's etc don't have com.sun.* classes. Why don't they trip over this?
Why do we have those imports in the first place? Looks like code for old JAXB code - which is hopefully stale now.
Where do we use it?
{code}
Targets
String 'com.sun.tools.xjc'
Found usages (38 usages found)
drools-compiler (7 usages found)
/home/gdesmet/projects/jboss/droolsjbpm/drools/drools-compiler (1 usage found)
pom.xml (1 usage found)
(246: 15) com.sun.tools.xjc.*;resolution:=optional,
org.drools.compiler.builder.impl (1 usage found)
KnowledgeBuilderFactoryServiceImpl.java (1 usage found)
(18: 8) import com.sun.tools.xjc.Options;
org.drools.compiler.runtime.pipeline.impl (5 usages found)
DroolsJaxbHelperProviderImpl.java (5 usages found)
(77: 8) import com.sun.tools.xjc.BadCommandLineException;
(78: 8) import com.sun.tools.xjc.ErrorReceiver;
(79: 8) import com.sun.tools.xjc.ModelLoader;
(80: 8) import com.sun.tools.xjc.Options;
(81: 8) import com.sun.tools.xjc.model.Model;
drools-core (2 usages found)
org.drools.core.builder.conf.impl (2 usages found)
JaxbConfigurationImpl.java (2 usages found)
(28: 8) import com.sun.tools.xjc.Language;
(34: 8) import com.sun.tools.xjc.Options;
kie-internal (6 usages found)
/home/gdesmet/projects/jboss/droolsjbpm/droolsjbpm-knowledge/kie-internal (1 usage found)
pom.xml (1 usage found)
(27: 15) com.sun.tools.xjc;resolution:=optional,
org.kie.internal.builder (3 usages found)
JaxbConfiguration.java (1 usage found)
(23: 8) import com.sun.tools.xjc.Options;
KnowledgeBuilderFactory.java (1 usage found)
(24: 8) import com.sun.tools.xjc.Options;
KnowledgeBuilderFactoryService.java (1 usage found)
(24: 8) import com.sun.tools.xjc.Options;
org.kie.internal.builder.help (2 usages found)
DroolsJaxbHelperProvider.java (1 usage found)
(29: 8) import com.sun.tools.xjc.Options;
KnowledgeBuilderHelper.java (1 usage found)
(30: 8) import com.sun.tools.xjc.Options;
knowledge-api (8 usages found)
org.drools.builder (3 usages found)
JaxbConfiguration.java (1 usage found)
(21: 8) import com.sun.tools.xjc.Options;
KnowledgeBuilderFactory.java (1 usage found)
(24: 8) import com.sun.tools.xjc.Options;
KnowledgeBuilderFactoryService.java (1 usage found)
(24: 8) import com.sun.tools.xjc.Options;
org.drools.builder.help (3 usages found)
DroolsJaxbHelperProvider.java (1 usage found)
(29: 8) import com.sun.tools.xjc.Options;
KnowledgeBuilderHelper.java (2 usages found)
(32: 8) import com.sun.tools.xjc.Language;
(33: 8) import com.sun.tools.xjc.Options;
org.drools.impl (1 usage found)
KnowledgeBuilderFactoryServiceImpl.java (1 usage found)
(16: 8) import com.sun.tools.xjc.Options;
org.drools.impl.adapters (1 usage found)
JaxbConfigurationAdapter.java (1 usage found)
(3: 8) import com.sun.tools.xjc.Options;
{code}
was:
By importing com.sun.tools.xjc, 3 problems arise:
* OSGi and Karaf trip over it.
{code}
[WARNING] No export found to match com.sun.tools.xjc (imported by mvn:org.drools/drools-core/6.0.0.Final)
{code}
* JDK 9 will break any java app that uses com.sun.* classes. See Mark Reinhold's Jigsaw presentation at devoxxBE 2013.
* IBM JDK's etc don't have com.sun.* classes. Why don't they trip over this?
Why do we have those imports in the first place? Looks like code for old JAXB code - which is hopefully stale now.
Where do we use it?
{code}
Targets
String 'com.sun.tools.xjc'
Found usages (38 usages found)
drools-compiler (7 usages found)
/home/gdesmet/projects/jboss/droolsjbpm/drools/drools-compiler (1 usage found)
pom.xml (1 usage found)
(246: 15) com.sun.tools.xjc.*;resolution:=optional,
org.drools.compiler.builder.impl (1 usage found)
KnowledgeBuilderFactoryServiceImpl.java (1 usage found)
(18: 8) import com.sun.tools.xjc.Options;
org.drools.compiler.runtime.pipeline.impl (5 usages found)
DroolsJaxbHelperProviderImpl.java (5 usages found)
(77: 8) import com.sun.tools.xjc.BadCommandLineException;
(78: 8) import com.sun.tools.xjc.ErrorReceiver;
(79: 8) import com.sun.tools.xjc.ModelLoader;
(80: 8) import com.sun.tools.xjc.Options;
(81: 8) import com.sun.tools.xjc.model.Model;
drools-core (2 usages found)
org.drools.core.builder.conf.impl (2 usages found)
JaxbConfigurationImpl.java (2 usages found)
(28: 8) import com.sun.tools.xjc.Language;
(34: 8) import com.sun.tools.xjc.Options;
kie-internal (6 usages found)
/home/gdesmet/projects/jboss/droolsjbpm/droolsjbpm-knowledge/kie-internal (1 usage found)
pom.xml (1 usage found)
(27: 15) com.sun.tools.xjc;resolution:=optional,
org.kie.internal.builder (3 usages found)
JaxbConfiguration.java (1 usage found)
(23: 8) import com.sun.tools.xjc.Options;
KnowledgeBuilderFactory.java (1 usage found)
(24: 8) import com.sun.tools.xjc.Options;
KnowledgeBuilderFactoryService.java (1 usage found)
(24: 8) import com.sun.tools.xjc.Options;
org.kie.internal.builder.help (2 usages found)
DroolsJaxbHelperProvider.java (1 usage found)
(29: 8) import com.sun.tools.xjc.Options;
KnowledgeBuilderHelper.java (1 usage found)
(30: 8) import com.sun.tools.xjc.Options;
knowledge-api (8 usages found)
org.drools.builder (3 usages found)
JaxbConfiguration.java (1 usage found)
(21: 8) import com.sun.tools.xjc.Options;
KnowledgeBuilderFactory.java (1 usage found)
(24: 8) import com.sun.tools.xjc.Options;
KnowledgeBuilderFactoryService.java (1 usage found)
(24: 8) import com.sun.tools.xjc.Options;
org.drools.builder.help (3 usages found)
DroolsJaxbHelperProvider.java (1 usage found)
(29: 8) import com.sun.tools.xjc.Options;
KnowledgeBuilderHelper.java (2 usages found)
(32: 8) import com.sun.tools.xjc.Language;
(33: 8) import com.sun.tools.xjc.Options;
org.drools.impl (1 usage found)
KnowledgeBuilderFactoryServiceImpl.java (1 usage found)
(16: 8) import com.sun.tools.xjc.Options;
org.drools.impl.adapters (1 usage found)
JaxbConfigurationAdapter.java (1 usage found)
(3: 8) import com.sun.tools.xjc.Options;
{code}
> Do not import com.sun.tools.xjc in drools-core and drools-compiler to fix drools on Karaff/Fuse and/or Java 9
> -------------------------------------------------------------------------------------------------------------
>
> Key: DROOLS-355
> URL: https://issues.jboss.org/browse/DROOLS-355
> Project: Drools
> Issue Type: Task
> Affects Versions: 6.0.0.Final
> Reporter: Geoffrey De Smet
> Assignee: Mario Fusco
> Priority: Blocker
>
> By importing com.sun.tools.xjc, 3 problems arise:
> * OSGi and Karaf trip over it.
> {code}
> [WARNING] No export found to match com.sun.tools.xjc (imported by mvn:org.drools/drools-core/6.0.0.Final)
> {code}
> * JDK 9 will break any java app that uses com.sun.* classes. See Mark Reinhold's Jigsaw presentation at devoxxBE 2013. But XJC is an exception because it's not part of the JDK, it's a separate jar?
> * IBM JDK's etc don't have com.sun.* classes. Why don't they trip over this?
> Why do we have those imports in the first place? Looks like code for old JAXB code - which is hopefully stale now.
> Where do we use it?
> {code}
> Targets
> String 'com.sun.tools.xjc'
> Found usages (38 usages found)
> drools-compiler (7 usages found)
> /home/gdesmet/projects/jboss/droolsjbpm/drools/drools-compiler (1 usage found)
> pom.xml (1 usage found)
> (246: 15) com.sun.tools.xjc.*;resolution:=optional,
> org.drools.compiler.builder.impl (1 usage found)
> KnowledgeBuilderFactoryServiceImpl.java (1 usage found)
> (18: 8) import com.sun.tools.xjc.Options;
> org.drools.compiler.runtime.pipeline.impl (5 usages found)
> DroolsJaxbHelperProviderImpl.java (5 usages found)
> (77: 8) import com.sun.tools.xjc.BadCommandLineException;
> (78: 8) import com.sun.tools.xjc.ErrorReceiver;
> (79: 8) import com.sun.tools.xjc.ModelLoader;
> (80: 8) import com.sun.tools.xjc.Options;
> (81: 8) import com.sun.tools.xjc.model.Model;
> drools-core (2 usages found)
> org.drools.core.builder.conf.impl (2 usages found)
> JaxbConfigurationImpl.java (2 usages found)
> (28: 8) import com.sun.tools.xjc.Language;
> (34: 8) import com.sun.tools.xjc.Options;
> kie-internal (6 usages found)
> /home/gdesmet/projects/jboss/droolsjbpm/droolsjbpm-knowledge/kie-internal (1 usage found)
> pom.xml (1 usage found)
> (27: 15) com.sun.tools.xjc;resolution:=optional,
> org.kie.internal.builder (3 usages found)
> JaxbConfiguration.java (1 usage found)
> (23: 8) import com.sun.tools.xjc.Options;
> KnowledgeBuilderFactory.java (1 usage found)
> (24: 8) import com.sun.tools.xjc.Options;
> KnowledgeBuilderFactoryService.java (1 usage found)
> (24: 8) import com.sun.tools.xjc.Options;
> org.kie.internal.builder.help (2 usages found)
> DroolsJaxbHelperProvider.java (1 usage found)
> (29: 8) import com.sun.tools.xjc.Options;
> KnowledgeBuilderHelper.java (1 usage found)
> (30: 8) import com.sun.tools.xjc.Options;
> knowledge-api (8 usages found)
> org.drools.builder (3 usages found)
> JaxbConfiguration.java (1 usage found)
> (21: 8) import com.sun.tools.xjc.Options;
> KnowledgeBuilderFactory.java (1 usage found)
> (24: 8) import com.sun.tools.xjc.Options;
> KnowledgeBuilderFactoryService.java (1 usage found)
> (24: 8) import com.sun.tools.xjc.Options;
> org.drools.builder.help (3 usages found)
> DroolsJaxbHelperProvider.java (1 usage found)
> (29: 8) import com.sun.tools.xjc.Options;
> KnowledgeBuilderHelper.java (2 usages found)
> (32: 8) import com.sun.tools.xjc.Language;
> (33: 8) import com.sun.tools.xjc.Options;
> org.drools.impl (1 usage found)
> KnowledgeBuilderFactoryServiceImpl.java (1 usage found)
> (16: 8) import com.sun.tools.xjc.Options;
> org.drools.impl.adapters (1 usage found)
> JaxbConfigurationAdapter.java (1 usage found)
> (3: 8) import com.sun.tools.xjc.Options;
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 8 months