Feature complete?

Neil Bartlett njbartlett at gmail.com
Tue Dec 1 17:20:11 UTC 2015

David is correct that OSGi does not change accessibility at all. Instead we use visibility to control encapsulation. This may not be perfect, though it does actually address many of the concerns that have been expressed on this list recently. If a type is declared by a module (for example a service implementation class) then other modules can access that type via reflection even if it is in a non-exported package of the module.

With regards to Alessio’s comments on complexity, I certainly understand that adapting a framework like Spring to a modular platform has its challenges. What puzzles me is that anybody thinks this process will somehow be easier in Jigsaw, or indeed any other module system design. To me it seems likely to be harder, as Jigsaw does not have any of the escape hatches available in OSGi. For example you specifically mentioned DynamicImport-Package, which is used by modules that have no idea what they depend on until runtime. This is considered terrible practice and all experts frown on it; but at the same time it exists for a reason and can help you in some very marginal edge cases.

As you said, it will be interesting to see whether and how dynamic languages will adapt to the new module system.


> On 1 Dec 2015, at 15:24, Alessio Stalla <alessiostalla at gmail.com> wrote:
> 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 <pbenedict at 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.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> 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