Non-proposal: Final Interfaces

[Paulo Levi]

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*
>
>