----- Mail original ----- > De: "Jochen Theodorou" <blackd...@gmx.org> > À: jigsaw-dev@openjdk.java.net > 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
