Feature complete?

[David M. Lloyd]

I think Peter Kriens is best qualified to answer about OSGi, but I'm 
fairly confident in saying that OSGi doesn't meddle with accessibility 
in this way (or at all).

On 12/01/2015 09:06 AM, Paul Benedict wrote:
> 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.
>
> Cheers,
> Paul
>
> On Tue, Dec 1, 2015 at 8:54 AM, David M. Lloyd <david.lloyd at redhat.com
> <mailto:david.lloyd at redhat.com>> wrote:
>
>     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
>         <mailto: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
>
>

-- 
- DML