Add upward compatibility to Java 9 Modularity #323
Conversation
|
In fact, the jar-derived name might likely be jython.slim, given that that's the preferred artifact to be used in maven dependency management. ( I think the proper solution (perhaps for Jython 3) would be a proper module structure of several modules, e.g.
|
|
Yeah, that's a good idea. But for the current Jython 2, we can set at least explicit the from jar name derived module name. Means for example setting for Jython Slim the |
|
I authorised the regression tests but they don't involve the affected parts of the build. One would need to go through the build for release to test it. |
|
I'm still puzzled whether the different Jython distribution flavors (normal, slim, standalone, installer) should or shouldn't have the same module name. This PR suggests they should. That changes status quo since until now with jar-derived module names they did not. Let's say an external module has a clause |
No worries, I am rather confident this change wouldn't break anything within Jython. It can only possibly affect external usage of Jython. And that's not Jython's responsibility to test. |
|
Bottom line in https://stackoverflow.com/questions/43192741/how-should-i-name-my-java-9-module appears to be to make it the same as a leading API package from the JAR, and that should be based on the reverse domain name. When I specify a dependency in Gradle it is Edit: It appears there can only be one module in each JAR, but no obstacle in the automatic module scheme to having the same packages in differently named modules. You ask a sensible question about the same Java module in multiple JARs (as this PR proposes). I think there would only be a problem if two JARs with the same module were dependencies in the same project. I don't know for sure. I know you're thinking ahead to a Jython 3, but I think that question would be relevant now, should anyone cite both |
|
Ok, I've made a little test, building with ant jython-slim and jython-standalone, jython and python-installer. The issue I've found is a module resolving error by having both on module path: Cmdline was: In my module path, I had the following jar's: Means that for prevent this error, the automatic module name must be set for each jar different. Else if depending for example on jython-slim and jython-standalone, all get broken. |
|
Now, my suggestion would be, using for example as base module name |
|
I'm still educating myself about modules (not my first attempt). However ... I would have predicted the module clash from adding two of our JARs to the module path. I can't think of any reason to do that deliberately. I suppose it might occur accidentally in a complex build where two dependencies used Jython different ways. As I understand it, the dependency graph is between modules, and a JAR is only a way of presenting a module. It would be bad (I think) if the same module had different content depending on which JARs were present, so I think we need different names for the modules, even though they contain many of the same packages. I much prefer a module name (or names) starting The installer doesn't have to be a module, I suggest: it is a packaged app. |
I think I have seen errors when multiple modules are on the module path that contain colliding package names. So, unless we would change package names as well (just kidding), it might anyway not be possible to have e.g. jython.jar and jython-standalone.jar on the module path concurrrently. That is, even if module names differ. However, that was only a compile-time observation and perhaps I overlooked some workaround or magic javac parameters. I see that it is impossible to fulfill all requirements - one module per jar, unique package names and having the concurring Jython distribution flavors. It's a shame that jigsaw does not offer a proper solution for this. (Perhaps one would model module similarities and differences as provided and used services.) My suggestion is the following: we should check if colliding package names are feasible at all. If yes, I'm fine with having different module names. Otherwise I would suggest to have a common module name because multiple ones would not have a benefit and would just pointlessly break the promise that package names are unique across modules. Users can still choose/specify their exact Jython dependency on pom-level. |
|
Perhaps it would be good to introduce a new additional Jython artifact Note that some of Jython's maven dependencies, e.g. netty, would actually apply to |
|
Now regarding to this, having a look at https://stackoverflow.com/questions/53245628/jdk9-automatic-modules-and-split-packages-dependencies, split packages are neither allowed in automatic modules. But looking at the solution, at least in maven it would give two possibilities to solve for example in a complex build an dependency on say jython-slim and jython-standalone:
So in this case, I think as like @Stewori said, it might be better to have a common module name. Otherwise, the idea to modularize the Lib folder with the additional artifact |
|
If split packages are tolerated in explicit, i.e. non-automatic modules, perhaps we could add a proper |
|
I've built JARs from this PR branch and tried them out as I would a release,. They work as expected, i.e. they work with the same failures as when I tested 2.7.4b1. I didn't find any problem mixing the JARs with the same module name. It ran ok, and the JVM seems to accept the first definition it finds on the module path: There is no reason to do that if you control everything, but it is imaginable that transitive dependencies might bring that about. I think we know that if different modules try to supply the same package, we will have a problem. So if we give each jar its own module name, then we also have to break up the contents into non-overlapping collections as @Stewori suggests. But then a project previously satisfied by I wouldn't want to inflict that change on users of Jython 2. (Jython 3, of course, is allowed to be quite different.) So for Jython 2 I think what we have here is fine. To get into 2.7.4, we would have to have a second beta as I tagged b1 last week. |
Adding |
I don't understand this idea yet. (Fortunately, that is not in the way of this PR.) I can use Gradle to build an application with |
|
Okay, sorry Jeff. I must have checked the wrong file or somehow overlooked it. I was in the believe |
|
Confusion resolved, thanks. I'm not at all sure it is done right (including |
|
@R077A6r1an : thanks for working on this and encouraging us to understand modules better. We'd like to include this in a 2.7.4b2 release in a few weeks. (You just missed the b1.) For this I need to give you a few tasks.
After that, I'll:
Point of technique: those last steps I do will make a mess of your fork because your |
|
Okay, I will prepare all. Of what I know, my |
Happier if you leave it as it is for this PR (as long as I can push to it). Once we've merged to our |
|
I've made a new PR from my updated branch at #325. |
|
Ok, I'll pull that one and test. |
I've noticed that Jython uses 1.8 source and target compatibility, but when Jython is used as a Maven/Gradle dependency with Java >= 9 it becomes an unnamed module. Adding the
Automatic-Module-Nameattribute in the jar's manifest resolves this issue, so named modules can require on a save way on it, without need to move Jython to Java 9. The Java 8 build will not be affected by this change, and for java module users it increase stability instead of the module name derived from the jar file name.Now have a look if the module name
org.python.jythonfits, or if you prefer another name instead. In case of keep compatibility to the module name derived from the jar file name, the module name should be changed tojython, as this is the name that Java derives from the jar file published on Maven Central.