Will split-packages ever be supported?

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Will split-packages ever be supported?

wzberger
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?

- Wolfgang

Reply | Threaded
Open this post in threaded view
|

Re: Will split-packages ever be supported?

Alan Bateman
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.
Reply | Threaded
Open this post in threaded view
|

Re: 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
Reply | Threaded
Open this post in threaded view
|

Re: Will split-packages ever be supported?

forax
----- Mail original -----
> De: "Jochen Theodorou" <[hidden email]>
> À: [hidden email]
> 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
Reply | Threaded
Open this post in threaded view
|

RE: Will split-packages ever be supported?

Stephen Felts
In reply to this post by Alan Bateman
Wouldn't it be possible to add an enhancement to allow for a module to add a package to an existing module?  Sort of like OSGI fragment bundles, which are very popular.
I don't understand what is so fundamental about this.


-----Original Message-----
From: Alan Bateman
Sent: Tuesday, May 30, 2017 8:17 AM
To: wzberger; [hidden email]
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.
Reply | Threaded
Open this post in threaded view
|

RE: Will split-packages ever be supported?

forax


On May 30, 2017 4:28:00 PM GMT+02:00, Stephen Felts <[hidden email]> 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.

> Sort of like OSGI fragment
>bundles, which are very popular.

popular among OSGI users, and  sometimes for the wrong reason IMO like a practical workaround of the one artifact == one classloader limitation of OSGI

>I don't understand what is so fundamental about this.

OSGI requires packages, not modules, so fragments make a lot of more sense.

In JPMS, the identity of a module is its containing packages (even the non exported ones at least for 9) so fragment makes even less sense because they will change the ABI of a module.

Also note that the configuration adaptability use cases of fragments is covered by different mechanisms, services (using an interface instead of injecting property files is cleaner IMO), the require static (to react if a class is present or not by reflection), the multi version jars (for features depending on the JDK version) and jmod file (for including native libraries).

cheers,
Rémi

>
>
>-----Original Message-----
>From: Alan Bateman
>Sent: Tuesday, May 30, 2017 8:17 AM
>To: wzberger; [hidden email]
>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.
Reply | Threaded
Open this post in threaded view
|

RE: 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:[hidden email]]
Sent: Tuesday, May 30, 2017 12:41 PM
To: [hidden email]; 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 <[hidden email]> 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; [hidden email]
>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.
Reply | Threaded
Open this post in threaded view
|

Re: Will split-packages ever be supported?

Sander Mak

> On 30 May 2017, at 19:11, Stephen Felts <[hidden email]> wrote:
>
> 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?

You can't patch module-info.class, which may be significant if any of the 44 jars have dependencies the original module hasn't. You can use --add-reads (possibly in combination with --add-modules) to introduce new readability relations for the patched module though.


Sander

Reply | Threaded
Open this post in threaded view
|

Re: Will split-packages ever be supported?

Volker Simonis
In reply to this post by Stephen Felts
One limitation is that it is not a "standard" Java option so you can't
be sure every Java 9 implementation supports it.

On Tue, May 30, 2017 at 7:11 PM, Stephen Felts <[hidden email]> wrote:

> 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:[hidden email]]
> Sent: Tuesday, May 30, 2017 12:41 PM
> To: [hidden email]; 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 <[hidden email]> 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; [hidden email]
>>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.
Reply | Threaded
Open this post in threaded view
|

Re: Will split-packages ever be supported?

Jochen Theodorou
In reply to this post by forax

On 30.05.2017 16:21, Remi Forax wrote:
[...]
> 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.

I see it more as intermediate solution... and like it is with solutions
like that, it will be the final solution for a long time. Maybe I would
go with two flavors for the modules. One is the big monolith, the other
is after a jar has been freed from the split package problem. In that
case your project can depend on the small module, which will
transitively depend on the shrunken monolith. This allows the project a
transition phase of undetermined length and shows it is still future
proof. One could even consider using a bytecode rewriting tool and let
the monolith use the old package names.

Probably because nobody really cared about how easily the Java platform
can be exploited. Well, I dare to say, that we have been especially bad
here. Not that any of the exploits I know the specifics about, would not
be working anymore in JDK9... sorry I digress.

Of course if you are in a situation like we are, then all this will not
help, because we have split package problems with third party projects.
Our own fault, really, yes... but the split package problem is not
something many people have been aware of it seems. Especially since in
our case it was really only a name space question, not a question about
access rights at all.

bye Jochen