Feature complete?

[Paul Benedict]

On Fri, Dec 4, 2015 at 2:58 PM, David M. Lloyd <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.

Cheers,
Paul