Non-proposal: Final Interfaces

[Paulo Levi]

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