Module identities belong in the source

[Neal Gafter]

[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/28148b45/attachment-0001.html>