From casey.barber at cutspb.ru Wed Jun 8 01:55:23 2016 From: casey.barber at cutspb.ru (FedEx International MailService) Date: Wed, 8 Jun 2016 04:55:23 +0300 Subject: Courier was unable to deliver the parcel, ID000681029 Message-ID: <1be11a7dfc4b38a019f038d7b2222ac0@cutspb.ru> Dear Customer, This is to confirm that one or more of your parcels has been shipped. You can review complete details of your order in the find attached. Thank you for choosing FedEx, Casey Barber, FedEx Station Agent. From peter.levart at gmail.com Thu Jun 30 11:13:07 2016 From: peter.levart at gmail.com (Peter Levart) Date: Thu, 30 Jun 2016 13:13:07 +0200 Subject: Proposals for some open JPMS issues, #ResourceEncapsulation In-Reply-To: <5772f09c.2a8a6b0a.50ebf.ffffdfc4SMTPIN_ADDED_BROKEN@mx.google.com> References: <5772f09c.2a8a6b0a.50ebf.ffffdfc4SMTPIN_ADDED_BROKEN@mx.google.com> Message-ID: <669aaab4-a5fe-9b07-660b-afff3861d691@gmail.com> Hi, The proposal for #ResourceEncapsulation plans to drop the resource-encapsulation requirement. Have you thought about a "middle ground" ? Possibility 1: resources in a module could be divided in two groups: always accessible: resources in "root" package and special directories such as META-INF/**, WEB-INF/** (dilemma: how to define "special directories") governed by qualified/unqualified package exports: other resources located in module subdirectories mapped to package names Possibility 2: access to classes is by default restricted and explicitly enabled by package exports. Access to resources could be governed by special module-info syntax, modeled for example by file patterns used in ANT build tool: module m1 { requires ... exports ... uses ... provides ... exportsResources *, META-INF/**, WEB-INF/**; } Automatic modules would "export" all resources. Module readability would not play any role in accessing the resources (as it is the case with accessing classes by reflection). Regards, Peter On 06/28/2016 11:47 PM, mark.reinhold at oracle.com wrote: > FYI, I've just posted proposals for some of the open issues in the > draft JPMS specification, including: > > #CompileTimeDependences > #ReflectiveAccessToNonExportedTypes > #ModuleAnnotations and #ModuleDeprecation > #ResourceEncapsulation and #ClassFilesAsResources > #ReflectiveAccessByInstrumentationAgents > #BootstrapClassLoaderSearchInJVMTI > #CustomizableAutomaticModuleNameMapping > > Links to the proposals are available in the issue summary [1]. > > Comments and discussion are welcome here on jigsaw-dev but, as usual, > the best way to ensure that the EG sees any specific comment is to > send it to the EG's "suggestion box" list, jpms-spec-comments [2]. > > If you comment on one of these proposals, via any channel, please > include the hashtag of the relevant issue(s) in the subject line of > your message, to simplify tracking. Thanks! > > - Mark > > > [1] http://openjdk.java.net/projects/jigsaw/spec/issues/ > [2] http://mail.openjdk.java.net/mailman/listinfo/jpms-spec-comments From pbenedict at apache.org Thu Jun 30 15:30:21 2016 From: pbenedict at apache.org (Paul Benedict) Date: Thu, 30 Jun 2016 10:30:21 -0500 Subject: Proposal: #ResourceEncapsulation and #ClassFilesAsResources Message-ID: Dear EG Members, I would like to formally submit this suggestion for your consideration [1]. The link is what I sent to the "observers" list, but EG members are not required to read that. Hence the message here. In summary, I do not believe that unilaterally dropping resource encapsulation is the right solution. The original proposal encapsulated resources because they were thought to be implementation details. They could be -- but not always. It's clear that some resources are meant to be public while others should be private. So while the former erred by keeping everything private, the latter is now erring by keeping everything public. Neither is really acceptable due to their being two legitimate use cases. There are libraries that do want to share their resources; others do not. So I would like to propose keeping the current encapsulation requirements but amending it. My proposal is simply making META-INF an always publicly accessible folder for resources. What I don't prefer... I am not a fan of putting public resources *in* the code location where classes reside. I understand this is a current pattern [1], but I believe that pattern has relied on the assumption resources are public. Given that Jigsaw does change assumptions, I find it perfectly acceptable to specify that private resources belong where classes reside and public resources go in META-INF. It is not technically difficult to replicate the package structure in META-INF if a framework wishes to organize resources that way. It's different but not difficult. I am not a fan of adding more module directives to export resources [2]. This is really not necessary if META-INF can do it. I find adding additional directives is an unnecessary complication. [1] http://mail.openjdk.java.net/pipermail/jpms-spec-observers/2016-June/000412.html [2] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-June/008355.html Cheers, Paul From pbenedict at apache.org Thu Jun 30 15:42:01 2016 From: pbenedict at apache.org (Paul Benedict) Date: Thu, 30 Jun 2016 10:42:01 -0500 Subject: #ModuleAnnotations Message-ID: Dear EG Members, I would like to formally submit this suggestion for your consideration [1]. The link is what I sent to the "observers" list, but EG members are not required to read that. Hence the message here. First, if annotations are going to be placed on individual directives, please open a new RFE so that javax.lang.model reflects those new elements. Second, I do not believe annotations should be placed on individual directives. Here's why: as the module descriptor currently stands, the syntax is more about operations than a declaration. It makes no more sense to annotate a "requires" statement than it does an "import" statement. These are not declarations; they direct something to be done. For the same reason, you also cannot annotate "for", "if", and "while" statements. All those things do something. None of them declare something. I hope you recognize what I am objecting to, because it's about to introduce an incongruity into the Java language. In the event the EG really, really, really wants to annotate individual directives, I believe you first need to solve the incongruity -- by changing the module source syntax. I don't have a proposal for you here, but I am raising the obvious language problem you're about to introduce. [1] http://mail.openjdk.java.net/pipermail/jpms-spec-observers/2016-June/000415.html Cheers, Paul From pbenedict at apache.org Thu Jun 30 15:45:18 2016 From: pbenedict at apache.org (Paul Benedict) Date: Thu, 30 Jun 2016 10:45:18 -0500 Subject: #ReflectiveAccessToNonExportedTypes Message-ID: Dear EG Members, I think the main problem here is that core reflection has become too restrictive. Reflection should be "magical" and have no knowledge of any kind of module and/or visibility boundaries. If you really want to control what can be reflected upon, that should be done via the Policy file of the Security Manager. This proposal is trying to hack out-of-the-box created by too strict of a design. It is very awkward to denote which packages must be reflectable ahead of time --- how can you figure that out?? The consumers who are doing the reflection are innumerable. I'd go as far to say it's it's impossible to devise a preemptive comprehensive strategy that may satisfy the kinds of tooling in the wild. It's best just to open up reflection so it can continue doing what it always has done well: let me see anything I want unless the Security Manager says no. Cheers, Paul