Feedback and comments on ARM proposal

[Joshua Bloch]

Mark and Tim,
I think it might be easier to specify (and implement the package variant.
 Roughly speaking, the legal types for "manageable resources" are those that
are assignment compatible with one and only one of the classes in
java.lang.auto.  While it's not generally possible to enumerate over classes
in a package, the compiler can be (are, in fact) tied to particular versions
of the platform so this shouldn't present too big a problem (though it could
limit extensibility by JRE hackers).

What about the magic marker interface (if you'll pardon my wordplay)? This
may be difficult to specify.  Loosely speaking you want a manageable
resource to be assignment compatible with one and only one interface that
extends the magic marker. But this opens a whole can of works.  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.

        Josh

On Sat, Mar 21, 2009 at 8:30 AM, Mark Mahieu <markmahieu at googlemail.com>wrote:

> 2009/3/21 Tim Peierls <tim at peierls.net>
>
> > On Fri, Mar 20, 2009 at 5:18 PM, Mark Mahieu <markmahieu at googlemail.com
> >wrote:
> >
> >> Or perhaps a marker interface rather than a special package?  That might
> >> be more consistent with existing 'special behaviour' (eg. Serializable).
> >
> >
> > And a magic interface seems simpler than a magic package. It would make
> it
> > a lot easier for people to roll their own AutoXyz variants. OTOH, maybe
> > unrestricted extensibility is just asking for trouble?
> >
> > --tim
> >
>
> Possibly, though I'm sure that people who will 'abuse' ARM by applying it
> to
> inappropriate APIs would be just as likely to do so with a restricted set
> of
> interfaces anyway.  Names like 'close' are wonderfully generic and easy to
> incorporate into an API if you've convinced yourself that the end justifies
> the means.
> I don't think there's any way it (either approach) would allow people to
> cause trouble with APIs they don't own though.  For example, I couldn't get
> ARM to call Iterator.remove() at the end of my try blocks :)
>
> I guess I'm most interested in those APIs that would otherwise be left out
> in the cold, like the new JDBC 4 java.sql methods I mentioned in another
> email.
>
> Mark
>
>