Java 9 module support - Githubissues

dev-sce commented 6 years ago

Hello, Is it possible to add java 9 module support to ejml. For the moment, if I create a module: module EjmlTest { requires ejml.core; requires ejml.cdense; requires ejml.ddense; requires ejml.fdense; requires ejml.dsparse; requires ejml.experimental; requires ejml.simple; requires ejml.zdense; }

with a sample test: package test; import org.ejml.data.DMatrix3x3; public class Test { public static void main(String[] args) { DMatrix3x3 a = new DMatrix3x3(); a.print(); } }

I get the following error message: Error occurred during initialization of boot layer java.lang.module.ResolutionException: Modules ejml.ddense and ejml.experimental export package org.ejml.dense.row.decomposition.lu to module EjmlTest

Thanks!

lessthanoptimal commented 6 years ago

https://stackoverflow.com/questions/46277188/modules-a-and-b-export-package-some-package-to-module-c-in-java-9

I haven't used Java 9 modules yet but that's first hit that I get. Is there another module where you require the same packages?

dev-sce commented 6 years ago

I don't think so. I have strictly only one class in this test project, the Test class, and only one dependency, ejml. The 8 jar files are in ModulePath of the project.

With only ejml.core and ejml.ddense, it works, but if I add ejml.cdense, it doesn't work anymore I think, but I'm not sure, that the problems come from the fact that, as example, ejml.ddense declares the package (/org/ejml/dense/row/) and ejml.cdense declares the same package. As your link says, module-a (ejml.ddense) and module-b (ejml.cdense) contain the same package (/org/ejml/dense/row/ for example) and this is not allowed with Java 9 modules (in my case, I use java 10, but I don't think that's a problem).

Thanks

lessthanoptimal commented 6 years ago

I hope that's not the case. Would require a lot code breaking changes and result in a less consistent package layout. Plus a ton of other libraries would not be Java 9 modules compatible. Could you hack around it by converting everything into a single jar?

dev-sce commented 6 years ago

Yes it work. I created a single jar file (ejm-all) containing all classes of all ejml jars and it works. It could be a workaround in the meantime.

seinecle commented 3 years ago

Hi, Hitting the same issue here: module net.clement.levallois.gaze reads package org.ejml.dense.row.factory from both ejml.ddense and ejml.cdense

The solution consists in using unique package names across the modules of the library. Is it possible for @lessthanoptimal to do it?

lessthanoptimal commented 3 years ago

This might happen, but not in the next release. In the past massive API breaking refactorings have caused a a splinter that takes a 2+ years to resolve as no one wants to update when every function call is broken. Last time I provided a script that did about 80% of the work. Not sure anyone used it or not.

I was forced to attempt to create a small Module based project recently. Couldn't get it to work the proper way and ended up "disabling" Modules, but I did learn a bit more about Modules. There does seem to be command line arguments that you can pass to javac and java that enable you to include a non-Module API. I also wonder if I can provide identical module-info.java to all the different jars. That would be a good first pass before proper support is added.

Oliver-Loeffler commented 3 years ago

Hi, I have played now with modules as well and actually, the only drawback in EJML is that the Jars in Maven Central have some common packages aka split packages which is very painful. As @dev-sce mentioned, having a single JAR containing everything would help.

So I see the complexity and the work involved. In order to lets say, slowly remove some blockings w/o disturbing long time users, following proposal:

step 1 - add a new build target comparable to ejml-all where all packages are included, we could call it ejml-all-bundle, basically a fat jar and include this in publishing (e.g. 0.42)
step 2 - create a new sub project and collect shared functionality there so that other projects can rely on this one and eliminate the split packages (0.50)
step 3 - add automatic module name desriptors in the Manifest (0.51)

Making EJML compatible with Java modules does not necessarily require to move to modules. This would also keep the required work at minimum.

What do you thing @lessthanoptimal? I could help you with that.

lessthanoptimal commented 3 years ago

Since Android now allows for Java 11 byte code I was thinking of changing the minimum version to 11, where it will probably stay for a long time. So this is probably a good time to revisit modules. I've still yet to create a module project, but everything you've said seems to make sense and would be a good first pass.

Oliver-Loeffler commented 1 year ago

Hi @lessthanoptimal, happy new year at first!

I'd be open and willing to create a PR for step 1, for creating an artifact called ejml-all-bundle (or any different name better describing the intention) with an appropriate module descriptor and tests to verify if this setup works. It would not break existing code as the idea is more. This would at first allow to use this nice lib in a modular environment. Are you open to review such a PR?

Regards!

lessthanoptimal commented 1 year ago

Sounds like a great plan.

lessthanoptimal / ejml

Java 9 module support #39