Module identities belong in the source

[Neal Gafter]

If you read the draft specification carefully, you'll see that 294's module
identity at runtime is defined by the pair [module name, class loader]:
5.4.4 Access Control Terminology:

   - A class's *runtime module* is the pair of its module name and defining
   classloader.

Consequently, 294's language mechanism and OSGI's will interoperate
perfectly in this context to satisfy the use case you describe.

On Wed, Feb 4, 2009 at 8:07 AM, Hal Hildebrand <hal.hildebrand at oracle.com>wrote:

> Not sure if I can still post to this list, but I would like to add the
> additional replies which speak directly to the questions raised:
> On Feb 4, 2009, at 6:48 AM, Hal Hildebrand wrote:
>
> And let's be perfectly clear here.  Alex is not making the argument that
> JSR 294 is defining a static module system.  Rather, he's making the
> argument that the *only* way to implement the "module private" keyword is
> with a static module system.  It's not that he wants to, it's that he's
> *forced* to.  This is clearly false as I've demonstrated.  Now his argument
> is that it's way too hard and so overly complex that in order to implement
> it, we are forced to make the module system static.
> It's a silly argument, but it's the one Alex is making.  The argument that
> JSR 294 is about the static definition of a module system is something
> completely different and would at least be an honest argument to make.
>
> On Feb 4, 2009, at 5:57 AM, Hal Hildebrand wrote:
>
> I'm sorry but I gave a very simple use case which 294 breaks.  I'll spell
> it out again in hopes that this will be more clear.
> I have module A.  Module A has problems with class statics that makes it
> impossible to reuse it's services in a different context within the same
> class loader space.  To make it more concrete so that I'm not misunderstood,
> let's say that module A is a clustered cache solution that, because of class
> statics, cannot provide services to more than one cluster.  Being a
> container provider, we would like to use module A in several different
> implementations of services we provide.  This requires multiple clusters.
>  Thus, to accomplish this, we need to include module A privately in any
> service which wants to make use of it.
>
> Not going to argue about design and changing this, as this is a business
> decision as to whether or not it's worth the cost.  Not a technological
> decision.
>
> In OSGi, I can simply make this module a bundle, and for the services which
> require this module - but in a private context, due to the issues with class
> statics - I can either inline the classes straight into the bundle for the
> new service module, or I can make use of OSGi's class path mechanism.
>
> However, now due to actually encoding the module identity right into the
> source and class files of module A, I now have to literally RECOMPILE the
> module and maintain a separate code line for each and every use of this
> generic library throughout my code base - and I work for a company with 20K
> or so application developers, and 10K or so infrastructure developers.  I
> know we're not MicroSoft, but it's still a hell of a lot of code to wrangle.
>
> Thus, while I can certainly accommodate the static identity of
> modules ensconced forever in source and compiled classes, it is now a huge
> PAIN IN THE ASS.  You have now made our lives a living hell, vastly
> complicated the very large build processes we have, have massively
> multiplied the maintenance costs.
>
> And for what?
>
> My use case above isn't the only use case for repackaging modules after
> compilation - I have many more.  But it's a simple one which illustrates the
> issue nicely.  It's also one which is completely and utterly ignored in this
> JSR, and it's ignored by *definition* because the apparent purpose of this
> JSR is to define a completely static module system.
>
> As I said, OSGi will accommodate whatever insanity y'all come up with.  It
> won't be fun and it will cause us headaches, but since there's no stopping
> this train, our job is to figure out how to deal with the fallout.
>
> But please don't think characterize this a shortcoming of OSGi.  You're
> defining a new modular system from scratch, based on academic ideas rather
> than understanding the practical aspects of the only existing module system
> in Java.  Again, the prerogative of this JSR, by all means.
>
>
> On Feb 4, 2009, at 8:02 AM, Neal Gafter wrote:
>
> [re-adding the list, with permission]
>
> If the "requirements of OSGI" are that the java programming language must
> include static checking of language features such that the static checking
> is misaligned with (and possibly undermined by) the meaning of the language
> features at runtime, then I agree that the JSR ought not to satisfy those
> requirements.  If you're saying that the OSGI model cannot accomodate module
> boundaries that are anticipated by developers prior to deployment, that
> sounds like a shortcoming of OSGI.  I would expect that such pre-planning
> (presently recorded in "project" configuration, but recorded in module
> declarations in the future) would be a common feature of code deployed under
> OSGI.  But you are in a position to know better than I; perhaps projects
> using OSGI really do not anticipate module boundaries until the code is
> deployed.  In that case we cannot reasonably expect to have any
> language-static checking of modules in the OSGI sense, and interoperability
> with the language is hopeless.  Whatever the case, I also agree that the
> JSR's changes should not break existing systems, and I'm not aware of
> anything in the proposal that would.
>
> On Tue, Feb 3, 2009 at 10:27 PM, Hal Hildebrand <hal.hildebrand at oracle.com
> > wrote:
>
>> Sorry to be so short, but to be clear, the requirements of OSGi are not
>> being accommodated in this JSR.  And this does, unfortunately, mean that
>> interoperability with OSGi is not going to be one of the results of this
>> JSR.  I'm not sure if that's a bug or a feature at this point, but the
>> result will be the same.  This will have serious repercussions throughout
>> the existing OSGi community.  Ignoring this is the prerogative of Alex, in
>> particular, and the JSR EG, in general.  Developing a statically defined
>> module system is all well and good, and I'm quite clear as to what the
>> target is and I understand the intent.  I just don't think it's particularly
>> useful ignore the obvious compatibility issues and to sweep away the
>> implications on well established and existing systems and what effect
>> breaking these will have on the community - whether purposefully or
>> inadvertently.
>>
>>
>> On Feb 3, 2009, at 10:01 PM, Hal Hildebrand wrote:
>>
>>  I'm sorry, but OSGi is a *Dynamic* module system.  If you wish to
>>> interoperate with OSGi, then you will have to accommodate the dynamism of
>>> the only module system in Java at present time, one that has been around for
>>> 10 years and is the basis that a number of companies are basing their
>>> technology on.  If you want to make serious changes in this existing system
>>> and completely ignore compatibility with OSGi then there's really nothing
>>> anyone can do to stop the JSR.
>>>
>>> Have fun storming the castle.
>>>
>>> On Feb 3, 2009, at 9:54 PM, Neal Gafter wrote:
>>>
>>>  The purpose of static checking is to verify, at compile time, features
>>>> of the program that will be present at runtime.  It is important that the
>>>> sense and meaning of a concept at compile-time is closely related - ideally
>>>> identical - to the runtime concept.  The purpose of adding modularity to the
>>>> Java language is to provide language support (checking) for an additional
>>>> level of access control.
>>>>
>>>> The runtime packaging of Java programs is not part of the language.
>>>>  Moreover, even if it were it cannot be related to a statically checked
>>>> feature such as module membership, since packaging takes place long after
>>>> the source code is compiled.  The Java compiler has no insight into the way
>>>> an application will be packaged.  Nor does (nor should) the Java language
>>>> specification talk about compiler command-line switches or IDE
>>>> project/package descriptions, classpaths, or which things were compiled "at
>>>> the same time".  Those sources of information are not properly part of the
>>>> Java programming language.  Especially important is separate compilation: an
>>>> entire chapter of the JLS (13 Binary Compatibility) is devoted to a
>>>> description of Java's support for separate compilation and the meaning of
>>>> independently compiled units.  This would be undermined by a requirement
>>>> that a module be compiled all-at-once.  Morover, such a requirement would
>>>> make it impossible to have different modules with interdependent members.
>>>>
>>>> Could module identity be recorded outside the source of a class?  Sure,
>>>> but whatever the source of that information, if the compiler will do some
>>>> checking on it, that source of information IS part of the Java programming
>>>> language, and must be specified in the JLS.  I personally prefer that the
>>>> meaning of a compilation unit (and its module membership) be self-evident
>>>> from the text of a compilation unit.  The module membership lving nearby in
>>>> module-info.java is a close second.  But command-line switches, classpaths,
>>>> jar packaging, etc, do not properly belong in the realm of the programming
>>>> language.
>>>>
>>>> The purpose of the java compiler is to implement the language
>>>> specification. The compiler should not be "extended" to give meaning to
>>>> language constructs except as described in the language specification.  For
>>>> this reason, and for the readability of Java programs, I believe that module
>>>> identity should properly appear explicitly within the Java programming
>>>> language.
>>>>
>>>
>>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/jsr294-modularity-observer/attachments/20090204/d09dfac4/attachment.html>