On 27 Jul 2016, at 8:27, Malachi de Ælfweald wrote:
> I would not expect to specify any transitive dependency. I would not
> expect any user of my API to have to manually specify any transitive
> dependencies I used in my public API (return types for example). If they
> did - that completely bre
Changeset: 559e85570040
Author:jjg
Date: 2016-07-26 17:54 -0700
URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/559e85570040
8160489: Multiple -Xpatch lines ignored by javac
! src/jdk.compiler/share/classes/com/sun/tools/javac/file/BaseFileManager.java
! src/jdk.compiler/
The developer of the main library gets to choose the strength of its
dependence on the companion library. If the developer uses companion API
types in the main library's API signatures, then I think it's good
practice for the main module to say 'requires public companion' or
'requires public st
Malachi, it's not a matter of how one knows or even if one should know.
It's not even a matter of how things should be but how things are. There
are distributions that have a main library and companion libraries.
Sometimes these are coded in a way such that the main library is API that
knows about
If your M3 depends on M2, how do you know what the current implementation
of M2 does behind the scenes? How do you know it isn't depending on M1?
To give a concrete example, if an app depends on GSON, why should they know
about all the internals of how the GSON library is written to know which
met
- Mail original -
> De: "Jason Greene"
> À: "Paul Benedict"
> Cc: "Remi Forax" , "ZML-OpenJDK-Jigsaw-Developers"
>
> Envoyé: Mardi 26 Juillet 2016 23:56:34
> Objet: Re: Weakness of "requires public"
>> On Jul 26, 2016, at 4:50 PM, Paul Benedict wrote:
>>
>> Okay, I accept your scenar
- Mail original -
> De: "Neil Bartlett"
> À: "Malachi de Ælfweald"
> Cc: "Remi Forax" , "ZML-OpenJDK-Jigsaw-Developers"
>
> Envoyé: Mardi 26 Juillet 2016 23:54:06
> Objet: Re: Weakness of "requires public"
> If you have client code that depends on Animal and calls the eat(Organism)
> m
> Hopefully this will be rare. Subclassing creates a very tightly coupled
dependency and it really shouldn’t be done across module boundaries.
While I agree that subclassing is more tightly coupled than say ECS - most
subclasses are of 3rd party classes...?
Malachi de Ælfweald
http://www.google
Alex, that's one half of the puzzle. The other half would be excluding it
at compile time too. In the scenario I was giving Remi, I do not even need
M1 at compile time. It can be completely eliminated from my project.
Cheers,
Paul
On Tue, Jul 26, 2016 at 4:58 PM, Alex Buckley
wrote:
> On 7/26/2
On 7/26/2016 2:50 PM, Paul Benedict wrote:
Okay, I accept your scenario for what it is. You created a very nice
example to illustrate your point where everything must be one, but
you know not every project is like this. The whole discussion with
Joda Time was based on having additional functional
> On Jul 26, 2016, at 4:50 PM, Paul Benedict wrote:
>
> Okay, I accept your scenario for what it is. You created a very nice
> example to illustrate your point where everything must be one, but you know
> not every project is like this. The whole discussion with Joda Time was
> based on having a
If you have client code that depends on Animal and calls the eat(Organism)
method, then your code has a direct dependency on Organism. Now you have a
choice between:
1. explicitly declaring requirements for all the types that you actually use
(i.e. Animal and Organism)
2. explicitly declaring r
Cheers,
Paul
On Tue, Jul 26, 2016 at 4:16 PM, Remi Forax wrote:
> Hi Paul,
> suppose you have a module M1 that declare a class A in an exported package,
>
> module M1 {
> exports m1;
> }
>
> package m1;
> public class A { ... }
>
> now suppose i have a second module M2 that use B as a type of
I admit I came late to the discussion, so I am probably missing something
obvious.
To try to better understand the discussion, I replaced the abritrary
A/B/C/M1/M2/M3 with concrete names...
package world;
public class Organism{...}
package fauna;
public class Animal {
public void eat(Organis
- Mail original -
> De: "Stephen Colebourne"
> À: "jigsaw-dev"
> Envoyé: Mardi 26 Juillet 2016 18:42:47
> Objet: Re: Exporting - the wrong default?
> The purpose of this change is meant to be to enhance Java. While
> security may be part of the issue being tackled, it has never been
>
Hi Paul,
suppose you have a module M1 that declare a class A in an exported package,
module M1 {
exports m1;
}
package m1;
public class A { ... }
now suppose i have a second module M2 that use B as a type of one parameter of
a public method
module M2 {
requires M1;
exports m2;
}
packag
This is one example where Jigsaw is taking on too much responsibility and
it shows. Transitive dependencies is a tricky subject. The reason
transitive dependencies are meant to exist is to bring along common
features but professional build tools allow me to exclude them. AFAICT,
Jigsaw does not
I would not expect to specify any transitive dependency. I would not
expect any user of my API to have to manually specify any transitive
dependencies I used in my public API (return types for example). If they
did - that completely breaks the point of me specifying transitive
dependencies in the
SOURCE_PATH is normally a package-oriented (JDK-8 style) path. It's not
a module-oriented path, so generally, you won't find modules on it.
You probably want to use MODULE_SOURCE_PATH.
-- Jon
On 07/26/2016 06:59 AM, Konstantin Barzilovich wrote:
Hello,
I try to use method getModuleLocatio
In a modularized world, I don't see "requires public" delivering the value
it should.
Let's take this example:
module java.sql {
requires public java.logging;
requires public java.xml;
exports java.sql;
exports javax.sql;
exports javax.transaction.xa;
}
Given a theoretical Mav
The purpose of this change is meant to be to enhance Java. While
security may be part of the issue being tackled, it has never been
claimed as the main one. This proposal does not make it much of an
issue either, as the runtime would likely still have a list of
exported packages - it would be the d
+1
> On Jul 26, 2016, at 11:38 AM, Sundararajan Athijegannathan
> wrote:
>
> Please review http://cr.openjdk.java.net/~sundar/8162538/webrev.00/ for
> https://bugs.openjdk.java.net/browse/JDK-8162538
>
> Thanks,
>
> -Sundar
>
Please review http://cr.openjdk.java.net/~sundar/8162538/webrev.00/ for
https://bugs.openjdk.java.net/browse/JDK-8162538
Thanks,
-Sundar
Hello,
I try to use method getModuleLocation() like this:
JavaFileManager.Location location =
ToolProvider.getSystemJavaCompiler().getStandardFileManager(null, null,
null).getModuleLocation(StandardLocation.SOURCE_PATH, "myModule");
But variable 'location' is always null.
I expected Unsupp
Groovy-core 44 exported and 25 maybe not exported
On 26.07.2016 12:10, Stephen Colebourne wrote:
There has been a lot of discussion about exporting packages - at
compile time vs runtime and also the related problem of resources. I
decided to take a look at some open source projects to see whe
But the question really comes down to, "will 80% of developers be interested in
this level of restriction, or is this functionality which only 20% of all
software needs?
The defaults fails to support open, shared access to facilitate reuse. Instead
it supposes that we are all creating secured,
Exported vs non-exported determined by looking at the packages and
deciding if end users need to be able to compile against them.
Stephen
On 26 July 2016 at 11:48, Alessio Stalla wrote:
> Just curious - how did you identify exported and non-exported packages? Are
> you speaking about your design
On 26/07/2016 11:10, Stephen Colebourne wrote:
Please use this thread to add summaries of other open source
projects.
Many general libraries are going to export most or all packages as that
is the way that they are structured. No surprise there. Exporting all
packages is also the starting poi
Just curious - how did you identify exported and non-exported packages? Are
you speaking about your design intentions or are you looking at actual use
of the libraries in wild?
On 26 July 2016 at 12:10, Stephen Colebourne wrote:
> There has been a lot of discussion about exporting packages - at
On 26.07.2016 12:30, Stephen Colebourne wrote:
This does not appear to change the underlying model of modules
(reliable configuration and strong encapsulation), but would make it
much more practical to use.
It wouldn't be as robust in face of change, as it would require
consciously tracking
Over recent weeks, there has been a long debate about exporting at
runtime, with other discussions about resources. I want to express my
view that listing specific packages for export seems to be the wrong
approach.
In my last thread [1], I found that just 2.5% of packages in the open
source libra
There has been a lot of discussion about exporting packages - at
compile time vs runtime and also the related problem of resources. I
decided to take a look at some open source projects to see whether a
list of exported packages is useful as currently defined:
These standard open source projects w
On 26/07/2016 09:47, Jochen Theodorou wrote:
Around April 10 this year I had to use
-XaddExports:jdk.compiler/com.sun.tools.javac.api=ALL-UNNAMED to get
access using the jigsaw build, which means there was a module
jdk.compiler, that did not export this class.
That is a different package, it
On 26.07.2016 09:11, Alan Bateman wrote:
On 26/07/2016 07:58, Jochen Theodorou wrote:
Hi all,
when I tried the Groovy build jigsaw about 2 months ago the usage of
com.sun.tools.javac.Main required me to make the module it was defined
in to be accessible for the unnamed module. In the latest
On 26/07/2016 07:58, Jochen Theodorou wrote:
Hi all,
when I tried the Groovy build jigsaw about 2 months ago the usage of
com.sun.tools.javac.Main required me to make the module it was defined
in to be accessible for the unnamed module. In the latest version I
tried this was not required any
35 matches
Mail list logo
