Feature complete?

[Alan Bateman]

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.