Anyone who cares about grammar would know "requires optional" is awkward
(and horrible) English. It's an oxymoron. It's non-nonsensical.
Since this is all about dependencies, why not be straightforward like this:
dependency requires foo.bar1;
dependency optional foo.bar2;
NB: I did once submit a
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 ranges) fall under
> the scope
Good job, Robert! It looks nice and useful.
Cheers,
Paul
On Thu, Aug 25, 2016 at 12:28 PM, Robert Scholte
wrote:
> Hi,
>
> JavaOne spoiler alert:
> I've been able to add this kind of information to the output of the
> maven-dependency-plugin:
>
> [INFO] --- maven-dependency-plugin:3.0.0-SNAPSHO
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
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 topological
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?
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
that.
Charbel, have you looked into the Maven Shade Plugin? I wonder if you could
shade what's in the unnamed package so as to put it in some other named
package?
Cheers,
Paul
On Tue, Aug 2, 2016 at 2:21 AM, charbel yazbeck wrote:
> hi,
>
>
> most of the open sources jars have classes with unnamed p
packages were public by default. Now that default changes to
> private, but notice that even here, a package is only private outside its
> scope (the module). Other packages in the same scope (module) will be able
> to access it.
>
> So for me it's always been about exporting fro
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
Engli
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 rathe
Buckley
wrote:
> You can determine that. The "Modules in the Java Language and JVM"
> document specifies when ACC_MANDATED is present and when it isn't.
> (Channeling Neal, the document is acting as a mini compiler spec when it
> says "then a compiler must emit
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 l
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
activ
Error to correct: I meant a "requires" not an "export". Thank you.
Cheers,
Paul
On Thu, Jul 28, 2016 at 1:57 PM, Paul Benedict wrote:
> Alex, I thank you for repeating the explanation again, but I find your
> definition hard to accept. To me, something that's
eclared (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 be included,
Yes. Thanks Alan.
Cheers,
Paul
On Thu, Jul 28, 2016 at 11:20 AM, Alan Bateman
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 one module deep or go al
Although "java.base" is mandated to be included, it is also inserted
automatically by the compiler. Isn't anything automatically inserted by the
compiler considered synthetic? When I examine the class file, I get
ACC_MANDATED but not ACC_SYNTHETIC for this export. I believe both should
be there.
F
Here is an example use case. Please confirm my understanding. I'd like to
know if transitive dependencies go one module deep or go all the way
through.
1) A@1.0 is published
module A { // exports all packages }
2a) A@1.1 gets split into B@1.0 and C@1.0
2b) A@1.1 uses "requires public" to mimic
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 Ja
addition to module-info may also make sense.
>
> Stephen
>
>
> On 26 July 2016 at 19:35, Paul Benedict wrote:
> > In a modularized world, I don't see "requires public" delivering the
> value
> > it should.
> >
> > Let's take this ex
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
unde
27;la ServiceLoader) where you are controlling which items get
> loaded - but that's different than what some black box does internally.
>
>
>
>
> Malachi de Ælfweald
> http://www.google.com/profiles/malachid
>
> On Tue, Jul 26, 2016 at 3:12 PM, Paul Benedict
> wrot
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
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
e 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 first place.
>
>
>
> Malachi de Ælfweald
> http://www.google.com/
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 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 h
out 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 disagree with yo
ow why it needs
this proof?
Cheers,
Paul
On Wed, Jul 20, 2016 at 6:00 PM, Alex Buckley
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 export
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, I
n the blank)
I leave "(fill in the blank)" 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
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
wrote:
> On 19/07/2016 21:16, Paul Benedict wrote:
>
>
> Can you into more about packages &
On Tue, Jul 19, 2016 at 3:00 PM, Alan Bateman
wrote:
> On 19/07/2016 19:38, Paul Benedict wrote:
>
>> 2) Must all modules that could ever be loaded be specified on the module
>> path? I was hoping to find a hook where I could provide by own
>> implementation of Module
On Tue, Jul 19, 2016 at 3:00 PM, Alan Bateman
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 why you would ever call
>> ModuleD
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 alon
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
s
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
depe
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
reflecti
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
Exper
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 to
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
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
publ
it?
[1] http://openjdk.java.net/projects/jigsaw/quick-start
Cheers,
Paul
On Mon, Jul 11, 2016 at 4:32 PM, Alan Bateman
wrote:
> On 11/07/2016 19:48, Paul Benedict wrote:
>
> Regarding this exception:
>> java.lang.module.ResolutionException: Two versions of module com.domain2
&g
Nevermind. Strike that follow-up, please. The "exports" regards packages.
Cheers,
Paul
On Mon, Jul 11, 2016 at 3:14 PM, Paul Benedict wrote:
> Thanks Jon. I bet the marker placement code is shared code because the
> same problem is exhibited with other keywords like "expor
2016 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: modu
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
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 "
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
wrote:
>
>
> On 11/07/2016 17:09, Paul Benedict wrote:
>
>>
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
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
calcul
nd the
restriction as the default behavior.
On Jul 9, 2016 4:22 PM, "Alan Bateman" 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 it. Reflection
. But I do know I don't
like controlling 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" wrote:
On 08/07/2016 22:42,
AR.
PS: I don't see #1 and #2 to be mutually exclusive.
Cheers,
Paul
On Fri, Jul 8, 2016 at 4:16 PM, Jason Greene
wrote:
>
> On Jul 7, 2016, at 5:31 PM, Paul Benedict wrote:
>
> If this restriction stays (and I am really hoping it doesn't), my next
> best hope is
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 wrote:
> Okay. Th
lass. 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
> wrote:
>>
>> I am wondering if the addition
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 ar
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 you'r
n Wed, Jul 6, 2016 at 6:05 PM, Peter Firmstone wrote:
> Hmm, be useful for debugging.
>
> Peter.
>
> Sent from my Samsung device.
>
> Original message
> From: David M. Lloyd
> Sent: 07/07/2016 03:40:22 am
> To: Paul Benedict
> Cc: jigsaw-dev ; Java Pla
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 wrote:
>
>
> On 07/07/16 15:52, Paul Benedict wrote:
> > Hi Mark. Do these set of changes mean th
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 r
t (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 filled in.
&g
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 make
s(java.base/Configuration.java:370)
> at
> java.lang.module.ModuleDescriptor$1.resolveRequiresAndUses(java.base/ModuleDescriptor.java:1986)
> at
> jdk.internal.module.ModuleBootstrap.boot(java.base/ModuleBootstrap.java:263)
> at java.lang.System.initPhase2(java.base/System.java:1928)
>
eers,
Paul
On Mon, Jun 27, 2016 at 12:36 PM, Mandy Chung
wrote:
> -XshowSettings would probably be a good place to include the VM arguments.
> $ java -XshowSettings:vm -—dry-run
>
> I file a JBS issue:
> https://bugs.openjdk.java.net/browse/JDK-8160389
>
> Mandy
>
>
Mandy, if I may recommend another suggestion, another "sanity" check could
be dumping the command line arguments. I know quite a few bash programmers
who would really love to see they passed their arguments correctly without
executing their program. :-)
Cheers,
Paul
On Mon, Jun 27, 2016 at 10:48
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
wrote:
> On 16/06/2016
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
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 15/05/2016 19:46, Remi Forax wrot
heers,
Paul
On Thu, May 12, 2016 at 11:37 AM, David M. Lloyd
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 assist specifying the Mo
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
default
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, Andrew Dinn wrote:
>
>>
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 1
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 named module A
> depends o
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 wrote:
>
&
ed 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 one another.
>
> - Russ
>
>
ment-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 that module =
> > deployment-artifact-with-de
pplication and they have different
> > dependencies. If we disagree that module =
> > deployment-artifact-with-dependencies, then perhaps we have bigger
> > problems to solve here.
>
> We agree that a module = deployment-artifact-with-dependencies, but we
> disagree because fo
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
s
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 modu
schemes out there.
It's my opinion the Version should *not* ever be used for "resolution at
runtime" but only for build time. At runtime, it's informational only and
not an input to any functional requirement.
Cheers,
Paul
On Wed, Mar 23, 2016 at 10:06 PM, Paul Benedict
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
>
> - Mail original -
> > De: "Paul Benedict"
> > À: "ML Op
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
>
> - Mail
Based on today's discussions, I've been thinking if there is any merit in
dumping the notion of Module Version altogether? I am beginning to think
it's completely irrelevant to the Module System.
Versions are important during builds and for interacting with artifact
repositories, but once artifact
ms (what
> where they exactly?) when packages are split, which means that we get
> a different limitation "for free": no two modules loaded by the same
> class loader may split a package - exported or not.
>
> so long ... Nicolai
>
>
>
> On 22.03.2016 21:4
Regarding split packages, would an "easy" workaround be to introduce a new
command line option so that modules that share packages get the same
ClassLoader?
Cheers,
Paul
On Tue, Mar 22, 2016 at 3:27 PM, Richard Opalka wrote:
> Hi Nicolai,
>
>some examples can be found here:
>
> https://issu
>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
asily 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 wrot
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 they
File src/z/module-info.java:
package z;
Command line:
javac -d out src/z/module-info.java
Output:
An exception has occurred in the compiler (9-ea). Please file a bug against
the Java compiler via the Java bug reporting page (http://bugreport.java.com)
after checking the Bug Database (http://bugs.
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
wrote:
> On Mon, Mar 14, 2016 at 5:21 PM, Alex Buckley
> wrote:
>
>> The JLS doesn't know what the string &qu
or 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:
>
>>
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
on
Alex, you wrote: "The JLS doesn't prevent javac from rejecting a package
declaration or an import declaration in a file called module-info.java."
It seems that a package declaration, in this context, should be prohibited
syntax because module-info.class is always in the JAR root which has no
packa
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
ses put you in a split package
situation?
Cheers,
Paul
>
>
> *From:* Paul Benedict [mailto:pbened...@apache.org]
> *Sent:* Thursday, March 10, 2016 10:16 PM
> *To:* Stephen Felts
> *Cc:* Alex Buckley; ML OpenJDK Jigsaw Developers
>
> *Subject:* Re: Unnamed module and dupl
alternative implementations of the javax.* hierarchy, with
> > only the java.* hierarchy being off-limits due to the
> > SecurityException that would be thrown by ClassLoader.defineClass.
> >
> > Neil
> >
> >
> >> On 10 Mar 2016, at 21:25, Paul Bene
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 wrote:
> Alex,
>
> For the sake of usability, ho
he provenance of the JAR on the classpath.
>
> There has been some discussion of a jdeps-like tool that detects when a
> JAR on your classpath is trying to split a JDK package:
> http://mail.openjdk.java.net/pipermail/jigsaw-dev/2015-November/005227.html
> .
>
> Alex
>
>
erop 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,
>
1 - 100 of 142 matches
Mail list logo
