Feedback and comments on ARM proposal

Joshua Bloch jjb at
Sat Mar 21 11:01:52 PDT 2009


On Sat, Mar 21, 2009 at 9:37 AM, Mark Mahieu <markmahieu at>wrote:

> Hi Josh,
> 2009/3/21 Joshua Bloch <jjb at>
>> What if you have an interface that extends an interface that extends the
>> magic marker?  There should be nothing wrong with that.  While there may be
>> some easy way to specify this (and give it reasonable semantics) it isn't
>> jumping out at me.  If anyone has any clever ideas along these lines, I'd
>> love to know.
> I'm probably missing the point, but doesn't the JLS generally use the
> phrase 'is a subtype of' to describe this kind of relationship?

 I don't think I did a good job of explaining the problem. Consider this:

interface Closeable extends MagicMarker {
    void close();

interface Foo extends Closeable { // Must be OK for ARM
    // Lots of methods

class bar implements Foo { // Must be OK for ARM
    // Lots of methods

interface Baz extends Foo { //
  // No new methods

class Qux Implements Foo, Baz { // Probably OK for Arm

interface Disposable extends MagicMarker {
    public void dispose();

class Nope implements Closeable, Disposeable {  // Probably not OK for ARM

The problem with Nope is that it contains two "magic methods"  (sole
parameterless method in an interface that directly extends MagicMarker).  Is
it sufficient to say that a class must have one and only one magic method to
make it eligible for automatic resource management?  Is it practical to
implement this in the compiler? I dunno.



More information about the coin-dev mailing list