JSR 294 requirements

[Christopher Brind]

Hi,

I'm wondering where the requirements of JSR 294 describe runtime behaviour?
The only problem that seems to be stated is:

Today, an implementation can be partitioned into multiple packages. Subparts
> of such an implementation need to be more tightly coupled to each other than
> to the surrounding software environment. Today designers are forced to
> declare elements of the program that are needed by other subparts of the
> implementation as public - thereby making them globally accessible, which is
> clearly suboptimal.
>
> Alternately, the entire implementation can be placed in a single package.
> This resolves the issue above, but is unwieldy, and exposes all internals of
> all subparts to each other.
>
No one has said that the existing implementation of package is 'wrong' or
'broken', so I believe the solution to the above is quite simple; add
another class modifier to the language that allows access only to classes in
the parent package.  That is, if I define a class in package com.foo.bar and
mark it with the new modifier, it can only be accessed from classes that are
in the package com.foo.

As a result, the JSR is satisfied and, IMHO, a pleasant side effect of this
is that the package structure now becomes a true hierarchy, rather than the
faux-hierarchy that it currently is.  However, this package hierarchy would
only be in the context in which the new modifier is used since public and
all the other modifiers will work as they do now.

The down-side is that I could separately write a class and say it is in
package com.foo in order to override the class modifier mechanism, but from
where I sit that seems to be a problem with current implementation of the
class modifiers anyway.  For example: Classes with no modifier (i.e.
package-private) are accessible only by classes in the same package, but
again I could easily write a class and say it is in that package in order to
access it and make it's methods available publicly by delegation.

OK, so this might not be *the* solution, but if the solution can't be as
simple as this then given some of the posts being made it is clear that JSR
294 is too vague.  It looks as though someone had the idea first, then
defined the problem and then invited a load of people with reasonably
different ideas about modularity to contribute.

I guess my questions are:
- Is there a clear set of requirements for JSR 294 and do they deal with
runtime scenarios?
- Are existing class modifiers considered broken? If so, should this aspect
be declared/defined in the JSR?

Regards,
Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/jsr294-modularity-observer/attachments/20090209/221d3c68/attachment.html>