[jira] [Commented] (LANG-1312) LocaleUtils#toLocale does not support language followed by UN M.49 numeric-3 area code
[
https://issues.apache.org/jira/browse/LANG-1312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15875172#comment-15875172
]
ASF GitHub Bot commented on LANG-1312:
--
Github user kinow commented on the issue:
https://github.com/apache/commons-lang/pull/239
Will merge it tomorrow if there's no objection (or feel free to merge it
@PascalSchumacher :-) )
> LocaleUtils#toLocale does not support language followed by UN M.49 numeric-3
> area code
> --
>
> Key: LANG-1312
> URL: https://issues.apache.org/jira/browse/LANG-1312
> Project: Commons Lang
> Issue Type: Bug
>Affects Versions: 3.5
>Reporter: Pascal Schumacher
>Priority: Minor
>
> These all work:
> {code:java}
> System.out.println(new Locale("en", "001"));
> System.out.println(new Locale("en", "150"));
> System.out.println(new Locale("ar", "001"));
> {code}
> but these all fail with an IllegalArgumentException:
> {code:java}
> System.out.println(LocaleUtils.toLocale("en_001"));
> System.out.println(LocaleUtils.toLocale("en_150"));
> System.out.println(LocaleUtils.toLocale("ar_001"));
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[GitHub] commons-lang issue #239: LANG-1312: LocaleUtils#toLocale does not support la...
Github user kinow commented on the issue: https://github.com/apache/commons-lang/pull/239 Will merge it tomorrow if there's no objection (or feel free to merge it @PascalSchumacher :-) ) --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (LANG-1145) 64 bit check in SystemUtils
[ https://issues.apache.org/jira/browse/LANG-1145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15875169#comment-15875169 ] ASF GitHub Bot commented on LANG-1145: -- Github user kinow commented on the issue: https://github.com/apache/commons-lang/pull/231 @michael-o >What is the real pupose for this actually? The client should not care about the arch at all. I think @Tomschi use case is valid, where a client could need to know the arch before loading a certain library, and we had another issue submitted LANG-1145 with similar requirement. >The regex match is brittle. This will likely fail on ARM and it fails here on Itanium with HP-UX for os.arch IA64N which is a 32 bit VM. Note taken, perhaps before merging we can try to cover more archs, like this list: * http://lopica.sourceforge.net/os.html There is another place where arch is used within Commons too: * https://github.com/apache/commons-crypto/blob/158be0644c353a617427ab190a4f09082cda42ac/src/main/java/org/apache/commons/crypto/OsInfo.java#L28 We can possibly look at how crypto is using it, and if we could maybe use a similar approach here. > 64 bit check in SystemUtils > --- > > Key: LANG-1145 > URL: https://issues.apache.org/jira/browse/LANG-1145 > Project: Commons Lang > Issue Type: Improvement > Components: lang.* >Reporter: Gabor Liptak >Priority: Minor > > Add is64bit method to SystemUtils.java > http://stackoverflow.com/a/2269242/304690 for Windows snippet and > https://github.com/apache/spark/blob/master/core/src/main/scala/org/apache/spark/util/SizeEstimator.scala > for zOS snippet -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[GitHub] commons-lang issue #231: Evaluate Architecure
Github user kinow commented on the issue: https://github.com/apache/commons-lang/pull/231 @michael-o >What is the real pupose for this actually? The client should not care about the arch at all. I think @Tomschi use case is valid, where a client could need to know the arch before loading a certain library, and we had another issue submitted LANG-1145 with similar requirement. >The regex match is brittle. This will likely fail on ARM and it fails here on Itanium with HP-UX for os.arch IA64N which is a 32 bit VM. Note taken, perhaps before merging we can try to cover more archs, like this list: * http://lopica.sourceforge.net/os.html There is another place where arch is used within Commons too: * https://github.com/apache/commons-crypto/blob/158be0644c353a617427ab190a4f09082cda42ac/src/main/java/org/apache/commons/crypto/OsInfo.java#L28 We can possibly look at how crypto is using it, and if we could maybe use a similar approach here. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] commons-lang issue #231: Evaluate Architecure
Github user michael-o commented on the issue: https://github.com/apache/commons-lang/pull/231 What is the real pupose for this actually? The client should not care about the arch at all. The regex match is brittle. This will likely fail on ARM and it fails here on Itanium with HP-UX for `os.arch` `IA64N` which is a 32 bit VM. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (LANG-1313) Add SystemUtils#IS_(32|64)_BIT_JVM
[ https://issues.apache.org/jira/browse/LANG-1313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15875099#comment-15875099 ] ASF GitHub Bot commented on LANG-1313: -- Github user PascalSchumacher commented on the issue: https://github.com/apache/commons-lang/pull/231 jira issue: https://issues.apache.org/jira/browse/LANG-1313 I plan to merge this tomorrow (if there are no objections). > Add SystemUtils#IS_(32|64)_BIT_JVM > -- > > Key: LANG-1313 > URL: https://issues.apache.org/jira/browse/LANG-1313 > Project: Commons Lang > Issue Type: New Feature >Reporter: Pascal Schumacher >Priority: Minor > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[GitHub] commons-lang issue #231: Evaluate Architecure
Github user PascalSchumacher commented on the issue: https://github.com/apache/commons-lang/pull/231 jira issue: https://issues.apache.org/jira/browse/LANG-1313 I plan to merge this tomorrow (if there are no objections). --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Created] (LANG-1313) Add SystemUtils#IS_(32|64)_BIT_JVM
Pascal Schumacher created LANG-1313: --- Summary: Add SystemUtils#IS_(32|64)_BIT_JVM Key: LANG-1313 URL: https://issues.apache.org/jira/browse/LANG-1313 Project: Commons Lang Issue Type: New Feature Reporter: Pascal Schumacher Priority: Minor -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[GitHub] commons-lang issue #238: Validate's String.format without arguments
Github user PascalSchumacher commented on the issue: https://github.com/apache/commons-lang/pull/238 Yes, lets keep the pull requests as is is. Sorry if I caused the impression of being overtly critical of this change. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] commons-lang pull request #238: Validate's String.format without arguments
Github user asfgit closed the pull request at: https://github.com/apache/commons-lang/pull/238 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Closed] (CODEC-226) Provide version independent javadoc URL?
[ https://issues.apache.org/jira/browse/CODEC-226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pascal Schumacher closed CODEC-226. --- Resolution: Invalid Missed that. Sorry for the noise. > Provide version independent javadoc URL? > > > Key: CODEC-226 > URL: https://issues.apache.org/jira/browse/CODEC-226 > Project: Commons Codec > Issue Type: Improvement >Reporter: Pascal Schumacher >Priority: Minor > > https://commons.apache.org/proper/commons-codec/javadocs/api-release/ > does not exist, while these do > https://commons.apache.org/proper/commons-lang/javadocs/api-release/ > https://commons.apache.org/proper/commons-io/javadocs/api-release/ -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (LANG-1311) TypeUtils.toString() doesn't handle primitive and Object arrays correctly
[
https://issues.apache.org/jira/browse/LANG-1311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15875073#comment-15875073
]
Pascal Schumacher commented on LANG-1311:
-
Thanks for clarifying! :)
> TypeUtils.toString() doesn't handle primitive and Object arrays correctly
> -
>
> Key: LANG-1311
> URL: https://issues.apache.org/jira/browse/LANG-1311
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.reflect.*
>Affects Versions: 3.4, 3.5
>Reporter: Aaron Digulla
>Assignee: Pascal Schumacher
>Priority: Minor
> Fix For: 3.6
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> TypeUtils.toString() doesn't handle primitive and Object arrays correctly.
> Specifically, these tests will fail:
> {code}
> assertEquals("int[]", TypeUtils.toString(int[].class));
> assertEquals("java.lang.Integer[]", TypeUtils.toString(Integer[].class));
> {code}
> If you declare a field with type {{List[]}}, then you can add this
> test:
> {code}
> assertEquals("java.util.List[]",
> TypeUtils.toString(field.getGenericType()));
> {code}
> This patch fixes the issue:
> {code}
> private static String classToString(final Class c) {
> // begin patch
> if (c.isArray()) {
> return toString(c.getComponentType()) + "[]";
> }
> // end patch
>
> final StringBuilder buf = new StringBuilder();
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (LANG-1311) TypeUtils.toString() doesn't handle primitive and Object arrays correctly
[
https://issues.apache.org/jira/browse/LANG-1311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15875025#comment-15875025
]
Aaron Digulla commented on LANG-1311:
-
Thanks.
The generics list worked but I didn't see a unit test for a mix of generics and
arrays, so I added one for good measure.
> TypeUtils.toString() doesn't handle primitive and Object arrays correctly
> -
>
> Key: LANG-1311
> URL: https://issues.apache.org/jira/browse/LANG-1311
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.reflect.*
>Affects Versions: 3.4, 3.5
>Reporter: Aaron Digulla
>Assignee: Pascal Schumacher
>Priority: Minor
> Fix For: 3.6
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> TypeUtils.toString() doesn't handle primitive and Object arrays correctly.
> Specifically, these tests will fail:
> {code}
> assertEquals("int[]", TypeUtils.toString(int[].class));
> assertEquals("java.lang.Integer[]", TypeUtils.toString(Integer[].class));
> {code}
> If you declare a field with type {{List[]}}, then you can add this
> test:
> {code}
> assertEquals("java.util.List[]",
> TypeUtils.toString(field.getGenericType()));
> {code}
> This patch fixes the issue:
> {code}
> private static String classToString(final Class c) {
> // begin patch
> if (c.isArray()) {
> return toString(c.getComponentType()) + "[]";
> }
> // end patch
>
> final StringBuilder buf = new StringBuilder();
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[GitHub] commons-lang issue #238: Validate's String.format without arguments
Github user kinow commented on the issue: https://github.com/apache/commons-lang/pull/238 @mureinik I think removing these calls should be fine. Specially given that other classes in lang use a normal String, and not `String.format` when there are no parameters, e.g. https://github.com/apache/commons-lang/blob/954ade4c1ae2adc0aaac3a1dbe800495c519520c/src/main/java/org/apache/commons/lang3/ThreadUtils.java#L54 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] commons-lang issue #238: Validate's String.format without arguments
Github user mureinik commented on the issue: https://github.com/apache/commons-lang/pull/238 Now that I think about it, a cleaner solution might be to add `Object...` arguments to these methods' signatures, and pass it on to the `String.format` calls. This way, we keep the code 100% backwards compatible, regardless of any `%n`s anyone might have used - any existing calls just pass empty varargs, which is perfectly legal. The downside is slightly less elegant signatures. If the maintainers prefer this approach, I'd be happy to push such a patch. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Created] (CODEC-227) Implement UTF-7 encodings?
Sebb created CODEC-227: -- Summary: Implement UTF-7 encodings? Key: CODEC-227 URL: https://issues.apache.org/jira/browse/CODEC-227 Project: Commons Codec Issue Type: New Feature Reporter: Sebb There are two related UTF-7 encodings which might be worth implementing: [1] RFC 2152 - UTF-7 A Mail-Safe Transformation Format of Unicode [2] RFC 3501 - INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1 (5.1.3) [1] https://tools.ietf.org/html/rfc2152 [2] https://tools.ietf.org/html/rfc3501#section-5.1.3 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (CODEC-226) Provide version independent javadoc URL?
[ https://issues.apache.org/jira/browse/CODEC-226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15874327#comment-15874327 ] Sebb commented on CODEC-226: Click on "Project Reports" http://commons.apache.org/proper/commons-codec/project-reports.html > Provide version independent javadoc URL? > > > Key: CODEC-226 > URL: https://issues.apache.org/jira/browse/CODEC-226 > Project: Commons Codec > Issue Type: Improvement >Reporter: Pascal Schumacher >Priority: Minor > > https://commons.apache.org/proper/commons-codec/javadocs/api-release/ > does not exist, while these do > https://commons.apache.org/proper/commons-lang/javadocs/api-release/ > https://commons.apache.org/proper/commons-io/javadocs/api-release/ -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (IO-529) FileReaderWithEncoding
Joachim Raue created IO-529: --- Summary: FileReaderWithEncoding Key: IO-529 URL: https://issues.apache.org/jira/browse/IO-529 Project: Commons IO Issue Type: New Feature Components: Streams/Writers Reporter: Joachim Raue I really enjoy using the FileWriterWithEncoding that you offer. I feel it would be very helpful if there was a simple FileReaderWithEncoding providing similar syntactic sugar. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Comment Edited] (CLI-221) cli's with last option as list type values and have argument are not parsed correctly
[
https://issues.apache.org/jira/browse/CLI-221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15874256#comment-15874256
]
Simon Zee edited comment on CLI-221 at 2/20/17 9:38 AM:
Purely coming here to agree with others that the current behaviour is extremely
unintuitive, and I can testify I personally have wasted hours puzzling over why
changing the order of options seemed to break my code.
Consider that simply reordering the options completely changes the parsing:
ie:
program -foo 1 -bar 1,2 fubar
parses differently to
program -bar 1,2 -foo 1 fubar
Nobody will expect that.
Here is a diff that resolves this issue for me:
{code}
Index: src/main/java/org/apache/commons/cli/Parser.java
===
--- src/main/java/org/apache/commons/cli/Parser.java(revision 1783729)
+++ src/main/java/org/apache/commons/cli/Parser.java(working copy)
@@ -340,7 +340,7 @@
String str = iter.next();
// found an Option, not an argument
-if (getOptions().hasOption(str) && str.startsWith("-"))
+if (getOptions().hasOption(str) && str.startsWith("-") ||
"--".equals(str))
{
iter.previous();
break;
{code}
was (Author: simonzee):
Purely coming here to agree with others that the current behaviour is extremely
unintuitive, and I can testify I personally have wasted hours puzzling over why
changing the order of options seemed to break my code.
Consider that simply reordering the options completely changes the parsing:
ie:
program -foo 1 -bar 1,2 fubar
parses differently to
program -bar 1,2 -foo 1 fubar
Nobody will expect that.
Here is a diff that resolves this issue for me:
Index: src/main/java/org/apache/commons/cli/Parser.java
===
--- src/main/java/org/apache/commons/cli/Parser.java(revision 1783729)
+++ src/main/java/org/apache/commons/cli/Parser.java(working copy)
@@ -340,7 +340,7 @@
String str = iter.next();
// found an Option, not an argument
-if (getOptions().hasOption(str) && str.startsWith("-"))
+if (getOptions().hasOption(str) && str.startsWith("-") ||
"--".equals(str))
{
iter.previous();
break;
> cli's with last option as list type values and have argument are not parsed
> correctly
> -
>
> Key: CLI-221
> URL: https://issues.apache.org/jira/browse/CLI-221
> Project: Commons CLI
> Issue Type: Bug
> Components: Parser
>Affects Versions: 1.2
>Reporter: Gagan Jain
>
> I have set the value separator for an option to be comma (',').
> Consider the following cli:
> cli definition : cmd1 -o1 a1
> command name: 'cmd1'
> options: 'o1' accpets list of values separated by ','
> arguments: 'a1' single valued argument
> {code}cmd1 -o1 o1v1,o1v2,o1v3 a1v1{code}
> GnuParser parses this the cli with o1 having values {o1v1, o1v2, o1v3, a1v1}
> instead of {o1v1,o1v2,o1v3}
> Bug seems to be in org.apache.commons.cli.Parser's class processArgs method.
> {code:java}
> public void processArgs(Option opt, ListIterator iter) throws
> ParseException
> {
> // loop until an option is found
> while (iter.hasNext())
> {
> String str = (String) iter.next();
> // found an Option, not an argument
> if (getOptions().hasOption(str) && str.startsWith("-"))
> {
> iter.previous();
> break;
> }
> // found a value
> try
> {
>
> opt.addValueForProcessing(Util.stripLeadingAndTrailingQuotes(str));
> }
> catch (RuntimeException exp)
> {
> iter.previous();
> break;
> }
> }
> if (opt.getValues() == null && !opt.hasOptionalArg())
> {
> throw new MissingArgumentException(opt);
> }
> }
> {code}
> In my opinion, if a value separator is defined for option, and is other than
> space (' '), loop should break immediately after one iteration.
> Correct me, if I am wrong in my understanding.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (CLI-221) cli's with last option as list type values and have argument are not parsed correctly
[
https://issues.apache.org/jira/browse/CLI-221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15874256#comment-15874256
]
Simon Zee commented on CLI-221:
---
Purely coming here to agree with others that the current behaviour is extremely
unintuitive, and I can testify I personally have wasted hours puzzling over why
changing the order of options seemed to break my code.
Consider that simply reordering the options completely changes the parsing:
ie:
program -foo 1 -bar 1,2 fubar
parses differently to
program -bar 1,2 -foo 1 fubar
Nobody will expect that.
Here is a diff that resolves this issue for me:
Index: src/main/java/org/apache/commons/cli/Parser.java
===
--- src/main/java/org/apache/commons/cli/Parser.java(revision 1783729)
+++ src/main/java/org/apache/commons/cli/Parser.java(working copy)
@@ -340,7 +340,7 @@
String str = iter.next();
// found an Option, not an argument
-if (getOptions().hasOption(str) && str.startsWith("-"))
+if (getOptions().hasOption(str) && str.startsWith("-") ||
"--".equals(str))
{
iter.previous();
break;
> cli's with last option as list type values and have argument are not parsed
> correctly
> -
>
> Key: CLI-221
> URL: https://issues.apache.org/jira/browse/CLI-221
> Project: Commons CLI
> Issue Type: Bug
> Components: Parser
>Affects Versions: 1.2
>Reporter: Gagan Jain
>
> I have set the value separator for an option to be comma (',').
> Consider the following cli:
> cli definition : cmd1 -o1 a1
> command name: 'cmd1'
> options: 'o1' accpets list of values separated by ','
> arguments: 'a1' single valued argument
> {code}cmd1 -o1 o1v1,o1v2,o1v3 a1v1{code}
> GnuParser parses this the cli with o1 having values {o1v1, o1v2, o1v3, a1v1}
> instead of {o1v1,o1v2,o1v3}
> Bug seems to be in org.apache.commons.cli.Parser's class processArgs method.
> {code:java}
> public void processArgs(Option opt, ListIterator iter) throws
> ParseException
> {
> // loop until an option is found
> while (iter.hasNext())
> {
> String str = (String) iter.next();
> // found an Option, not an argument
> if (getOptions().hasOption(str) && str.startsWith("-"))
> {
> iter.previous();
> break;
> }
> // found a value
> try
> {
>
> opt.addValueForProcessing(Util.stripLeadingAndTrailingQuotes(str));
> }
> catch (RuntimeException exp)
> {
> iter.previous();
> break;
> }
> }
> if (opt.getValues() == null && !opt.hasOptionalArg())
> {
> throw new MissingArgumentException(opt);
> }
> }
> {code}
> In my opinion, if a value separator is defined for option, and is other than
> space (' '), loop should break immediately after one iteration.
> Correct me, if I am wrong in my understanding.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[GitHub] commons-lang issue #238: Validate's String.format without arguments
Github user PascalSchumacher commented on the issue: https://github.com/apache/commons-lang/pull/238 Yes, currently the user has to escape single `%`s in the error message with `%%`. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (LANG-1312) LocaleUtils#toLocale does not support language followed by UN M.49 numeric-3 area code
[
https://issues.apache.org/jira/browse/LANG-1312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15874168#comment-15874168
]
ASF GitHub Bot commented on LANG-1312:
--
Github user PascalSchumacher commented on the issue:
https://github.com/apache/commons-lang/pull/239
@kinow: Thanks for the review. :-)
I also did not know about UN M.49 till yesterday. I just stumbled over this
while analyzing commons-lang test failures on java 9 for
https://issues.apache.org/jira/browse/LANG-1265
> LocaleUtils#toLocale does not support language followed by UN M.49 numeric-3
> area code
> --
>
> Key: LANG-1312
> URL: https://issues.apache.org/jira/browse/LANG-1312
> Project: Commons Lang
> Issue Type: Bug
>Affects Versions: 3.5
>Reporter: Pascal Schumacher
>Priority: Minor
>
> These all work:
> {code:java}
> System.out.println(new Locale("en", "001"));
> System.out.println(new Locale("en", "150"));
> System.out.println(new Locale("ar", "001"));
> {code}
> but these all fail with an IllegalArgumentException:
> {code:java}
> System.out.println(LocaleUtils.toLocale("en_001"));
> System.out.println(LocaleUtils.toLocale("en_150"));
> System.out.println(LocaleUtils.toLocale("ar_001"));
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
