For what is worth, I don't like the OSGi model. I'm far from being an OSGi
guru, but I've used it enough to have a somewhat informed opinion. It is
workable, but it's not easily understood by typical developers, it makes
things so much more complicated. Working with Spring on Apache ServiceMix
is a pain - you need to tweak imports and exports often, you need to embed
non-OSGi-ready jars into your bundle, and I've seen many developers simply
give up and dynamic-import everything, which is a way to bypass module
boundaries (and still sometimes it is not all that is needed to get things
working). Mind you, Spring is just an example, it is no different in that
regard from typical dynamic languages. In fact, I'm pressed to hear how the
Nashorn team is reacting to Jigsaw.
On Tue, Dec 1, 2015 at 4:06 PM, Paul Benedict <pbened...@apache.org> 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>
> 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> 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
> >
>
