Alternative mechanism for reflective access control (#ReflectiveAccessToNonExportedTypes / #AwkwardStrongEncapsulation)

[dalibor topic]

On 26.09.2016 05:50, GREGG WONDERLY wrote:
>What’s odd, is that you are still trying to block access to reflective 
access to the “open JDK”.
> If it’s really open

The term "open" in the context of community names typically refers to 
open source, as defined by the Open Source Definition, which can be 
found online at https://opensource.org/osd . You can find the open 
source licensing information for OpenJDK at http://openjdk.java.net/legal/ .

> why do we need to block access, hide details and otherwise obfuscate access details?

A software licensing choice expressed by the use of the term "open" in 
the context of a software development community name typically does not 
determine the architecture (or any other properties or qualities) of 
software produced by such communities, aside from the aforementioned choice.

cheers,
dalibor topic
-- 
<http://www.oracle.com> Dalibor Topic | Principal Product Manager
Phone: +494089091214 <tel:+494089091214> | Mobile: +491737185961
<tel:+491737185961>

ORACLE Deutschland B.V. & Co. KG | Kühnehöfe 5 | 22761 Hamburg

ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstr. 25, D-80992 München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V.
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher

<http://www.oracle.com/commitment> Oracle is committed to developing
practices and products that help protect the environment