Alan,
What's the reason a new java/bytecode access modifier to indicate
module-private wasn't implemented? I agree that public not being really
public is a big wart.
sent from my phone
On Dec 1, 2015 9:27 AM, "Alan Bateman" <alan.bate...@oracle.com> wrote:
>
> On 01/12/2015 13:54, Stephen Colebourne wrote:
>
>> :
>> The JavaOne talks specifically mention the need for code changes for
>> reflection code (adding readability IIRC). And I know there will be
>> lots of psuedo code that says:
>> if (!member.isPublic) {
>> member = member.setAccessible(true)
>> }
>> which is also likely to have problems, because public no longer has
>> exactly the same meaning as today.
>>
>> The J1 slides on adding read edges was in the context of migration to an
> explicit module. We used the Jackson JSON data-binding API as an example as
> it's a small enough example to demonstrate a library that attempts to
> access or instantiate a type in the consumer module that it doesn't read.
> So a migration topic and not meant to give the impression that all
> libraries on the class path using core reflection would break.
>
> "public does not guarantee accessible" will of course be a surprise at
> first. In terms of compatibility then it becomes an issue when an existing
> library on the class path (that doesn't know anything about modules) get a
> reference to a type in a non-exported package of an explicit module. It's
> the first item in the Risks and Assumptions section of JEP 261 but I think
> we'll need to see how people get on mixing the class path and modules to
> understand the impact. I hope in time that there will be a good migration
> guide to modules and I've no doubt that this will be one of the topics that
> it will need to cover.
>
> -Alan.
>
