Feature complete?

[David M. Lloyd]

On 12/04/2015 03:24 PM, Paul Benedict wrote:
> On Fri, Dec 4, 2015 at 2:58 PM, David M. Lloyd <david.lloyd at redhat.com
> <mailto:david.lloyd at redhat.com>> wrote:
>
>     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 available"?
>
>
> David, point taken. Yes, it is backwards, but that is where things seem
> to be going, right? Currently everything is "locked down" unless you
> export. There is supposedly research going on about the best way of
> letting people jailbreak the module boundaries for frameworks and
> backwards compatibility. I was working within that "these modules can
> have some elevated privilege" assumption. However, I agree with you.
>
>     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.
>
>
> Correct. I believe this also alludes to your previous post about why
> Shared Secrets came into existence.
>
>     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).
>
>
> Are you referring to a hypothetical "module" scope keyword? If so, it is
> a very compelling alternative. Developers has worked under the
> assumption for decades that "public" really means public in terms of a
> social contract. Code that is "public" today should, IMO, continue to
> function under that assumption; future code using "module" scoped types
> would not be restricted within. BTW, didn't JSR 294 explore this? I
> faintly remember discussions regarding module scoping in the language,
> but it's been a very long time since.

Correct, or more accurately, the idea of *having* a new access level.  I 
think that the package-private level should be replaced with a 
module-private access level rather than introduce a new keyword.

Regarding JSR 294, I was searching through the archives again and I 
don't think the idea was ever rejected (unless it happened on a call for 
which there are no minutes on the list archives), in which case it 
simply wasn't done in Jigsaw because it wasn't done.

-- 
- DML