JDK7 Tackles Java Verbosity

Jeroen,

I'm curious why you think automatic resource handilng "seems extremely dangerous". 

As someone who also programs in C#, I find this approach extremely useful in scoping resource usage. 

The only downside I can see is that obscuring the setup/teardown of resources can make them less forward in one's mind. The best comparison I can make is to the times I've been on projects that rely on Spring to manage database connections that develop connection leaks in the one or two specialized cases where the Spring management is circumvented. But that's more an issue of understanding the frameworks you're using rather than blindly using them. 

The API doesnt change. If you want explicit resource handling you can do, but you are no longer forced to do so.

I/O in its current state is horrible. Its primarily because of the many checked exceptions you have to handle on closing resources. This results in heavy boilerplate finally blocks like this:

    public static <T> T copy(T original) {
        ByteArrayOutputStream bos = null;
        ObjectInputStream in = null;
        ObjectOutputStream out = null;
        T obj = null;
        try {
            bos = new ByteArrayOutputStream();
            out = new ObjectOutputStream(bos);
            out.writeObject(original);
            out.flush();
            in = new ObjectInputStream(new ByteArrayInputStream(bos.toByteArray()));
            obj = (T) in.readObject();
        }
        catch(IOException e) {
            LOG.error("copy", e);
            throw new RuntimeException(e);
        }
        catch(ClassNotFoundException e) {
            LOG.error("copy", e);
            throw new RuntimeException(e);
        }
        finally {
            Exception ex = null;
            try {
                bos.close();
            }
            catch (IOException e) {
                LOG.error("copy", e);
                ex = e;
            }
            try {
                out.close();
            }
            catch (IOException e) {
                LOG.error("copy", e);
                ex = e;
            }
            try {
                in.close();
            }
            catch (IOException e) {
                LOG.error("copy", e);
                ex = e;
            }
            if (ex != null) {
                throw new RuntimeException(ex);
            }
        }
       
        LOG.trace("Deep copy completed: " + obj);
       
        return obj;
    }

I appreciate the changes on that! Language features are for writing maintainable code. Let newbies learn their own lessons...

Well, I think the the automatic resource management is quite confusing. I don't find it readable.

I see the following problems:

- long try statement

- can you catch exception? I think yes

- what if you close the stream in your code?

- if you catch the IOException, do you also catch the code in the try brackets?

- what if your code is "if (path.starts("http://")) stream = new URL(path).openStream() else stream = new FileInputStream(path);"?

I don't understand why can't we have "if an object implements Disposable and is no longer reachable/used => close it".  Implementation of this should probably be done at compile time to keep backward compatibility.

 ...

I can see with it a new chapter in the Java Puzzlers book coming. 

Thanks for pointing to this project, the code is indeed more readable than a

try (InputStream in = new FileInputStream(args[0])) {
    try (OutputStream out = new FileOutputStream(args[1]) {
        ... 
    }
} 

try (InputStream in = new FileInputStream(args[0]);
      OutputStream out = new FileOutputStream(args[1]))
{
        ... 
} 

Question about Collection literals:

Can I do this:

void test(Map<String, String> map)
{
}

void test2()
{
  test( { "a": "A", "b" : "B" } );
}

Second question, can I nest, like so:

void test(Map<String, Map<String, Integer>> map)
{
}

void test2()
{
  test( { "a": { "b": 123 } } );
}

???

Map<String, List<BigDecimal>> numberMap = new TreeMap<>();

why do we need to use generics for right side. if compiler can understand with empty <>;

I think it can understand without <>.