(update) Use "default" keyword for default visibility

[Joseph D. Darcy]

Hello.

While the lack of an explicit name for the default accessibility in Java 
has slightly annoyed me at times over the years, I don't think it in 
isolation is such a troublesome issue that a language change is warranted.

A few comments inline...

Adrian Kuhn wrote:
> Updated the default visibility proposal
>
> PROJECT COIN SMALL LANGUAGE CHANGE PROPOSAL FORM v1.0
>
> AUTHOR(S): Adrian Kuhn
>
> OVERVIEW:
> Allow the "package" keyword to be used as modifier for default  
> visibility.
>
> FEATURE SUMMARY:
> Use "package" keyword for default visibility.
>
> MAJOR ADVANTAGE:
> This change is a "5 cent coin" at best, there are not many advantages  
> beyond improved readability and a more beautiful language definition.  
> However, the benefit of improved readability is not to be  
> underestimated. The missing keyword for default visibility breaks the   
> symmetry of visibility modifiers. The use of package visibility is  
> less obvious than other visibility since an explicit modifier is  
> missing. This decreases readability of source code. For example,  
> omitting any of the three explicit modifiers by mistake (or vice verse  
> mistakingly adding any of the tree) may introduce unexpected behavior  
> which is hard to spot due to the bad readability.
>
> MAJOR BENEFIT:
> Improved readability.
>
> MAJOR DISADVANTAGE:
> Two ways to express the same thing (in compatibility mode).
>
> ALTERNATIVES:
> - Using /*default*/ comments (as often seen) is not an alternative  
> since such comments are not processed by the compiler.
> - Using a custom-made @Package annotation is feasible (it is what I  
> use now) and can be processed by the compiler using an annotation  
> processor.
>
> EXAMPLES
>
> SIMPLE EXAMPLE:
> public class Point {
> 	package int x;
> 	package int y;
> }
>
> ADVANCED EXAMPLE:
> package ch.akuhn.util;
> package class Foo {
> }
>
> DETAILS
>
> SPECIFICATION:
> "package" is already a keyword, introducing it as a new visibility  
> modifier is thus save. To distinguish package visible top-level  
> classes and package declarations, the grammar will need a lookahead of  
> two tokens (I dont know if this is a problem).
>   

Not all modifiers are applicable in all places.  For example, "private" 
cannot appear on the methods of an interface.   A more convincing 
specification would list explicitly the grammar changes and updated JLS 
sections.

> COMPILATION:
> Same as now with implicit default visibility.
>
> TESTING:
> Same as now with implicit default visibility.
>
> LIBRARY SUPPORT:
> None.
>
> REFLECTIVE APIS:
> None.
>
> OTHER CHANGES:
> None.
>
> MIGRATION:
> See below, strict vs compatibility mode.
>
> COMPATIBILITY:
> A compiler switch is offered to set either strict or compatibility  
> mode. In strict mode, an error is issued if a member has not  
> visibility modifier.

That would be a non-starter if mandatory; it would mean gratuitous 
source incompatibilities between JDK 7 and earlier source levels.  An 
annotation processor can be written to do this to enforce local coding 
conventions.

-Joe

>  In compatibility mode, members without visibility  
> modifier as treated as default visibile (which is the current  
> semantics of Java).
>
> BREAKING CHANGES:
> None.
>
> EXISTING PROGRAMS:
> Work fine in compatibility mode.
>
> REFERENCES
>
> EXISTING BUGS: To my best knowledge, none.
>
> URL FOR PROTOTYPE (optional):
>
> On Mar 3, 2009, at 13:01 , Stephen Colebourne wrote:
>
>   
>>> PROJECT COIN SMALL LANGUAGE CHANGE PROPOSAL FORM v1.0
>>> AUTHOR(S): Adrian Kuhn
>>> OVERVIEW
>>> Allow the "default" keyword to be used as modifier for default   
>>> visibility. In strict mode, missing use of default is a warning /   
>>> error, in compatibility mode both the current (ie no default  
>>> keyword)  and the new syntax are accepted.
>>> FEATURE SUMMARY: Use "default" keyword for default visibility.
>>> MAJOR ADVANTAGE: The missing keyword for default visibility breaks  
>>> the  symmetry of visibility modifiers. Since it is the only  
>>> implicit  modifier, omitting any of the three explicit modifiers by  
>>> mistake may  be the source of unexpected behavior and thus hard to  
>>> track down bugs.  (There was an example on a blog post recently,  
>>> but I cannot find it  know).
>>> MAJOR BENEFIT: Symmetry of visibility modifiers is restored.
>>> MAJOR DISADVANTAGE: Two ways to express the same thing (in   
>>> compatibility mode).
>>> ALTERNATIVES: Using a comment such as /* default */ is not an   
>>> alternative since such comments are not processed by the compiler.
>>> EXAMPLES
>>> public class C {
>>> 	default Field f;
>>> }
>>> SIMPLE EXAMPLE: See above.
>>> ADVANCED EXAMPLE: None.
>>> DETAILS
>>> SPECIFICATION: "default" is already a keyword and introducing it as  
>>> a  new visibility modifier is save, it does not lead to ambiguous  
>>> grammar.
>>> COMPILATION: Same as now for implicit default visibility.
>>> TESTING: Same as now for implicit default visibility.
>>> LIBRARY SUPPORT: None.
>>> REFLECTIVE APIS: None.
>>> OTHER CHANGES: None.
>>> MIGRATION: Compatibility mode allows both, implicit and explicit   
>>> default visibility, to be used at  the same time.
>>> COMPATIBILITY
>>> BREAKING CHANGES: None.
>>> EXISTING PROGRAMS: Work fine in compatibility mode.
>>> REFERENCES
>>> EXISTING BUGS: To my best knowledge, none.
>>> URL FOR PROTOTYPE (optional):
>>>       
>
>
>