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 <stephen.fe...@oracle.com> 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:fo...@univ-mlv.fr] > Sent: Tuesday, May 30, 2017 12:41 PM > To: jigsaw-dev@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.fe...@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@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.
