groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "KARR, DAVID" <dk0...@att.com>
Subject RE: Thread safety and OptionBuilder
Date Sun, 03 May 2015 01:34:22 GMT
> -----Original Message-----
> From: Jacopo Cappellato [mailto:jacopo.cappellato@gmail.com]
> Sent: Saturday, May 02, 2015 3:52 AM
> To: dev@groovy.incubator.apache.org
> Subject: Thread safety and OptionBuilder
> 
> Hi all,
> 
> in the GroovyMain class there is the following code:
> 
> /**
>  * Build the options parser.  Has to be synchronized because of the
> way Options are constructed.
>  *
>  * @return an options parser.
>  */
> private static synchronized Options buildOptions() {
>     Options options = new Options();
>     options.addOption(OptionBuilder.hasArg()....
> ...
> 
> The JavaDoc comment says:
> 
> "Has to be synchronized because of the way Options are
> constructed."
> 
> but unfortunately this is not enough to make the Groovy code thread
> safe.
> In fact the current version of Commons CLI used by Groovy is 1.2,
> which is the latest stable release, and in this version the
> OptionBuilder class is clearly not meant to be used by more than
> one thread (there are several static fields modified by the builder
> methods); the issue has been reported a few times (e.g.
> https://issues.apache.org/jira/browse/CLI-209) and has been fixed
> by deprecating the class in favor of a new Option.builder() method:
> 
> https://commons.apache.org/proper/commons-
> cli/apidocs/org/apache/commons/cli/OptionBuilder.html
> 
> Unfortunately I don't know if Commons-CLI 1.3 will be released soon
> (1.2. was released 2 years ago). And the OptionBuilder class is
> used in a few classes in Groovy.
> 
> My question is: is this a concern/known issue for Groovy? what is
> the best way to address the issue? Should we get in touch with the
> Commons CLI community to know more about their plans or should me
> look for a different approach? With this information I will try to
> help to move in the direction you feel is the best.

I know nothing about this issue, I'm just reading what you've written here and interpreting
it.

Why exactly do you believe that synchronizing the static method is not enough to "make the
Groovy code thread safe" (ignoring the lack of specificity in that statement).

If OptionsBuilder is truly not thread-safe, if you can guarantee that this class is the only
one making use of OptionsBuilder in the application, and this static synchronized method is
the only method in the class using OptionsBuilder, then that seems like reasonable protection.

Mime
View raw message