Non-proposal: Final Interfaces

[Joe Darcy]

Yes, the proposal is out of date for consideration and the modularity 
language features for JSR 294 may support this kind of capability.

-Joe

On 04/20/09 03:49 PM, Paulo Levi wrote:
> Actually the
> "All methods that are deprecated can be deleted on the interface and all
> implementations (since they are controlled completly.)"
>
> Doesn't apply since clients use the methods, but methods can be added
> "(since they are controlled completly.)".
>
> On Mon, Apr 20, 2009 at 10:49 PM, Paulo Levi <i30817 at gmail.com> wrote:
>
>   
>> *I know this is much out of date for consideration, but i think that this
>> is a idea that would really help library evolution, and i did not see any of
>> this kind of strategy floating around in the other proposals.
>> *
>>
>> *
>> *
>>
>> *AUTHOR(S):* Paulo Levi Martins Faria, a student at FCUL, faculdade de
>> ciencias da universidade de lisboa at Lisbon, Portugal.
>>
>> *OVERVIEW*
>>
>> A way for interfaces to be used as references outside a package, but the
>> only implementations of them to exist on a package, to allow the evolution
>> (adding) of methods to interfaces and all their implementations.
>>
>> FEATURE SUMMARY:
>>
>> insted of declaring interfaces as:
>>
>> package xyz;
>>
>> public interface A{
>>
>> } or
>>
>> package xyz;
>>
>> interface A{
>>
>> }
>>
>> declare them as :
>>
>> package xyz;
>>
>> public final interface A{
>>
>> }
>>
>> And all implementations or extensions of A must be in the package xyz
>>
>>
>> MAJOR ADVANTAGE: What makes the proposal a favorable change?
>>
>> This would allow library authors to control the evolution of the
>> implementations of a common interface, deprecating old methods, while at the
>> same time allowing clients to program to the interfaces. The prohibition of
>> implementation/extension outside of package allows the library author to
>> control the package evolution completly. I have personally seen cases where
>> performance reasons lead to dangerous downcasts or using the raw type,
>> and/or subclassing of various classes, to implement something more
>> efficiently than the library core can, because of public interfaces.
>>
>> MAJOR BENEFIT:
>>
>> The jdk can decide if certain interfaces are not likely to be extended
>> outside of the library, and thus control api evolution more completly.
>>
>> All methods that are deprecated can be deleted on the interface and all
>> implementations (since they are controlled completly.)
>>
>> MAJOR DISADVANTAGE:
>>
>> Can not be retrofitted to existing api's (easily).
>>
>> Somewhat overlapping with abstract classes, but more powerfull.
>>
>> Losses flexibility of extension for clients, a risk i am well disposed
>> towards.
>>
>> ALTERNATIVES: Can the benefits and advantages be had some way without a
>> language change?
>>
>> Can think of a way how.
>>
>> *EXAMPLES*
>>
>> Show us the code!
>>
>> SIMPLE EXAMPLE: Show the simplest possible program utilizing the new
>> feature.
>>
>> ADVANCED EXAMPLE: Show advanced usage(s) of the feature.
>>
>> *DETAILS*
>>
>> SPECIFICATION: Describe how the proposal affects the grammar, type system,
>> and meaning of expressions and statements in the Java Programming Language
>> as well as any other known impacts.
>>
>> COMPILATION: How would the feature be compiled to class files? Show how the
>> simple and advanced examples would be compiled. Compilation can be expressed
>> as at least one of a desugaring to existing source constructs and a
>> translation down to bytecode. If a new bytecode is used or the semantics of
>> an existing bytecode are changed, describe those changes, including how they
>> impact verification. Also discuss any new class file attributes that are
>> introduced. Note that there are many downstream tools that consume class
>> files and that they may to be updated to support the proposal!
>>
>> I don't think that this changes compilation beyond the type checj
>>
>> TESTING: How can the feature be tested?
>>
>> Try to implement extend a final interface outside its package.
>>
>> LIBRARY SUPPORT: Are any supporting libraries needed for the feature?
>>
>> No.
>>
>> REFLECTIVE APIS: Do any of the various and sundry reflection APIs need to
>> be updated? This list of reflective APIs includes but is not limited to core
>> reflection (java.lang.Class and java.lang.reflect.*), javax.lang.model.*,
>> the doclet API, and JPDA.
>>
>> Don't think so.
>>
>> OTHER CHANGES: Do any other parts of the platform need be updated too?
>> Possibilities include but are not limited to JNI, serialization, and output
>> of the javadoc tool.
>>
>> No.
>>
>> MIGRATION:
>>
>> Create a new final sub interface to public one on the api, deplicate
>> methods taking that interface to use the new one. Deprecate the old methods
>> and interfaces. Wait for the pichforks.
>>
>> *COMPATIBILITY*
>>
>> BREAKING CHANGES: Are any previously valid programs now invalid? If so,
>> list one.
>>
>> None
>>
>> EXISTING PROGRAMS: How do source and class files of earlier platform
>> versions interact with the feature? Can any new overloadings occur? Can any
>> new overriding occur?
>>
>> No
>>
>> *REFERENCES*
>>
>>
>>     
>
>