Will split-packages ever be supported?

[Stephen Felts]

So for this use case if patches are used, there would be one jar on the module path and 44 jars passed to --patch-module?
What are the limitations of modules used in --patch-module?


-----Original Message-----
From: Remi Forax [mailto:forax at univ-mlv.fr] 
Sent: Tuesday, May 30, 2017 12:41 PM
To: jigsaw-dev at openjdk.java.net; Stephen Felts; Alan Bateman; wzberger
Subject: RE: Will split-packages ever be supported?



On May 30, 2017 4:28:00 PM GMT+02:00, Stephen Felts <stephen.felts at oracle.com> wrote:

Hi Stephen,

>Wouldn't it be possible to add an enhancement to allow for a module to 
>add a package to an existing module?

You can already use --patch-module at compile time and runtime and obviously inject packages before creating the module DAG if you create a ModuleLayer.


>
>
>-----Original Message-----
>From: Alan Bateman
>Sent: Tuesday, May 30, 2017 8:17 AM
>To: wzberger; jigsaw-dev at openjdk.java.net
>Subject: Re: Will split-packages ever be supported?
>
>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. However, in Jigsaw the 
>> split-package concept is not supported - so we have to completely 
>> rework our package structure. This means:
>>
>> - the new package structure will become more complicated because we 
>> have to add new packages
>> - our API isn't backward compatible
>> - our users have to rework their applications
>> - our users have to learn the new API (package structure)
>>
>> So how likely is it that split packages will be supported in the near
>
>> future?
>It's fundamental to reliable configuration that two or more modules do 
>not export a package with the same name to a module that reads both 
>(continuing from the spec "This includes the case where a module M 
>containing package p reads another module that exports p to M"). It 
>seems very unlikely to me that something as fundamental and core as 
>this will ever be dropped.
>
>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.
>
>-Alan.

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.