[jira] [Closed] (LANG-1354) FieldUtils should ignore any synthetic fields

[Charles Honton (JIRA)]

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

Charles Honton closed LANG-1354.

Resolution: Fixed

> FieldUtils should ignore any synthetic fields
> -
>
> Key: LANG-1354
> URL: https://issues.apache.org/jira/browse/LANG-1354
> Project: Commons Lang
>  Issue Type: Improvement
>Reporter: Yegor Koldov
>Assignee: Charles Honton
>Priority: Minor
>
> For my opinion [FieldUtils.getAllFieldsList | 
> https://github.com/apache/commons-lang/blob/release/src/main/java/org/apache/commons/lang3/reflect/FieldUtils.java#L212]
>  should ignore any synthetic fileds (Jacoco for ex.)
> If you agree with that, i could prepaire PR on github



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Reopened] (LANG-1354) FieldUtils should ignore any synthetic fields

[Charles Honton (JIRA)]

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

Charles Honton reopened LANG-1354:
--

> FieldUtils should ignore any synthetic fields
> -
>
> Key: LANG-1354
> URL: https://issues.apache.org/jira/browse/LANG-1354
> Project: Commons Lang
>  Issue Type: Improvement
>Reporter: Yegor Koldov
>Assignee: Charles Honton
>Priority: Minor
>
> For my opinion [FieldUtils.getAllFieldsList | 
> https://github.com/apache/commons-lang/blob/release/src/main/java/org/apache/commons/lang3/reflect/FieldUtils.java#L212]
>  should ignore any synthetic fileds (Jacoco for ex.)
> If you agree with that, i could prepaire PR on github



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (LANG-1354) FieldUtils should ignore any synthetic fields

[Charles Honton (JIRA)]

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

Charles Honton closed LANG-1354.

Resolution: Fixed
  Assignee: Charles Honton

> FieldUtils should ignore any synthetic fields
> -
>
> Key: LANG-1354
> URL: https://issues.apache.org/jira/browse/LANG-1354
> Project: Commons Lang
>  Issue Type: Improvement
>Reporter: Yegor Koldov
>Assignee: Charles Honton
>Priority: Minor
>
> For my opinion [FieldUtils.getAllFieldsList | 
> https://github.com/apache/commons-lang/blob/release/src/main/java/org/apache/commons/lang3/reflect/FieldUtils.java#L212]
>  should ignore any synthetic fileds (Jacoco for ex.)
> If you agree with that, i could prepaire PR on github



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (RNG-37) Ziggurat algorithm

[OlgaK (JIRA)]

[ 
https://issues.apache.org/jira/browse/RNG-37?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16199556#comment-16199556
 ] 

OlgaK edited comment on RNG-37 at 10/10/17 11:28 PM:
-

Gilles, are you trying to pull it from 
https://github.com/apache/commons-rng/pull/5 (this is the last one)? In my case 
it works smoothly, no conflicts
{noformat}
git pull https://github.com/cur4so/commons-rng.git
>From https://github.com/cur4so/commons-rng
 * branchHEAD   -> FETCH_HEAD
Already up-to-date.
{noformat}
and on the github site it points that there are no conflicts. 
I've changed `fixes` on `Javadoc`



was (Author: cur4so):
Gilles, are you trying to pull it from 
https://github.com/apache/commons-rng/pull/5 (this is the last one)? In my case 
it works smoothly, no conflicts
{noformat}
git pull https://github.com/cur4so/commons-rng.git
>From https://github.com/cur4so/commons-rng
 \* branchHEAD   -> FETCH_HEAD
Already up-to-date.
{noformat}
and on the github site it points that there are no conflicts. 
I've changed `fixes` on `Javadoc`


> Ziggurat algorithm
> --
>
> Key: RNG-37
> URL: https://issues.apache.org/jira/browse/RNG-37
> Project: Commons RNG
>  Issue Type: Wish
>Reporter: Gilles
>Priority: Minor
>
> Fast algorithm for sampling a Gaussian distribution: 
> https://en.wikipedia.org/wiki/Ziggurat_algorithm



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (RNG-37) Ziggurat algorithm

[OlgaK (JIRA)]

[ 
https://issues.apache.org/jira/browse/RNG-37?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16199556#comment-16199556
 ] 

OlgaK edited comment on RNG-37 at 10/10/17 11:28 PM:
-

Gilles, are you trying to pull it from 
https://github.com/apache/commons-rng/pull/5 (this is the last one)? In my case 
it works smoothly, no conflicts
{noformat}
git pull https://github.com/cur4so/commons-rng.git
>From https://github.com/cur4so/commons-rng
 \* branchHEAD   -> FETCH_HEAD
Already up-to-date.
{noformat}
and on the github site it points that there are no conflicts. 
I've changed `fixes` on `Javadoc`



was (Author: cur4so):
Gilles, are you trying to pull it from 
https://github.com/apache/commons-rng/pull/5 (this is the last one)? In my case 
it works smoothly, no conflicts
```
git pull https://github.com/cur4so/commons-rng.git
>From https://github.com/cur4so/commons-rng
 \* branchHEAD   -> FETCH_HEAD
Already up-to-date.
```
and on the github site it points that there are no conflicts. 
I've changed `fixes` on `Javadoc`


> Ziggurat algorithm
> --
>
> Key: RNG-37
> URL: https://issues.apache.org/jira/browse/RNG-37
> Project: Commons RNG
>  Issue Type: Wish
>Reporter: Gilles
>Priority: Minor
>
> Fast algorithm for sampling a Gaussian distribution: 
> https://en.wikipedia.org/wiki/Ziggurat_algorithm



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (RNG-37) Ziggurat algorithm

[OlgaK (JIRA)]

[ 
https://issues.apache.org/jira/browse/RNG-37?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16199556#comment-16199556
 ] 

OlgaK edited comment on RNG-37 at 10/10/17 11:26 PM:
-

Gilles, are you trying to pull it from 
https://github.com/apache/commons-rng/pull/5 (this is the last one)? In my case 
it works smoothly, no conflicts
```
git pull https://github.com/cur4so/commons-rng.git
>From https://github.com/cur4so/commons-rng
 \* branchHEAD   -> FETCH_HEAD
Already up-to-date.
```
and on the github site it points that there are no conflicts. 
I've changed `fixes` on `Javadoc`



was (Author: cur4so):
Gilles, are you trying to pull it from 
https://github.com/apache/commons-rng/pull/5 (this is the last one)? In my case 
it works smoothly, no conflicts
```git pull https://github.com/cur4so/commons-rng.git
>From https://github.com/cur4so/commons-rng
 \* branchHEAD   -> FETCH_HEAD
Already up-to-date.```
and on the github site it points that there are no conflicts. 
I've changed `fixes` on `Javadoc`


> Ziggurat algorithm
> --
>
> Key: RNG-37
> URL: https://issues.apache.org/jira/browse/RNG-37
> Project: Commons RNG
>  Issue Type: Wish
>Reporter: Gilles
>Priority: Minor
>
> Fast algorithm for sampling a Gaussian distribution: 
> https://en.wikipedia.org/wiki/Ziggurat_algorithm



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (RNG-37) Ziggurat algorithm

[OlgaK (JIRA)]

[ 
https://issues.apache.org/jira/browse/RNG-37?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16199556#comment-16199556
 ] 

OlgaK edited comment on RNG-37 at 10/10/17 11:25 PM:
-

Gilles, are you trying to pull it from 
https://github.com/apache/commons-rng/pull/5 (this is the last one)? In my case 
it works smoothly, no conflicts
```git pull https://github.com/cur4so/commons-rng.git
>From https://github.com/cur4so/commons-rng
 \* branchHEAD   -> FETCH_HEAD
Already up-to-date.```
and on the github site it points that there are no conflicts. 
I've changed `fixes` on `Javadoc`



was (Author: cur4so):
Gilles, are you trying to pull it from 
https://github.com/apache/commons-rng/pull/5 (this is the last one)? In my case 
it works smoothly, no conflicts
```git pull https://github.com/cur4so/commons-rng.git
>From https://github.com/cur4so/commons-rng
 * branchHEAD   -> FETCH_HEAD
Already up-to-date.```
and on the github site it points that there are no conflicts. 
I've changed `fixes` on `Javadoc`


> Ziggurat algorithm
> --
>
> Key: RNG-37
> URL: https://issues.apache.org/jira/browse/RNG-37
> Project: Commons RNG
>  Issue Type: Wish
>Reporter: Gilles
>Priority: Minor
>
> Fast algorithm for sampling a Gaussian distribution: 
> https://en.wikipedia.org/wiki/Ziggurat_algorithm



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (RNG-37) Ziggurat algorithm

[OlgaK (JIRA)]

[ 
https://issues.apache.org/jira/browse/RNG-37?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16199556#comment-16199556
 ] 

OlgaK commented on RNG-37:
--

Gilles, are you trying to pull it from 
https://github.com/apache/commons-rng/pull/5 (this is the last one)? In my case 
it works smoothly, no conflicts
```git pull https://github.com/cur4so/commons-rng.git
>From https://github.com/cur4so/commons-rng
 * branchHEAD   -> FETCH_HEAD
Already up-to-date.```
and on the github site it points that there are no conflicts. 
I've changed `fixes` on `Javadoc`


> Ziggurat algorithm
> --
>
> Key: RNG-37
> URL: https://issues.apache.org/jira/browse/RNG-37
> Project: Commons RNG
>  Issue Type: Wish
>Reporter: Gilles
>Priority: Minor
>
> Fast algorithm for sampling a Gaussian distribution: 
> https://en.wikipedia.org/wiki/Ziggurat_algorithm



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (DAEMON-374) Add support for Java 9 command-line arguments

[Gary Gregory (JIRA)]

[ 
https://issues.apache.org/jira/browse/DAEMON-374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16199532#comment-16199532
 ] 

Gary Gregory commented on DAEMON-374:
-

Patches welcome! :-)

> Add support for Java 9 command-line arguments
> -
>
> Key: DAEMON-374
> URL: https://issues.apache.org/jira/browse/DAEMON-374
> Project: Commons Daemon
>  Issue Type: Bug
>  Components: Jsvc
>Affects Versions: 1.0.15
>Reporter: Evgenij Ryazanov
>
> Add support for new command-line arguments
> --add-modules
> --add-exports
> --add-opens
> --patch-module
> and others.
> For example, Apache Tomcat cannot clean memory buffers without
> --add-exports java.base/jdk.internal.ref=ALL-UNNAMED
> and assorted additional parameters are required for some existing web 
> applications.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (DBUTILS-112) Provide DbUtils.rollbackQuietly() method

[Gary Gregory (JIRA)]

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

Gary Gregory updated DBUTILS-112:
-
Fix Version/s: (was: 1.7)
   2.0

> Provide DbUtils.rollbackQuietly() method
> 
>
> Key: DBUTILS-112
> URL: https://issues.apache.org/jira/browse/DBUTILS-112
> Project: Commons DbUtils
>  Issue Type: Wish
>Affects Versions: 1.5
>Reporter: alexander brack
>Priority: Trivial
>  Labels: features
> Fix For: 2.0
>
> Attachments: DBUTILS-112.patch
>
>   Original Estimate: 5m
>  Remaining Estimate: 5m
>
> One has to surround DbUtils.rollback(conn) method-call with try/catch wich 
> produces cluttered code. Connection has to remain open, that's why 
> DbUtils.rollbackAndCloseQuietly(conn) method is ruled out.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (DBUTILS-124) Introduce SPI to add more column, property handlers

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/DBUTILS-124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16199512#comment-16199512
 ] 

ASF GitHub Bot commented on DBUTILS-124:


Github user garydgregory commented on the issue:

https://github.com/apache/commons-dbutils/pull/3
  
I created https://issues.apache.org/jira/browse/DBUTILS-135 to track this 
fix. Committed to git master.


> Introduce SPI to add more column, property handlers
> ---
>
> Key: DBUTILS-124
> URL: https://issues.apache.org/jira/browse/DBUTILS-124
> Project: Commons DbUtils
>  Issue Type: New Feature
>Reporter: Carl Hall
>Assignee: Carl Hall
> Fix For: 1.7
>
>
> The column types and property types handled by {{BeanProcessor}} are hard 
> coded to the processor.  We already use a common return type, so we could add 
> a services approach using the spi built into the jdk.  This should also allow 
> other types to be handled outside of {{commons-dbutils}}.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (DBUTILS-135) BeanProcessor is not thread safe since [DBUTILS-124]

[Gary Gregory (JIRA)]

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

Gary Gregory resolved DBUTILS-135.
--
   Resolution: Fixed
Fix Version/s: 2.0

Fixed in git master.

> BeanProcessor is not thread safe since [DBUTILS-124]
> 
>
> Key: DBUTILS-135
> URL: https://issues.apache.org/jira/browse/DBUTILS-135
> Project: Commons DbUtils
>  Issue Type: Bug
>Affects Versions: Nightly Builds
>Reporter: Gary Gregory
> Fix For: 2.0
>
>
> BeanProcessor is not thread safe since [DBUTILS-124].



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (RNG-37) Ziggurat algorithm

[Gilles (JIRA)]

[ 
https://issues.apache.org/jira/browse/RNG-37?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16199505#comment-16199505
 ] 

Gilles commented on RNG-37:
---

{{git}} reports a conflict when I try to pull the latest set of changes ("fixes 
3"):
{noformat}
You have unmerged paths.
  (fix conflicts and run "git commit")
  (use "git merge --abort" to abort the merge)

Unmerged paths:
  (use "git add ..." to mark resolution)

both added:  
commons-rng-sampling/src/main/java/org/apache/commons/rng/sampling/distribution/ZigguratGaussianSampler.java
{noformat}

By the way, Olga, the log must be useful for later review; a message like 
"fixes" is useless.  If the change has improved the Javadoc; the message can 
just be "Javadoc"; if it fixes problems signaled by a reporting tool, the 
message would be like "Avoid warning from " etc.  If the code is 
modified in a non-obvious, it's always nice to summarize the changes for the 
log.


> Ziggurat algorithm
> --
>
> Key: RNG-37
> URL: https://issues.apache.org/jira/browse/RNG-37
> Project: Commons RNG
>  Issue Type: Wish
>Reporter: Gilles
>Priority: Minor
>
> Fast algorithm for sampling a Gaussian distribution: 
> https://en.wikipedia.org/wiki/Ziggurat_algorithm



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (DBUTILS-135) BeanProcessor is not thread safe since [DBUTILS-124]

[Gary Gregory (JIRA)]

Gary Gregory created DBUTILS-135:


 Summary: BeanProcessor is not thread safe since [DBUTILS-124]
 Key: DBUTILS-135
 URL: https://issues.apache.org/jira/browse/DBUTILS-135
 Project: Commons DbUtils
  Issue Type: Bug
Affects Versions: Nightly Builds
Reporter: Gary Gregory


BeanProcessor is not thread safe since [DBUTILS-124].



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] commons-lang pull request #299: Add module-info for Java 9

[stokito]

Github user stokito commented on a diff in the pull request:

https://github.com/apache/commons-lang/pull/299#discussion_r143869192
  
--- Diff: .travis.yml ---
@@ -17,12 +17,10 @@ language: java
 sudo: false
 
 jdk:
-  - openjdk7
--- End diff --

Why did you removed the build for jdk7 and 8?
If lang3 still support them then it should be runned tests on 7 and 8


---

[jira] [Commented] (DBUTILS-124) Introduce SPI to add more column, property handlers

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/DBUTILS-124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16199258#comment-16199258
 ] 

ASF GitHub Bot commented on DBUTILS-124:


Github user hdevalke commented on a diff in the pull request:

https://github.com/apache/commons-dbutils/pull/3#discussion_r143833029
  
--- Diff: src/main/java/org/apache/commons/dbutils/BeanProcessor.java ---
@@ -65,19 +65,21 @@
  */
 private static final Map primitiveDefaults = new 
HashMap();
 
-/**
- * ServiceLoader to find ColumnHandler implementations on 
the classpath.  The iterator for this is
- * lazy and each time iterator() is called.
- */
-// FIXME: I think this instantiates new handlers on each iterator() 
call. This might be worth caching upfront.
-private static final ServiceLoader columnHandlers = 
ServiceLoader.load(ColumnHandler.class);
+private static final List columnHandlers = new 
ArrayList();
 
-/**
- * ServiceLoader to find PropertyHandler implementations 
on the classpath.  The iterator for this is
- * lazy and each time iterator() is called.
- */
-// FIXME: I think this instantiates new handlers on each iterator() 
call. This might be worth caching upfront.
-private static final ServiceLoader propertyHandlers = 
ServiceLoader.load(PropertyHandler.class);
+static{
+for (ColumnHandler h : ServiceLoader.load(ColumnHandler.class)) {
+columnHandlers.add(h);
+}
+}
+
+private static final List propertyHandlers = new 
ArrayList();
+
+static {
+for (PropertyHandler h : 
ServiceLoader.load(PropertyHandler.class)) {
+propertyHandlers.add(h);
--- End diff --

I didn't see there was already a static block initializing 
`primitiveDefaults`. I find it more readable initializing each static variable 
in their own block. I did an update and put all in one static block.


> Introduce SPI to add more column, property handlers
> ---
>
> Key: DBUTILS-124
> URL: https://issues.apache.org/jira/browse/DBUTILS-124
> Project: Commons DbUtils
>  Issue Type: New Feature
>Reporter: Carl Hall
>Assignee: Carl Hall
> Fix For: 1.7
>
>
> The column types and property types handled by {{BeanProcessor}} are hard 
> coded to the processor.  We already use a common return type, so we could add 
> a services approach using the spi built into the jdk.  This should also allow 
> other types to be handled outside of {{commons-dbutils}}.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (DBUTILS-124) Introduce SPI to add more column, property handlers

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/DBUTILS-124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16199193#comment-16199193
 ] 

ASF GitHub Bot commented on DBUTILS-124:


Github user garydgregory commented on a diff in the pull request:

https://github.com/apache/commons-dbutils/pull/3#discussion_r143822953
  
--- Diff: src/main/java/org/apache/commons/dbutils/BeanProcessor.java ---
@@ -65,19 +65,21 @@
  */
 private static final Map primitiveDefaults = new 
HashMap();
 
-/**
- * ServiceLoader to find ColumnHandler implementations on 
the classpath.  The iterator for this is
- * lazy and each time iterator() is called.
- */
-// FIXME: I think this instantiates new handlers on each iterator() 
call. This might be worth caching upfront.
-private static final ServiceLoader columnHandlers = 
ServiceLoader.load(ColumnHandler.class);
+private static final List columnHandlers = new 
ArrayList();
 
-/**
- * ServiceLoader to find PropertyHandler implementations 
on the classpath.  The iterator for this is
- * lazy and each time iterator() is called.
- */
-// FIXME: I think this instantiates new handlers on each iterator() 
call. This might be worth caching upfront.
-private static final ServiceLoader propertyHandlers = 
ServiceLoader.load(PropertyHandler.class);
+static{
+for (ColumnHandler h : ServiceLoader.load(ColumnHandler.class)) {
+columnHandlers.add(h);
+}
+}
+
+private static final List propertyHandlers = new 
ArrayList();
+
+static {
+for (PropertyHandler h : 
ServiceLoader.load(PropertyHandler.class)) {
+propertyHandlers.add(h);
--- End diff --

I think of it the other way around: Why use two blocks when you could use 
one?


> Introduce SPI to add more column, property handlers
> ---
>
> Key: DBUTILS-124
> URL: https://issues.apache.org/jira/browse/DBUTILS-124
> Project: Commons DbUtils
>  Issue Type: New Feature
>Reporter: Carl Hall
>Assignee: Carl Hall
> Fix For: 1.7
>
>
> The column types and property types handled by {{BeanProcessor}} are hard 
> coded to the processor.  We already use a common return type, so we could add 
> a services approach using the spi built into the jdk.  This should also allow 
> other types to be handled outside of {{commons-dbutils}}.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (DBUTILS-124) Introduce SPI to add more column, property handlers

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/DBUTILS-124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16199166#comment-16199166
 ] 

ASF GitHub Bot commented on DBUTILS-124:


Github user hdevalke commented on a diff in the pull request:

https://github.com/apache/commons-dbutils/pull/3#discussion_r143818665
  
--- Diff: src/main/java/org/apache/commons/dbutils/BeanProcessor.java ---
@@ -65,19 +65,21 @@
  */
 private static final Map primitiveDefaults = new 
HashMap();
 
-/**
- * ServiceLoader to find ColumnHandler implementations on 
the classpath.  The iterator for this is
- * lazy and each time iterator() is called.
- */
-// FIXME: I think this instantiates new handlers on each iterator() 
call. This might be worth caching upfront.
-private static final ServiceLoader columnHandlers = 
ServiceLoader.load(ColumnHandler.class);
+private static final List columnHandlers = new 
ArrayList();
 
-/**
- * ServiceLoader to find PropertyHandler implementations 
on the classpath.  The iterator for this is
- * lazy and each time iterator() is called.
- */
-// FIXME: I think this instantiates new handlers on each iterator() 
call. This might be worth caching upfront.
-private static final ServiceLoader propertyHandlers = 
ServiceLoader.load(PropertyHandler.class);
+static{
+for (ColumnHandler h : ServiceLoader.load(ColumnHandler.class)) {
+columnHandlers.add(h);
+}
+}
+
+private static final List propertyHandlers = new 
ArrayList();
+
+static {
+for (PropertyHandler h : 
ServiceLoader.load(PropertyHandler.class)) {
+propertyHandlers.add(h);
--- End diff --

Can you explain why that is problematic?


> Introduce SPI to add more column, property handlers
> ---
>
> Key: DBUTILS-124
> URL: https://issues.apache.org/jira/browse/DBUTILS-124
> Project: Commons DbUtils
>  Issue Type: New Feature
>Reporter: Carl Hall
>Assignee: Carl Hall
> Fix For: 1.7
>
>
> The column types and property types handled by {{BeanProcessor}} are hard 
> coded to the processor.  We already use a common return type, so we could add 
> a services approach using the spi built into the jdk.  This should also allow 
> other types to be handled outside of {{commons-dbutils}}.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (DBUTILS-124) Introduce SPI to add more column, property handlers

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/DBUTILS-124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16199145#comment-16199145
 ] 

ASF GitHub Bot commented on DBUTILS-124:


Github user garydgregory commented on a diff in the pull request:

https://github.com/apache/commons-dbutils/pull/3#discussion_r143814271
  
--- Diff: src/main/java/org/apache/commons/dbutils/BeanProcessor.java ---
@@ -65,19 +65,21 @@
  */
 private static final Map primitiveDefaults = new 
HashMap();
 
-/**
- * ServiceLoader to find ColumnHandler implementations on 
the classpath.  The iterator for this is
- * lazy and each time iterator() is called.
- */
-// FIXME: I think this instantiates new handlers on each iterator() 
call. This might be worth caching upfront.
-private static final ServiceLoader columnHandlers = 
ServiceLoader.load(ColumnHandler.class);
+private static final List columnHandlers = new 
ArrayList();
 
-/**
- * ServiceLoader to find PropertyHandler implementations 
on the classpath.  The iterator for this is
- * lazy and each time iterator() is called.
- */
-// FIXME: I think this instantiates new handlers on each iterator() 
call. This might be worth caching upfront.
-private static final ServiceLoader propertyHandlers = 
ServiceLoader.load(PropertyHandler.class);
+static{
+for (ColumnHandler h : ServiceLoader.load(ColumnHandler.class)) {
+columnHandlers.add(h);
+}
+}
+
+private static final List propertyHandlers = new 
ArrayList();
+
+static {
+for (PropertyHandler h : 
ServiceLoader.load(PropertyHandler.class)) {
+propertyHandlers.add(h);
--- End diff --

What not use a single static block?


> Introduce SPI to add more column, property handlers
> ---
>
> Key: DBUTILS-124
> URL: https://issues.apache.org/jira/browse/DBUTILS-124
> Project: Commons DbUtils
>  Issue Type: New Feature
>Reporter: Carl Hall
>Assignee: Carl Hall
> Fix For: 1.7
>
>
> The column types and property types handled by {{BeanProcessor}} are hard 
> coded to the processor.  We already use a common return type, so we could add 
> a services approach using the spi built into the jdk.  This should also allow 
> other types to be handled outside of {{commons-dbutils}}.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] commons-lang issue #299: Add module-info for Java 9

[britter]

Github user britter commented on the issue:

https://github.com/apache/commons-lang/pull/299
  
Awesome! Would be create if you could create and reference a JIRA ticket as 
described in CONTRIBUTING.md, so this will show up in our release notes.


---

[jira] [Commented] (BCEL-296) Incorrect comment in several classes.

[Mark Roberts (JIRA)]

[ 
https://issues.apache.org/jira/browse/BCEL-296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16199103#comment-16199103
 ] 

Mark Roberts commented on BCEL-296:
---

ok - will try to set up a PR next week.

> Incorrect comment in several classes.
> -
>
> Key: BCEL-296
> URL: https://issues.apache.org/jira/browse/BCEL-296
> Project: Commons BCEL
>  Issue Type: Improvement
>Reporter: Mark Roberts
>Priority: Trivial
>
> There are 70 odd classes in the generic directory that have empty 
> constructors with the following comment:
>  * Empty constructor needed for the Class.newInstance() statement in
>  * Instruction.readInstruction(). Not to be used otherwise.
> Class.newInstance() is no longer called, the empty constructors are 
> referenced directly.  Perhaps the comment should just read:
>  * Empty constructor needed Instruction.readInstruction(). 
>  * Not to be used otherwise.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (BCEL-296) Incorrect comment in several classes.

[Gary Gregory (JIRA)]

[ 
https://issues.apache.org/jira/browse/BCEL-296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16199090#comment-16199090
 ] 

Gary Gregory commented on BCEL-296:
---

Patches welcome! :-)

> Incorrect comment in several classes.
> -
>
> Key: BCEL-296
> URL: https://issues.apache.org/jira/browse/BCEL-296
> Project: Commons BCEL
>  Issue Type: Improvement
>Reporter: Mark Roberts
>Priority: Trivial
>
> There are 70 odd classes in the generic directory that have empty 
> constructors with the following comment:
>  * Empty constructor needed for the Class.newInstance() statement in
>  * Instruction.readInstruction(). Not to be used otherwise.
> Class.newInstance() is no longer called, the empty constructors are 
> referenced directly.  Perhaps the comment should just read:
>  * Empty constructor needed Instruction.readInstruction(). 
>  * Not to be used otherwise.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (BCEL-296) Incorrect comment in several classes.

[Gary Gregory (JIRA)]

[ 
https://issues.apache.org/jira/browse/BCEL-296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16199090#comment-16199090
 ] 

Gary Gregory edited comment on BCEL-296 at 10/10/17 6:00 PM:
-

Patches or GitHub PRs welcome! :-)


was (Author: garydgregory):
Patches welcome! :-)

> Incorrect comment in several classes.
> -
>
> Key: BCEL-296
> URL: https://issues.apache.org/jira/browse/BCEL-296
> Project: Commons BCEL
>  Issue Type: Improvement
>Reporter: Mark Roberts
>Priority: Trivial
>
> There are 70 odd classes in the generic directory that have empty 
> constructors with the following comment:
>  * Empty constructor needed for the Class.newInstance() statement in
>  * Instruction.readInstruction(). Not to be used otherwise.
> Class.newInstance() is no longer called, the empty constructors are 
> referenced directly.  Perhaps the comment should just read:
>  * Empty constructor needed Instruction.readInstruction(). 
>  * Not to be used otherwise.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (LANG-1355) TimeZone.getTimeZone() in FastDateParser causes resource contention

[Gary Gregory (JIRA)]

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

Gary Gregory resolved LANG-1355.

   Resolution: Fixed
Fix Version/s: 3.7

In git master, please verify and close.

> TimeZone.getTimeZone() in FastDateParser causes resource contention
> ---
>
> Key: LANG-1355
> URL: https://issues.apache.org/jira/browse/LANG-1355
> Project: Commons Lang
>  Issue Type: Bug
>  Components: lang.time.*
>Affects Versions: 3.6
> Environment: Windows
>Reporter: Keith Boone
>Assignee: Charles Honton
> Fix For: 3.7
>
>   Original Estimate: 48h
>  Remaining Estimate: 48h
>
> Under heavy load we are seeing contention in FastDateParser.parse() on calls 
> to TimeZone.getTimeZone().  TimeZone.getTimeZone() is a synchronized static 
> in the Oracle JVM.
> Our proposed solution is to add a class TimeZoneCache containing a single 
> method getTimeZone() which gets the requested time zone from a ConcurrentMap, 
> and if not present, looks it up via TimeZone.getTimeZone() and caches it 
> before returning it.
> Then replace calls to TimeZone.getTimeZone() in FastDateParser ( and 
> whereever else) to calls to TimeZoneCache.getTimeZone().  
> The reason to add a separate class is because it can also be used by other 
> applications which heavily parse or format or do other things where TimeZone 
> is repeatedly needed.
> Under extreme load we have seen an 50:1 improvement in calls to 
> FastDateParser.parse().  This saves about a ms/call in our test environment, 
> and reduces contention.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (BCEL-297) Incorrect override implementation of Object.equals

[Mark Roberts (JIRA)]

Mark Roberts created BCEL-297:
-

 Summary: Incorrect override implementation of Object.equals
 Key: BCEL-297
 URL: https://issues.apache.org/jira/browse/BCEL-297
 Project: Commons BCEL
  Issue Type: Bug
Reporter: Mark Roberts
Priority: Minor


classfile/JavaClass.java: 
classfile/Field.java: 
classfile/Constant.java:  
classfile/Method.java:  
generic/FieldGen.java:   
generic/MethodGen.java:  

all define a bcelComparator that overrides Object.equals.  However, they will 
throw a null pointer exception for myConstant.equals(null) instead of returning 
false.  This non-standard behavior should either be corrected or documented.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (LANG-1355) TimeZone.getTimeZone() in FastDateParser causes resource contention

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/LANG-1355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16199086#comment-16199086
 ] 

ASF GitHub Bot commented on LANG-1355:
--

Github user asfgit closed the pull request at:

https://github.com/apache/commons-lang/pull/296


> TimeZone.getTimeZone() in FastDateParser causes resource contention
> ---
>
> Key: LANG-1355
> URL: https://issues.apache.org/jira/browse/LANG-1355
> Project: Commons Lang
>  Issue Type: Bug
>  Components: lang.time.*
>Affects Versions: 3.6
> Environment: Windows
>Reporter: Keith Boone
>Assignee: Charles Honton
>   Original Estimate: 48h
>  Remaining Estimate: 48h
>
> Under heavy load we are seeing contention in FastDateParser.parse() on calls 
> to TimeZone.getTimeZone().  TimeZone.getTimeZone() is a synchronized static 
> in the Oracle JVM.
> Our proposed solution is to add a class TimeZoneCache containing a single 
> method getTimeZone() which gets the requested time zone from a ConcurrentMap, 
> and if not present, looks it up via TimeZone.getTimeZone() and caches it 
> before returning it.
> Then replace calls to TimeZone.getTimeZone() in FastDateParser ( and 
> whereever else) to calls to TimeZoneCache.getTimeZone().  
> The reason to add a separate class is because it can also be used by other 
> applications which heavily parse or format or do other things where TimeZone 
> is repeatedly needed.
> Under extreme load we have seen an 50:1 improvement in calls to 
> FastDateParser.parse().  This saves about a ms/call in our test environment, 
> and reduces contention.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] commons-lang pull request #296: LANG-1355: Add FastTimeZone to decrease Time...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/commons-lang/pull/296


---

[jira] [Commented] (LANG-1355) TimeZone.getTimeZone() in FastDateParser causes resource contention

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/LANG-1355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16199076#comment-16199076
 ] 

ASF GitHub Bot commented on LANG-1355:
--

Github user garydgregory commented on a diff in the pull request:

https://github.com/apache/commons-lang/pull/296#discussion_r143804862
  
--- Diff: src/main/java/org/apache/commons/lang3/time/FastTimeZone.java ---
@@ -0,0 +1,95 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements.  See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License.  You may obtain a copy of the License at
+ *
+ *  http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.commons.lang3.time;
+
+import java.util.TimeZone;
+import java.util.regex.Matcher;
+import java.util.regex.Pattern;
+
+/**
+ * Faster methods to produce custom time zones.
+ *
+ * @since 3.7
+ */
+public class FastTimeZone {
+
+private static final TimeZone GREENWICH = new GmtTimeZone(false, 0, 0);
+
+// do not instantiate
+private FastTimeZone() {
+}
+
+/**
+ * Get the GMT TimeZone.
+ * @return A TimeZone with a raw offset of zero.
+ */
+public static TimeZone getGmtTimeZone() {
+return GREENWICH;
+}
+
+/**
+ * Get a TimeZone, looking first for GMT custom ids, then falling back 
to Olson ids.
--- End diff --

In future patches, you can use the active voice for Javadocs: "Gets a 
TimeZone..." instead of "Get...". :-)


> TimeZone.getTimeZone() in FastDateParser causes resource contention
> ---
>
> Key: LANG-1355
> URL: https://issues.apache.org/jira/browse/LANG-1355
> Project: Commons Lang
>  Issue Type: Bug
>  Components: lang.time.*
>Affects Versions: 3.6
> Environment: Windows
>Reporter: Keith Boone
>Assignee: Charles Honton
>   Original Estimate: 48h
>  Remaining Estimate: 48h
>
> Under heavy load we are seeing contention in FastDateParser.parse() on calls 
> to TimeZone.getTimeZone().  TimeZone.getTimeZone() is a synchronized static 
> in the Oracle JVM.
> Our proposed solution is to add a class TimeZoneCache containing a single 
> method getTimeZone() which gets the requested time zone from a ConcurrentMap, 
> and if not present, looks it up via TimeZone.getTimeZone() and caches it 
> before returning it.
> Then replace calls to TimeZone.getTimeZone() in FastDateParser ( and 
> whereever else) to calls to TimeZoneCache.getTimeZone().  
> The reason to add a separate class is because it can also be used by other 
> applications which heavily parse or format or do other things where TimeZone 
> is repeatedly needed.
> Under extreme load we have seen an 50:1 improvement in calls to 
> FastDateParser.parse().  This saves about a ms/call in our test environment, 
> and reduces contention.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] commons-lang pull request #296: LANG-1355: Add FastTimeZone to decrease Time...

[garydgregory]

Github user garydgregory commented on a diff in the pull request:

https://github.com/apache/commons-lang/pull/296#discussion_r143804862
  
--- Diff: src/main/java/org/apache/commons/lang3/time/FastTimeZone.java ---
@@ -0,0 +1,95 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements.  See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License.  You may obtain a copy of the License at
+ *
+ *  http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.commons.lang3.time;
+
+import java.util.TimeZone;
+import java.util.regex.Matcher;
+import java.util.regex.Pattern;
+
+/**
+ * Faster methods to produce custom time zones.
+ *
+ * @since 3.7
+ */
+public class FastTimeZone {
+
+private static final TimeZone GREENWICH = new GmtTimeZone(false, 0, 0);
+
+// do not instantiate
+private FastTimeZone() {
+}
+
+/**
+ * Get the GMT TimeZone.
+ * @return A TimeZone with a raw offset of zero.
+ */
+public static TimeZone getGmtTimeZone() {
+return GREENWICH;
+}
+
+/**
+ * Get a TimeZone, looking first for GMT custom ids, then falling back 
to Olson ids.
--- End diff --

In future patches, you can use the active voice for Javadocs: "Gets a 
TimeZone..." instead of "Get...". :-)


---

[jira] [Created] (BCEL-296) Incorrect comment in several classes.

[Mark Roberts (JIRA)]

Mark Roberts created BCEL-296:
-

 Summary: Incorrect comment in several classes.
 Key: BCEL-296
 URL: https://issues.apache.org/jira/browse/BCEL-296
 Project: Commons BCEL
  Issue Type: Improvement
Reporter: Mark Roberts
Priority: Trivial


There are 70 odd classes in the generic directory that have empty constructors 
with the following comment:
 * Empty constructor needed for the Class.newInstance() statement in
 * Instruction.readInstruction(). Not to be used otherwise.

Class.newInstance() is no longer called, the empty constructors are referenced 
directly.  Perhaps the comment should just read:
 * Empty constructor needed Instruction.readInstruction(). 
 * Not to be used otherwise.





--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (BCEL-295) Incorrect live range information in LocalVariableGen

[Mark Roberts (JIRA)]

[ 
https://issues.apache.org/jira/browse/BCEL-295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16199060#comment-16199060
 ] 

Mark Roberts commented on BCEL-295:
---

I might have time to provide a unit test next week.

> Incorrect live range information in LocalVariableGen
> 
>
> Key: BCEL-295
> URL: https://issues.apache.org/jira/browse/BCEL-295
> Project: Commons BCEL
>  Issue Type: Bug
>Reporter: Mark Roberts
> Attachments: LocalVariableGen.diff
>
>
> (Not sure of priority - blocker for me, but probably of little consequence 
> for most clients.)
> There is a design flaw with the treatment of local variable live ranges.  In 
> the .class file these are demarcated via byte code offsets into the method's 
> instructions.  The range is from start up to, but not including, the length. 
> If the live range lasts through the end of the method, then length points to 
> the first byte 'past' the end of the method.  BCEL converts these offsets 
> into InstructionHandles and in doing so can no longer differentiate between a 
> live range that ends prior to the last instruction of the method or one that 
> includes the last instruction of the method.
> How to fix this is a bit of a problem.  The 'correct' solution would seem to 
> be to keep end as a null InstructionHandle as indicated by some of the 
> comments.  Unfortunately, LocalVariableGen does not have access to the 
> method's InstructionList and thus cannot easily convert this null pointer 
> back to the correct length for output.  We could grab the InstructionHandle 
> for start and then count the instruction bytes as we iterate to the end.
> But all this still begs the question of the fact this would be a change in 
> behavior - a client would now have to check for a null end handle before 
> dereferencing.  The proposed fix I have attached takes another approach.  It 
> sets a flag in the constructor if the initial value for end is null and then 
> lets all else proceed unchanged.  A client may test this flag to see if the 
> special case is active.  Also, the getLocalVariable method uses this flag to 
> correctly set the length on output.  
> I believe this approach would have no effect on existing code.  We would only 
> need to document the new flag for clients that might care.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (BCEL-295) Incorrect live range information in LocalVariableGen

[Gary Gregory (JIRA)]

[ 
https://issues.apache.org/jira/browse/BCEL-295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16199046#comment-16199046
 ] 

Gary Gregory commented on BCEL-295:
---

The patch is small and seems OK at first glance but I am not comfortable 
applying without a matching unit test. I do appreciate the low/no impact WRT 
compatibility. That's a plus :-) What do others think?

> Incorrect live range information in LocalVariableGen
> 
>
> Key: BCEL-295
> URL: https://issues.apache.org/jira/browse/BCEL-295
> Project: Commons BCEL
>  Issue Type: Bug
>Reporter: Mark Roberts
> Attachments: LocalVariableGen.diff
>
>
> (Not sure of priority - blocker for me, but probably of little consequence 
> for most clients.)
> There is a design flaw with the treatment of local variable live ranges.  In 
> the .class file these are demarcated via byte code offsets into the method's 
> instructions.  The range is from start up to, but not including, the length. 
> If the live range lasts through the end of the method, then length points to 
> the first byte 'past' the end of the method.  BCEL converts these offsets 
> into InstructionHandles and in doing so can no longer differentiate between a 
> live range that ends prior to the last instruction of the method or one that 
> includes the last instruction of the method.
> How to fix this is a bit of a problem.  The 'correct' solution would seem to 
> be to keep end as a null InstructionHandle as indicated by some of the 
> comments.  Unfortunately, LocalVariableGen does not have access to the 
> method's InstructionList and thus cannot easily convert this null pointer 
> back to the correct length for output.  We could grab the InstructionHandle 
> for start and then count the instruction bytes as we iterate to the end.
> But all this still begs the question of the fact this would be a change in 
> behavior - a client would now have to check for a null end handle before 
> dereferencing.  The proposed fix I have attached takes another approach.  It 
> sets a flag in the constructor if the initial value for end is null and then 
> lets all else proceed unchanged.  A client may test this flag to see if the 
> special case is active.  Also, the getLocalVariable method uses this flag to 
> correctly set the length on output.  
> I believe this approach would have no effect on existing code.  We would only 
> need to document the new flag for clients that might care.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (DBUTILS-124) Introduce SPI to add more column, property handlers

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/DBUTILS-124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16198985#comment-16198985
 ] 

ASF GitHub Bot commented on DBUTILS-124:


Github user thecarlhall commented on the issue:

https://github.com/apache/commons-dbutils/pull/3
  
Thanks, @hdevalke!  Nice catch.  I totally missed that `ServiceLoader` 
isn't thread safe.  I'll work to get this merged into master and cut a new 
release as soon as I can.


> Introduce SPI to add more column, property handlers
> ---
>
> Key: DBUTILS-124
> URL: https://issues.apache.org/jira/browse/DBUTILS-124
> Project: Commons DbUtils
>  Issue Type: New Feature
>Reporter: Carl Hall
>Assignee: Carl Hall
> Fix For: 1.7
>
>
> The column types and property types handled by {{BeanProcessor}} are hard 
> coded to the processor.  We already use a common return type, so we could add 
> a services approach using the spi built into the jdk.  This should also allow 
> other types to be handled outside of {{commons-dbutils}}.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] commons-lang pull request #299: Add module-info for Java 9

[jodastephen]

GitHub user jodastephen opened a pull request:

https://github.com/apache/commons-lang/pull/299

Add module-info for Java 9

Add the module-info.java file
Make the appropriate changes to pom.xml

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/jodastephen/commons-lang module-info

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/commons-lang/pull/299.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #299


commit 8f5aeed9db2ec0fed0e81ebd24a9608d0d4d68d6
Author: Stephen Colebourne 
Date:   2017-10-10T16:56:41Z

Add module-info for Java 9

Add the module-info.java file
Make the appropriate changes to pom.xml




---

[jira] [Commented] (LANG-1355) TimeZone.getTimeZone() in FastDateParser causes resource contention

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/LANG-1355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16198912#comment-16198912
 ] 

ASF GitHub Bot commented on LANG-1355:
--

Github user PascalSchumacher commented on a diff in the pull request:

https://github.com/apache/commons-lang/pull/296#discussion_r143781416
  
--- Diff: src/main/java/org/apache/commons/lang3/time/FastTimeZone.java ---
@@ -39,10 +43,11 @@ public static TimeZone getGmtTimeZone() {
 
 /**
  * Get a TimeZone, looking first for GMT custom ids, then falling back 
to Olson ids.
- * A GMT custom id has an optional prefix of GMT, followed by sign, 
hours digit(s), optional
- * colon(':'), and optional minutes digits: [GMT] (+|-) Hours [[:] 
Minutes]
+ * A GMT custom id can be 'Z', or 'UTC', or has an optional prefix of 
GMT,
+ * followed by sign, hours digit(s), optional colon(':'), and optional 
minutes digits.
+ * i.e. [GMT] (+|-) Hours [[:] Minutes]
  *
- * @param id A GMT custom id or Olsen id
+ * @param id A GMT custom id (or Olson id
--- End diff --

Nitpick: either a superfluous `(` or a missing `)`


> TimeZone.getTimeZone() in FastDateParser causes resource contention
> ---
>
> Key: LANG-1355
> URL: https://issues.apache.org/jira/browse/LANG-1355
> Project: Commons Lang
>  Issue Type: Bug
>  Components: lang.time.*
>Affects Versions: 3.6
> Environment: Windows
>Reporter: Keith Boone
>Assignee: Charles Honton
>   Original Estimate: 48h
>  Remaining Estimate: 48h
>
> Under heavy load we are seeing contention in FastDateParser.parse() on calls 
> to TimeZone.getTimeZone().  TimeZone.getTimeZone() is a synchronized static 
> in the Oracle JVM.
> Our proposed solution is to add a class TimeZoneCache containing a single 
> method getTimeZone() which gets the requested time zone from a ConcurrentMap, 
> and if not present, looks it up via TimeZone.getTimeZone() and caches it 
> before returning it.
> Then replace calls to TimeZone.getTimeZone() in FastDateParser ( and 
> whereever else) to calls to TimeZoneCache.getTimeZone().  
> The reason to add a separate class is because it can also be used by other 
> applications which heavily parse or format or do other things where TimeZone 
> is repeatedly needed.
> Under extreme load we have seen an 50:1 improvement in calls to 
> FastDateParser.parse().  This saves about a ms/call in our test environment, 
> and reduces contention.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] commons-lang pull request #296: LANG-1355: Add FastTimeZone to decrease Time...

[PascalSchumacher]

Github user PascalSchumacher commented on a diff in the pull request:

https://github.com/apache/commons-lang/pull/296#discussion_r143781416
  
--- Diff: src/main/java/org/apache/commons/lang3/time/FastTimeZone.java ---
@@ -39,10 +43,11 @@ public static TimeZone getGmtTimeZone() {
 
 /**
  * Get a TimeZone, looking first for GMT custom ids, then falling back 
to Olson ids.
- * A GMT custom id has an optional prefix of GMT, followed by sign, 
hours digit(s), optional
- * colon(':'), and optional minutes digits: [GMT] (+|-) Hours [[:] 
Minutes]
+ * A GMT custom id can be 'Z', or 'UTC', or has an optional prefix of 
GMT,
+ * followed by sign, hours digit(s), optional colon(':'), and optional 
minutes digits.
+ * i.e. [GMT] (+|-) Hours [[:] Minutes]
  *
- * @param id A GMT custom id or Olsen id
+ * @param id A GMT custom id (or Olson id
--- End diff --

Nitpick: either a superfluous `(` or a missing `)`


---

[jira] [Updated] (BCEL-295) Incorrect live range information in LocalVariableGen

[Mark Roberts (JIRA)]

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

Mark Roberts updated BCEL-295:
--
Attachment: LocalVariableGen.diff

> Incorrect live range information in LocalVariableGen
> 
>
> Key: BCEL-295
> URL: https://issues.apache.org/jira/browse/BCEL-295
> Project: Commons BCEL
>  Issue Type: Bug
>Reporter: Mark Roberts
> Attachments: LocalVariableGen.diff
>
>
> (Not sure of priority - blocker for me, but probably of little consequence 
> for most clients.)
> There is a design flaw with the treatment of local variable live ranges.  In 
> the .class file these are demarcated via byte code offsets into the method's 
> instructions.  The range is from start up to, but not including, the length. 
> If the live range lasts through the end of the method, then length points to 
> the first byte 'past' the end of the method.  BCEL converts these offsets 
> into InstructionHandles and in doing so can no longer differentiate between a 
> live range that ends prior to the last instruction of the method or one that 
> includes the last instruction of the method.
> How to fix this is a bit of a problem.  The 'correct' solution would seem to 
> be to keep end as a null InstructionHandle as indicated by some of the 
> comments.  Unfortunately, LocalVariableGen does not have access to the 
> method's InstructionList and thus cannot easily convert this null pointer 
> back to the correct length for output.  We could grab the InstructionHandle 
> for start and then count the instruction bytes as we iterate to the end.
> But all this still begs the question of the fact this would be a change in 
> behavior - a client would now have to check for a null end handle before 
> dereferencing.  The proposed fix I have attached takes another approach.  It 
> sets a flag in the constructor if the initial value for end is null and then 
> lets all else proceed unchanged.  A client may test this flag to see if the 
> special case is active.  Also, the getLocalVariable method uses this flag to 
> correctly set the length on output.  
> I believe this approach would have no effect on existing code.  We would only 
> need to document the new flag for clients that might care.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (BCEL-295) Incorrect live range information in LocalVariableGen

[Mark Roberts (JIRA)]

Mark Roberts created BCEL-295:
-

 Summary: Incorrect live range information in LocalVariableGen
 Key: BCEL-295
 URL: https://issues.apache.org/jira/browse/BCEL-295
 Project: Commons BCEL
  Issue Type: Bug
Reporter: Mark Roberts


(Not sure of priority - blocker for me, but probably of little consequence for 
most clients.)

There is a design flaw with the treatment of local variable live ranges.  In 
the .class file these are demarcated via byte code offsets into the method's 
instructions.  The range is from start up to, but not including, the length. If 
the live range lasts through the end of the method, then length points to the 
first byte 'past' the end of the method.  BCEL converts these offsets into 
InstructionHandles and in doing so can no longer differentiate between a live 
range that ends prior to the last instruction of the method or one that 
includes the last instruction of the method.

How to fix this is a bit of a problem.  The 'correct' solution would seem to be 
to keep end as a null InstructionHandle as indicated by some of the comments.  
Unfortunately, LocalVariableGen does not have access to the method's 
InstructionList and thus cannot easily convert this null pointer back to the 
correct length for output.  We could grab the InstructionHandle for start and 
then count the instruction bytes as we iterate to the end.

But all this still begs the question of the fact this would be a change in 
behavior - a client would now have to check for a null end handle before 
dereferencing.  The proposed fix I have attached takes another approach.  It 
sets a flag in the constructor if the initial value for end is null and then 
lets all else proceed unchanged.  A client may test this flag to see if the 
special case is active.  Also, the getLocalVariable method uses this flag to 
correctly set the length on output.  

I believe this approach would have no effect on existing code.  We would only 
need to document the new flag for clients that might care.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (LANG-1355) TimeZone.getTimeZone() in FastDateParser causes resource contention

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/LANG-1355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16198762#comment-16198762
 ] 

ASF GitHub Bot commented on LANG-1355:
--

Github user coveralls commented on the issue:

https://github.com/apache/commons-lang/pull/296
  

[![Coverage 
Status](https://coveralls.io/builds/13650527/badge)](https://coveralls.io/builds/13650527)

Coverage decreased (-0.007%) to 95.199% when pulling 
**db5c0a208e26bbae13d1bd4700049e330569aa3b on chonton:LANG-1355** into 
**15d5503215a4cd1efc1ae6659d82194a22ebee9b on apache:master**.



> TimeZone.getTimeZone() in FastDateParser causes resource contention
> ---
>
> Key: LANG-1355
> URL: https://issues.apache.org/jira/browse/LANG-1355
> Project: Commons Lang
>  Issue Type: Bug
>  Components: lang.time.*
>Affects Versions: 3.6
> Environment: Windows
>Reporter: Keith Boone
>Assignee: Charles Honton
>   Original Estimate: 48h
>  Remaining Estimate: 48h
>
> Under heavy load we are seeing contention in FastDateParser.parse() on calls 
> to TimeZone.getTimeZone().  TimeZone.getTimeZone() is a synchronized static 
> in the Oracle JVM.
> Our proposed solution is to add a class TimeZoneCache containing a single 
> method getTimeZone() which gets the requested time zone from a ConcurrentMap, 
> and if not present, looks it up via TimeZone.getTimeZone() and caches it 
> before returning it.
> Then replace calls to TimeZone.getTimeZone() in FastDateParser ( and 
> whereever else) to calls to TimeZoneCache.getTimeZone().  
> The reason to add a separate class is because it can also be used by other 
> applications which heavily parse or format or do other things where TimeZone 
> is repeatedly needed.
> Under extreme load we have seen an 50:1 improvement in calls to 
> FastDateParser.parse().  This saves about a ms/call in our test environment, 
> and reduces contention.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] commons-lang issue #296: LANG-1355: Add FastTimeZone to decrease TimeZone.ge...

[coveralls]

Github user coveralls commented on the issue:

https://github.com/apache/commons-lang/pull/296
  

[![Coverage 
Status](https://coveralls.io/builds/13650527/badge)](https://coveralls.io/builds/13650527)

Coverage decreased (-0.007%) to 95.199% when pulling 
**db5c0a208e26bbae13d1bd4700049e330569aa3b on chonton:LANG-1355** into 
**15d5503215a4cd1efc1ae6659d82194a22ebee9b on apache:master**.



---

[jira] [Commented] (LANG-1355) TimeZone.getTimeZone() in FastDateParser causes resource contention

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/LANG-1355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16198751#comment-16198751
 ] 

ASF GitHub Bot commented on LANG-1355:
--

Github user chonton commented on a diff in the pull request:

https://github.com/apache/commons-lang/pull/296#discussion_r143749105
  
--- Diff: src/test/java/org/apache/commons/lang3/time/GmtTimeZoneTest.java 
---
@@ -0,0 +1,80 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements.  See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License.  You may obtain a copy of the License at
+ *
+ *  http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.commons.lang3.time;
+
+import org.junit.Assert;
+import org.junit.Test;
+
+/**
+ * Tests for GmtTimeZone
+ */
+public class GmtTimeZoneTest {
+
+@Test(expected = IllegalArgumentException.class)
+public void hoursOutOfRange() {
+new GmtTimeZone(false, 24, 0);
+}
+
+@Test
+public void hoursInRange() {
+Assert.assertEquals(23 * 60 * 60 * 1000, new GmtTimeZone(false, 
23, 0).getRawOffset());
+}
+
+@Test(expected = IllegalArgumentException.class)
+public void minutesOutOfRange() {
+Assert.assertEquals(0, new GmtTimeZone(false, 60, 0));
--- End diff --

great catch! thanks.
done.


> TimeZone.getTimeZone() in FastDateParser causes resource contention
> ---
>
> Key: LANG-1355
> URL: https://issues.apache.org/jira/browse/LANG-1355
> Project: Commons Lang
>  Issue Type: Bug
>  Components: lang.time.*
>Affects Versions: 3.6
> Environment: Windows
>Reporter: Keith Boone
>Assignee: Charles Honton
>   Original Estimate: 48h
>  Remaining Estimate: 48h
>
> Under heavy load we are seeing contention in FastDateParser.parse() on calls 
> to TimeZone.getTimeZone().  TimeZone.getTimeZone() is a synchronized static 
> in the Oracle JVM.
> Our proposed solution is to add a class TimeZoneCache containing a single 
> method getTimeZone() which gets the requested time zone from a ConcurrentMap, 
> and if not present, looks it up via TimeZone.getTimeZone() and caches it 
> before returning it.
> Then replace calls to TimeZone.getTimeZone() in FastDateParser ( and 
> whereever else) to calls to TimeZoneCache.getTimeZone().  
> The reason to add a separate class is because it can also be used by other 
> applications which heavily parse or format or do other things where TimeZone 
> is repeatedly needed.
> Under extreme load we have seen an 50:1 improvement in calls to 
> FastDateParser.parse().  This saves about a ms/call in our test environment, 
> and reduces contention.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (LANG-1355) TimeZone.getTimeZone() in FastDateParser causes resource contention

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/LANG-1355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16198752#comment-16198752
 ] 

ASF GitHub Bot commented on LANG-1355:
--

Github user chonton commented on a diff in the pull request:

https://github.com/apache/commons-lang/pull/296#discussion_r143749142
  
--- Diff: src/test/java/org/apache/commons/lang3/time/GmtTimeZoneTest.java 
---
@@ -0,0 +1,80 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements.  See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License.  You may obtain a copy of the License at
+ *
+ *  http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.commons.lang3.time;
+
+import org.junit.Assert;
+import org.junit.Test;
+
+/**
+ * Tests for GmtTimeZone
+ */
+public class GmtTimeZoneTest {
+
+@Test(expected = IllegalArgumentException.class)
+public void hoursOutOfRange() {
+new GmtTimeZone(false, 24, 0);
+}
+
+@Test
+public void hoursInRange() {
+Assert.assertEquals(23 * 60 * 60 * 1000, new GmtTimeZone(false, 
23, 0).getRawOffset());
+}
+
+@Test(expected = IllegalArgumentException.class)
+public void minutesOutOfRange() {
+Assert.assertEquals(0, new GmtTimeZone(false, 60, 0));
+}
+
+@Test
+public void minutesInRange() {
+Assert.assertEquals(59 * 60 * 1000, new GmtTimeZone(false, 0, 
59).getRawOffset());
+}
+
+@Test
+public void getOffset() {
+Assert.assertEquals(0, new GmtTimeZone(false, 0, 
0).getOffset(234304));
+}
+
+@Test(expected = UnsupportedOperationException.class)
+public void setRawOffset() {
+new GmtTimeZone(false, 0, 0).setRawOffset(0);
+}
+
+@Test
+public void getRawOffset() {
+Assert.assertEquals(0, new GmtTimeZone(false, 0, 
0).getRawOffset());
+}
+
+@Test
+public void getID() {
+Assert.assertEquals("GMT+00:00", new GmtTimeZone(false, 0, 
0).getID());
+Assert.assertEquals("GMT+01:02", new GmtTimeZone(false, 1, 
2).getID());
+Assert.assertEquals("GMT+11:22", new GmtTimeZone(false, 11, 
22).getID());
+Assert.assertEquals("GMT-01:02", new GmtTimeZone(true, 1, 
2).getID());
+Assert.assertEquals("GMT-11:22", new GmtTimeZone(true, 11, 
22).getID());
+}
+
+@Test
+public void useDaylightTime() {
+Assert.assertFalse(new GmtTimeZone(false, 0, 0).useDaylightTime());
+}
+
+@Test
+public void inDaylightTime() {
+Assert.assertFalse(new GmtTimeZone(false, 0, 0).useDaylightTime());
+}
--- End diff --

done


> TimeZone.getTimeZone() in FastDateParser causes resource contention
> ---
>
> Key: LANG-1355
> URL: https://issues.apache.org/jira/browse/LANG-1355
> Project: Commons Lang
>  Issue Type: Bug
>  Components: lang.time.*
>Affects Versions: 3.6
> Environment: Windows
>Reporter: Keith Boone
>Assignee: Charles Honton
>   Original Estimate: 48h
>  Remaining Estimate: 48h
>
> Under heavy load we are seeing contention in FastDateParser.parse() on calls 
> to TimeZone.getTimeZone().  TimeZone.getTimeZone() is a synchronized static 
> in the Oracle JVM.
> Our proposed solution is to add a class TimeZoneCache containing a single 
> method getTimeZone() which gets the requested time zone from a ConcurrentMap, 
> and if not present, looks it up via TimeZone.getTimeZone() and caches it 
> before returning it.
> Then replace calls to TimeZone.getTimeZone() in FastDateParser ( and 
> whereever else) to calls to TimeZoneCache.getTimeZone().  
> The reason to add a separate class is because it can also be used by other 
> applications which heavily parse or format or do other things where TimeZone 
> is repeatedly needed.
> Under extreme load we have seen an 50:1 improvement in calls to 
> FastDateParser.parse().  This saves about a ms/call in our test environment, 

[GitHub] commons-lang pull request #296: LANG-1355: Add FastTimeZone to decrease Time...

[chonton]

Github user chonton commented on a diff in the pull request:

https://github.com/apache/commons-lang/pull/296#discussion_r143749105
  
--- Diff: src/test/java/org/apache/commons/lang3/time/GmtTimeZoneTest.java 
---
@@ -0,0 +1,80 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements.  See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License.  You may obtain a copy of the License at
+ *
+ *  http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.commons.lang3.time;
+
+import org.junit.Assert;
+import org.junit.Test;
+
+/**
+ * Tests for GmtTimeZone
+ */
+public class GmtTimeZoneTest {
+
+@Test(expected = IllegalArgumentException.class)
+public void hoursOutOfRange() {
+new GmtTimeZone(false, 24, 0);
+}
+
+@Test
+public void hoursInRange() {
+Assert.assertEquals(23 * 60 * 60 * 1000, new GmtTimeZone(false, 
23, 0).getRawOffset());
+}
+
+@Test(expected = IllegalArgumentException.class)
+public void minutesOutOfRange() {
+Assert.assertEquals(0, new GmtTimeZone(false, 60, 0));
--- End diff --

great catch! thanks.
done.


---

[GitHub] commons-lang pull request #296: LANG-1355: Add FastTimeZone to decrease Time...

[chonton]

Github user chonton commented on a diff in the pull request:

https://github.com/apache/commons-lang/pull/296#discussion_r143749142
  
--- Diff: src/test/java/org/apache/commons/lang3/time/GmtTimeZoneTest.java 
---
@@ -0,0 +1,80 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements.  See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License.  You may obtain a copy of the License at
+ *
+ *  http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.commons.lang3.time;
+
+import org.junit.Assert;
+import org.junit.Test;
+
+/**
+ * Tests for GmtTimeZone
+ */
+public class GmtTimeZoneTest {
+
+@Test(expected = IllegalArgumentException.class)
+public void hoursOutOfRange() {
+new GmtTimeZone(false, 24, 0);
+}
+
+@Test
+public void hoursInRange() {
+Assert.assertEquals(23 * 60 * 60 * 1000, new GmtTimeZone(false, 
23, 0).getRawOffset());
+}
+
+@Test(expected = IllegalArgumentException.class)
+public void minutesOutOfRange() {
+Assert.assertEquals(0, new GmtTimeZone(false, 60, 0));
+}
+
+@Test
+public void minutesInRange() {
+Assert.assertEquals(59 * 60 * 1000, new GmtTimeZone(false, 0, 
59).getRawOffset());
+}
+
+@Test
+public void getOffset() {
+Assert.assertEquals(0, new GmtTimeZone(false, 0, 
0).getOffset(234304));
+}
+
+@Test(expected = UnsupportedOperationException.class)
+public void setRawOffset() {
+new GmtTimeZone(false, 0, 0).setRawOffset(0);
+}
+
+@Test
+public void getRawOffset() {
+Assert.assertEquals(0, new GmtTimeZone(false, 0, 
0).getRawOffset());
+}
+
+@Test
+public void getID() {
+Assert.assertEquals("GMT+00:00", new GmtTimeZone(false, 0, 
0).getID());
+Assert.assertEquals("GMT+01:02", new GmtTimeZone(false, 1, 
2).getID());
+Assert.assertEquals("GMT+11:22", new GmtTimeZone(false, 11, 
22).getID());
+Assert.assertEquals("GMT-01:02", new GmtTimeZone(true, 1, 
2).getID());
+Assert.assertEquals("GMT-11:22", new GmtTimeZone(true, 11, 
22).getID());
+}
+
+@Test
+public void useDaylightTime() {
+Assert.assertFalse(new GmtTimeZone(false, 0, 0).useDaylightTime());
+}
+
+@Test
+public void inDaylightTime() {
+Assert.assertFalse(new GmtTimeZone(false, 0, 0).useDaylightTime());
+}
--- End diff --

done


---

[jira] [Commented] (LANG-1355) TimeZone.getTimeZone() in FastDateParser causes resource contention

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/LANG-1355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16198750#comment-16198750
 ] 

ASF GitHub Bot commented on LANG-1355:
--

Github user chonton commented on a diff in the pull request:

https://github.com/apache/commons-lang/pull/296#discussion_r143748954
  
--- Diff: src/main/java/org/apache/commons/lang3/time/GmtTimeZone.java ---
@@ -0,0 +1,103 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements.  See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License.  You may obtain a copy of the License at
+ *
+ *  http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.commons.lang3.time;
+
+import java.util.Date;
+import java.util.TimeZone;
+
+/**
+ * Custom timezone that contains offset from GMT.
+ *
+ * @since 3.7
+ */
+class GmtTimeZone extends TimeZone {
--- End diff --

great catch! done


> TimeZone.getTimeZone() in FastDateParser causes resource contention
> ---
>
> Key: LANG-1355
> URL: https://issues.apache.org/jira/browse/LANG-1355
> Project: Commons Lang
>  Issue Type: Bug
>  Components: lang.time.*
>Affects Versions: 3.6
> Environment: Windows
>Reporter: Keith Boone
>Assignee: Charles Honton
>   Original Estimate: 48h
>  Remaining Estimate: 48h
>
> Under heavy load we are seeing contention in FastDateParser.parse() on calls 
> to TimeZone.getTimeZone().  TimeZone.getTimeZone() is a synchronized static 
> in the Oracle JVM.
> Our proposed solution is to add a class TimeZoneCache containing a single 
> method getTimeZone() which gets the requested time zone from a ConcurrentMap, 
> and if not present, looks it up via TimeZone.getTimeZone() and caches it 
> before returning it.
> Then replace calls to TimeZone.getTimeZone() in FastDateParser ( and 
> whereever else) to calls to TimeZoneCache.getTimeZone().  
> The reason to add a separate class is because it can also be used by other 
> applications which heavily parse or format or do other things where TimeZone 
> is repeatedly needed.
> Under extreme load we have seen an 50:1 improvement in calls to 
> FastDateParser.parse().  This saves about a ms/call in our test environment, 
> and reduces contention.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (LANG-1355) TimeZone.getTimeZone() in FastDateParser causes resource contention

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/LANG-1355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16198748#comment-16198748
 ] 

ASF GitHub Bot commented on LANG-1355:
--

Github user chonton commented on a diff in the pull request:

https://github.com/apache/commons-lang/pull/296#discussion_r143748823
  
--- Diff: src/main/java/org/apache/commons/lang3/time/FastTimeZone.java ---
@@ -0,0 +1,90 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements.  See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License.  You may obtain a copy of the License at
+ *
+ *  http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.commons.lang3.time;
+
+import java.util.TimeZone;
+import java.util.regex.Matcher;
+import java.util.regex.Pattern;
+
+/**
+ * Faster methods to produce custom time zones.
+ *
+ * @since 3.7
+ */
+public class FastTimeZone {
--- End diff --

done


> TimeZone.getTimeZone() in FastDateParser causes resource contention
> ---
>
> Key: LANG-1355
> URL: https://issues.apache.org/jira/browse/LANG-1355
> Project: Commons Lang
>  Issue Type: Bug
>  Components: lang.time.*
>Affects Versions: 3.6
> Environment: Windows
>Reporter: Keith Boone
>Assignee: Charles Honton
>   Original Estimate: 48h
>  Remaining Estimate: 48h
>
> Under heavy load we are seeing contention in FastDateParser.parse() on calls 
> to TimeZone.getTimeZone().  TimeZone.getTimeZone() is a synchronized static 
> in the Oracle JVM.
> Our proposed solution is to add a class TimeZoneCache containing a single 
> method getTimeZone() which gets the requested time zone from a ConcurrentMap, 
> and if not present, looks it up via TimeZone.getTimeZone() and caches it 
> before returning it.
> Then replace calls to TimeZone.getTimeZone() in FastDateParser ( and 
> whereever else) to calls to TimeZoneCache.getTimeZone().  
> The reason to add a separate class is because it can also be used by other 
> applications which heavily parse or format or do other things where TimeZone 
> is repeatedly needed.
> Under extreme load we have seen an 50:1 improvement in calls to 
> FastDateParser.parse().  This saves about a ms/call in our test environment, 
> and reduces contention.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (LANG-1355) TimeZone.getTimeZone() in FastDateParser causes resource contention

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/LANG-1355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16198749#comment-16198749
 ] 

ASF GitHub Bot commented on LANG-1355:
--

Github user chonton commented on a diff in the pull request:

https://github.com/apache/commons-lang/pull/296#discussion_r143748869
  
--- Diff: src/main/java/org/apache/commons/lang3/time/FastTimeZone.java ---
@@ -0,0 +1,90 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements.  See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License.  You may obtain a copy of the License at
+ *
+ *  http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.commons.lang3.time;
+
+import java.util.TimeZone;
+import java.util.regex.Matcher;
+import java.util.regex.Pattern;
+
+/**
+ * Faster methods to produce custom time zones.
+ *
+ * @since 3.7
+ */
+public class FastTimeZone {
+
+private static final TimeZone GREENWICH = new GmtTimeZone(false, 0, 0);
+
+/**
+ * Get the GMT TimeZone.
+ * @return A TimeZone with a raw offset of zero.
+ */
+public static TimeZone getGmtTimeZone() {
+return GREENWICH;
+}
+
+/**
+ * Get a TimeZone, looking first for GMT custom ids, then falling back 
to Olson ids.
+ * A GMT custom id has an optional prefix of GMT, followed by sign, 
hours digit(s), optional
+ * colon(':'), and optional minutes digits: [GMT] (+|-) Hours [[:] 
Minutes]
+ *
+ * @param id A GMT custom id or Olsen id
+ * @return A timezone
+ */
+public static TimeZone getTimeZone(String id) {
+TimeZone tz = getGmtTimeZone(id);
+if (tz != null) {
+return tz;
+}
+return TimeZone.getTimeZone(id);
+}
+
+private static final Pattern GMT_PATTERN = 
Pattern.compile("^(?:(?i)GMT)?([+-])?(\\d\\d?)?(:?(\\d\\d?))?$");
+
+/**
+ * Get a TimeZone with GMT offsets.  A GMT offset must be either 'Z' 
or match
+ * (GMT)? hh?(:?mm?)?, where h and m are digits representing hours and 
minutes.
--- End diff --

done


> TimeZone.getTimeZone() in FastDateParser causes resource contention
> ---
>
> Key: LANG-1355
> URL: https://issues.apache.org/jira/browse/LANG-1355
> Project: Commons Lang
>  Issue Type: Bug
>  Components: lang.time.*
>Affects Versions: 3.6
> Environment: Windows
>Reporter: Keith Boone
>Assignee: Charles Honton
>   Original Estimate: 48h
>  Remaining Estimate: 48h
>
> Under heavy load we are seeing contention in FastDateParser.parse() on calls 
> to TimeZone.getTimeZone().  TimeZone.getTimeZone() is a synchronized static 
> in the Oracle JVM.
> Our proposed solution is to add a class TimeZoneCache containing a single 
> method getTimeZone() which gets the requested time zone from a ConcurrentMap, 
> and if not present, looks it up via TimeZone.getTimeZone() and caches it 
> before returning it.
> Then replace calls to TimeZone.getTimeZone() in FastDateParser ( and 
> whereever else) to calls to TimeZoneCache.getTimeZone().  
> The reason to add a separate class is because it can also be used by other 
> applications which heavily parse or format or do other things where TimeZone 
> is repeatedly needed.
> Under extreme load we have seen an 50:1 improvement in calls to 
> FastDateParser.parse().  This saves about a ms/call in our test environment, 
> and reduces contention.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] commons-lang pull request #296: LANG-1355: Add FastTimeZone to decrease Time...

[chonton]

Github user chonton commented on a diff in the pull request:

https://github.com/apache/commons-lang/pull/296#discussion_r143748954
  
--- Diff: src/main/java/org/apache/commons/lang3/time/GmtTimeZone.java ---
@@ -0,0 +1,103 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements.  See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License.  You may obtain a copy of the License at
+ *
+ *  http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.commons.lang3.time;
+
+import java.util.Date;
+import java.util.TimeZone;
+
+/**
+ * Custom timezone that contains offset from GMT.
+ *
+ * @since 3.7
+ */
+class GmtTimeZone extends TimeZone {
--- End diff --

great catch! done


---

[GitHub] commons-lang pull request #296: LANG-1355: Add FastTimeZone to decrease Time...

[chonton]

Github user chonton commented on a diff in the pull request:

https://github.com/apache/commons-lang/pull/296#discussion_r143748869
  
--- Diff: src/main/java/org/apache/commons/lang3/time/FastTimeZone.java ---
@@ -0,0 +1,90 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements.  See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License.  You may obtain a copy of the License at
+ *
+ *  http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.commons.lang3.time;
+
+import java.util.TimeZone;
+import java.util.regex.Matcher;
+import java.util.regex.Pattern;
+
+/**
+ * Faster methods to produce custom time zones.
+ *
+ * @since 3.7
+ */
+public class FastTimeZone {
+
+private static final TimeZone GREENWICH = new GmtTimeZone(false, 0, 0);
+
+/**
+ * Get the GMT TimeZone.
+ * @return A TimeZone with a raw offset of zero.
+ */
+public static TimeZone getGmtTimeZone() {
+return GREENWICH;
+}
+
+/**
+ * Get a TimeZone, looking first for GMT custom ids, then falling back 
to Olson ids.
+ * A GMT custom id has an optional prefix of GMT, followed by sign, 
hours digit(s), optional
+ * colon(':'), and optional minutes digits: [GMT] (+|-) Hours [[:] 
Minutes]
+ *
+ * @param id A GMT custom id or Olsen id
+ * @return A timezone
+ */
+public static TimeZone getTimeZone(String id) {
+TimeZone tz = getGmtTimeZone(id);
+if (tz != null) {
+return tz;
+}
+return TimeZone.getTimeZone(id);
+}
+
+private static final Pattern GMT_PATTERN = 
Pattern.compile("^(?:(?i)GMT)?([+-])?(\\d\\d?)?(:?(\\d\\d?))?$");
+
+/**
+ * Get a TimeZone with GMT offsets.  A GMT offset must be either 'Z' 
or match
+ * (GMT)? hh?(:?mm?)?, where h and m are digits representing hours and 
minutes.
--- End diff --

done


---

[GitHub] commons-lang pull request #296: LANG-1355: Add FastTimeZone to decrease Time...

[chonton]

Github user chonton commented on a diff in the pull request:

https://github.com/apache/commons-lang/pull/296#discussion_r143748823
  
--- Diff: src/main/java/org/apache/commons/lang3/time/FastTimeZone.java ---
@@ -0,0 +1,90 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements.  See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License.  You may obtain a copy of the License at
+ *
+ *  http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.commons.lang3.time;
+
+import java.util.TimeZone;
+import java.util.regex.Matcher;
+import java.util.regex.Pattern;
+
+/**
+ * Faster methods to produce custom time zones.
+ *
+ * @since 3.7
+ */
+public class FastTimeZone {
--- End diff --

done


---

[jira] [Commented] (TEXT-74) StrSubstitutor: Ability to turn off substitution in values

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TEXT-74?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16198730#comment-16198730
 ] 

ASF GitHub Bot commented on TEXT-74:


Github user asfgit closed the pull request at:

https://github.com/apache/commons-text/pull/68


> StrSubstitutor: Ability to turn off substitution in values
> --
>
> Key: TEXT-74
> URL: https://issues.apache.org/jira/browse/TEXT-74
> Project: Commons Text
>  Issue Type: Improvement
>Reporter: Arend v. Reinersdorff
>Priority: Minor
>  Labels: features
> Fix For: 1.x
>
>
> StrSubstitutor replaces variables in values. And currently there's no way to 
> turn this off.
> Why turn it off: I want to replace some variables in a simple template. Some 
> of the replacement values are arbitrary user input.
> At the moment I escape all dollar signs in the replacement values with "$$". 
> This is annoying. Especially as I use one template with variables as a value 
> for another variable. Here I have to escape twice.
> Here's some example code. At the moment it prints:
> {code}
> Hello Hamburg from Hamburg
> {code}
> The commented line is my suggestion for this feature. If it works, it should 
> print:
> {code}
> Hello ${city} from Hamburg
> {code}
> {code}
> // untrusted user input
> String userInputName = "${city}";
> String userInputCity = "Hamburg";
> Map valueMap = new HashMap<>();
> valueMap.put("name", userInputName);
> valueMap.put("city", userInputCity);
> String source = "Hello ${name} from ${city}";
> StrSubstitutor strSubstitutor = new StrSubstitutor(valueMap);
> // strSubstitutor.setEnableSubstitutionInValues(false);
> System.out.println(strSubstitutor.replace(source));
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (TEXT-74) StrSubstitutor: Ability to turn off substitution in values

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TEXT-74?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16198592#comment-16198592
 ] 

ASF GitHub Bot commented on TEXT-74:


Github user sermojohn commented on the issue:

https://github.com/apache/commons-text/pull/68
  
For backwards compatibility, it needs to be off by default, so recursive 
substitution applies by default.


> StrSubstitutor: Ability to turn off substitution in values
> --
>
> Key: TEXT-74
> URL: https://issues.apache.org/jira/browse/TEXT-74
> Project: Commons Text
>  Issue Type: Improvement
>Reporter: Arend v. Reinersdorff
>Priority: Minor
>  Labels: features
> Fix For: 1.x
>
>
> StrSubstitutor replaces variables in values. And currently there's no way to 
> turn this off.
> Why turn it off: I want to replace some variables in a simple template. Some 
> of the replacement values are arbitrary user input.
> At the moment I escape all dollar signs in the replacement values with "$$". 
> This is annoying. Especially as I use one template with variables as a value 
> for another variable. Here I have to escape twice.
> Here's some example code. At the moment it prints:
> {code}
> Hello Hamburg from Hamburg
> {code}
> The commented line is my suggestion for this feature. If it works, it should 
> print:
> {code}
> Hello ${city} from Hamburg
> {code}
> {code}
> // untrusted user input
> String userInputName = "${city}";
> String userInputCity = "Hamburg";
> Map valueMap = new HashMap<>();
> valueMap.put("name", userInputName);
> valueMap.put("city", userInputCity);
> String source = "Hello ${name} from ${city}";
> StrSubstitutor strSubstitutor = new StrSubstitutor(valueMap);
> // strSubstitutor.setEnableSubstitutionInValues(false);
> System.out.println(strSubstitutor.replace(source));
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (TEXT-74) StrSubstitutor: Ability to turn off substitution in values

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TEXT-74?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16198588#comment-16198588
 ] 

ASF GitHub Bot commented on TEXT-74:


Github user chtompki commented on the issue:

https://github.com/apache/commons-text/pull/68
  
Do we want it to be off by default?


> StrSubstitutor: Ability to turn off substitution in values
> --
>
> Key: TEXT-74
> URL: https://issues.apache.org/jira/browse/TEXT-74
> Project: Commons Text
>  Issue Type: Improvement
>Reporter: Arend v. Reinersdorff
>Priority: Minor
>  Labels: features
> Fix For: 1.x
>
>
> StrSubstitutor replaces variables in values. And currently there's no way to 
> turn this off.
> Why turn it off: I want to replace some variables in a simple template. Some 
> of the replacement values are arbitrary user input.
> At the moment I escape all dollar signs in the replacement values with "$$". 
> This is annoying. Especially as I use one template with variables as a value 
> for another variable. Here I have to escape twice.
> Here's some example code. At the moment it prints:
> {code}
> Hello Hamburg from Hamburg
> {code}
> The commented line is my suggestion for this feature. If it works, it should 
> print:
> {code}
> Hello ${city} from Hamburg
> {code}
> {code}
> // untrusted user input
> String userInputName = "${city}";
> String userInputCity = "Hamburg";
> Map valueMap = new HashMap<>();
> valueMap.put("name", userInputName);
> valueMap.put("city", userInputCity);
> String source = "Hello ${name} from ${city}";
> StrSubstitutor strSubstitutor = new StrSubstitutor(valueMap);
> // strSubstitutor.setEnableSubstitutionInValues(false);
> System.out.println(strSubstitutor.replace(source));
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (TEXT-74) StrSubstitutor: Ability to turn off substitution in values

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TEXT-74?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16198584#comment-16198584
 ] 

ASF GitHub Bot commented on TEXT-74:


Github user chtompki commented on the issue:

https://github.com/apache/commons-text/pull/68
  
Seems reasonable to me.


> StrSubstitutor: Ability to turn off substitution in values
> --
>
> Key: TEXT-74
> URL: https://issues.apache.org/jira/browse/TEXT-74
> Project: Commons Text
>  Issue Type: Improvement
>Reporter: Arend v. Reinersdorff
>Priority: Minor
>  Labels: features
> Fix For: 1.x
>
>
> StrSubstitutor replaces variables in values. And currently there's no way to 
> turn this off.
> Why turn it off: I want to replace some variables in a simple template. Some 
> of the replacement values are arbitrary user input.
> At the moment I escape all dollar signs in the replacement values with "$$". 
> This is annoying. Especially as I use one template with variables as a value 
> for another variable. Here I have to escape twice.
> Here's some example code. At the moment it prints:
> {code}
> Hello Hamburg from Hamburg
> {code}
> The commented line is my suggestion for this feature. If it works, it should 
> print:
> {code}
> Hello ${city} from Hamburg
> {code}
> {code}
> // untrusted user input
> String userInputName = "${city}";
> String userInputCity = "Hamburg";
> Map valueMap = new HashMap<>();
> valueMap.put("name", userInputName);
> valueMap.put("city", userInputCity);
> String source = "Hello ${name} from ${city}";
> StrSubstitutor strSubstitutor = new StrSubstitutor(valueMap);
> // strSubstitutor.setEnableSubstitutionInValues(false);
> System.out.println(strSubstitutor.replace(source));
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (DBUTILS-124) Introduce SPI to add more column, property handlers

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/DBUTILS-124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16198473#comment-16198473
 ] 

ASF GitHub Bot commented on DBUTILS-124:


GitHub user hdevalke opened a pull request:

https://github.com/apache/commons-dbutils/pull/3

Fixes a thread safety problem introduced by DBUTILS-124.

ColumnHandlers and PropertyHandlers are preloaded in a list as the 
ServiceLoader instances are not thread safe

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/hdevalke/commons-dbutils master

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/commons-dbutils/pull/3.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #3


commit 59d114082708ade64c9f05b13128d0c0eb39bc7f
Author: Hannes De Valkeneer 
Date:   2017-10-05T14:05:18Z

Fixes a thread safety problem introduced by DBUTILS-124.

ColumnHandlers and PropertyHandlers are preloaded in a list as the 
ServiceLoader instances are not thread safe




> Introduce SPI to add more column, property handlers
> ---
>
> Key: DBUTILS-124
> URL: https://issues.apache.org/jira/browse/DBUTILS-124
> Project: Commons DbUtils
>  Issue Type: New Feature
>Reporter: Carl Hall
>Assignee: Carl Hall
> Fix For: 1.7
>
>
> The column types and property types handled by {{BeanProcessor}} are hard 
> coded to the processor.  We already use a common return type, so we could add 
> a services approach using the spi built into the jdk.  This should also allow 
> other types to be handled outside of {{commons-dbutils}}.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (LANG-1355) TimeZone.getTimeZone() in FastDateParser causes resource contention

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/LANG-1355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16198380#comment-16198380
 ] 

ASF GitHub Bot commented on LANG-1355:
--

Github user kinow commented on a diff in the pull request:

https://github.com/apache/commons-lang/pull/296#discussion_r143660909
  
--- Diff: src/main/java/org/apache/commons/lang3/time/FastTimeZone.java ---
@@ -0,0 +1,90 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements.  See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License.  You may obtain a copy of the License at
+ *
+ *  http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.commons.lang3.time;
+
+import java.util.TimeZone;
+import java.util.regex.Matcher;
+import java.util.regex.Pattern;
+
+/**
+ * Faster methods to produce custom time zones.
+ *
+ * @since 3.7
+ */
+public class FastTimeZone {
+
+private static final TimeZone GREENWICH = new GmtTimeZone(false, 0, 0);
+
+/**
+ * Get the GMT TimeZone.
+ * @return A TimeZone with a raw offset of zero.
+ */
+public static TimeZone getGmtTimeZone() {
+return GREENWICH;
+}
+
+/**
+ * Get a TimeZone, looking first for GMT custom ids, then falling back 
to Olson ids.
+ * A GMT custom id has an optional prefix of GMT, followed by sign, 
hours digit(s), optional
+ * colon(':'), and optional minutes digits: [GMT] (+|-) Hours [[:] 
Minutes]
+ *
+ * @param id A GMT custom id or Olsen id
+ * @return A timezone
+ */
+public static TimeZone getTimeZone(String id) {
+TimeZone tz = getGmtTimeZone(id);
+if (tz != null) {
+return tz;
+}
+return TimeZone.getTimeZone(id);
+}
+
+private static final Pattern GMT_PATTERN = 
Pattern.compile("^(?:(?i)GMT)?([+-])?(\\d\\d?)?(:?(\\d\\d?))?$");
+
+/**
+ * Get a TimeZone with GMT offsets.  A GMT offset must be either 'Z' 
or match
+ * (GMT)? hh?(:?mm?)?, where h and m are digits representing hours and 
minutes.
--- End diff --

Maybe instead of

> A GMT offset must be either 'Z' or match (GMT)? hh?(:?mm?)?

It should be

> A GMT offset must be 'Z', or 'UTC', or match (GMT)? hh?(:?mm?)?

?




> TimeZone.getTimeZone() in FastDateParser causes resource contention
> ---
>
> Key: LANG-1355
> URL: https://issues.apache.org/jira/browse/LANG-1355
> Project: Commons Lang
>  Issue Type: Bug
>  Components: lang.time.*
>Affects Versions: 3.6
> Environment: Windows
>Reporter: Keith Boone
>Assignee: Charles Honton
>   Original Estimate: 48h
>  Remaining Estimate: 48h
>
> Under heavy load we are seeing contention in FastDateParser.parse() on calls 
> to TimeZone.getTimeZone().  TimeZone.getTimeZone() is a synchronized static 
> in the Oracle JVM.
> Our proposed solution is to add a class TimeZoneCache containing a single 
> method getTimeZone() which gets the requested time zone from a ConcurrentMap, 
> and if not present, looks it up via TimeZone.getTimeZone() and caches it 
> before returning it.
> Then replace calls to TimeZone.getTimeZone() in FastDateParser ( and 
> whereever else) to calls to TimeZoneCache.getTimeZone().  
> The reason to add a separate class is because it can also be used by other 
> applications which heavily parse or format or do other things where TimeZone 
> is repeatedly needed.
> Under extreme load we have seen an 50:1 improvement in calls to 
> FastDateParser.parse().  This saves about a ms/call in our test environment, 
> and reduces contention.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (LANG-1355) TimeZone.getTimeZone() in FastDateParser causes resource contention

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/LANG-1355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16198379#comment-16198379
 ] 

ASF GitHub Bot commented on LANG-1355:
--

Github user kinow commented on a diff in the pull request:

https://github.com/apache/commons-lang/pull/296#discussion_r143664742
  
--- Diff: src/main/java/org/apache/commons/lang3/time/GmtTimeZone.java ---
@@ -0,0 +1,103 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements.  See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License.  You may obtain a copy of the License at
+ *
+ *  http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.commons.lang3.time;
+
+import java.util.Date;
+import java.util.TimeZone;
+
+/**
+ * Custom timezone that contains offset from GMT.
+ *
+ * @since 3.7
+ */
+class GmtTimeZone extends TimeZone {
--- End diff --

TimeZone is Serializabe. Do we need to add a serialVersionUID here?


> TimeZone.getTimeZone() in FastDateParser causes resource contention
> ---
>
> Key: LANG-1355
> URL: https://issues.apache.org/jira/browse/LANG-1355
> Project: Commons Lang
>  Issue Type: Bug
>  Components: lang.time.*
>Affects Versions: 3.6
> Environment: Windows
>Reporter: Keith Boone
>Assignee: Charles Honton
>   Original Estimate: 48h
>  Remaining Estimate: 48h
>
> Under heavy load we are seeing contention in FastDateParser.parse() on calls 
> to TimeZone.getTimeZone().  TimeZone.getTimeZone() is a synchronized static 
> in the Oracle JVM.
> Our proposed solution is to add a class TimeZoneCache containing a single 
> method getTimeZone() which gets the requested time zone from a ConcurrentMap, 
> and if not present, looks it up via TimeZone.getTimeZone() and caches it 
> before returning it.
> Then replace calls to TimeZone.getTimeZone() in FastDateParser ( and 
> whereever else) to calls to TimeZoneCache.getTimeZone().  
> The reason to add a separate class is because it can also be used by other 
> applications which heavily parse or format or do other things where TimeZone 
> is repeatedly needed.
> Under extreme load we have seen an 50:1 improvement in calls to 
> FastDateParser.parse().  This saves about a ms/call in our test environment, 
> and reduces contention.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (LANG-1355) TimeZone.getTimeZone() in FastDateParser causes resource contention

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/LANG-1355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16198383#comment-16198383
 ] 

ASF GitHub Bot commented on LANG-1355:
--

Github user kinow commented on a diff in the pull request:

https://github.com/apache/commons-lang/pull/296#discussion_r143667312
  
--- Diff: src/test/java/org/apache/commons/lang3/time/GmtTimeZoneTest.java 
---
@@ -0,0 +1,80 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements.  See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License.  You may obtain a copy of the License at
+ *
+ *  http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.commons.lang3.time;
+
+import org.junit.Assert;
+import org.junit.Test;
+
+/**
+ * Tests for GmtTimeZone
+ */
+public class GmtTimeZoneTest {
+
+@Test(expected = IllegalArgumentException.class)
+public void hoursOutOfRange() {
+new GmtTimeZone(false, 24, 0);
+}
+
+@Test
+public void hoursInRange() {
+Assert.assertEquals(23 * 60 * 60 * 1000, new GmtTimeZone(false, 
23, 0).getRawOffset());
+}
+
+@Test(expected = IllegalArgumentException.class)
+public void minutesOutOfRange() {
+Assert.assertEquals(0, new GmtTimeZone(false, 60, 0));
+}
+
+@Test
+public void minutesInRange() {
+Assert.assertEquals(59 * 60 * 1000, new GmtTimeZone(false, 0, 
59).getRawOffset());
+}
+
+@Test
+public void getOffset() {
+Assert.assertEquals(0, new GmtTimeZone(false, 0, 
0).getOffset(234304));
+}
+
+@Test(expected = UnsupportedOperationException.class)
+public void setRawOffset() {
+new GmtTimeZone(false, 0, 0).setRawOffset(0);
+}
+
+@Test
+public void getRawOffset() {
+Assert.assertEquals(0, new GmtTimeZone(false, 0, 
0).getRawOffset());
+}
+
+@Test
+public void getID() {
+Assert.assertEquals("GMT+00:00", new GmtTimeZone(false, 0, 
0).getID());
+Assert.assertEquals("GMT+01:02", new GmtTimeZone(false, 1, 
2).getID());
+Assert.assertEquals("GMT+11:22", new GmtTimeZone(false, 11, 
22).getID());
+Assert.assertEquals("GMT-01:02", new GmtTimeZone(true, 1, 
2).getID());
+Assert.assertEquals("GMT-11:22", new GmtTimeZone(true, 11, 
22).getID());
+}
+
+@Test
+public void useDaylightTime() {
+Assert.assertFalse(new GmtTimeZone(false, 0, 0).useDaylightTime());
+}
+
+@Test
+public void inDaylightTime() {
+Assert.assertFalse(new GmtTimeZone(false, 0, 0).useDaylightTime());
+}
--- End diff --

Maybe add something like

```
@Test
public void testToString() {
Assert.assertEquals("[GmtTimeZone 
id=\"GMT+23:00\",offset=8280]", new GmtTimeZone(false, 23, 0).toString());
}

@Test
public void testGetOffset() {
Assert.assertEquals(8280, new GmtTimeZone(false, 23, 
0).getOffset(1, 1, 1, 1, 1, 1));
}
```

With these two tests we reach 100% for GmtTimeZone.


> TimeZone.getTimeZone() in FastDateParser causes resource contention
> ---
>
> Key: LANG-1355
> URL: https://issues.apache.org/jira/browse/LANG-1355
> Project: Commons Lang
>  Issue Type: Bug
>  Components: lang.time.*
>Affects Versions: 3.6
> Environment: Windows
>Reporter: Keith Boone
>Assignee: Charles Honton
>   Original Estimate: 48h
>  Remaining Estimate: 48h
>
> Under heavy load we are seeing contention in FastDateParser.parse() on calls 
> to TimeZone.getTimeZone().  TimeZone.getTimeZone() is a synchronized static 
> in the Oracle JVM.
> Our proposed solution is to add a class TimeZoneCache containing a single 
> method getTimeZone() which gets the requested time zone from a ConcurrentMap, 
> and if not present, looks it up via TimeZone.getTimeZone() and caches it 
> before returning it.
> Then 

[GitHub] commons-lang pull request #296: LANG-1355: Add FastTimeZone to decrease Time...

[kinow]

Github user kinow commented on a diff in the pull request:

https://github.com/apache/commons-lang/pull/296#discussion_r143664742
  
--- Diff: src/main/java/org/apache/commons/lang3/time/GmtTimeZone.java ---
@@ -0,0 +1,103 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements.  See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License.  You may obtain a copy of the License at
+ *
+ *  http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.commons.lang3.time;
+
+import java.util.Date;
+import java.util.TimeZone;
+
+/**
+ * Custom timezone that contains offset from GMT.
+ *
+ * @since 3.7
+ */
+class GmtTimeZone extends TimeZone {
--- End diff --

TimeZone is Serializabe. Do we need to add a serialVersionUID here?


---

[GitHub] commons-lang pull request #296: LANG-1355: Add FastTimeZone to decrease Time...

[kinow]

Github user kinow commented on a diff in the pull request:

https://github.com/apache/commons-lang/pull/296#discussion_r143667156
  
--- Diff: src/test/java/org/apache/commons/lang3/time/GmtTimeZoneTest.java 
---
@@ -0,0 +1,80 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements.  See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License.  You may obtain a copy of the License at
+ *
+ *  http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.commons.lang3.time;
+
+import org.junit.Assert;
+import org.junit.Test;
+
+/**
+ * Tests for GmtTimeZone
+ */
+public class GmtTimeZoneTest {
+
+@Test(expected = IllegalArgumentException.class)
+public void hoursOutOfRange() {
+new GmtTimeZone(false, 24, 0);
+}
+
+@Test
+public void hoursInRange() {
+Assert.assertEquals(23 * 60 * 60 * 1000, new GmtTimeZone(false, 
23, 0).getRawOffset());
+}
+
+@Test(expected = IllegalArgumentException.class)
+public void minutesOutOfRange() {
+Assert.assertEquals(0, new GmtTimeZone(false, 60, 0));
--- End diff --

This test is wrong. Its title states that the minutes will be out of range, 
but the hour is actually out of range (60). Minute is 0, but never gets checked.


---

[jira] [Commented] (LANG-1355) TimeZone.getTimeZone() in FastDateParser causes resource contention

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/LANG-1355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16198381#comment-16198381
 ] 

ASF GitHub Bot commented on LANG-1355:
--

Github user kinow commented on a diff in the pull request:

https://github.com/apache/commons-lang/pull/296#discussion_r143663160
  
--- Diff: src/main/java/org/apache/commons/lang3/time/FastTimeZone.java ---
@@ -0,0 +1,90 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements.  See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License.  You may obtain a copy of the License at
+ *
+ *  http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.commons.lang3.time;
+
+import java.util.TimeZone;
+import java.util.regex.Matcher;
+import java.util.regex.Pattern;
+
+/**
+ * Faster methods to produce custom time zones.
+ *
+ * @since 3.7
+ */
+public class FastTimeZone {
--- End diff --

Do we need a private constructor to prevent instantiation of FastTimeZone? 
It seems to contain only static methods. Not sure if that's the intended 
design. But noticed it while looking at the cobertura report (which is looking 
great).


> TimeZone.getTimeZone() in FastDateParser causes resource contention
> ---
>
> Key: LANG-1355
> URL: https://issues.apache.org/jira/browse/LANG-1355
> Project: Commons Lang
>  Issue Type: Bug
>  Components: lang.time.*
>Affects Versions: 3.6
> Environment: Windows
>Reporter: Keith Boone
>Assignee: Charles Honton
>   Original Estimate: 48h
>  Remaining Estimate: 48h
>
> Under heavy load we are seeing contention in FastDateParser.parse() on calls 
> to TimeZone.getTimeZone().  TimeZone.getTimeZone() is a synchronized static 
> in the Oracle JVM.
> Our proposed solution is to add a class TimeZoneCache containing a single 
> method getTimeZone() which gets the requested time zone from a ConcurrentMap, 
> and if not present, looks it up via TimeZone.getTimeZone() and caches it 
> before returning it.
> Then replace calls to TimeZone.getTimeZone() in FastDateParser ( and 
> whereever else) to calls to TimeZoneCache.getTimeZone().  
> The reason to add a separate class is because it can also be used by other 
> applications which heavily parse or format or do other things where TimeZone 
> is repeatedly needed.
> Under extreme load we have seen an 50:1 improvement in calls to 
> FastDateParser.parse().  This saves about a ms/call in our test environment, 
> and reduces contention.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (LANG-1355) TimeZone.getTimeZone() in FastDateParser causes resource contention

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/LANG-1355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16198382#comment-16198382
 ] 

ASF GitHub Bot commented on LANG-1355:
--

Github user kinow commented on a diff in the pull request:

https://github.com/apache/commons-lang/pull/296#discussion_r143667156
  
--- Diff: src/test/java/org/apache/commons/lang3/time/GmtTimeZoneTest.java 
---
@@ -0,0 +1,80 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements.  See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License.  You may obtain a copy of the License at
+ *
+ *  http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.commons.lang3.time;
+
+import org.junit.Assert;
+import org.junit.Test;
+
+/**
+ * Tests for GmtTimeZone
+ */
+public class GmtTimeZoneTest {
+
+@Test(expected = IllegalArgumentException.class)
+public void hoursOutOfRange() {
+new GmtTimeZone(false, 24, 0);
+}
+
+@Test
+public void hoursInRange() {
+Assert.assertEquals(23 * 60 * 60 * 1000, new GmtTimeZone(false, 
23, 0).getRawOffset());
+}
+
+@Test(expected = IllegalArgumentException.class)
+public void minutesOutOfRange() {
+Assert.assertEquals(0, new GmtTimeZone(false, 60, 0));
--- End diff --

This test is wrong. Its title states that the minutes will be out of range, 
but the hour is actually out of range (60). Minute is 0, but never gets checked.


> TimeZone.getTimeZone() in FastDateParser causes resource contention
> ---
>
> Key: LANG-1355
> URL: https://issues.apache.org/jira/browse/LANG-1355
> Project: Commons Lang
>  Issue Type: Bug
>  Components: lang.time.*
>Affects Versions: 3.6
> Environment: Windows
>Reporter: Keith Boone
>Assignee: Charles Honton
>   Original Estimate: 48h
>  Remaining Estimate: 48h
>
> Under heavy load we are seeing contention in FastDateParser.parse() on calls 
> to TimeZone.getTimeZone().  TimeZone.getTimeZone() is a synchronized static 
> in the Oracle JVM.
> Our proposed solution is to add a class TimeZoneCache containing a single 
> method getTimeZone() which gets the requested time zone from a ConcurrentMap, 
> and if not present, looks it up via TimeZone.getTimeZone() and caches it 
> before returning it.
> Then replace calls to TimeZone.getTimeZone() in FastDateParser ( and 
> whereever else) to calls to TimeZoneCache.getTimeZone().  
> The reason to add a separate class is because it can also be used by other 
> applications which heavily parse or format or do other things where TimeZone 
> is repeatedly needed.
> Under extreme load we have seen an 50:1 improvement in calls to 
> FastDateParser.parse().  This saves about a ms/call in our test environment, 
> and reduces contention.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] commons-lang pull request #296: LANG-1355: Add FastTimeZone to decrease Time...

[kinow]

Github user kinow commented on a diff in the pull request:

https://github.com/apache/commons-lang/pull/296#discussion_r143660909
  
--- Diff: src/main/java/org/apache/commons/lang3/time/FastTimeZone.java ---
@@ -0,0 +1,90 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements.  See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License.  You may obtain a copy of the License at
+ *
+ *  http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.commons.lang3.time;
+
+import java.util.TimeZone;
+import java.util.regex.Matcher;
+import java.util.regex.Pattern;
+
+/**
+ * Faster methods to produce custom time zones.
+ *
+ * @since 3.7
+ */
+public class FastTimeZone {
+
+private static final TimeZone GREENWICH = new GmtTimeZone(false, 0, 0);
+
+/**
+ * Get the GMT TimeZone.
+ * @return A TimeZone with a raw offset of zero.
+ */
+public static TimeZone getGmtTimeZone() {
+return GREENWICH;
+}
+
+/**
+ * Get a TimeZone, looking first for GMT custom ids, then falling back 
to Olson ids.
+ * A GMT custom id has an optional prefix of GMT, followed by sign, 
hours digit(s), optional
+ * colon(':'), and optional minutes digits: [GMT] (+|-) Hours [[:] 
Minutes]
+ *
+ * @param id A GMT custom id or Olsen id
+ * @return A timezone
+ */
+public static TimeZone getTimeZone(String id) {
+TimeZone tz = getGmtTimeZone(id);
+if (tz != null) {
+return tz;
+}
+return TimeZone.getTimeZone(id);
+}
+
+private static final Pattern GMT_PATTERN = 
Pattern.compile("^(?:(?i)GMT)?([+-])?(\\d\\d?)?(:?(\\d\\d?))?$");
+
+/**
+ * Get a TimeZone with GMT offsets.  A GMT offset must be either 'Z' 
or match
+ * (GMT)? hh?(:?mm?)?, where h and m are digits representing hours and 
minutes.
--- End diff --

Maybe instead of

> A GMT offset must be either 'Z' or match (GMT)? hh?(:?mm?)?

It should be

> A GMT offset must be 'Z', or 'UTC', or match (GMT)? hh?(:?mm?)?

?




---

[GitHub] commons-lang pull request #296: LANG-1355: Add FastTimeZone to decrease Time...

[kinow]

Github user kinow commented on a diff in the pull request:

https://github.com/apache/commons-lang/pull/296#discussion_r143663160
  
--- Diff: src/main/java/org/apache/commons/lang3/time/FastTimeZone.java ---
@@ -0,0 +1,90 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements.  See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License.  You may obtain a copy of the License at
+ *
+ *  http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.commons.lang3.time;
+
+import java.util.TimeZone;
+import java.util.regex.Matcher;
+import java.util.regex.Pattern;
+
+/**
+ * Faster methods to produce custom time zones.
+ *
+ * @since 3.7
+ */
+public class FastTimeZone {
--- End diff --

Do we need a private constructor to prevent instantiation of FastTimeZone? 
It seems to contain only static methods. Not sure if that's the intended 
design. But noticed it while looking at the cobertura report (which is looking 
great).


---

[GitHub] commons-lang pull request #296: LANG-1355: Add FastTimeZone to decrease Time...

[kinow]

Github user kinow commented on a diff in the pull request:

https://github.com/apache/commons-lang/pull/296#discussion_r143667312
  
--- Diff: src/test/java/org/apache/commons/lang3/time/GmtTimeZoneTest.java 
---
@@ -0,0 +1,80 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements.  See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License.  You may obtain a copy of the License at
+ *
+ *  http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.commons.lang3.time;
+
+import org.junit.Assert;
+import org.junit.Test;
+
+/**
+ * Tests for GmtTimeZone
+ */
+public class GmtTimeZoneTest {
+
+@Test(expected = IllegalArgumentException.class)
+public void hoursOutOfRange() {
+new GmtTimeZone(false, 24, 0);
+}
+
+@Test
+public void hoursInRange() {
+Assert.assertEquals(23 * 60 * 60 * 1000, new GmtTimeZone(false, 
23, 0).getRawOffset());
+}
+
+@Test(expected = IllegalArgumentException.class)
+public void minutesOutOfRange() {
+Assert.assertEquals(0, new GmtTimeZone(false, 60, 0));
+}
+
+@Test
+public void minutesInRange() {
+Assert.assertEquals(59 * 60 * 1000, new GmtTimeZone(false, 0, 
59).getRawOffset());
+}
+
+@Test
+public void getOffset() {
+Assert.assertEquals(0, new GmtTimeZone(false, 0, 
0).getOffset(234304));
+}
+
+@Test(expected = UnsupportedOperationException.class)
+public void setRawOffset() {
+new GmtTimeZone(false, 0, 0).setRawOffset(0);
+}
+
+@Test
+public void getRawOffset() {
+Assert.assertEquals(0, new GmtTimeZone(false, 0, 
0).getRawOffset());
+}
+
+@Test
+public void getID() {
+Assert.assertEquals("GMT+00:00", new GmtTimeZone(false, 0, 
0).getID());
+Assert.assertEquals("GMT+01:02", new GmtTimeZone(false, 1, 
2).getID());
+Assert.assertEquals("GMT+11:22", new GmtTimeZone(false, 11, 
22).getID());
+Assert.assertEquals("GMT-01:02", new GmtTimeZone(true, 1, 
2).getID());
+Assert.assertEquals("GMT-11:22", new GmtTimeZone(true, 11, 
22).getID());
+}
+
+@Test
+public void useDaylightTime() {
+Assert.assertFalse(new GmtTimeZone(false, 0, 0).useDaylightTime());
+}
+
+@Test
+public void inDaylightTime() {
+Assert.assertFalse(new GmtTimeZone(false, 0, 0).useDaylightTime());
+}
--- End diff --

Maybe add something like

```
@Test
public void testToString() {
Assert.assertEquals("[GmtTimeZone 
id=\"GMT+23:00\",offset=8280]", new GmtTimeZone(false, 23, 0).toString());
}

@Test
public void testGetOffset() {
Assert.assertEquals(8280, new GmtTimeZone(false, 23, 
0).getOffset(1, 1, 1, 1, 1, 1));
}
```

With these two tests we reach 100% for GmtTimeZone.


---

[jira] [Commented] (LANG-1355) TimeZone.getTimeZone() in FastDateParser causes resource contention

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/LANG-1355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16198329#comment-16198329
 ] 

ASF GitHub Bot commented on LANG-1355:
--

Github user PascalSchumacher commented on the issue:

https://github.com/apache/commons-lang/pull/296
  
Looks good imho.  


> TimeZone.getTimeZone() in FastDateParser causes resource contention
> ---
>
> Key: LANG-1355
> URL: https://issues.apache.org/jira/browse/LANG-1355
> Project: Commons Lang
>  Issue Type: Bug
>  Components: lang.time.*
>Affects Versions: 3.6
> Environment: Windows
>Reporter: Keith Boone
>Assignee: Charles Honton
>   Original Estimate: 48h
>  Remaining Estimate: 48h
>
> Under heavy load we are seeing contention in FastDateParser.parse() on calls 
> to TimeZone.getTimeZone().  TimeZone.getTimeZone() is a synchronized static 
> in the Oracle JVM.
> Our proposed solution is to add a class TimeZoneCache containing a single 
> method getTimeZone() which gets the requested time zone from a ConcurrentMap, 
> and if not present, looks it up via TimeZone.getTimeZone() and caches it 
> before returning it.
> Then replace calls to TimeZone.getTimeZone() in FastDateParser ( and 
> whereever else) to calls to TimeZoneCache.getTimeZone().  
> The reason to add a separate class is because it can also be used by other 
> applications which heavily parse or format or do other things where TimeZone 
> is repeatedly needed.
> Under extreme load we have seen an 50:1 improvement in calls to 
> FastDateParser.parse().  This saves about a ms/call in our test environment, 
> and reduces contention.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] commons-lang issue #296: LANG-1355: Add FastTimeZone to decrease TimeZone.ge...

[PascalSchumacher]

Github user PascalSchumacher commented on the issue:

https://github.com/apache/commons-lang/pull/296
  
Looks good imho. 👍 


---