Right; I find the usage of findAll() + findFirst() not perfect,
though, given it's about a single JAR file to begin with. Hence the
suggestion of a dedicated method for that case. But I'll go with your
suggestion for now. Thanks again.
--Gunnar
2017-04-25 10:03 GMT+02:00 Remi Forax :
> If you wa
- Mail original -
> De: "mark reinhold"
> À: "Brian Fox"
> Cc: jigsaw-dev@openjdk.java.net
> Envoyé: Lundi 24 Avril 2017 20:54:18
> Objet: Re: Alternatives for naming automatic modules, and a proposal
> (#AutomaticModuleNames)
> 2017/4/24 10:39:25 -0700, Brian Fox :
>> On Mon, Apr 24, 2
On 25.04.2017 16:38, David M. Lloyd wrote:
[...]
I think that Maven- and Gradle-based tooling will appear to fill this
need. The only correct solution (automatic modules or not) to
modularizing arbitrary groups of artifacts will likely involve a
separate assembly step which will inevitably inclu
On 4/25/2017 1:20 AM, Stephan Herrmann wrote:
On 25.04.2017 03:50, Alex Buckley wrote:
Dependency resolution in JPMS is accomplished by the static 'resolve'
method of java.lang.module.Configuration.
Interesting.
Are you saying the semantics of JPMS depends on the implementation
of one or more
Maven Enforcer Plugin
http://maven.apache.org/enforcer/enforcer-rules/banTransitiveDependencies.html
Checks for lots of different things, including transitive deps.
Stephen
On 25 April 2017 at 17:00, Brian Fox wrote:
> Here's one I'm familiar with:
> https://maven.apache.org/plugins/maven-depend
Here's one I'm familiar with:
https://maven.apache.org/plugins/maven-dependency-plugin/analyze-mojo.html
At least within Maven, it's a known best practice to ensure you're not
dependent on transitives.
On Tue, Apr 25, 2017 at 11:44 AM, wrote:
> 2017/4/25 6:53:45 -0700, bri...@infinity.nu:
> > .
2017/4/25 6:53:45 -0700, bri...@infinity.nu:
> ...
>
> While it's technically true you can consider all the exports to be part of
> the API, the reality is that most libraries aren't used that way. In fact,
> there are commonly accepted tools to detect when you are depending on a
> transitive depe
- Mail original -
> De: "David M. Lloyd"
> À: "Brian Fox"
> Cc: "jigsaw-dev"
> Envoyé: Mardi 25 Avril 2017 16:38:54
> Objet: Re: Alternatives for naming automatic modules, and a proposal
> (#AutomaticModuleNames)
[...]
>
> OSGi, by the way, avoids this situation somewhat more effect
Changeset: 153f6f683816
Author:alanb
Date: 2017-04-25 16:06 +0100
URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/153f6f683816
loadAgent should cleanup if starting agent fails
! src/java.instrument/share/classes/java/lang/instrument/package.html
! src/java.instrument/share/nati
On 04/25/2017 09:15 AM, Brian Fox wrote:
On Tue, Apr 25, 2017 at 9:10 AM, David M. Lloyd mailto:david.ll...@redhat.com>> wrote:
I agree with everything except for this last point. I think that,
given the amount of evangelism over the past 5 or so years, people
will adopt JPMS wheth
Changeset: 32367b88f515
Author:alanb
Date: 2017-04-25 15:22 +0100
URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/32367b88f515
Update java.lang.instrument to document Launcher-Agent-Class and link to JAR
spec
! src/java.instrument/share/classes/java/lang/instrument/package.htm
On Tue, Apr 25, 2017 at 9:10 AM, David M. Lloyd
wrote:
> I agree with everything except for this last point. I think that, given
> the amount of evangelism over the past 5 or so years, people will adopt
> JPMS whether or not it is a fit for their use case. Different shops will
> use different t
On 25/04/2017 14:51, Stephen Colebourne wrote:
:
Has this been documented anywhere? Because all modules in one
classloader seems like entirely the wrong default and I don't
understand the trade off. Clashes on concealed packages will not be
popular.
Changing visibility would be a huge change, es
I completely agree with Stephen.
While it's technically true you can consider all the exports to be part of
the API, the reality is that most libraries aren't used that way. In fact,
there are commonly accepted tools to detect when you are depending on a
transitive dependency that isn't explicitly
About multiple versions or true hiding of non exported packages, I do not
believe that someone is against those features.
But they both requires to change the VM in an extensive way and to my knowledge
nobody has ever done a prototype of those features.
The good news is that both these features
On 25 April 2017 at 14:31, Alan Bateman wrote:
> Someday then we might get to the point where modules on the application
> module path could be assigned to different class loaders but it has huge
> implications and would take an entire release to shake out issues.
Has this been documented anywher
On 04/25/2017 08:31 AM, Alan Bateman wrote:
On 25/04/2017 14:16, Michael Nascimento wrote:
:
and also the fact
packages must be defined by a single module even if they are not
exported,
because it was considered nearly impossible to track in real world
scenarios.
Keep in mind that this is not
On 25/04/2017 14:16, Michael Nascimento wrote:
:
and also the fact
packages must be defined by a single module even if they are not exported,
because it was considered nearly impossible to track in real world
scenarios.
Keep in mind that this is not a module system limitation, instead it is
ju
On Tue, Apr 25, 2017 at 10:10 AM, David M. Lloyd
wrote:
> Just the fact that there is the *very idea* of a "fit"/"non-fit" for JPMS
> is sad though. It should have been the ubiquitous thing that everyone was
> expecting. But denying multiple versions? Blowing up on run time cycles?
> Reneging
On 04/25/2017 07:08 AM, Stephen Colebourne wrote:
On 24 April 2017 at 19:54, wrote:
An explicit module that depends upon one or more modules that are
automatic today is, itself, no more stable than those automatic modules.
It could be broken when those automatic modules are modularized
explici
I was thinking of (a), an automatic module should not allow Java keywords,
apart all methods ModuleDescriptor.new*Module should checks that each component
of the qualified name is not a Java keyword.
The idea is that all variants of ModuleDescriptor.new*Module implements the JLS
semantics and M
On 24 April 2017 at 19:54, wrote:
> An explicit module that depends upon one or more modules that are
> automatic today is, itself, no more stable than those automatic modules.
> It could be broken when those automatic modules are modularized
> explicitly, and if it `requires transitive` an autom
When you say "bug" do you mean
(a) the name of that automatic module should avoid any Java keyword, or
(b) Java keywords should be accepted as (part of) a module name?
Option (a) would require a change in the specification of ModuleFinder
whereas (b) currently conflicts with JLS 7.7 which clearly
[...]
>
> Meanwhile, Mandy Chung has kindly offered to look into the security
> considerations that are at play and come up with a less restrictive
> policy which enforces the security needs more accurately. At that point
> I will probably remove the fallback -- in part because I hope that by
> t
A related note from a Spring perspective:
If automatic module names for third-party dependencies are not to be baked
into higher-level module descriptors, we'll have to wait for all of our
(optional) dependencies to ship module descriptors first, which
single-handedly moves our target date to 2019
On 25.04.2017 03:50, Alex Buckley wrote:
On 4/24/2017 5:22 PM, Stephan Herrmann wrote:
Obviously, defining JPMS is not done in index.html itself but delegated
to individual documents.
One of the linked documents is a version of JLS with changes on behalf
of JSR 376.
Jay's question was triggere
On 25/04/17 07:22, Alan Bateman wrote:
> On 25/04/2017 04:26, Martin Buchholz wrote:
>
>> :
>>
>> java.lang.IllegalArgumentException: illegal lookupClass: class
>> java.util.PriorityQueue
>>
>> Bytecode rewriting agents have the power to inject code into classes;
>> they
>> should somehow also be
On 25/04/2017 08:37, Sabari L Krishnamoorthy wrote:
Hi,
I was experimenting to use --exclude-resources plugin to remove .class
files from modules.
While trying to exclude a single .class file using this plugin works (see
point 1 below), but removal of all .class files from a package throws
err
If you want an Optional, you can use findFirst() on a stream,
Optional ref = ModuleFinder.of( jar
).findAll().stream().findFirst();
Rémi
- Mail original -
> De: "Gunnar Morling"
> À: "Alan Bateman"
> Cc: "jigsaw-dev"
> Envoyé: Mardi 25 Avril 2017 09:10:45
> Objet: Re: Getting the au
Seems to be a bug to me.
Rémi
- Mail original -
> De: "Rafael Winterhalter"
> À: "jigsaw-dev"
> Envoyé: Mardi 25 Avril 2017 09:12:04
> Objet: Module naming restrictions
> Hello,
>
> I did another update of my libraries to support Java 9 and found out that
> Byte Buddy cannot easily be
Hi,
I was experimenting to use --exclude-resources plugin to remove .class
files from modules.
While trying to exclude a single .class file using this plugin works (see
point 1 below), but removal of all .class files from a package throws
error (see point 2 below)
1)
jdk-9/bin/jlink --module-
Hello,
I did another update of my libraries to support Java 9 and found out that
Byte Buddy cannot easily be used as an automatic module. It is published as
byte-buddy.jar to Maven Central where its automatic module name would be
byte.buddy. This does however not compile due to "byte" being a keyw
I see; thanks, Alan.
I wanted to avoid using a regex or similar, in order to make sure the
JDK's own automatic naming rules are applied instead of
"re-implementing" them. I was kinda hoping for a method like
Path jar = ...;
Optional ref = ModuleReference.of( jar );
2017-04-25 8:49 GMT+0
33 matches
Mail list logo
