Proposal: Generic Specification by Method

[Ron Thomas]

I would like to propose an extension to generics that would allow a
generic type to be specified by methods in addition to the current
inheritance/implementations.

Generics by Method

AUTHOR(S):

Ron Thomas

OVERVIEW

FEATURE SUMMARY:

Generics by Method allows for the use of Generics when using a common
interface or super class is not an option.

MAJOR ADVANTAGE:

This would allow the use of generics based off of methods instead of
off of classes/interfaces.

MAJOR BENEFIT:

Generics by Method will allow working with different classes with
similar methods easier and more concise. Instead of relying on
instanceof checks and class wrappers a generic type would suffice.
While using Generics by Interface or super class is preferred, it is
not always an option when dealing with 3rd party APIs.

MAJOR DISADVANTAGE:

Reflection will be used in order to achieve this goal, and the
corresponding performance hit will be incurred.

ALTERNATIVES:

Use wrappers and class composition and use generics as-is.

EXAMPLES

SIMPLE EXAMPLE:

The following method calls the close method on a list of resources.
Unfortunately using the Closeable interface is no an option because
one of the resources is supplied by a 3rd party resource does not
implement the interface.

public  <T having(close() : void)>
void closeAllResources(List<T> resources) {
    for (T t : resources) {
        t.close();
    }
}

ADVANCED EXAMPLE: Show advanced usage(s) of the feature.

The following example requires two methods, one of which throws an exception.
public <T having(close() : void) having(open(String, int) throws
ResourceException : int)>
boolean checkResources(List<T> resources, String host, int port)
throws ResourceException {
    for (T t : resources) {
        int status = t.open(host, port);
        if (status < 0) {
            return false;
        }
        t.close();
    }
    return true;
}

DETAILS

SPECIFICATION:

A having generic specification shall be added in the form:
having(METHOD_SIG)

METHOD_SIG := METHOD_NAME([[PARAM_TYPE,]* PARAM_TYPE]*) :
[RETURN_TYPE] [throws [[EXCEPTION,]* EXCEPTION]*
METHOD_NAME := java legal method name
PARAM_TYPE := java legal parameter type
RETURN_TYPE := java legal return type
EXCEPTION := java level exception

The following generic expressions become legal:

Simple specification with no parameters.
<T having(method() : void)>
matches classes with:  void method()

Simple specifiation with parameters.
<T having(method(int,String) : int)>
matches classes with:  int method(int, String)

Constructor specification
<T having(new(int, String) : int)>
matches classes with constructor that have an int and String parameter

Specification with exception
<T having(method(int, String) throws AException : int)>
matches classes with : int method(int, String) throws AException
OR int method(int, String)


COMPILATION:

The compiler would use reflection to handle calling of the generic
methods themselves.

For example:
public <T having(close() : void)>
void closeAllResources(List<T> resources) {
    for (T t : resources) {
        t.close();
    }
}

Would effectively become:
<T extends Object>
void closeAllResources(List<T> resources) {
    for (T t : resources) {
        try {
            t.getClass().getMethod("close").invoke(t);
        } catch (IllegalAccessException ex) {
            throw new RuntimeException("Method close not found");
        } catch (InvocationTargetException ex) {
            throw new RuntimeException("Method close not found");
        } catch (NoSuchMethodException ex) {
            throw new RuntimeException("Method close not found");
        }
    }
}

The compiler would also check all uses of this feature, and generate a
compiler error if any usage does not match the criteria given.

TESTING:

The feature can be tested by compiling and running programs that
exercise the feature.

LIBRARY SUPPORT:

No.

REFLECTIVE APIS:

No.  The use of this feature is compile time only.

OTHER CHANGES:

No.

MIGRATION:

No. This is a new feature and no existing code should be affected.

COMPATIBILITY

BREAKING CHANGES:

No.

EXISTING PROGRAMS:

This is an addition to generics, and this change would be transparent to them.

REFERENCES

EXISTING BUGS: