Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Java 9 module support #39

Open
dev-sce opened this issue Jul 23, 2018 · 10 comments · May be fixed by #203
Open

Java 9 module support #39

dev-sce opened this issue Jul 23, 2018 · 10 comments · May be fixed by #203

Comments

@dev-sce
Copy link

dev-sce commented Jul 23, 2018

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
Copy link
Owner

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
Copy link
Author

dev-sce commented Jul 23, 2018

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
Copy link
Owner

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
Copy link
Author

dev-sce commented Jul 24, 2018

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
Copy link

seinecle commented Mar 24, 2021

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
Copy link
Owner

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
Copy link

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
Copy link
Owner

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
Copy link

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
Copy link
Owner

Sounds like a great plan.

@SamCarlberg SamCarlberg linked a pull request Dec 2, 2024 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants