Re: Avoiding same-package conflicts

On 03.11.2015 22:28, Alex Buckley wrote: [...] groovy-compiler will obviously have a hard dependency on groovy-base, but you can avoid groovy-base having a hard dependency on groovy-compiler by using services. Of course this assumes a suitable split between the interface of your compiler and its

Re: Avoiding same-package conflicts

On 04/11/2015 07:45, Jeroen Frijters wrote: : In your JavaOne talk you also mentioned "[no] duplication of exported packages", but the real restriction (at least in the current builds) seems to be "no duplication of packages (in the same layer)". Can you confirm this? Not quite, the

RE: Avoiding same-package conflicts

Alex Buckley wrote: > Yes. We were clear at JavaOne that 1:1 migration -- one module per JAR > -- is just one possibility among many. I actually expect the main > obstacle to 1:1 migration to be not duplication of exported packages but > rather cycles between classes in the JARs. In your JavaOne

Re: Avoiding same-package conflicts

On 02.11.2015 22:03, Alex Buckley wrote: [...] The initial modularization of JavaFX had a similar pattern: more split packages than you would think, due to a "horizontal" module wanting to share packages with numerous "vertical" domain modules. There, the "horizontal" module was a 'builder'

Re: Avoiding same-package conflicts

On 11/3/2015 1:56 AM, Jochen Theodorou wrote: On 02.11.2015 22:03, Alex Buckley wrote: For groovy.util the case is more problematic. Moving GroovyTestCase into a new package would for example break an estimated 95% of our test cases. What will most likely happen is, that the test module merges

Re: Avoiding same-package conflicts

On 10/30/2015 1:38 PM, Jochen Theodorou wrote: I can second that by an example using Groovy. We have not yet taken steps to make jigsaw modules, but we quite some time ago we have split the code base in what would become eventually become modules in the future. Because of history this did mean

Re: Avoiding same-package conflicts

I can second that by an example using Groovy. We have not yet taken steps to make jigsaw modules, but we quite some time ago we have split the code base in what would become eventually become modules in the future. Because of history this did mean to split packages. So we have a couple of jars

Re: Avoiding same-package conflicts

On 29 October 2015 at 13:48, Alan Bateman wrote: > The restriction is that no two modules with the same package (irrespective > of whether it is exported or not, or who reads the modules) can be mapped to > the same class loader. FWIW, I think that this could be a

Re: Avoiding same-package conflicts

On 10/30/2015 04:12 AM, Martin Lehmann wrote: Hi David, hi all, thanks, David, for your response. Sure, reply is inline. Full ACK. Bad practice. I disagree, actually. I think that this is a completely needless and artificial restriction that arose from implementation decisions, not from

RE: Avoiding same-package conflicts

sulate external stuff in different layers and/or to repackage external jar files to guarantee disjunct contents...?) Makes sense? Cheers, Martin -Original Message- From: jigsaw-dev [mailto:jigsaw-dev-boun...@openjdk.java.net] On Behalf Of David M. Lloyd Sent: Thursday, October 29, 2015 12:3

Re: Avoiding same-package conflicts

On 30/10/2015 11:28, Stephen Colebourne wrote: : Here are three cases that appear to be troubled by these restrictions: - a large project that has taken an existing project (module) and split it in two. In order to preserve backwards compatibility, the author wants to retain the package

Re: Avoiding same-package conflicts

On 10/29/2015 05:59 AM, Martin Lehmann wrote: Hi all, I stumbled across the same "issue". that having multiple versions of the same library isn't a best practice to say the least. Full ACK. Bad practice. I disagree, actually. I think that this is a completely needless and artificial

Re: Avoiding same-package conflicts

Hi Alex, indeed I'm on JDK 8 but at the moment I don't have different versions of the same library in the classpath. However sooner or later I will have to satisfy this requirement. I can wait the year or so that separates us from the GA release of JDK 9 but I'm afraid that Jigsaw won't be able

Re: Avoiding same-package conflicts

Hi Karl, Serious question: does your Java SE application expect that different versions of the same library are placed on the classpath in JDK 8? Alex On 10/28/2015 1:34 PM, Karl Sanders wrote: Hi, I'm trying out the JDK 9 EA with Jigsaw. I created two modules, A and B, which are required