On 12/04/2015 03:24 PM, Paul Benedict wrote:
On Fri, Dec 4, 2015 at 2:58 PM, David M. Lloyd <david.ll...@redhat.com <mailto:david.ll...@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
