Will split-packages ever be supported?

[Remi Forax]

----- Mail original -----
> De: "Jochen Theodorou" <blackdrag at gmx.org>
> À: jigsaw-dev at openjdk.java.net
> Envoyé: Mardi 30 Mai 2017 15:16:46
> Objet: Re: Will split-packages ever be supported?

> 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.

the big monolithic module is a good transition solution,
i've done that with Aether to get access to Maven Central inside a fully modularized project,
but it's like with automatic modules, it's just a temporary solution that you can use in your application and not something you can do if you want to publish a library.

> 
> bye Jochen


Rémi