If you were to allow jme to take the first step towards modularization by assigning an automatic module name, what would be the recommended names for the modules?
For example:
project
jme3-bullet-native-android
as a module,
jme3.bullet.native.android
or use the com.jme3, then project name,
com.jme3.jme3.bullet.native.android
This can be achieved with a minimal change to the common.gradle file.
changes to,
jar {
manifest {
attributes 'Implementation-Title': 'jMonkeyEngine',
'Implementation-Version': jmeFullVersion,
'Automatic-Module-Name': "com.jme3.${project.name.replace("-", ".")}"
}
}
This would follow standards of using the com.jme3 followed by project name and produce this.
Automatic-Module-Name: com.jme3.jme3.android.native
Automatic-Module-Name: com.jme3.jme3.android
Automatic-Module-Name: com.jme3.jme3.bullet.native.android
Automatic-Module-Name: com.jme3.jme3.bullet.native
Automatic-Module-Name: com.jme3.jme3.bullet
Automatic-Module-Name: com.jme3.jme3.core
Automatic-Module-Name: com.jme3.jme3.desktop
Automatic-Module-Name: com.jme3.jme3.effects
Automatic-Module-Name: com.jme3.jme3.ios
Automatic-Module-Name: com.jme3.jme3.jbullet
Automatic-Module-Name: com.jme3.jme3.jogg
Automatic-Module-Name: com.jme3.jme3.lwjgl
Automatic-Module-Name: com.jme3.jme3.lwjgl3
Automatic-Module-Name: com.jme3.jme3.networking
Automatic-Module-Name: com.jme3.jme3.niftygui
Automatic-Module-Name: com.jme3.jme3.plugins
Automatic-Module-Name: com.jme3.jme3.terrain
Automatic-Module-Name: com.jme3.jme3.testdata
Automatic-Module-Name: com.jme3.jme3.vr
Edit: In each jars manifest.
The jme3.jme3 part feels a bit redundant. What do other projects do?
See Chapter 6. Names example 6-1-2
The name of a module should correspond to the name of its principal exported package. If a module does not have such a package, or if for legacy reasons it must have a name that does not correspond to one of its exported packages, then its name should still start with the reversed form of an Internet domain with which its author is associated.
We have subprojects so probably drop com.jme3?
Edit: thats how its done when using netbeans auto generation of module-info.
requires jme3.lwjgl3;
requires jme3.desktop;
requires jme3.networking;
requires jme3.plugins;
requires lemur.proto;
requires lemur.props;
requires lemur;
requires jme3.core;
But can be whatever you guys want.
I haven’t had a need for this at all yet (and I still get cold sweats thinking about other packaging schemes)… so I don’t know what the common lore is here.
If it were me, I’d find packages where there is an overall umbrella with lots of sublibraries and see what they do. What does spring do? What does google do with gson, guava, etc.? That’s my approach for learning what’s stupid and what’s just dumb until I can form a strong opinion. 
The thing that interested me about modularization is blocking reflection. Sorta like obfuscation for free if done right, at least they make it sound like it is.
Looks to me like dropping the com.jme3 is the right way as jme3 is in the package name.
module org.springframework.samples.petclinic {
requires java.xml.bind;
requires javax.transaction.api;
requires validation.api;
requires hibernate.jpa;
requires hibernate.validator;
requires spring.beans;
requires spring.core;
requires spring.context;
requires spring.tx;
requires spring.web;
requires spring.webmvc;
requires spring.data.commons;
requires spring.data.jpa;
requires spring.boot;
requires spring.boot.autoconfigure;
requires cache.api;
}
So this is the change to common.gradle.
jar {
manifest {
attributes 'Implementation-Title': 'jMonkeyEngine',
'Implementation-Version': jmeFullVersion,
'Automatic-Module-Name': "${project.name.replace("-", ".")}"
}
}
which generates this.
Automatic-Module-Name: jme3.android.native
Automatic-Module-Name: jme3.android
Automatic-Module-Name: jme3.bullet.native.android
Automatic-Module-Name: jme3.bullet.native
Automatic-Module-Name: jme3.bullet
Automatic-Module-Name: jme3.core
Automatic-Module-Name: jme3.desktop
Automatic-Module-Name: jme3.effects
Automatic-Module-Name: jme3.ios
Automatic-Module-Name: jme3.jbullet
Automatic-Module-Name: jme3.jogg
Automatic-Module-Name: jme3.lwjgl
Automatic-Module-Name: jme3.lwjgl3
Automatic-Module-Name: jme3.networking
Automatic-Module-Name: jme3.niftygui
Automatic-Module-Name: jme3.plugins
Automatic-Module-Name: jme3.terrain
Automatic-Module-Name: jme3.testdata
Automatic-Module-Name: jme3.vr
This is a problem.
Automatic-Module-Name: jme3.lwjgl3
Module names are not supposed to end in digits if they match a major version. This will generate warning.
“three”
jme3-lwjgl.II
jme3-lwjgl.III
this would require minimum Java 9 while for now we have minimum 8, am i correct?
Since this is auto-generating the module names at compile time, it’d be simple enough to gate on the version of the compiler being used, would it not?
I’ve thought a couple of times that sub-project-as-module would be a good first pass, because when the sub-project structure was designed, module was what was wanted in the first place. It just hadn’t been invented yet.
What do you mean “require”? “Require” in that in order to use this feature, you need java 9 (then not really required). Or “Require” in that even having these options in your manifest will break java 8?
…which would be very strange because you can normally put whatever weird crap you want in a jar manifest file.
Its a manifest attribute so it affects nothing unless you want it to, but you would need java 9+ to use it.
Yes but I have read nothing that says you should do that. Everything I read says drop the version.
Can you point me to some info that recommends that?
It seems a little different in this case since we have two separate modules that integrate with two versions of the same library.
I wonder how something like slf4j deals with the log4j versus log4j2 adapter. (Or maybe they don’t.)
If I remember correctly it’s this.
As its a warning that can be suppressed.
I think I misunderstood who you were talking to.
You were telling @oxplay2 he could set the compiler version right?
If everyone is ok with this, I will issue a pr tomorrow.