On 01/12/2015 13:54, Stephen Colebourne wrote:
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.: 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.
"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.
