Feature complete?

Alan Bateman Alan.Bateman at oracle.com
Tue Dec 1 14:26:45 UTC 2015

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.


More information about the jigsaw-dev mailing list