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.
