On 30.05.2017 14:16, Alan Bateman wrote:
On 30/05/2017 11:52, wzberger wrote:
Our project has around 45 jar libraries and we currently using
split-packages as simplest modularization concept. It's a desktop
project with different kind of controls - all have in common that they
are located in the same package e.g. 'com.swing'. So users can add
only required libraries to their project
[...]
To your example, then if the project can't be restructured to address
the split packages issues then it will need to stay on the class path.
There's nothing wrong with that, it should continue to work as before.
Of course staying on the classpath means to get replaced in the future.
So I don't agree with you here: there is a lot wrong with that imho.
Nobody really cares in the end if you are used as module or not, but if
you cannot do it, you are being replaced with something that can,
because you are not future proof. Breaking the code of about everyone
depending of you can have of course the same effect.
I mean... assume you want to write a named module... how do you depend
on a class in an unnamed module? You do not. You can for example not
extend such a class. javac would not allow that. I can of course still
compile in classpath mode and then use a yet to be written tool, that
generates the module information independent of javac... It means your
module would have an undeclared requirement. I think that is a
complication you normally would not want to have. It is probably more
easy to drop the framework and use something else then.
Oh, you forgot the other alternative... make it a big monolith and
squash the 45 jars into one big module. Then it can move away from the
classpath too. Sure, making a monolithic module really defies the
purpose of the module system, but it is still better than breaking code
or requiring the users to do module system acrobatics.
bye Jochen
