Feedback and comments on ARM proposal (original) (raw)

Stefan Schulz schulz at e-spirit.de
Fri Mar 20 16:47:36 PDT 2009

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 >>> >>> >> >> >

More information about the coin-dev mailing list