Feature complete?

David M. Lloyd david.lloyd at redhat.com
Fri Dec 4 20:58:08 UTC 2015

This is backwards though: instead of saying "these modules can have some 
elevated privilege", which BTW is (in a way) the inverse of using a 
security manager to restrict permissions, doesn't it make more sense 
from a security POV to say "no modules have special access, however a 
module can offer up certain of its classes/interfaces to be publicly 

The only reason people historically used public for things that should 
be hidden (for security reasons) is because there isn't a better option 
for them - package-private is the next highest top-level access level 
available, and it's too restrictive for many use cases.

To me the requirements speak clearly: add an access level to accommodate 
the missing functionality; use public to *mean* public; move 
specifications (like Java EE) towards access to public types only.  It's 
an elegant and intuitive solution, which also can immediately solve the 
security issues plaguing the JDK by allowing the de-publicizing of all 
sensitive types, and also retain almost complete compatibility with the 
vast majority of today's software (OSS at least, and very likely an even 
more vast catalog of proprietary software as well).

Over time, more software will embrace the new access capabilities, and 
eventually setAccessible() could potentially be deprecated and someday 
maybe even removed completely.

On 12/04/2015 01:50 PM, Paul Benedict wrote:
> Reinier, you raise a good point. Rather than the command line, what if the
> Security Policy File could have a new permission that allows module
> boundaries to be broken? This would allow you to control which jars can
> have free reign; probably useful for framework libraries like Spring.
> Cheers,
> Paul
> On Fri, Dec 4, 2015 at 7:50 AM, Reinier Zwitserloot <reinier at zwitserloot.com
>> wrote:
>> On Tue, Dec 1, 2015 at 2:24 PM, Alan Bateman <Alan.Bateman at oracle.com>
>> wrote:
>>> This seems a bit pessimistic. One thing that would be helpful is to get
>>> more help testing of these libraries with the EA builds. If there are
>>> libraries and applications on the class path today that are using core
>>> reflection then they should continue to work as they do in JDK 8. The
>>> *only* issue *starting out* should be where core reflection is being used
>>> to get at JDK internal types, in which case a command-line option might
>> be
>>> needed to keep those deployments working.
>> Emphasis mine: "only"?
>> "Just add some command line switches" is not exactly a nice solution. From
>> personal experience, the vast majority of java users do not know how to add
>> configure command line switches to the various compile and build VMs being
>> started by their build tools of choice, for example. Also, not something
>> Alan mentioned here: Adding the command line switches is currently the
>> _ONLY_ solution, so tools that are aware of the issue can't even fix it,
>> other than by mangling modules (bad idea, I think we all agree on that I
>> assume), or advising the userbase not to actually USE any of the modularity
>> features and, preferably, to avoid switching to JDK9 altogether.
>> Emphasis mine: "starting out"?
>> This gets back to an earlier issue I raised on this mailing list: Okay,
>> starting out this isn't an issue, but by having no way to opt out of
>> export-based access control, it's a bit like switching from driving on the
>> left side of the road to the right: Unless the entire greater java
>> community switches in the same instant, we're all going to have a bad time.
>> A way to opt out needs to exist, and the fact that the discussion is still
>> going, and no plans have even been stated yet, means in my opinion that
>> jigsaw is not fully baked yet.
>>   --Reinier Zwitserloot


More information about the jigsaw-dev mailing list