Will split-packages ever be supported?

[Jochen Theodorou]

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