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.ll...@redhat.com
<mailto:david.ll...@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.bate...@oracle.com
<mailto:alan.bate...@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
