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