Mailing-List: contact notifications-help@groovy.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@groovy.apache.org
Date: Tue, 2 May 2017 02:09:07 +0000 (UTC)
From: "Paul King (JIRA)" <jira@apache.org>
To: notifications@groovy.apache.org
Message-ID: <JIRA.12818261.1378761373000.98320.1493690947381@Atlassian.JIRA>
In-Reply-To: <JIRA.12818261.1378761373000@Atlassian.JIRA>
References: <JIRA.12818261.1378761373000@Atlassian.JIRA> <JIRA.12818261.1378761373961@jira-lw-us.apache.org>
Subject: [jira] [Reopened] (GROOVY-6336) Support Java 7 ARM blocks
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Tue, 02 May 2017 02:09:13 -0000


     [ https://issues.apache.org/jira/browse/GROOVY-6336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul King reopened GROOVY-6336:
-------------------------------

> Support Java 7 ARM blocks
> -------------------------
>
>                 Key: GROOVY-6336
>                 URL: https://issues.apache.org/jira/browse/GROOVY-6336
>             Project: Groovy
>          Issue Type: New Feature
>          Components: Compiler
>    Affects Versions: 2.2.0-beta-2
>            Reporter: Tom Dunstan
>            Assignee: Daniel Sun
>             Fix For: 3.0
>
>
> Currently Groovy does not have an equivalent to Java 7's ARM blocks. The closest is adding a method which takes a closure to the class that you'd like to be auto-closed (or whatever gives you that resource), and implementing the closing logic in that method. This has a host of problems:
>  - It's inefficient, requiring multiple method calls and an extra closure class over the Java solution
>  - Since the closure-accepting methods are added ad-hoc, they have different names and quite possibly subtly different behaviour, particularly around what happens if an exception is thrown during the closing. By contrast this is well defined in Java 7 so a programmer doesn't have to go hunting for documentation or source code on the method that they're calling 
>  - If you are trying to work with an existing Java library rather than Groovy code, you're out of luck, since short of metaclass hacking you won't be able to add a wrapper method anyway
> It would also be nice to keep Groovy and Java syntax as consistent as possible to ease porting between the two.


--
This message was sent by Atlassian JIRA
(v6.3.15#6346)