Feature complete?

[David M. Lloyd]

This is something I hope to address in my alternative JDK module 
implementation.  I feel that Jigsaw as it stands right now has too many 
practical problems to be a candidate for JSR 376, and I'm hoping to 
either influence Jigsaw into a different state or move to an alternative 
design (like mine or another as-yet-unwritten) which fixes these flaws.

On 12/01/2015 08:42 AM, Vitaly Davidovich wrote:
> 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.Bateman at 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.
>>

-- 
- DML