Re: Multiple versions of a non-exported dependency

Neil, but doesn't the prohibition of duplicate packages continue to rear its head? Cheers, Paul On Wed, Aug 31, 2016 at 2:21 PM, cowwoc wrote: > Well, this is unfortunate. As I stated earlier, I fail to see how > depending on constant version numbers (not version

MNG-5567: Zips on classpath

I see that zip files will be added to the classpath with Maven 3.4: https://issues.apache.org/jira/browse/MNG-5567 I am sure there is a way to exclude them from the classpath, too, right? What is the means to do that? Not every "zip" is a jar. In fact, Java has 2 NIO file system providers -- one

Layer questions

Dear Jigsaw Experts, I have a few questions on layers: 1) True of False: Except for the Boot Layer, every Layer must have a parent Layer? 2) Is there any API to enumerate the Layer instances in the JVM? 3) Since Layer instances may commonly represent a miniature system design (think

Re: Issue with an automatic module

Given that "automatic modules" are meant to be a migration path, I think refusing any legacy jar adds an unfortunate surprise to migrating. I understand the intent to throw FindException with regard to real modules (has module-info.class), but why apply the same restriction to *automatic* modules?

Re: Flag missing with "requires java.base"?

Correct me if wrong, but it seems there is no universal way to flag something as compiler/tool generated. My take away from Alex's comments is that ACC_SYNTHETIC is very much concerned with implicitness/explicitness... but why? I still don't understand why it *must* be concerned anything like

Re: Exporting - the wrong default?

To echo David, there is a complaint by me in these archives how I still find it difficult to remember that "public" is no longer being public. I feel the same way today still. The word "public" means "for everyone" so it's always jarring to have it no longer mean what it should mean in normal

SPI for customizing modules?

Jigsaw Experts, It seems the only way to customize modules is not to use --module-path. It seems if I want to customize, I have to load myself. Right or wrong? I am looking for an SPI where I can customize any non-JDK module. I believe this would be easier than the current path I am on. I'd

Re: Flag missing with "requires java.base"?

ust emit ...".) > > Alex > > On 7/29/2016 12:18 PM, Paul Benedict wrote: > >> Okay. So I was hoping to look at any module-info.class and determine >> whether "requires java.base" was source code explicit or merely a >> compiler shim. I understand this p

Re: Flag missing with "requires java.base"?

Okay. So I was hoping to look at any module-info.class and determine whether "requires java.base" was source code explicit or merely a compiler shim. I understand this particular "requires" is ACC_MANDATED, but it seems there is not a way to trace back to the actual source code. I consider this a

Re: Exporting - the wrong default?

I think what Jigsaw has done (to modularize the JDK) is well-achieved and a round of kudos should go out to Mark, Alan, Alex, and the rest of the Oracle crowd for spending years on this herculean effort. With that said, there are many more wrinkles to iron out for everyone else. I believe the

Re: Flag missing with "requires java.base"?

ither explicitly declared (no ACC_SYNTHETIC, no ACC_MANDATED) or > implicitly declared (no ACC_SYNTHETIC, yes ACC_MANDATED) -- there are no > other possibilities. > > Alex > > > On 7/28/2016 9:11 AM, Paul Benedict wrote: > >> Although "java.base" is mandated to

Re: Transitive dependencies question

Yes. Thanks Alan. Cheers, Paul On Thu, Jul 28, 2016 at 11:20 AM, Alan Bateman <alan.bate...@oracle.com> wrote: > On 28/07/2016 16:44, Paul Benedict wrote: > > Here is an example use case. Please confirm my understanding. I'd like to >> know if transitive dependencies go

Question on specifying modules in layers

Dear Jigsaw experts, Instead of loading modules through --module-path, I would like to discover them programmatically through other means. I can produce a Configuration and Layer for this. I would like to delegate the module finding to the parent too. In other words, I want the parent to be the

Re: Weakness of "requires public"

flag to do > that, but an addition to module-info may also make sense. > > Stephen > > > On 26 July 2016 at 19:35, Paul Benedict <pbened...@apache.org> wrote: > > In a modularized world, I don't see "requires public" delivering the > value > > it sh

Re: Weakness of "requires public"

The other potential use case I have identified is when two modules carry transitive dependencies of the same package structures. Module A drags in Module B, Module C drags in Module D, but both B and D are code clones of each other. In a realistic scenario, B and D could be Apache Commons Lang

Re: Weakness of "requires public"

uck...@oracle.com> wrote: > 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 discussi

Re: Weakness of "requires public"

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

Re: Weakness of "requires public"

; http://www.google.com/profiles/malachid > > On Tue, Jul 26, 2016 at 11:35 AM, Paul Benedict <pbened...@apache.org> > wrote: > >> In a modularized world, I don't see "requires public" delivering the value >> it should. >> >> Let's take this examp

Weakness of "requires public"

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

Discussion on "static" and "dynamic" - right or wrong direction?

The one thought that keeps coming back to me is that "static" and "dynamic" bring Jigsaw into an area it was trying to get out of originally: build management. In my testing and the re-reading of what's been published, clearly these two things called "phases" represent what build management tools

Re: Issue with qualified exports

ments about how a qualified > export induces a compile-time circularity, being sure to note that taking a > more relaxed view means passing through garbage qualified exports. > > Alex > > On 7/20/2016 4:22 PM, Paul Benedict wrote: > >> Alex, I must respectfully disagr

Re: Issue with qualified exports

proof? Cheers, Paul On Wed, Jul 20, 2016 at 6:00 PM, Alex Buckley <alex.buck...@oracle.com> wrote: > On 7/20/2016 3:07 PM, Paul Benedict wrote: > >> Currently I am writing a module that another team will consume. Let's just >> call these modules A and B. Module A must ex

Issue with qualified exports

My build is build 9-ea+125-2016-07-08-164610.javare.5260.nc Currently I am writing a module that another team will consume. Let's just call these modules A and B. Module A must export its packages to Module B and B alone. For reasons beyond my control, I do not have access to Module B. However,

Re: Concealed packages (was Re: Module API usage questions)

k)" to be filled in. This is where I am fuzzy on what is currently specified. However, I am trying to illustrate that the JVM should be able to infer what's concealed since it's the same, in my opinion, as not exporting. Cheers, Paul On Wed, Jul 20, 2016 at 1:47 PM, Alan Bateman <

Concealed packages (was Re: Module API usage questions)

Alan, is the JVM going to verify that what's listed in ConcealedPackages structure actually exists as packages in the module? Cheers, Paul On Tue, Jul 19, 2016 at 4:56 PM, Alan Bateman <alan.bate...@oracle.com> wrote: > On 19/07/2016 21:16, Paul Benedict wrote: > > > Can y

Re: Module API usage questions

On Tue, Jul 19, 2016 at 3:00 PM, Alan Bateman <alan.bate...@oracle.com> wrote: > On 19/07/2016 19:38, Paul Benedict wrote: > > 3) What is the difference between adding a concealed package and not adding >> the package at all? If no difference, I don't know wh

Module API usage questions

I have a few questions regarding how to use the module API. Thanks for reading. 1) Is Configuration.empty() meant to be an immutable singleton or a mutable empty configuration? Is it supposed to be analogous to Collections::emptyList/Map where it's a stand-in? I am asking based on the javadoc

Re: Should setAccessible be part of Java or not? (was Re: It's not too late for access control)

Agreed with Jason. It's okay to say thank you, but no thank you. A third party library maintainer, no matter how well-intentioned, has absolutely no say over the way I design, assemble, and run my operations. Reflection is risky, yes, but it's my risk to take. If I bust down the wrong wall and do

Re: It's not too late for access control

I'll raise this subject over in the Log4J community where I am also active. Just note 1.x is EOL and is no longer maintained. Moving to 2.x is a whole redesign and the two are not compatible (neither binary nor configuration wise). 2.x is way better but it's not drop-and-replace. If you have a

#ReflectiveAccessToNonExportedTypes

Could someone please address/elucidate regarding the design goal to solve this issue with the Module Descriptor over the Security Manager? We already can restrict reflection with the Security Manager in today's world. Conceptually speaking, it seems like one stone throw away to restricting

Re: It's not too late for access control

If I may opine on this matter -- and do so respectfully toward all parties mentioned -- aside from Tim Ellison responding first, every other message is between David and Mark. The discussion thread is a really good read and a strong point/counterpoint match. However, there are 9 people on the

Re: Unnamed module .. singular or plural?

Mark, thanks for your reply. Some things for you to respond to when you can, please: 1) I think 5.4 clearly contradicts 3.1 on the surface. I don't think it serves readers any good (it didn't me) to first assert there is just "one unnamed module" and then, if you keep on reading to the advanced

Unnamed module .. singular or plural?

Given that ClassLoader#getUnnamedModule is not a static method, the signature implies different class loaders can have different unnamed modules. I only say "imply" because I would expected a static method to be the source of a singleton object. AFAICT, there is just one "unnamed" module according

Re: It's not too late for access control

I agree with David in what his email says. I find everything he has said in his email to be reasonable. It's not useful for me to repeat what he has stated. However, I will note that I, too, in my Jigsaw testing have found myself having difficulty retraining my mind that "public" does not mean

Re: RFE regarding duplicate module message

//openjdk.java.net/projects/jigsaw/quick-start Cheers, Paul On Mon, Jul 11, 2016 at 4:32 PM, Alan Bateman <alan.bate...@oracle.com> wrote: > On 11/07/2016 19:48, Paul Benedict wrote: > > Regarding this exception: >> java.lang.module.ResolutionException: Two versions of mo

Re: Placement of error marker when module not found

Nevermind. Strike that follow-up, please. The "exports" regards packages. Cheers, Paul On Mon, Jul 11, 2016 at 3:14 PM, Paul Benedict <pbened...@apache.org> wrote: > Thanks Jon. I bet the marker placement code is shared code because the > same problem is exhibited wi

Re: Placement of error marker when module not found

at 2:51 PM, Jonathan Gibbons < jonathan.gibb...@oracle.com> wrote: > Noted. Thanks for the report. > > -- Jon > > > On 07/11/2016 12:24 PM, Paul Benedict wrote: > >> Error from the command line: >> src\com.domain2\module-info.java:2: error: module no

Placement of error marker when module not found

Error from the command line: src\com.domain2\module-info.java:2: error: module not found: com.domain1 requires com.domain1; ^ If you can't see this message in fixed-width font, please note the caret sign placed at the dot in the module name. Since the dot(s) in the module name

RFE regarding duplicate module message

Regarding this exception: java.lang.module.ResolutionException: Two versions of module com.domain2 found in mods I have three requests: 1) The "two versions" is actually misleading. In my system, I purposely created three "com.domain2" in my modules directory. It's better to just say there is a

Re: Ever a Windows ZIP to install?

feature set of what got pushed from Jigsaw. Got any tips where to write instead? It's the lack of a ZIP with the EA builds that make this a bit cumbersome. Cheers, Paul On Mon, Jul 11, 2016 at 11:23 AM, Alan Bateman <alan.bate...@oracle.com> wrote: > > > On 11/07/2016 17:09, Paul

Ever a Windows ZIP to install?

Hi Dailbor, For Windows, I know the JDK only comes as a Windows Installer, but is their a reason that the JDK cannot be downloaded as a ZIP file? When it comes to the several companies I've been in, it's not a preferred practice that the JDK actually gets installed this way. Likewise, I wish not

Re: Jlink and automatic module

Should this be considered a hack? If you have a nexus repository, for example, you couldn't realistically do that solution with existing jars. First, there are too many. Second, and more importantly, you wouldn't want to change the binaries to add module-info.class because it will change the

Re: Feedback on proposal for #ReflectiveAccessToNonExportedTypes

estriction as the default behavior. On Jul 9, 2016 4:22 PM, "Alan Bateman" <alan.bate...@oracle.com> wrote: > On 09/07/2016 21:28, Paul Benedict wrote: > > The argument I'm making is not just someone really wants to do this, but >> that many people won't settle without i

Re: Feedback on proposal for #ReflectiveAccessToNonExportedTypes

how reflection acts through a module descriptor. That's clearly a responsibility of the Security Manager and this kind of external control should continue to be built upon. On Jul 9, 2016 3:01 AM, "Alan Bateman" <alan.bate...@oracle.com> wrote: On 08/07/2016 22:42, Paul Benedict w

Re: Feedback on proposal for #ReflectiveAccessToNonExportedTypes

#1 and #2 to be mutually exclusive. Cheers, Paul On Fri, Jul 8, 2016 at 4:16 PM, Jason Greene <jason.gre...@redhat.com> wrote: > > On Jul 7, 2016, at 5:31 PM, Paul Benedict <pbened...@apache.org> wrote: > > If this restriction stays (and I am really hopin

Re: #ModuleAnnotations - Rethinking scope of ElementType.MODULE

Remi, returning to my original question, there is no use case for @SuppressWarnings on the entire module? That's what I was originally driving at in my original question. My apologies for not being clearer. Cheers, Paul On Fri, Jul 8, 2016 at 11:57 AM, Paul Benedict <pbened...@apache.org>

Re: #ModuleAnnotations - Rethinking scope of ElementType.MODULE

ll the code inside the class. For an annotation like @Table the semantics > as an effect on the class only. > > So it should not be different for an annotation on a module. > > Rémi > > > > On July 8, 2016 4:38:47 PM GMT+02:00, Paul Benedict <pbened...@apache.or

#ModuleAnnotations - Rethinking scope of ElementType.MODULE

I am wondering if the addition of ElementType.MODULE should be rethought. When an annotation is applied to PACKAGE, it applies package-wide (and thus affecting things inside it too). For example, I can put a JAXB @XmlSchemaType annotation on a package to affect the way classes inside the package

Re: Feedback on proposal for #ReflectiveAccessToNonExportedTypes

It should be pointed out that the only reason IoC containers can succeed with setAccessible() is because developers commonly run without the Security Manager enabled. People who use IoC want to this circumvention on purpose. It's not an oversight -- it's intended. As far as I am concerned, if

Re: Proposal: #DefaultModule

, Jul 6, 2016 at 6:05 PM, Peter Firmstone <peter.firmst...@zeus.net.au > wrote: > Hmm, be useful for debugging. > > Peter. > > Sent from my Samsung device. > > Original message > From: David M. Lloyd <david.ll...@redhat.com> > Sent: 07/07/2016

Re: Updated EA builds with initial implementations of current proposals

Thanks Andrew. Lots of emails flying around. I picked the wrong one. I do see he made it clear in another post. Thanks. Cheers, Paul On Thu, Jul 7, 2016 at 9:58 AM, Andrew Dinn <ad...@redhat.com> wrote: > > > On 07/07/16 15:52, Paul Benedict wrote: > > Hi Mark. Do thes

Re: Updated EA builds with initial implementations of current proposals

Hi Mark. Do these set of changes mean those alternative proposals are now set in stone? I didn't know feedback was finished. For example, and I may have missed this, but I can't recall one message in support of the "requires static" syntax. As I said, I may have missed the supporters, but I don't

Re: Proposal: #DefaultModule

version on it (ideally free-form, not subject to the > restrictions of a layer which otherwise has no control over this module > anyway). > > I don't want to change the design of the module system to accommodate this > change, which is basically just allowing two fields to be f

Re: Proposal: #DefaultModule

The only problem, I see, with renaming the "unnamed" to "default" module is that it also changes the semantics. The unnnamed module has no name so it cannot be depended upon by a named module. However, once you begin calling it the "default" module and allow a name to be assigned, it no longer

Re: Review request: JDK-8159596 Add java --dry-run

java.base/System.java:1928) > > $ echo $? > 1 > > > > On Jun 28, 2016, at 8:18 AM, Paul Benedict <pbened...@apache.org> wrote: > > > > Mandy, if I am reading the diff correctly, it looks like you moved the > error exit code (1 = unhandled exception) inside the

Re: 8159248: ModuleFinder.of spec + 8158456: ModuleDescriptor.read does not verify dependence on java.base

Please definitely list all such possible exceptions. The knowledge outweighs concern for clutter, IMO. I'd rather know the full number of ways an API can fail rather than receive a failure that wasn't documented. Cheers, Paul On Thu, Jun 16, 2016 at 11:44 AM, Alan Bateman

Module in classpath

If a JAR, properly built as a module, is dropped onto the classpath at runtime, does it function as a module or does it get treated as part of the unnamed module with all types exported? Cheers, Paul

Re: Project JIGSAW does not work

It would be helpful in the next update to emit an error message specific to finding the "module" keyword and report it's only available in -source 9. That kind of little stuff can go a long way in helping users. On May 15, 2016 2:32 PM, "Alan Bateman" wrote: On

Re: module-info.java just causes problems

, Paul On Thu, May 12, 2016 at 11:37 AM, David M. Lloyd <david.ll...@redhat.com> wrote: > This is along the lines of what I've requested. Still waiting for any > kind of feedback though. > > On 05/12/2016 11:19 AM, Paul Benedict wrote: > >> Why can't the layer a

Re: module-info.java just causes problems

Why can't the layer assist specifying the Module Configuration to each module in the Module system? By that I mean that the module-info.class shouldn't be read and accepted without mediation. The Layer should get the chance to augment (add, change, remove) anything it wants. Now perhaps the

Re: #ReflectiveAccessByInstrumentationAgents

I prefer the originally-proposed addExports() but allowing the layer to authorize it -- with a security check or other custom constraint the implementer chooses to code. Cheers, Paul On Fri, May 6, 2016 at 9:34 AM, Peter Levart wrote: > Hi, > > > On 05/06/2016 10:07 AM,

Re: module-info.java just causes problems

It's tough to rehash issues. I don't want to re-open old discussions that go nowhere, yet, I still share David's concerns. Personally, I was very jealous :-) of the proprietary module.xml the initial jigsaw system had. I liked the XML way better and still do. Cheers, Paul On Wed, May 4, 2016 at

Re: automatic modules leaking types when using addmods

Automatic modules live in a classpath-like world. Everything is exported to each other. You use this feature if you don't have time to migrate to a modular architecture. On Apr 24, 2016 3:01 PM, "Paul Bakker" wrote: > So when modules B, C and D are automatic modules and

Re: modulepath and classpath mixture

about making sure that the > code works, not the packaging. So you put both main and test code on the > classpath, and there is no problem. The unit test can be done before the > main code is packaged into a module. > > - Russ > > On Mar 30, 2016, at 10:47 AM, Paul Benedict &l

Re: modulepath and classpath mixture

directory placed on a class path are treated as part > of the unnamed module > > Yes > > > So if the tests and main code are both in directories, which they have > been up to now in Maven, why would there be a problem? Both would be in the > unnamed module and able to access

Re: modulepath and classpath mixture

onsider that module = > > deployment-artifact-with-dependencies. With that mental model, putting > > tests inside the module is just not acceptable, because tests should > > not be deployed with the main application and they have different > > dependencies. If we disagree

Re: modulepath and classpath mixture

e the module is just not acceptable, because tests should > > not be deployed with the main application and they have different > > dependencies. If we disagree that module = > > deployment-artifact-with-dependencies, then perhaps we have bigger > > problems to solve here. > > We

Re: modulepath and classpath mixture

Stephen C, I'd like to question the assumption why tests must be their own module? Clearly tests are going to be their own artifact, but I am not sure they need the semantics of module boundaries. Placing on them classpath would be the best thing for them, I think. However, two requirements would

Re: Why not get rid of versions?

Remi, thanks for your response. You stated a lot of useful information. If you don't mind, I will just quote snippets to prevent the email from getting too lengthy. Thanks. You wrote: > This is part where we can not do exactly the same thing at compile time > and at runtime, because doing the

Re: Why not get rid of versions?

odule versions are just metadata, as you said they are not needed by the > JDK, > but jigsaw also wants to ease the interrop with module systems that does > their resolution at runtime, > so IMO the JDK has to provide a way to query the version of a module at > runtime. > > Rémi

Clarification on META-INF/services from SOTMS

>From section 4 on Services: "The module system could identify service providers by scanning module artifacts for META-INF/services resource entries, as the ServiceLoader class does today. That a module provides an implementation of a particular service is equally fundamental" My question regards

Re: "Provides" and "with" type relationships

e JCK team can easily set up abstract test cases like > this. What they can't do is check whether YOUR application runs on > JDK-9-with-Jigsaw, or whether arbitrary JARs on YOUR classpath work as > automatic modules. > > Alex > > > On 3/15/2016 12:07 PM, Paul Benedict wrote: &

"Provides" and "with" type relationships

module z { exports z; provides z.Main with z.Main; } The SOTM says "Service-provider declarations can be further interpreted to ensure that providers (e.g., com.mysql.jdbc.Driver) actually do implement their declared service interfaces" (section 4, para. 8). I see javac checking that

Re: Package, import and type declarations are allowed now in module-info.java by spec

I am happy to say the latest EA only allows "module" or types. It is either-or but not both. Cheers, Paul On Tue, Mar 15, 2016 at 12:43 PM, Paul Benedict <pbened...@apache.org> wrote: > On Mon, Mar 14, 2016 at 5:21 PM, Alex Buckley <alex.buck...@oracle.com> > wrot

Re: Package, import and type declarations are allowed now in module-info.java by spec

ave other intentions for the syntax. If you can also declare types, then a "package" statement begins to make more sense -- but it would seem like a clumsy way of doing things, which I wouldn't advocate (or allow syntactically). Cheers, Paul > In 3/14/2016 9:08 AM, Paul Benedict wrote: &g

Re: Support for multiple modules in one JAR-File

Stefan, I am curious about your suggestion. Truthfully, I am not a fan of making the JAR structure more complex; I think the 1:1 relationship between physical artifact and module is easy and clean. However, I do wonder if your suggestion can be met by the JMOD format? I think that format has as

Relationship between JDK modules and EE modules

In the future, is an application server meant to dynamically create a JDK module from an EE module (EAR, WAR, EJB JAR)? I am not asking anyone to define a specification; just curious how they are envisioned to interact. Cheers, Paul

Re: Unnamed module and duplicate package

My apologies for omitting some key qualifiers in my explanation. Read everything as a proposal to prohibit classpath jars from silently splitting whatever packages the JDK exports. -- Thanks On Thu, Mar 10, 2016 at 3:25 PM, Paul Benedict <pbened...@apache.org> wrote: > Alex, > &g

Re: Unnamed module and duplicate package

ortal danger to interop between unnamed and named modules. > > Alex > > On 3/9/2016 1:47 PM, Paul Benedict wrote: > >> Thank you Alex. Since it's roughly the same as JDK 8, then it's also not >> worse. I defer to your explanation on that point. >> >> Cheers, >&

Re: Automatic module names

Mark, I don't think that is sufficient for everyone who must support older class formats. I can think of three intersecting requirements that an existing project might have: 1) Wants to assign an official module name when used in the modulepath (forward looking requirement) 2) Doesn't want to

Re: Unnamed module and duplicate package

ing to > isolate modules from each other.) > > [*] Advanced scenario: the named module exporting A is actually an > automatic module which happened to co-bundle package A. By placing this JAR > on the modulepath to form an automatic module, it dominates the JAR left on > the clas

Re: Unnamed module and duplicate package

com> wrote: > On 3/9/2016 10:36 AM, Paul Benedict wrote: > >> From the doc: >> "If a package is defined in both a named module and the unnamed module >> then >> the package in the unnamed module is ignored. This preserves reliable >> configuration

Automatic module names

SOTMS: "We can, instead, treat org-baz-qux.jar as an *automatic module* by placing it, unmodified, on the module path rather than the class path. This will define an observable module whose name, org.baz.qux, is derived from that of the JAR file so that other, non-automatic modules can depend upon

Unnamed module and duplicate package

>From the doc: "If a package is defined in both a named module and the unnamed module then the package in the unnamed module is ignored. This preserves reliable configuration even in the face of the chaos of the class path, ensuring that every module still reads at most one module defining a given

Re: modulepath and classpath mixture

. And is there a secondary benefit to decoupling the module name and the module configuration? I'd like to hear another use case, if one exists. On 08/03/2016 20:06, Paul Benedict wrote: > >* Robert, it's sounds like a chicken-and-egg problem. You need the module > *>* name to compile but don't know it un

Re: modulepath and classpath mixture

ally a point to having support for it > at all. Why write it when you can generate it, and at the same time, keep > all your build-related information in one spot? > > > On 03/08/2016 02:06 PM, Paul Benedict wrote: > >> Robert, it's sounds like a chicken-and-egg problem. You need

Re: modulepath and classpath mixture

Robert, it's sounds like a chicken-and-egg problem. You need the module name to compile but don't know it until you have compiled. Too bad this file isn't XML so that any tool could read the module information outside of compiling. That's what I advocated for a long time but that battle has been

Re: Specifying module paths

Robert, in the SOTM document, it explicitly calls out that Module systems are not required to support multiple versions of a module. Correct me if wrong, but I think you're hinting at that? Cheers, Paul On Fri, Jan 15, 2016 at 3:06 AM, Robert Scholte wrote: > Op Thu, 14

Intersection of Modules and Multi-Release JARs

With multi-release JARs, there is a directory structure to partition out the class files for the destined versions of the Java runtime. With modules, the module-info.class sits in the root of the JAR. How will these two requirements be reconciled? Are there plans such as allowing

Re: Intersection of Modules and Multi-Release JARs

Thanks Alan. A poor-man's solution may be optional module dependencies. Cheers, Paul On Wed, Jan 13, 2016 at 11:08 AM, Alan Bateman <alan.bate...@oracle.com> wrote: > > On 13/01/2016 16:55, Paul Benedict wrote: > >> With multi-release JARs, there is a directory struc

Re: Specifying module paths

mmand line, .properties should be supported too. Cheers, Paul On Sun, Jan 10, 2016 at 3:26 AM, Alan Bateman <alan.bate...@oracle.com> wrote: > On 09/01/2016 22:12, Paul Benedict wrote: > >> What will the interaction be between a .properties and patching? It would >> make sense, I th

Re: Specifying module paths

What will the interaction be between a .properties and patching? It would make sense, I think, to allow a project to specify all the modules for compiling source, but then allow overrides for compiling/executing tests. If overrides aren't available, then overrides will have to be calculated

Re: Spring's need for optional dependencies

Adding read edges at runtime is not a backward compatible solution. Jigsaw should automatically allow you to read anything your Module Descriptor gives you access to -- required or optional. Cheers, Paul On Fri, Dec 18, 2015 at 10:02 AM, Peter Levart wrote: > > > On

Re: Spring's need for optional dependencies

Peter, when you say Jigsaw "doesn't search for module B" when it's optional, what do you mean by "search"? Cheers, Paul On Fri, Dec 18, 2015 at 10:42 AM, Peter Levart <peter.lev...@gmail.com> wrote: > Hi Paul, > > On 12/18/2015 05:14 PM, Paul Benedict wrot

Re: Spring's need for optional dependencies

le). > > Therefore it is an acceptable solution — at least if you accept the > Requirements! — to need explicit API calls such as addReads() in frameworks > when running in module mode. > > Regards, > Neil > > > On 18 Dec 2015, at 16:14, Paul Benedict <pbened...@apac

Re: Spring's need for optional dependencies

Peter, thanks for your comments. I differ in that I don't see any problems with optional dependencies. Right now, like in Spring, optional features are enabled with a Class.forName() runtime check; if ClassNotFoundException is captured, the feature is unavailable. I expect that coding pattern to

Re: HAHA! It runs!

On Tue, Dec 8, 2015 at 12:00 PM, Stephane Epardaud wrote: > Finally I was able to run my Ceylon modules in Java9!! > Congrats Stephane! > [1] ATM I can compile them with Java 9 but not as modules, I generate > the module-info.class from the JBoss Modules descriptor. I can

Re: Class file format version bump Re: is ClassLoader.loadClass() supposed to work on module-info classes?

I have just a quick question on the javadoc. It says "VarHandles cannot be subclassed by the user" but the class is abstract. What is the mechanism to actually prevent someone from subclassing it? Cheers, Paul On Mon, Dec 7, 2015 at 2:51 AM, Paul Sandoz wrote: > > > On

Re: modulepath spec

To summarize, I have thus far seen these two needs on the list: 1) The need to specify a list of jar modules by name. This is to support identifying what modules out of a set need to loaded. An example use case would be the "target" directory of a Maven project, where more than one module

Re: is ClassLoader.loadClass() supposed to work on module-info classes?

On Thu, Dec 3, 2015 at 1:46 PM, Alex Buckley wrote: > I expect you will say, "Encode exports somewhere other than the module > declaration, such as with @Exported annotations on types or packages." To > which I repeat: "if we're going to introduce the concept of a >

  1   2   >