Feature complete?

Paul Benedict pbenedict at apache.org
Tue Dec 1 15:06:49 UTC 2015

Personally, I am surprised that no one else from the EG has publicly
discussed or debated David's proposal. There are 10 people on the EG! It
would be nice to hear why and what the experts are for or against --
including the current Jigsaw design.

It's my current understanding that the "public does not guarantee
accessible" is similar to OSGi. Correct me if wrong, but it is similar
regarding the requirement to export packages, right? I would be interested
in knowing if people have the same critique about OSGi. With so many people
loving OSGi's accessibility model, why is it unacceptable for the JDK?
David, maybe you can speak to this too.


On Tue, Dec 1, 2015 at 8:54 AM, David M. Lloyd <david.lloyd at redhat.com>

> 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

More information about the jigsaw-dev mailing list