Feedback and comments on ARM proposal

[Stefan Schulz]

Hm, maybe I am blind to see, why it wouldn't then be possible to add a 
second "marker" interface "AutoOpenable".

I'm just a bit unsure, what the compiler has to do here. Will a 
ClosableResource have to be implemented directly, or may interfaces 
extend it? Sounds like quite some class traversing.

Stefan

Reinier Zwitserloot schrieb:
> Interesting idea. I'm ambivalent; one specific interface with a void 
> close() throws Exception method works for me, but this is slightly 
> more flexible and sufficiently simple too. As long as one of those two 
> things makes it in java7, I'm happy :P
> 
> 
> Using a special package which contains only interfaces that serve as 
> AutoDisposable: Okay. Can you add your own to this? Technically you 
> can just put "java.lang.auto.Foo" in your own jar files, do those get 
> picked up, or will java.lang.auto become a sealed package of some 
> sort, or will it be limited to only interfaces in the java.lang.auto 
> package in the java-core module? If any programmer can add their own, 
> I think a marker interface is a better idea.
> 
> 
> In either case, *IF* anybody is allowed to add their own, javac should 
> optimally be expanded to, at compile time, whine about mistakes: If 
> you add a non-interface to it, or an interface with more than 1 
> method, or with 1 method but that method takes parameters.
> 
> 
> It can even sort of, kind of, solve locking:
> 
> public interface java.lang.auto.DisposableLock {
>      void unlock();
> }
> 
> public interface java.util.concurrent.Lock implements DisposableLock 
> { ... }
> 
> 
> try ( lock ) {
>      lock.lock(); //People are going to forget this, unfortunately
>      doWhatever();
> }
> 
> 
>   --Reinier Zwitserloot
> 
> 
> 
> On Mar 20, 2009, at 22:23, Bob Lee wrote:
> 
>  > +1. I also like not adding types directly to java.lang.
>  >
>  > On Fri, Mar 20, 2009 at 2:19 PM, Joshua Bloch <jjb at google.com> wrote:
>  >
>  >> Tim,
>  >> This is very clever!  While it doesn't allow programmers to create 
>  >> their
>  >> own
>  >> interfaces for use with the construct, it allows future release of 
>  >> the
>  >> platform to broaden the applicability of the construct without 
>  >> changing the
>  >> language.  And it does so without abusing annotations.  While it's 
>  >> not a
>  >> typical uses of packages, it wouldn't be the first time the 
>  >> language gave
>  >> special standing to a package.  For example, members of java.lang are
>  >> automatically imported on demand.
>  >>
>  >> What do others think?
>  >>
>  >>            Josh
>  >>
>  >> On Fri, Mar 20, 2009 at 2:08 PM, Tim Peierls <tim at peierls.net> wrote:
>  >>
>  >>> How about using a special package -- java.lang.auto, say -- with
>  >> initially
>  >>> only one or two interfaces -- AutoCloseable and AutoDisposable, 
>  >>> say --
>  >> and
>  >>> word the ARM proposal so that only subtypes of interfaces with a 
>  >>> single,
>  >>> parameterless method that are declared in this special package are
>  >> allowed
>  >>> in the ARM try-initialization?
>  >>>
>  >>> The idea here is to remove the decision about which clean-up 
>  >>> methods to
>  >>> support from the current proposal and make it a library design 
>  >>> issue.
>  >>>
>  >>> --tim
>  >>>
>  >>>
>  >>
>  >>
>  >
> 
> 
>