Coin Considerations

[Florian Weimer]

* Reinier Zwitserloot:

> Here's my list (* means: Definitely 'believe' in it, just need the  
> time, and '-' means: Not entirely sure it can be made simple enough  
> for coin / is a good idea in the first place):

I would like to see:

  o transient modifier on local variables

    Basically,

       {
         transient SomeClass foo = getFoo();
         doSomething(foo);
       }

   is translated to:

       {
         transient SomeClass foo = getFoo();
         try {
           doSomething(foo);
         } finally {
           if (foo != null) {
             foo.cleanup();
           } 
         }
       }

    were SomeClass#cleanup() is the single method in class SomeClass
    which carries a @Cleanup annotation.

    The "!= null" part is there to make it possible to signal to the
    cleanup handler that the object has changed ownership.  Assignment
    to the variable does not trigger cleanup, cleanup only happens at
    scope exit.

    Annotation-controlled overlading is used instead of an interface
    because the existing cleanup routines have a myriad of different
    names and declare different checked exceptions, too.  If there are
    multiple @Cleanup methods for a type, a warning should be issued
    if this happens through inheritance (old code which needs to be
    ported), or an error if there are multiple such methods declared
    in the same type (erroneous new code).  In both cases, if such a
    type is used in a transient local variable declaration, the
    declaration is rejected.

    Syntactically, this extensions blends well with type inference for
    local variables.  However, similar to other forms of compile-time
    overloading, removing type declarations will change invoked
    methods in a few corner cases.

    The choice of the transient keyword means that the same syntax
    cannot be used for generating cleanup methods for classes.  It is
    not clear to me how to generate code for such classes in the
    presence of inheritance and exceptions, so I don't think this is a
    significant problem. (This problem does not arise in the local
    variables case because there is a clear nesting of scopes.)

    My hope is that such an extension eventually leads to code which
    has got fewer resource leaks, but is as succinct and as easy to
    read as code which (improperly) relies on garbage collection.

  o new-style for loops with non-Iterator iterators.

    Basically, allow interfaces besides Iterable and Iterator, guided
    by annotations (a more complicated variant of the approach for
    "transient").  The use case are iterators which may throw
    IOException (and other checked exceptions, of course).

    This is likely a waste if Java gets something which allows you to
    define new control flow constructs (and even syntactically
    lightweight anonymous classes might be good enough).

  o "class Foo extends ?" syntax for code injection through JSR 269

    Right now, you have to use a class name instead of "?" which you
    shouldn't use anywhere else due to concerns for circularity.  Not
    being able to name that class increases robustness.  The compiler
    would automatically generate a suitable type name in the same
    package as the class that contains the "?".  This would also
    enable code injection for nested types.
 
  o injection of automatically generated superinterface using JSR 269

    IIRC, there is a bug which prevents this from working.  I don't
    know if this is deliberate.  The syntax extension for classes
    might help here, too.

  o static methods in interface types

    This is for injecting code using a superinterface generated in a
    JSR 269 scenario.  Static member classes already work today (if
    you fix the bug mentioned in the previous item.)

  o compiler warnings for crass mismatches between syntax and
    indentation (if this is too hard to implement efficiently, a
    backport of the -Xlint:braces warning from Netbeans)

    A mode which rejects tab characters in the source code might be
    useful, too.

My larger wish list includes:

  - non-nullable reference types
  - tuples and structural record types
  - algebraic data types
  - type classes and type families
    (or reified generics with partial specialization)
  - non-hashable/comparable/synchronizable reference types
    (perhaps via type classes)

Okay, this list is not to be taken completely seriously.  But I think
some of the stuff is indeed useful (the last point would allow a clean
implementation of fixnums, for instance).

>   - factory interfaces (an interface to describe constructors and  
> static methods). I've got a simple way to do it, but I don't think its  
> simple enough for coin.

Method handles will cover many use cases, I think.