Reference edu.jas from Maven-Central

[HannesWell]

The current edu.jas packages are available on Maven-central under the following coordinates (http://krum.rz.uni-mannheim.de/jas/doc/download.html):

<groupId>de.uni-mannheim.rz.krum</groupId>
<artifactId>jas</artifactId>
<version>2.7.70</version>

When adding a corresponding dependency to the matheclipse-core module, all edu.jas source-packages can be removed from matheclipse-external.

Are there any reason why not to use the Maven-dependency? If not I will submit a PR.

[axkr]

No, there are no reasons. Please go ahead.

[axkr]

@HannesWell I'm not sure, but JAS from Mavem Central seems to require java 11

Exception in thread "main" java.lang.UnsupportedClassVersionError: edu/jas/structure/GcdRingElem has been compiled by a more recent version of the Java Runtime (class file version 55.0), this version of the Java Runtime only recognizes class file versions up to 52.0
        at java.lang.ClassLoader.defineClass1(Native Method)
        at java.lang.ClassLoader.defineClass(ClassLoader.java:763)
        at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
        at java.net.URLClassLoader.defineClass(URLClassLoader.java:468)
        at java.net.URLClassLoader.access$100(URLClassLoader.java:74)
        at java.net.URLClassLoader$1.run(URLClassLoader.java:369)
        at java.net.URLClassLoader$1.run(URLClassLoader.java:363)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.net.URLClassLoader.findClass(URLClassLoader.java:362)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
        at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:349)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
        at java.lang.ClassLoader.defineClass1(Native Method)
        at java.lang.ClassLoader.defineClass(ClassLoader.java:763)
        at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
        at java.net.URLClassLoader.defineClass(URLClassLoader.java:468)
        at java.net.URLClassLoader.access$100(URLClassLoader.java:74)
        at java.net.URLClassLoader$1.run(URLClassLoader.java:369)
        at java.net.URLClassLoader$1.run(URLClassLoader.java:363)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.net.URLClassLoader.findClass(URLClassLoader.java:362)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:424)

[HannesWell]

@HannesWell I'm not sure, but JAS from Mavem Central seems to require java 11

That's bad.
But the pom.xml of JAS from Maven Central uses a source and target level of 1.8 for the compiler plug-in so it should actually only require Java-8 (which corresponds to a class-file version of 52). But the README on JAS' Github page says it requires Java 1.11 (I think they mean 11). I could not find a workflow or similar, so I don't know how they build it exactly. But I can open an Issue and ask for clarification and if Java-1.8 would be possible.

Furthermore I noticed that the workflow of Symja also uses Java-11, but I thought Symja requires only Java 1.8 because it should be compatible with android? The setup-java JDK action says that it provides Java 8, 11 and 16. So if nothing else speaks against it I suggest to use Java 8 to make sure Java-11 API is not used.

[axkr]

Furthermore I noticed that the workflow of Symja also uses Java-11, but I thought Symja requires only Java 1.8 because it should be compatible with android? The setup-java JDK action says that it provides Java 8, 11 and 16. So if nothing else speaks against it I suggest to use Java 8 to make sure Java-11 API is not used.

If its easier for you to get to an 2.0 release, I think we can now support Java 11:
https://jakewharton.com/androids-java-9-10-11-and-12-support/

[axkr]

@HannesWell if you choose Java 11, jgrapht 1.5.1 can also be used from Maven Central.

[HannesWell]

Furthermore I noticed that the workflow of Symja also uses Java-11, but I thought Symja requires only Java 1.8 because it should be compatible with android? The setup-java JDK action says that it provides Java 8, 11 and 16. So if nothing else speaks against it I suggest to use Java 8 to make sure Java-11 API is not used.

If its easier for you to get to an 2.0 release, I think we can now support Java 11:
https://jakewharton.com/androids-java-9-10-11-and-12-support/

For the 2.0 release using Java-11 is not required respectively java-8 is not a blocker.
I derive from this answer that you can re-publish other projects work under your own groupID:
https://maven.apache.org/repository/guide-central-repository-upload.html#faq-and-common-mistakes

Nevertheless requiring Java-11 and with that dropping a patched jgrapht would be nice for us, because we already have jgrapht-1.5.1 in our application and symja adds it a second time. This does not cause issues but increases the application size a bit.
Btw. the choco-solver also requires jgrapht but uses version 1.4. Couldn't symja also use jgrapht-1.4.0?

On the other hand I don't want to break the use in android. Do you know a way to reliably test if the Java-11 features that would be used by Symja or its dependencies are available in android now? From the list in the linked article I deduce that Java-11 is only supported partially. Android is not a use case for me, therefore I almost know nothing about it.
Maybe we should open another issue to discuss the requirement of Java-11.

[axkr]

Ok we can open a new issue and do it the java-8 way.

The choco-solver is very new and experimental, I think we can "comment it out".

I simply have to remove references of the CHOCO_SOLVER toggle in the project:

• symja_android_library/symja_android_library/matheclipse-core/src/main/java/org/matheclipse/core/basic/ToggleFeature.java

  Line 12 in d6c492c

  public static boolean CHOCO_SOLVER = true;

[HannesWell]

Ok we can open a new issue and do it the java-8 way.

Do you mean open a new issue to address the jas Java-11 problem or open another issue to discuss if Symja requires java-11?

The choco-solver is very new and experimental, I think we can "comment it out".

I simply have to remove references of the CHOCO_SOLVER toggle in the project:

* https://github.com/axkr/symja_android_library/blob/d6c492cb66d953977dba165bb1d1f4ed776a2025/symja_android_library/matheclipse-core/src/main/java/org/matheclipse/core/basic/ToggleFeature.java#L12

As you prefer. My comment was just an observation without any intention. :)
Maybe it would be useful to have the choco-solver on a separate dev-branch if it is not yet ready to be part of a symja-release?

[HannesWell]

Since I have reverted the solution of this issue as result of the previous discussion, this issue is open again.

Once this issue is solved again the logging dependencies of jas should be considered.
What has to be done exactly depends on the solution used for Symja, but it is probably certain that the log4j-core dependency should be excluded and only the log4j-api dependency should be transitive in order to allow clients to bound to another Logger-implementation.

[HannesWell]

Resolved with commit 3788b02.