javax.activation.DataSource still giving errors

[crapo]

@tuxji , while what we did to change the target and change access rules for javax.activation/** seemed to work for me, both in the dev environment and when I updated from a zip in Eclipse for Java dev 2020-03, @AbhaMoitra gets the same error still (multiple javax.activation.DataSource classes, she will provide the exact message. I'm at a loss as to how to fix this problem, which keeps reappearing.

[AbhaMoitra]

@tuxji For VERDICT-STEM run in eclipse using SADL update of 10/29/2020, I see the following error, let me know of you need additional info.

[crapo]

I've pushed the changes to target. The changes to access rules don't appear in anything that's tracked so I'm not sure how those are supposed to be propagated to other developers. I built the update with a command-line maven install (mvn install -U), so I'm not sure how the changes that we made in eclipse were supposed to propagate to the maven build, or maybe they didn't and that's the problem? Anyway, I am at a loss....

[tuxji]

Oh, we ignore Eclipse files (.classpath, .project, .settings) in our .gitignore, so that's why your access rule changes didn't appear in anything tracked by git. I just updated my sadl checkout, ran mvn clean followed by mvn install, and confirmed that SADL builds successfully. I'll install SADL in Eclipse to try to reproduce Abha's error message later.

[tuxji]

OK, I have troubleshooted this issue and something in Abha's Eclipse must be causing the issue. I have verified that if I do the following steps with a fresh Eclipse install, I will not get a SADL error:

1. Download and unpack Eclipse IDE for Java and DSL Developers 2020-03 (Windows, macOS, Linux)
2. Start Eclipse DSL 2020-03 and click Help -> Install New Software...
3. Click Add... and enter the location of my SADL checkout (freshly built from this commit or later in the development branch)
4. Complete the installation of the SADL feature and restart Eclipse DSL
5. Edit the SADL preferences (open Window -> Preferences and click on SADL)
6. Set Type checking issues as warning only to true and click Apply and Close
7. Import the STEM project from my VERDICT checkout
8. Delete the files in the ImplicitModel folder and click Project -> Clean...
9. Open Run.sadl and run Test Model
10. SADL will run the queries in Run.sadl successfully without any SADL errors and a graph will appear

@crapo, should we make "true" the default setting for the SADL preference "Type checking issues as warning only" from now on? If step 6 is not done, SADL will print the following error message instead of running the queries in Run.sadl:

om.ge.research.sadl.reasoner.TranslationException: Invalid format: 
    at com.ge.research.sadl.model.SadlSerializationFormat.getRDFFormat(SadlSerializationFormat.java:64)
    at com.ge.research.sadl.ide.handlers.SadlRunInferenceHandler.run(SadlRunInferenceHandler.java:86)
    at com.ge.research.sadl.ide.handlers.SadlRunInferenceHandler.run(SadlRunInferenceHandler.java:78)
    at com.ge.research.sadl.ui.handlers.RunInference$1$1.run(RunInference.java:74)

[tuxji]

Upon further investigation, Abha and I have realized that running SADL with Java 8 causes these javax.activation.DataSource SADL error messages. These SADL errors go away after switching to Java 11. Unfortunately, Java 8 still has a copy of javax.activation.DataSource in the JRE while Java 11 has stopped including javax.activation.DataSource in the JRE. When we run SADL with Java 8, the loader is seeing javax.activation.DataSource loaded from both our jar and the JDK, so that is why we are getting the loader error message.

[crapo]

I did a little looking around to see if there is a good alternative to using javax.activation.DataSource, but didn't find anything that looks promising. I suppose one approach would be to build separate updates for Java 8 and Java 11. That would be a pain. Also, the setting of the access rules looks to me like something that every developer building a target for Java 11 will have to do, right?

[crapo]

@tuxji , @AbhaMoitra , @agabaldon , @weisenje , can we just no longer support Java 8, require that SADL users install Java 11?

[tuxji]

I'm fine with requiring Java 11.

[AbhaMoitra]

I am also fine requiring Java 11.

[crapo]

@tuxji , I'm currently in the situation (using Java 11) of having to go through and add an access rule to com.ge.research.jena for javax/activation/** in each project that uses javax.activation each time that I change branch or restart Eclipse. I haven't seen any way to make this rule persist. How should this be handled?

[tuxji]

Ouch. Here's my suggestion. Since we have decided to drop Java 8, we could move javax.activation from Import-Package to Require-Bundle in each MANIFEST.MF which imports javax.activation. According to https://stackoverflow.com/questions/49781697/how-to-specify-access-rules-in-plugin-project-dependency-outside-of-eclipse-user, this should work around the Eclipse access warning by changing the default level of access. To make this change work, we would have to add a line to the target platform definition file to get the javax.activation bundle from the ORBIT update site and possibly append a few lines to the feature file to add the javax.activation bundle to the SADL update site or zip archive. Also, we would have to stop exporting the javax.activation bundle from com.ge.research.jena/META-INF/MANIFEST.MF. I think we had things working this way in Java 11 before but it turned out not to work in Java 8. I found the old change to the target platform definition file in git history here:

https://github.com/SemanticApplicationDesignLanguage/sadl/commit/d52fab151e7419f60514ee2e1527d6224943c5f2

If you need to add javax.activation to the feature.xml because you get a bundle not found problem when installing SADL in a new Eclipse IDE, then here is a commit you can use as an example (I added jsoup to feature.xml to fix a similar error):

https://github.com/SemanticApplicationDesignLanguage/sadl/commit/b15a5e181e4f2c8c5e0a52fd9bc4bcee6a50bd14#diff-518b71678c4247286e60c4eff913235310aee9a71830f48650233ed07a73b8d2

[tuxji]

P.S. @crapo is there any reason why we haven't merged pull request https://github.com/SemanticApplicationDesignLanguage/sadl/pull/532 yet? Could we merge it after the activation problem is fixed?

[crapo]

@tuxji , as far as I know the activation issue is the only possible reason to not merge #532 and I'm not sure that there is actually a dependency between them. I'm pursuing a process where @agabaldon (or you) merges PR but I do not merge PRs.

[tuxji]

I tried my suggestion (Require-Bundle) but unfortunately it doesn't work. See #583.

I confirm I encounter the same Eclipse access rule errors when importing SADL projects into my Eclipse workspace. The simplest way to resolve these errors is to use the quick fix "Configure problem severity" and configure the workspace to turn these errors into warnings instead. You need to do that only once for any new workspace even if you repeatedly reimport SADL projects into the same workspace.

Meanwhile, using Java 11 instead of Java 8 resolves this issue so it can be closed.