Hi Stanley,

I would like to share my opinions on Java module system granularity  as well as Java scoping system which (I think) may be helpful to you (JSR#277) or JSR#294 expert group...

My humble opinion is that

• we have the scoping all wrong today
• JSR 277 should not deal with scoping at all and should stick to module as the boundary/entity (as I have declared in my review)
• improvements in scoping should be left up to JSR 294 or similar JSR, and JSR277 should just rely on...

This is the primary idea, main pont of my email: 

Do not try to solve resource export/imports. Just stick to module granularity level and leave resource protection to JSR#294 or similar initiative

Anything I will write below should be just a reference to JSR 277 because I think it's following problem is not responsibility of #277. If anyone, JSR #294 is closest responsible candidate to resolve this...

However, I believe these ideas/suggestions are closely related to what #277 is trying to achieve, although not directly specified or implemented by the #277 spec... But I believe this allows you to reject the explicit (or even implict) export filters as proposed by JSR277 draft...

I hope you could evaluate this and possibly forward these ideas to the #294 crew for further review...

So, to provide some details in addition to these plain statements:

Now that we have annotations, I would deprecate public|protected|private keywords and I would suggest to replace them with new annotations with new better semantics (which also covers the need of new Java Module System).

public|protected|private|(default) as we know them are all wrong:

1. public - most of the time, people want stuff to be public, so why using special keyword to declare this obvious fact? public should be the default just because it is the major use case
2. protected -  means "class hierarchy plus the package" which is wrong because of (5)
3. default - most useless declaration (package scoping only), people use it when they actualy think 'private' but they just don't care... so why is this the default?
4. private - the only reasonable scoping, there was nothing to do wrong :-)
5. missing class hierarchy scoping (only class and its descendants) - this should be 'protected', actually

I think we should deprecated these keywords and do it all again

• deprecation & new parallel alternative model means we can still support the old model while defining the transition to the new one
• new model implemented as annotations will not conflict with the old one, and...
• ... will define new stronger and more appropriate semantics
• will look much nicer together with other annotations (public|protected|private are just annotations/metadata, nothing else)
• last but not least, it will free up namespace currently  occupied by the metioned keywords... the less keywords the better...

PROPOSED MODEL:

@java.lang.Public

- public scoping, default!! most widely used... people usualy know better when the want to protect something. on the other hand, when you are not sure, just leave it open and accessible, you will not break anything nor you will prohibit extensibility... this corrresponds with my proposal to use implicit permit / explicit deny policy instead of implicit deny / explit permit 

@java.lang.Protected

- class hierarchy only (declaring class and descendants, no package); the missing piece in current model

@java.lang.Package

- package protected (currently 'default')

@java.lang.Private

- declaring class only

@java.lang.Module

- JSR277 module scoping

All these permissions are restrictive and can be combined, e.g:

• @Public @Module - means its publicly accessible but only within the given module
• @Protected @Module - similar: accessible within the class hierarchy but only within module
• @Package @Protected - as @Protected but only within the given package

There are of course some combinations that do not make any sense but they do not hurt or break anything:

• @Public @Private -> @Private is more restrictive so it wins
• etc, nothing improtant

As you see, I hope, all your requirements for module contents protection can be satisfied with single @Module scoping restrictive annotation :-)

The important conslusion is:

Whether this behaviour will be standardized as part of #294 or some other initiative, the JSR#277 spec should not deal with it. Just leave it to be defined by other spec which redesigns Java scoping model. Just stick to the module as the working entity.

Hope you find these thought helpful :-)

-- 
Patrik Beno
J2EE Software Architect
____________________________________
Cleverlance - The Clever Enterprise Solutions
www.cleverlance.com

European Business Center
Dukelskych hrdinu 34
170 00 Praha 7
Czech Republic

Tel.:        +420 266 177 166
Fax:        +420 266 177 155