[jira] [Updated] (COMMONSSITE-86) Update Logo with new ASF Feather

[Rob Tompkins (Jira)]

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

Rob Tompkins updated COMMONSSITE-86:

Assignee: Rob Tompkins

> Update Logo with new ASF Feather
> 
>
> Key: COMMONSSITE-86
> URL: https://issues.apache.org/jira/browse/COMMONSSITE-86
> Project: Apache Commons All
>  Issue Type: Task
>Reporter: Benedikt Ritter
>Assignee: Rob Tompkins
>Priority: Major
> Attachments: commons-logo_new.svg, commons-logo_new1.png, 
> commons-logo_new2.png, commons-logo_new3.png, commons-logo_new4.png, 
> commons_logo.small.png
>
>
> We should create a new logo from the new ASF Feather logo 
> (https://blogs.apache.org/foundation/entry/the_apache_software_foundation_announces86)



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Resolved] (FILEUPLOAD-353) JakartaServletFileUpload.getItemIterator() not working in 2.0.0-M1

[Rob Tompkins (Jira)]

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

Rob Tompkins resolved FILEUPLOAD-353.
-
Resolution: Cannot Reproduce

I wrote a test for this and checked it in. It seems to not happen.

> JakartaServletFileUpload.getItemIterator() not working in 2.0.0-M1
> --
>
> Key: FILEUPLOAD-353
> URL: https://issues.apache.org/jira/browse/FILEUPLOAD-353
> Project: Commons FileUpload
>  Issue Type: Bug
>Reporter: Rob Tompkins
>Assignee: Rob Tompkins
>Priority: Major
>
> Using the following library:
> 
>   org.apache.commons
>   commons-fileupload2-jakarta
>   2.0.0-M1
> 
> The Streaming API (documented here FileUpload – The Streaming API 
> (apache.org))
>   does not return any items. I've tested the following code using postman and 
> curl to send a multipart/form-data request, in both cases getItemIterator 
> fails to return any items (internally it seems an exceptio is thrown):
> public ResponseEntity upload(HttpServletRequest request) throws 
> IOException {
>if (!JakartaServletFileUpload.isMultipartContent(request)) {
>throw new IllegalArgumentException("not multipart");
>}
>JakartaServletFileUpload upload = new JakartaServletFileUpload();
>upload.getItemIterator(request).forEachRemaining(item -> {
>String name = item.getFieldName();
>InputStream stream = item.getInputStream();
>if (item.isFormField()) {
>System.out.println("Form field " + name + " with value "
>+ convertInputStreamToString(stream) + " detected.");
>} else {
>System.out.println("File field " + name + " with file name "
>+ item.getName() + " detected.");
>// Process the input stream
>}
>});
>   ...
> }



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (FILEUPLOAD-353) JakartaServletFileUpload.getItemIterator() not working in 2.0.0-M1

[Rob Tompkins (Jira)]

[ 
https://issues.apache.org/jira/browse/FILEUPLOAD-353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17773744#comment-17773744
 ] 

Rob Tompkins commented on FILEUPLOAD-353:
-

I'm curious if an exception is really being thrown at all.

> JakartaServletFileUpload.getItemIterator() not working in 2.0.0-M1
> --
>
> Key: FILEUPLOAD-353
> URL: https://issues.apache.org/jira/browse/FILEUPLOAD-353
> Project: Commons FileUpload
>  Issue Type: Bug
>Reporter: Rob Tompkins
>Assignee: Rob Tompkins
>Priority: Major
>
> Using the following library:
> 
>   org.apache.commons
>   commons-fileupload2-jakarta
>   2.0.0-M1
> 
> The Streaming API (documented here FileUpload – The Streaming API 
> (apache.org))
>   does not return any items. I've tested the following code using postman and 
> curl to send a multipart/form-data request, in both cases getItemIterator 
> fails to return any items (internally it seems an exceptio is thrown):
> public ResponseEntity upload(HttpServletRequest request) throws 
> IOException {
>if (!JakartaServletFileUpload.isMultipartContent(request)) {
>throw new IllegalArgumentException("not multipart");
>}
>JakartaServletFileUpload upload = new JakartaServletFileUpload();
>upload.getItemIterator(request).forEachRemaining(item -> {
>String name = item.getFieldName();
>InputStream stream = item.getInputStream();
>if (item.isFormField()) {
>System.out.println("Form field " + name + " with value "
>+ convertInputStreamToString(stream) + " detected.");
>} else {
>System.out.println("File field " + name + " with file name "
>+ item.getName() + " detected.");
>// Process the input stream
>}
>});
>   ...
> }



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Comment Edited] (FILEUPLOAD-353) JakartaServletFileUpload.getItemIterator() not working in 2.0.0-M1

[Rob Tompkins (Jira)]

[ 
https://issues.apache.org/jira/browse/FILEUPLOAD-353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17773725#comment-17773725
 ] 

Rob Tompkins edited comment on FILEUPLOAD-353 at 10/10/23 4:07 PM:
---

Working on that. This is just something that came in from the user's list. I 
figure'd that I should log it here, but I'm a little lost with how to get the 
dev environment going to sort this one out. I suppose I'll write a test that 
does this and see what happens.


was (Author: chtompki):
Working on that. This is just something that came in from the user's 
listany suggestions on how I would go about testing this?

> JakartaServletFileUpload.getItemIterator() not working in 2.0.0-M1
> --
>
> Key: FILEUPLOAD-353
> URL: https://issues.apache.org/jira/browse/FILEUPLOAD-353
> Project: Commons FileUpload
>  Issue Type: Bug
>Reporter: Rob Tompkins
>Assignee: Rob Tompkins
>Priority: Major
>
> Using the following library:
> 
>   org.apache.commons
>   commons-fileupload2-jakarta
>   2.0.0-M1
> 
> The Streaming API (documented here FileUpload – The Streaming API 
> (apache.org))
>   does not return any items. I've tested the following code using postman and 
> curl to send a multipart/form-data request, in both cases getItemIterator 
> fails to return any items (internally it seems an exceptio is thrown):
> public ResponseEntity upload(HttpServletRequest request) throws 
> IOException {
>if (!JakartaServletFileUpload.isMultipartContent(request)) {
>throw new IllegalArgumentException("not multipart");
>}
>JakartaServletFileUpload upload = new JakartaServletFileUpload();
>upload.getItemIterator(request).forEachRemaining(item -> {
>String name = item.getFieldName();
>InputStream stream = item.getInputStream();
>if (item.isFormField()) {
>System.out.println("Form field " + name + " with value "
>+ convertInputStreamToString(stream) + " detected.");
>} else {
>System.out.println("File field " + name + " with file name "
>+ item.getName() + " detected.");
>// Process the input stream
>}
>});
>   ...
> }



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (FILEUPLOAD-353) JakartaServletFileUpload.getItemIterator() not working in 2.0.0-M1

[Rob Tompkins (Jira)]

[ 
https://issues.apache.org/jira/browse/FILEUPLOAD-353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17773725#comment-17773725
 ] 

Rob Tompkins commented on FILEUPLOAD-353:
-

Working on that. This is just something that came in from the user's 
listany suggestions on how I would go about testing this?

> JakartaServletFileUpload.getItemIterator() not working in 2.0.0-M1
> --
>
> Key: FILEUPLOAD-353
> URL: https://issues.apache.org/jira/browse/FILEUPLOAD-353
> Project: Commons FileUpload
>  Issue Type: Bug
>Reporter: Rob Tompkins
>Assignee: Rob Tompkins
>Priority: Major
>
> Using the following library:
> 
>   org.apache.commons
>   commons-fileupload2-jakarta
>   2.0.0-M1
> 
> The Streaming API (documented here FileUpload – The Streaming API 
> (apache.org))
>   does not return any items. I've tested the following code using postman and 
> curl to send a multipart/form-data request, in both cases getItemIterator 
> fails to return any items (internally it seems an exceptio is thrown):
> public ResponseEntity upload(HttpServletRequest request) throws 
> IOException {
>if (!JakartaServletFileUpload.isMultipartContent(request)) {
>throw new IllegalArgumentException("not multipart");
>}
>JakartaServletFileUpload upload = new JakartaServletFileUpload();
>upload.getItemIterator(request).forEachRemaining(item -> {
>String name = item.getFieldName();
>InputStream stream = item.getInputStream();
>if (item.isFormField()) {
>System.out.println("Form field " + name + " with value "
>+ convertInputStreamToString(stream) + " detected.");
>} else {
>System.out.println("File field " + name + " with file name "
>+ item.getName() + " detected.");
>// Process the input stream
>}
>});
>   ...
> }



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Created] (FILEUPLOAD-353) JakartaServletFileUpload.getItemIterator() not working in 2.0.0-M1

[Rob Tompkins (Jira)]

Rob Tompkins created FILEUPLOAD-353:
---

 Summary: JakartaServletFileUpload.getItemIterator() not working in 
2.0.0-M1
 Key: FILEUPLOAD-353
 URL: https://issues.apache.org/jira/browse/FILEUPLOAD-353
 Project: Commons FileUpload
  Issue Type: Bug
Reporter: Rob Tompkins
Assignee: Rob Tompkins


Using the following library:


  org.apache.commons
  commons-fileupload2-jakarta
  2.0.0-M1


The Streaming API (documented here FileUpload – The Streaming API 
(apache.org))
  does not return any items. I've tested the following code using postman and 
curl to send a multipart/form-data request, in both cases getItemIterator fails 
to return any items (internally it seems an exceptio is thrown):


public ResponseEntity upload(HttpServletRequest request) throws 
IOException {
   if (!JakartaServletFileUpload.isMultipartContent(request)) {
   throw new IllegalArgumentException("not multipart");
   }

   JakartaServletFileUpload upload = new JakartaServletFileUpload();

   upload.getItemIterator(request).forEachRemaining(item -> {
   String name = item.getFieldName();
   InputStream stream = item.getInputStream();
   if (item.isFormField()) {
   System.out.println("Form field " + name + " with value "
   + convertInputStreamToString(stream) + " detected.");
   } else {
   System.out.println("File field " + name + " with file name "
   + item.getName() + " detected.");
   // Process the input stream
   }
   });
  ...
}




--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (CONFIGURATION-812) Support for TOML configuration files

[Rob Tompkins (Jira)]

[ 
https://issues.apache.org/jira/browse/CONFIGURATION-812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17479004#comment-17479004
 ] 

Rob Tompkins commented on CONFIGURATION-812:


All help is welcome regardless of form. We need all the hands we can get :-)

> Support for TOML configuration files
> 
>
> Key: CONFIGURATION-812
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-812
> Project: Commons Configuration
>  Issue Type: New Feature
>  Components: Format
>Reporter: Thomas Reiter
>Priority: Minor
>
> I would like to add a parser and implementation for the TOML format (v1.0.0).
> Let me know, if you have any thoughts on this.
> See [TOML 1.0.0|https://toml.io/en/v1.0.0]
>  



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (COMMONSSITE-140) What are the benefits/advantages of using an Apache server over other servers?

[Rob Tompkins (Jira)]

[ 
https://issues.apache.org/jira/browse/COMMONSSITE-140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17239768#comment-17239768
 ] 

Rob Tompkins commented on COMMONSSITE-140:
--

Note, I think you’re looking for the Apache httpd server project. The 
“COMMONSSITE” jira project is dedicated to the Apache Commons Project’s  public 
website “http://commons.Apache.org”.  For questions about the httpd project, I 
would read over http://httpd.apache.org/ABOUT_APACHE.html

> What are the benefits/advantages of using an Apache server over other servers?
> --
>
> Key: COMMONSSITE-140
> URL: https://issues.apache.org/jira/browse/COMMONSSITE-140
> Project: Apache Commons All
>  Issue Type: Improvement
>  Components: Site
>Affects Versions: 29
>Reporter: avera
>Priority: Major
> Fix For: 1.2
>
>
> There are a lot of benefits that you get from using 
> [Apache|https://www.getcompanydetails.com/company/apache-applications-ltd-uk-06595956]
>  on your but before that, you need to have information on what Apache server 
> is? Apache can be defined as a server platform which is used by most of the 
> websites today. One can surely say that Apache has been one of the main 
> sources by which behind the expansion of the website across the internet. 
> Apache has set its standard and one of the main driving force behind other 
> server platforms. So today if you are looking to use Apache on your server, 
> then I would like to recommend you to go with HostingRaja dedicated hosting 
> plan which is the best option and also helps your website to load faster.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Resolved] (COMMONSSITE-138) Create Signature Validation script for releases

[Rob Tompkins (Jira)]

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

Rob Tompkins resolved COMMONSSITE-138.
--
Resolution: Fixed

> Create Signature Validation script for releases
> ---
>
> Key: COMMONSSITE-138
> URL: https://issues.apache.org/jira/browse/COMMONSSITE-138
> Project: Apache Commons All
>  Issue Type: New Feature
>  Components: Commons Release Plugin
>Affects Versions: 1.7
>Reporter: Rob Tompkins
>Assignee: Rob Tompkins
>Priority: Major
> Fix For: 1.8
>
>
> I would like to have a {{signature-validator.sh}} at the root of the svn 
> distribution directory that accommodates validating all the signatures of the 
> release artifact. Maybe this goes here, maybe this should go in the 
> individual components?
> For now I'm going to put it here for the sake of keeping things "DRY." I 
> think this file becomes complex for multi-module builds and we may want 
> individual projects to contribute their own signature-validator.sh file. I 
> think {{commons-rng}} will be a good place to show how to incorporate such a 
> customized file. (Happy to do the work myself)



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (COMMONSSITE-138) Create Signature Validation script for releases

[Rob Tompkins (Jira)]

Rob Tompkins created COMMONSSITE-138:


 Summary: Create Signature Validation script for releases
 Key: COMMONSSITE-138
 URL: https://issues.apache.org/jira/browse/COMMONSSITE-138
 Project: Apache Commons All
  Issue Type: New Feature
  Components: Commons Release Plugin
Affects Versions: 1.7
Reporter: Rob Tompkins
Assignee: Rob Tompkins
 Fix For: 1.8


I would like to have a {{signature-validator.sh}} at the root of the svn 
distribution director that accommodates validating all the signatures of the 
release artifact. Maybe this goes here, maybe this should go in the individual 
components?

For now I'm going to put it here for the sake of keeping things "DRY." I think 
this file becomes complex for multi-module builds and we may want individual 
projects to contribute their own signature-validator.sh file. I think 
{{commons-rng}} will be a good place to show how to incorporate such a 
customized file. (Happy to do the work myself)



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Resolved] (LANG-1549) implement TODO in CharSequenceUtils.lastIndexOf : remake it.

[Rob Tompkins (Jira)]

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

Rob Tompkins resolved LANG-1549.

Fix Version/s: 3.11
 Assignee: Rob Tompkins
   Resolution: Fixed

Merged with https://github.com/apache/commons-lang/pull/535

> implement TODO in CharSequenceUtils.lastIndexOf : remake it.
> 
>
> Key: LANG-1549
> URL: https://issues.apache.org/jira/browse/LANG-1549
> Project: Commons Lang
>  Issue Type: Improvement
>Reporter: Jin Xu
>Assignee: Rob Tompkins
>Priority: Major
> Fix For: 3.11
>
>  Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> [https://github.com/apache/commons-lang/pull/535]



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (CONFIGURATION-766) BigDecimal(double) should not be used

[Rob Tompkins (Jira)]

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

Rob Tompkins updated CONFIGURATION-766:
---
Assignee: Rob Tompkins

> BigDecimal(double) should not be used
> -
>
> Key: CONFIGURATION-766
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-766
> Project: Commons Configuration
>  Issue Type: Bug
> Environment: A single occurrence in file PropertyConverter.java, line 
> 393:
> {code:java}
> return new BigDecimal(n.doubleValue());
> {code}
>Reporter: Haris Adzemovic
>Assignee: Rob Tompkins
>Priority: Minor
>
> Static analysis with SonarQube shows a violation of rule 
> [S2111|[https://rules.sonarsource.com/java/type/Bug/RSPEC-2111]] - a 
> dangerous use of the BigDecimal constructor.
> Fixed by using BigDecimal.valueOf(param) instead.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (CODEC-239) Allows "look-alike" characters like 0 (digit zero) and 1 (digit one) as aliases for O (uppercase oh) and I (uppercase eye) respectively when decoding

[Rob Tompkins (Jira)]

[ 
https://issues.apache.org/jira/browse/CODEC-239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16939824#comment-16939824
 ] 

Rob Tompkins commented on CODEC-239:


Pardon my smileit was at the "only 2 years late." Gary's point here is 
fair...right? #3#3 ~= HEHE

That said usage dictates boundaries I suppose. Should be attempt to be like a 
dictionary and maintain the "language" boundary here as best we can?

> Allows "look-alike" characters like 0 (digit zero) and 1 (digit one) as 
> aliases for O (uppercase oh) and I (uppercase eye) respectively when decoding
> -
>
> Key: CODEC-239
> URL: https://issues.apache.org/jira/browse/CODEC-239
> Project: Commons Codec
>  Issue Type: Improvement
>Affects Versions: 1.10
>Reporter: Christopher Schultz
>Priority: Minor
>  Labels: patch-available
> Attachments: CODEC-239-2.diff, CODEC-239.diff
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Allowing {{1}} -> {{I}} and {{0}} -> {{O}} can help usability, especially for 
> human users who are entering data expected to be in base32-encoded format.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (CODEC-239) Allows "look-alike" characters like 0 (digit zero) and 1 (digit one) as aliases for O (uppercase oh) and I (uppercase eye) respectively when decoding

[Rob Tompkins (Jira)]

[ 
https://issues.apache.org/jira/browse/CODEC-239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16939816#comment-16939816
 ] 

Rob Tompkins commented on CODEC-239:


:-)

> Allows "look-alike" characters like 0 (digit zero) and 1 (digit one) as 
> aliases for O (uppercase oh) and I (uppercase eye) respectively when decoding
> -
>
> Key: CODEC-239
> URL: https://issues.apache.org/jira/browse/CODEC-239
> Project: Commons Codec
>  Issue Type: Improvement
>Affects Versions: 1.10
>Reporter: Christopher Schultz
>Priority: Minor
>  Labels: patch-available
> Attachments: CODEC-239-2.diff, CODEC-239.diff
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Allowing {{1}} -> {{I}} and {{0}} -> {{O}} can help usability, especially for 
> human users who are entering data expected to be in base32-encoded format.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (BEANUTILS-520) BeanUtils2 mitigate CVE-2014-0114

[Rob Tompkins (JIRA)]

[ 
https://issues.apache.org/jira/browse/BEANUTILS-520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16910001#comment-16910001
 ] 

Rob Tompkins commented on BEANUTILS-520:


I’m planning to get to it soon. 

> BeanUtils2 mitigate CVE-2014-0114
> -
>
> Key: BEANUTILS-520
> URL: https://issues.apache.org/jira/browse/BEANUTILS-520
> Project: Commons BeanUtils
>  Issue Type: Improvement
>  Components: Bean / Property Utils
>Affects Versions: 1.9.3
>Reporter: Melloware
>Assignee: Rob Tompkins
>Priority: Major
>  Labels: security
> Fix For: 1.9.4, 2.0.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> https://nvd.nist.gov/vuln/detail/CVE-2014-0114
> Due to the above CVE in 1.9.2 they added a Suppression but it is still being 
> marked as a security risk through most major checks from OWASP and Sonatype 
> IQ.
> "commons-beanutils added a SuppressPropertiesBeanIntrospector which includes 
> a specialized instance of itself as the SUPPRESS_CLASS constant beginning in 
> version 1.9.2 that specifically suppresses the class property. +However, this 
> fix is not enabled by default.+"
> For BeanUtils2 why not make this the default and have people "enable" it if 
> it they want to get the feature.
> Thanks for your consideration.
>  



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

[jira] [Reopened] (MATH-1490) Percentile computational accuracy issue

[Rob Tompkins (JIRA)]

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

Rob Tompkins reopened MATH-1490:


Test case is different.

> Percentile computational accuracy issue
> ---
>
> Key: MATH-1490
> URL: https://issues.apache.org/jira/browse/MATH-1490
> Project: Commons Math
>  Issue Type: Bug
>Affects Versions: 3.4, 3.4.1, 3.5, 3.6, 3.6.1
> Environment: System: Linux testinglab 4.4.0-131-generic 
> #157~14.04.1-Ubuntu
> Java version "1.8.0_191"
> Java(TM) SE Runtime Environment (build 1.8.0_191-b12)
> Java HotSpot(TM) 64-Bit Server VM (build 25.191-b12, mixed mode)
>  
>  
>Reporter: Lingchao Chen
>Assignee: Rob Tompkins
>Priority: Major
>  Labels: performance
> Attachments: BugDemo.java
>
>
> The percentile method works well on the older versions, e.g., the version 
> before 3.4. However, when I update commons-math to the newer version, there 
> produces a computational accuracy issue. There is a backward compatibility 
> bug behind it.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Closed] (MATH-1490) Percentile computational accuracy issue

[Rob Tompkins (JIRA)]

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

Rob Tompkins closed MATH-1490.
--
Resolution: Duplicate
  Assignee: Rob Tompkins

> Percentile computational accuracy issue
> ---
>
> Key: MATH-1490
> URL: https://issues.apache.org/jira/browse/MATH-1490
> Project: Commons Math
>  Issue Type: Bug
>Affects Versions: 3.4, 3.4.1, 3.5, 3.6, 3.6.1
> Environment: System: Linux testinglab 4.4.0-131-generic 
> #157~14.04.1-Ubuntu
> Java version "1.8.0_191"
> Java(TM) SE Runtime Environment (build 1.8.0_191-b12)
> Java HotSpot(TM) 64-Bit Server VM (build 25.191-b12, mixed mode)
>  
>  
>Reporter: Lingchao Chen
>Assignee: Rob Tompkins
>Priority: Major
>  Labels: performance
> Attachments: BugDemo.java
>
>
> The percentile method works well on the older versions, e.g., the version 
> before 3.4. However, when I update commons-math to the newer version, there 
> produces a computational accuracy issue. There is a backward compatibility 
> bug behind it.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MATH-1491) Percentile computational accuracy issue

[Rob Tompkins (JIRA)]

[ 
https://issues.apache.org/jira/browse/MATH-1491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16868734#comment-16868734
 ] 

Rob Tompkins commented on MATH-1491:


I meant to link this one [~erans], to STATISTICS-7

> Percentile computational accuracy issue
> ---
>
> Key: MATH-1491
> URL: https://issues.apache.org/jira/browse/MATH-1491
> Project: Commons Math
>  Issue Type: Bug
>Affects Versions: 3.4, 3.4.1, 3.5, 3.6, 3.6.1
> Environment: System: Linux testinglab 4.4.0-131-generic 
> #157~14.04.1-Ubuntu
> Java version "1.8.0_191"
> Java(TM) SE Runtime Environment (build 1.8.0_191-b12)
> Java HotSpot(TM) 64-Bit Server VM (build 25.191-b12, mixed mode)
>  
>  
>Reporter: Lingchao Chen
>Priority: Major
>  Labels: performance
> Attachments: BugDemo.java
>
>
> Hi, 
> The percentile method works well on the older versions, e.g., the version 
> before 3.4. However, when I update commons-math to the newer version, there 
> produces a computational accuracy issue. There is a backward compatibility 
> bug behind it.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MATH-1490) Percentile computational accuracy issue

[Rob Tompkins (JIRA)]

[ 
https://issues.apache.org/jira/browse/MATH-1490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16868732#comment-16868732
 ] 

Rob Tompkins commented on MATH-1490:


I think [~erans] wanted to link this over to STATISTICS-7 too.

> Percentile computational accuracy issue
> ---
>
> Key: MATH-1490
> URL: https://issues.apache.org/jira/browse/MATH-1490
> Project: Commons Math
>  Issue Type: Bug
>Affects Versions: 3.4, 3.4.1, 3.5, 3.6, 3.6.1
> Environment: System: Linux testinglab 4.4.0-131-generic 
> #157~14.04.1-Ubuntu
> Java version "1.8.0_191"
> Java(TM) SE Runtime Environment (build 1.8.0_191-b12)
> Java HotSpot(TM) 64-Bit Server VM (build 25.191-b12, mixed mode)
>  
>  
>Reporter: Lingchao Chen
>Priority: Major
>  Labels: performance
> Attachments: BugDemo.java
>
>
> The percentile method works well on the older versions, e.g., the version 
> before 3.4. However, when I update commons-math to the newer version, there 
> produces a computational accuracy issue. There is a backward compatibility 
> bug behind it.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (BEANUTILS-520) BeanUtils2 mitigate CVE-2014-0114

[Rob Tompkins (JIRA)]

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

Rob Tompkins updated BEANUTILS-520:
---
Fix Version/s: 1.9.4

> BeanUtils2 mitigate CVE-2014-0114
> -
>
> Key: BEANUTILS-520
> URL: https://issues.apache.org/jira/browse/BEANUTILS-520
> Project: Commons BeanUtils
>  Issue Type: Improvement
>  Components: Bean / Property Utils
>Affects Versions: 1.9.3
>Reporter: Melloware
>Assignee: Rob Tompkins
>Priority: Major
>  Labels: security
> Fix For: 1.9.4, 2.0.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> https://nvd.nist.gov/vuln/detail/CVE-2014-0114
> Due to the above CVE in 1.9.2 they added a Suppression but it is still being 
> marked as a security risk through most major checks from OWASP and Sonatype 
> IQ.
> "commons-beanutils added a SuppressPropertiesBeanIntrospector which includes 
> a specialized instance of itself as the SUPPRESS_CLASS constant beginning in 
> version 1.9.2 that specifically suppresses the class property. +However, this 
> fix is not enabled by default.+"
> For BeanUtils2 why not make this the default and have people "enable" it if 
> it they want to get the feature.
> Thanks for your consideration.
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (BEANUTILS-520) BeanUtils2 mitigate CVE-2014-0114

[Rob Tompkins (JIRA)]

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

Rob Tompkins resolved BEANUTILS-520.

Resolution: Fixed

> BeanUtils2 mitigate CVE-2014-0114
> -
>
> Key: BEANUTILS-520
> URL: https://issues.apache.org/jira/browse/BEANUTILS-520
> Project: Commons BeanUtils
>  Issue Type: Improvement
>  Components: Bean / Property Utils
>Affects Versions: 1.9.3
>Reporter: Melloware
>Assignee: Rob Tompkins
>Priority: Major
>  Labels: security
> Fix For: 1.9.4, 2.0.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> https://nvd.nist.gov/vuln/detail/CVE-2014-0114
> Due to the above CVE in 1.9.2 they added a Suppression but it is still being 
> marked as a security risk through most major checks from OWASP and Sonatype 
> IQ.
> "commons-beanutils added a SuppressPropertiesBeanIntrospector which includes 
> a specialized instance of itself as the SUPPRESS_CLASS constant beginning in 
> version 1.9.2 that specifically suppresses the class property. +However, this 
> fix is not enabled by default.+"
> For BeanUtils2 why not make this the default and have people "enable" it if 
> it they want to get the feature.
> Thanks for your consideration.
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Reopened] (BEANUTILS-520) BeanUtils2 mitigate CVE-2014-0114

[Rob Tompkins (JIRA)]

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

Rob Tompkins reopened BEANUTILS-520:

  Assignee: Rob Tompkins

> BeanUtils2 mitigate CVE-2014-0114
> -
>
> Key: BEANUTILS-520
> URL: https://issues.apache.org/jira/browse/BEANUTILS-520
> Project: Commons BeanUtils
>  Issue Type: Improvement
>  Components: Bean / Property Utils
>Affects Versions: 1.9.3
>Reporter: Melloware
>Assignee: Rob Tompkins
>Priority: Major
>  Labels: security
> Fix For: 2.0.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> https://nvd.nist.gov/vuln/detail/CVE-2014-0114
> Due to the above CVE in 1.9.2 they added a Suppression but it is still being 
> marked as a security risk through most major checks from OWASP and Sonatype 
> IQ.
> "commons-beanutils added a SuppressPropertiesBeanIntrospector which includes 
> a specialized instance of itself as the SUPPRESS_CLASS constant beginning in 
> version 1.9.2 that specifically suppresses the class property. +However, this 
> fix is not enabled by default.+"
> For BeanUtils2 why not make this the default and have people "enable" it if 
> it they want to get the feature.
> Thanks for your consideration.
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (LANG-1453) StringUtils.removeIgnoreCase("İa", "a") throws IndexOutOfBoundsException

[Rob Tompkins (JIRA)]

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

Rob Tompkins commented on LANG-1453:


There are some curiosities when dealing with Unicode characters that are 
outside the standard UTF-8 character set. I’m working on a separate set of 
UnicodeStringUtils due to the slow running nature of dealing with “surrogate 
pairs.”

> StringUtils.removeIgnoreCase("İa", "a") throws IndexOutOfBoundsException
> 
>
> Key: LANG-1453
> URL: https://issues.apache.org/jira/browse/LANG-1453
> Project: Commons Lang
>  Issue Type: Bug
>  Components: lang.text.*
>Affects Versions: 3.8.1
>Reporter: Thomas Neerup
>Priority: Critical
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> *try* {
> String s = StringUtils._removeIgnoreCase_("İa", "a");
> } *catch* (Exception e) {
> e.printStackTrace();
> }
> output
> java.lang.IndexOutOfBoundsException: start 3, end 2, s.length() 2
> at java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:539)
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (LANG-1451) Should there be a better implementation of substring that deals with Unicode surrogate pairs correctly?

[Rob Tompkins (JIRA)]

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

Rob Tompkins commented on LANG-1451:


Huge performance degradations. My implementation above takes approximately 4.21 
times longer than the original implementation. {{UnicodeStringUtils}} seems the 
most reasonable I think?

> Should there be a better implementation of substring that deals with Unicode 
> surrogate pairs correctly?
> ---
>
> Key: LANG-1451
> URL: https://issues.apache.org/jira/browse/LANG-1451
> Project: Commons Lang
>  Issue Type: New Feature
>Affects Versions: 3.9
> Environment: Any
>Reporter: Sebastiaan
>Assignee: Rob Tompkins
>Priority: Minor
>  Labels: features
>
> There are some major problems with Java's substring implementation which 
> works using chars. For a brief overview read this blog post: 
> [https://codeahoy.com/2016/05/08/the-char-type-in-java-is-broken/]
>  
> I have some demo code showing the issues and a possible solution here:
> {code:java}
> public class SubstringTest {
> public static void main(String[] args) {
> String stringWithPlus2ByteCodePoints = "";
> String substring1 = stringWithPlus2ByteCodePoints.substring(0, 1);
> String substring2 = stringWithPlus2ByteCodePoints.substring(0, 2);
> String substring3 = stringWithPlus2ByteCodePoints.substring(1, 3);
> System.out.println(stringWithPlus2ByteCodePoints);
> System.out.println("invalid sub: " + substring1);
> System.out.println("invalid sub: " + substring2);
> System.out.println("invalid sub: " + substring3);
> String realSub1 = getRealSubstring(stringWithPlus2ByteCodePoints, 0, 
> 1);
> String realSub2 = getRealSubstring(stringWithPlus2ByteCodePoints, 0, 
> 2);
> String realSub3 = getRealSubstring(stringWithPlus2ByteCodePoints, 1, 
> 3);
> System.out.println("real sub: " + realSub1);
> System.out.println("real sub: " + realSub2);
> System.out.println("real sub: " + realSub3);
> }
> private static String getRealSubstring(String string, int beginIndex, int 
> endIndex) {
> if (string == null)
> throw new IllegalArgumentException("String should not be null");
> int length = string.length();
> if (endIndex < 0 || beginIndex > endIndex || beginIndex > length || 
> endIndex > length)
> throw new IllegalArgumentException("Invalid indices");
> int realBeginIndex = string.offsetByCodePoints(0, beginIndex);
> int realEndIndex = string.offsetByCodePoints(0, endIndex);
> return string.substring(realBeginIndex, realEndIndex);
> }
> }{code}
> The output is:
> {noformat}
> 
> invalid sub: ?
> invalid sub: 
> invalid sub: ??
> real sub: 
> real sub: 
> real sub: {noformat}
>  
> The same issues appear in Apache Commons Text's substring method.
> Should Apache Commons Text use this code or something similar in the 
> substring implementation, rather than the flawed Java substring method? Or at 
> least offer an additional utility method that does take a string with unicode 
> codepoints that require surrogate pairs and substrings it correctly?
>  I also posted my implementation at 
> [https://stackoverflow.com/questions/55663213/java-substring-by-code-point-indices-treating-pairs-of-surrogate-code-units-as/]
>  asking for advice and there is a more robust version as an answer.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (LANG-1451) Should there be a better implementation of substring that deals with Unicode surrogate pairs correctly?

[Rob Tompkins (JIRA)]

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

Rob Tompkins commented on LANG-1451:


If so, then we'd clearly want separate methods I would think

> Should there be a better implementation of substring that deals with Unicode 
> surrogate pairs correctly?
> ---
>
> Key: LANG-1451
> URL: https://issues.apache.org/jira/browse/LANG-1451
> Project: Commons Lang
>  Issue Type: New Feature
>Affects Versions: 3.9
> Environment: Any
>Reporter: Sebastiaan
>Assignee: Rob Tompkins
>Priority: Minor
>  Labels: features
>
> There are some major problems with Java's substring implementation which 
> works using chars. For a brief overview read this blog post: 
> [https://codeahoy.com/2016/05/08/the-char-type-in-java-is-broken/]
>  
> I have some demo code showing the issues and a possible solution here:
> {code:java}
> public class SubstringTest {
> public static void main(String[] args) {
> String stringWithPlus2ByteCodePoints = "";
> String substring1 = stringWithPlus2ByteCodePoints.substring(0, 1);
> String substring2 = stringWithPlus2ByteCodePoints.substring(0, 2);
> String substring3 = stringWithPlus2ByteCodePoints.substring(1, 3);
> System.out.println(stringWithPlus2ByteCodePoints);
> System.out.println("invalid sub: " + substring1);
> System.out.println("invalid sub: " + substring2);
> System.out.println("invalid sub: " + substring3);
> String realSub1 = getRealSubstring(stringWithPlus2ByteCodePoints, 0, 
> 1);
> String realSub2 = getRealSubstring(stringWithPlus2ByteCodePoints, 0, 
> 2);
> String realSub3 = getRealSubstring(stringWithPlus2ByteCodePoints, 1, 
> 3);
> System.out.println("real sub: " + realSub1);
> System.out.println("real sub: " + realSub2);
> System.out.println("real sub: " + realSub3);
> }
> private static String getRealSubstring(String string, int beginIndex, int 
> endIndex) {
> if (string == null)
> throw new IllegalArgumentException("String should not be null");
> int length = string.length();
> if (endIndex < 0 || beginIndex > endIndex || beginIndex > length || 
> endIndex > length)
> throw new IllegalArgumentException("Invalid indices");
> int realBeginIndex = string.offsetByCodePoints(0, beginIndex);
> int realEndIndex = string.offsetByCodePoints(0, endIndex);
> return string.substring(realBeginIndex, realEndIndex);
> }
> }{code}
> The output is:
> {noformat}
> 
> invalid sub: ?
> invalid sub: 
> invalid sub: ??
> real sub: 
> real sub: 
> real sub: {noformat}
>  
> The same issues appear in Apache Commons Text's substring method.
> Should Apache Commons Text use this code or something similar in the 
> substring implementation, rather than the flawed Java substring method? Or at 
> least offer an additional utility method that does take a string with unicode 
> codepoints that require surrogate pairs and substrings it correctly?
>  I also posted my implementation at 
> [https://stackoverflow.com/questions/55663213/java-substring-by-code-point-indices-treating-pairs-of-surrogate-code-units-as/]
>  asking for advice and there is a more robust version as an answer.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Comment Edited] (LANG-1451) Should there be a better implementation of substring that deals with Unicode surrogate pairs correctly?

[Rob Tompkins (JIRA)]

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

Rob Tompkins edited comment on LANG-1451 at 4/30/19 1:02 PM:
-

maybe rename the variables to analogs of {{startOffsetByCodePoints}}


was (Author: chtompki):
maybe rename the variables to {{startOffsetByCodePoints}}

> Should there be a better implementation of substring that deals with Unicode 
> surrogate pairs correctly?
> ---
>
> Key: LANG-1451
> URL: https://issues.apache.org/jira/browse/LANG-1451
> Project: Commons Lang
>  Issue Type: New Feature
>Affects Versions: 3.9
> Environment: Any
>Reporter: Sebastiaan
>Assignee: Rob Tompkins
>Priority: Minor
>  Labels: features
>
> There are some major problems with Java's substring implementation which 
> works using chars. For a brief overview read this blog post: 
> [https://codeahoy.com/2016/05/08/the-char-type-in-java-is-broken/]
>  
> I have some demo code showing the issues and a possible solution here:
> {code:java}
> public class SubstringTest {
> public static void main(String[] args) {
> String stringWithPlus2ByteCodePoints = "";
> String substring1 = stringWithPlus2ByteCodePoints.substring(0, 1);
> String substring2 = stringWithPlus2ByteCodePoints.substring(0, 2);
> String substring3 = stringWithPlus2ByteCodePoints.substring(1, 3);
> System.out.println(stringWithPlus2ByteCodePoints);
> System.out.println("invalid sub: " + substring1);
> System.out.println("invalid sub: " + substring2);
> System.out.println("invalid sub: " + substring3);
> String realSub1 = getRealSubstring(stringWithPlus2ByteCodePoints, 0, 
> 1);
> String realSub2 = getRealSubstring(stringWithPlus2ByteCodePoints, 0, 
> 2);
> String realSub3 = getRealSubstring(stringWithPlus2ByteCodePoints, 1, 
> 3);
> System.out.println("real sub: " + realSub1);
> System.out.println("real sub: " + realSub2);
> System.out.println("real sub: " + realSub3);
> }
> private static String getRealSubstring(String string, int beginIndex, int 
> endIndex) {
> if (string == null)
> throw new IllegalArgumentException("String should not be null");
> int length = string.length();
> if (endIndex < 0 || beginIndex > endIndex || beginIndex > length || 
> endIndex > length)
> throw new IllegalArgumentException("Invalid indices");
> int realBeginIndex = string.offsetByCodePoints(0, beginIndex);
> int realEndIndex = string.offsetByCodePoints(0, endIndex);
> return string.substring(realBeginIndex, realEndIndex);
> }
> }{code}
> The output is:
> {noformat}
> 
> invalid sub: ?
> invalid sub: 
> invalid sub: ??
> real sub: 
> real sub: 
> real sub: {noformat}
>  
> The same issues appear in Apache Commons Text's substring method.
> Should Apache Commons Text use this code or something similar in the 
> substring implementation, rather than the flawed Java substring method? Or at 
> least offer an additional utility method that does take a string with unicode 
> codepoints that require surrogate pairs and substrings it correctly?
>  I also posted my implementation at 
> [https://stackoverflow.com/questions/55663213/java-substring-by-code-point-indices-treating-pairs-of-surrogate-code-units-as/]
>  asking for advice and there is a more robust version as an answer.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (LANG-1451) Should there be a better implementation of substring that deals with Unicode surrogate pairs correctly?

[Rob Tompkins (JIRA)]

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

Rob Tompkins commented on LANG-1451:


maybe rename the variables to {{startOffsetByCodePoints}}

> Should there be a better implementation of substring that deals with Unicode 
> surrogate pairs correctly?
> ---
>
> Key: LANG-1451
> URL: https://issues.apache.org/jira/browse/LANG-1451
> Project: Commons Lang
>  Issue Type: New Feature
>Affects Versions: 3.9
> Environment: Any
>Reporter: Sebastiaan
>Assignee: Rob Tompkins
>Priority: Minor
>  Labels: features
>
> There are some major problems with Java's substring implementation which 
> works using chars. For a brief overview read this blog post: 
> [https://codeahoy.com/2016/05/08/the-char-type-in-java-is-broken/]
>  
> I have some demo code showing the issues and a possible solution here:
> {code:java}
> public class SubstringTest {
> public static void main(String[] args) {
> String stringWithPlus2ByteCodePoints = "";
> String substring1 = stringWithPlus2ByteCodePoints.substring(0, 1);
> String substring2 = stringWithPlus2ByteCodePoints.substring(0, 2);
> String substring3 = stringWithPlus2ByteCodePoints.substring(1, 3);
> System.out.println(stringWithPlus2ByteCodePoints);
> System.out.println("invalid sub: " + substring1);
> System.out.println("invalid sub: " + substring2);
> System.out.println("invalid sub: " + substring3);
> String realSub1 = getRealSubstring(stringWithPlus2ByteCodePoints, 0, 
> 1);
> String realSub2 = getRealSubstring(stringWithPlus2ByteCodePoints, 0, 
> 2);
> String realSub3 = getRealSubstring(stringWithPlus2ByteCodePoints, 1, 
> 3);
> System.out.println("real sub: " + realSub1);
> System.out.println("real sub: " + realSub2);
> System.out.println("real sub: " + realSub3);
> }
> private static String getRealSubstring(String string, int beginIndex, int 
> endIndex) {
> if (string == null)
> throw new IllegalArgumentException("String should not be null");
> int length = string.length();
> if (endIndex < 0 || beginIndex > endIndex || beginIndex > length || 
> endIndex > length)
> throw new IllegalArgumentException("Invalid indices");
> int realBeginIndex = string.offsetByCodePoints(0, beginIndex);
> int realEndIndex = string.offsetByCodePoints(0, endIndex);
> return string.substring(realBeginIndex, realEndIndex);
> }
> }{code}
> The output is:
> {noformat}
> 
> invalid sub: ?
> invalid sub: 
> invalid sub: ??
> real sub: 
> real sub: 
> real sub: {noformat}
>  
> The same issues appear in Apache Commons Text's substring method.
> Should Apache Commons Text use this code or something similar in the 
> substring implementation, rather than the flawed Java substring method? Or at 
> least offer an additional utility method that does take a string with unicode 
> codepoints that require surrogate pairs and substrings it correctly?
>  I also posted my implementation at 
> [https://stackoverflow.com/questions/55663213/java-substring-by-code-point-indices-treating-pairs-of-surrogate-code-units-as/]
>  asking for advice and there is a more robust version as an answer.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (LANG-1451) Should there be a better implementation of substring that deals with Unicode surrogate pairs correctly?

[Rob Tompkins (JIRA)]

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

Rob Tompkins commented on LANG-1451:


Actuallyif we make our {{substring}} method the following:

{code:java}
public static String substring(final String str, int start, int end) {
if (str == null) {
return null;
}

// handle negatives
if (end < 0) {
end = str.length() + end; // remember end is negative
}
if (start < 0) {
start = str.length() + start; // remember start is negative
}

// check length next
if (end > str.length()) {
end = str.length();
}

// if start is greater than end, return ""
if (start > end) {
return EMPTY;
}

if (start < 0) {
start = 0;
}
if (end < 0) {
end = 0;
}
int realUtf16Start = str.offsetByCodePoints(0, start);
int realUtf16End = str.offsetByCodePoints(0, end);
return str.substring(realUtf16Start, realUtf16End);
}
{code}

we're just good. I think this is likely the best path.

> Should there be a better implementation of substring that deals with Unicode 
> surrogate pairs correctly?
> ---
>
> Key: LANG-1451
> URL: https://issues.apache.org/jira/browse/LANG-1451
> Project: Commons Lang
>  Issue Type: New Feature
>Affects Versions: 3.9
> Environment: Any
>Reporter: Sebastiaan
>Assignee: Rob Tompkins
>Priority: Minor
>  Labels: features
>
> There are some major problems with Java's substring implementation which 
> works using chars. For a brief overview read this blog post: 
> [https://codeahoy.com/2016/05/08/the-char-type-in-java-is-broken/]
>  
> I have some demo code showing the issues and a possible solution here:
> {code:java}
> public class SubstringTest {
> public static void main(String[] args) {
> String stringWithPlus2ByteCodePoints = "";
> String substring1 = stringWithPlus2ByteCodePoints.substring(0, 1);
> String substring2 = stringWithPlus2ByteCodePoints.substring(0, 2);
> String substring3 = stringWithPlus2ByteCodePoints.substring(1, 3);
> System.out.println(stringWithPlus2ByteCodePoints);
> System.out.println("invalid sub: " + substring1);
> System.out.println("invalid sub: " + substring2);
> System.out.println("invalid sub: " + substring3);
> String realSub1 = getRealSubstring(stringWithPlus2ByteCodePoints, 0, 
> 1);
> String realSub2 = getRealSubstring(stringWithPlus2ByteCodePoints, 0, 
> 2);
> String realSub3 = getRealSubstring(stringWithPlus2ByteCodePoints, 1, 
> 3);
> System.out.println("real sub: " + realSub1);
> System.out.println("real sub: " + realSub2);
> System.out.println("real sub: " + realSub3);
> }
> private static String getRealSubstring(String string, int beginIndex, int 
> endIndex) {
> if (string == null)
> throw new IllegalArgumentException("String should not be null");
> int length = string.length();
> if (endIndex < 0 || beginIndex > endIndex || beginIndex > length || 
> endIndex > length)
> throw new IllegalArgumentException("Invalid indices");
> int realBeginIndex = string.offsetByCodePoints(0, beginIndex);
> int realEndIndex = string.offsetByCodePoints(0, endIndex);
> return string.substring(realBeginIndex, realEndIndex);
> }
> }{code}
> The output is:
> {noformat}
> 
> invalid sub: ?
> invalid sub: 
> invalid sub: ??
> real sub: 
> real sub: 
> real sub: {noformat}
>  
> The same issues appear in Apache Commons Text's substring method.
> Should Apache Commons Text use this code or something similar in the 
> substring implementation, rather than the flawed Java substring method? Or at 
> least offer an additional utility method that does take a string with unicode 
> codepoints that require surrogate pairs and substrings it correctly?
>  I also posted my implementation at 
> [https://stackoverflow.com/questions/55663213/java-substring-by-code-point-indices-treating-pairs-of-surrogate-code-units-as/]
>  asking for advice and there is a more robust version as an answer.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (LANG-1451) Should there be a better implementation of substring that deals with Unicode surrogate pairs correctly?

[Rob Tompkins (JIRA)]

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

Rob Tompkins commented on LANG-1451:


Do we want to call these methods {{codePointSubstring}} and 
{{codePointLastIndexOf}}? The accepted answer to the "question" in 
stackoverflow would indicate that to be a good naming convention for such a 
method.

> Should there be a better implementation of substring that deals with Unicode 
> surrogate pairs correctly?
> ---
>
> Key: LANG-1451
> URL: https://issues.apache.org/jira/browse/LANG-1451
> Project: Commons Lang
>  Issue Type: New Feature
>Affects Versions: 3.9
> Environment: Any
>Reporter: Sebastiaan
>Assignee: Rob Tompkins
>Priority: Minor
>  Labels: features
>
> There are some major problems with Java's substring implementation which 
> works using chars. For a brief overview read this blog post: 
> [https://codeahoy.com/2016/05/08/the-char-type-in-java-is-broken/]
>  
> I have some demo code showing the issues and a possible solution here:
> {code:java}
> public class SubstringTest {
> public static void main(String[] args) {
> String stringWithPlus2ByteCodePoints = "";
> String substring1 = stringWithPlus2ByteCodePoints.substring(0, 1);
> String substring2 = stringWithPlus2ByteCodePoints.substring(0, 2);
> String substring3 = stringWithPlus2ByteCodePoints.substring(1, 3);
> System.out.println(stringWithPlus2ByteCodePoints);
> System.out.println("invalid sub: " + substring1);
> System.out.println("invalid sub: " + substring2);
> System.out.println("invalid sub: " + substring3);
> String realSub1 = getRealSubstring(stringWithPlus2ByteCodePoints, 0, 
> 1);
> String realSub2 = getRealSubstring(stringWithPlus2ByteCodePoints, 0, 
> 2);
> String realSub3 = getRealSubstring(stringWithPlus2ByteCodePoints, 1, 
> 3);
> System.out.println("real sub: " + realSub1);
> System.out.println("real sub: " + realSub2);
> System.out.println("real sub: " + realSub3);
> }
> private static String getRealSubstring(String string, int beginIndex, int 
> endIndex) {
> if (string == null)
> throw new IllegalArgumentException("String should not be null");
> int length = string.length();
> if (endIndex < 0 || beginIndex > endIndex || beginIndex > length || 
> endIndex > length)
> throw new IllegalArgumentException("Invalid indices");
> int realBeginIndex = string.offsetByCodePoints(0, beginIndex);
> int realEndIndex = string.offsetByCodePoints(0, endIndex);
> return string.substring(realBeginIndex, realEndIndex);
> }
> }{code}
> The output is:
> {noformat}
> 
> invalid sub: ?
> invalid sub: 
> invalid sub: ??
> real sub: 
> real sub: 
> real sub: {noformat}
>  
> The same issues appear in Apache Commons Text's substring method.
> Should Apache Commons Text use this code or something similar in the 
> substring implementation, rather than the flawed Java substring method? Or at 
> least offer an additional utility method that does take a string with unicode 
> codepoints that require surrogate pairs and substrings it correctly?
>  I also posted my implementation at 
> [https://stackoverflow.com/questions/55663213/java-substring-by-code-point-indices-treating-pairs-of-surrogate-code-units-as/]
>  asking for advice and there is a more robust version as an answer.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (LANG-1451) Should there be a better implementation of substring that deals with Unicode surrogate pairs correctly?

[Rob Tompkins (JIRA)]

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

Rob Tompkins commented on LANG-1451:


[~Sebastiaan83] - when I try to even instantiate a string like one of those 
above, I am unable to do so. Do you have some special settings such that you 
can instantiate such strings? For example I get the followoing:

{code:java}
System.out.println(""); \\ 
{code}

The best thing that I could do to get the output was to do the following:

{code:java}
String PLUS_2_BYTE_CODE_POINTS = 
"\uD83D\uDC66\uD83D\uDC69\uD83D\uDC6A\uD83D\uDC6B";
{code}

Does that work for you?

> Should there be a better implementation of substring that deals with Unicode 
> surrogate pairs correctly?
> ---
>
> Key: LANG-1451
> URL: https://issues.apache.org/jira/browse/LANG-1451
> Project: Commons Lang
>  Issue Type: New Feature
>Affects Versions: 3.9
> Environment: Any
>Reporter: Sebastiaan
>Assignee: Rob Tompkins
>Priority: Minor
>  Labels: features
>
> There are some major problems with Java's substring implementation which 
> works using chars. For a brief overview read this blog post: 
> [https://codeahoy.com/2016/05/08/the-char-type-in-java-is-broken/]
>  
> I have some demo code showing the issues and a possible solution here:
> {code:java}
> public class SubstringTest {
> public static void main(String[] args) {
> String stringWithPlus2ByteCodePoints = "";
> String substring1 = stringWithPlus2ByteCodePoints.substring(0, 1);
> String substring2 = stringWithPlus2ByteCodePoints.substring(0, 2);
> String substring3 = stringWithPlus2ByteCodePoints.substring(1, 3);
> System.out.println(stringWithPlus2ByteCodePoints);
> System.out.println("invalid sub: " + substring1);
> System.out.println("invalid sub: " + substring2);
> System.out.println("invalid sub: " + substring3);
> String realSub1 = getRealSubstring(stringWithPlus2ByteCodePoints, 0, 
> 1);
> String realSub2 = getRealSubstring(stringWithPlus2ByteCodePoints, 0, 
> 2);
> String realSub3 = getRealSubstring(stringWithPlus2ByteCodePoints, 1, 
> 3);
> System.out.println("real sub: " + realSub1);
> System.out.println("real sub: " + realSub2);
> System.out.println("real sub: " + realSub3);
> }
> private static String getRealSubstring(String string, int beginIndex, int 
> endIndex) {
> if (string == null)
> throw new IllegalArgumentException("String should not be null");
> int length = string.length();
> if (endIndex < 0 || beginIndex > endIndex || beginIndex > length || 
> endIndex > length)
> throw new IllegalArgumentException("Invalid indices");
> int realBeginIndex = string.offsetByCodePoints(0, beginIndex);
> int realEndIndex = string.offsetByCodePoints(0, endIndex);
> return string.substring(realBeginIndex, realEndIndex);
> }
> }{code}
> The output is:
> {noformat}
> 
> invalid sub: ?
> invalid sub: 
> invalid sub: ??
> real sub: 
> real sub: 
> real sub: {noformat}
>  
> The same issues appear in Apache Commons Text's substring method.
> Should Apache Commons Text use this code or something similar in the 
> substring implementation, rather than the flawed Java substring method? Or at 
> least offer an additional utility method that does take a string with unicode 
> codepoints that require surrogate pairs and substrings it correctly?
>  I also posted my implementation at 
> [https://stackoverflow.com/questions/55663213/java-substring-by-code-point-indices-treating-pairs-of-surrogate-code-units-as/]
>  asking for advice and there is a more robust version as an answer.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (LANG-1450) Maven deploy doesn’t generate javadoc jar

[Rob Tompkins (JIRA)]

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

Rob Tompkins resolved LANG-1450.

Resolution: Fixed

https://github.com/apache/commons-lang/commit/89679976b8b05c14707725489122532fcd71e2ce

> Maven deploy doesn’t generate javadoc jar
> -
>
> Key: LANG-1450
> URL: https://issues.apache.org/jira/browse/LANG-1450
> Project: Commons Lang
>  Issue Type: Bug
>Affects Versions: 3.9
>Reporter: Rob Tompkins
>Assignee: Rob Tompkins
>Priority: Major
> Fix For: 3.10
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (LANG-1450) Maven deploy doesn’t generate javadoc jar

[Rob Tompkins (JIRA)]

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

Rob Tompkins commented on LANG-1450:


If you grab {{master}} now, i think it should work for you.

> Maven deploy doesn’t generate javadoc jar
> -
>
> Key: LANG-1450
> URL: https://issues.apache.org/jira/browse/LANG-1450
> Project: Commons Lang
>  Issue Type: Bug
>Affects Versions: 3.9
>Reporter: Rob Tompkins
>Assignee: Rob Tompkins
>Priority: Major
> Fix For: 3.10
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (LANG-1450) Maven deploy doesn’t generate javadoc jar

[Rob Tompkins (JIRA)]

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

Rob Tompkins updated LANG-1450:
---
Fix Version/s: 3.10

> Maven deploy doesn’t generate javadoc jar
> -
>
> Key: LANG-1450
> URL: https://issues.apache.org/jira/browse/LANG-1450
> Project: Commons Lang
>  Issue Type: Bug
>Affects Versions: 3.9
>Reporter: Rob Tompkins
>Assignee: Rob Tompkins
>Priority: Major
> Fix For: 3.10
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (LANG-1450) Maven deploy doesn’t generate javadoc jar

[Rob Tompkins (JIRA)]

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

Rob Tompkins updated LANG-1450:
---
Affects Version/s: 3.9

> Maven deploy doesn’t generate javadoc jar
> -
>
> Key: LANG-1450
> URL: https://issues.apache.org/jira/browse/LANG-1450
> Project: Commons Lang
>  Issue Type: Bug
>Affects Versions: 3.9
>Reporter: Rob Tompkins
>Assignee: Rob Tompkins
>Priority: Major
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (LANG-1451) Should there be a better implementation of substring that deals with Unicode surrogate pairs correctly?

[Rob Tompkins (JIRA)]

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

Rob Tompkins commented on LANG-1451:


No stress :-) moved.

> Should there be a better implementation of substring that deals with Unicode 
> surrogate pairs correctly?
> ---
>
> Key: LANG-1451
> URL: https://issues.apache.org/jira/browse/LANG-1451
> Project: Commons Lang
>  Issue Type: New Feature
>Affects Versions: 3.9
> Environment: Any
>Reporter: Sebastiaan
>Assignee: Rob Tompkins
>Priority: Minor
>  Labels: features
>
> There are some major problems with Java's substring implementation which 
> works using chars. For a brief overview read this blog post: 
> [https://codeahoy.com/2016/05/08/the-char-type-in-java-is-broken/]
>  
> I have some demo code showing the issues and a possible solution here:
> {code:java}
> public class SubstringTest {
> public static void main(String[] args) {
> String stringWithPlus2ByteCodePoints = "";
> String substring1 = stringWithPlus2ByteCodePoints.substring(0, 1);
> String substring2 = stringWithPlus2ByteCodePoints.substring(0, 2);
> String substring3 = stringWithPlus2ByteCodePoints.substring(1, 3);
> System.out.println(stringWithPlus2ByteCodePoints);
> System.out.println("invalid sub: " + substring1);
> System.out.println("invalid sub: " + substring2);
> System.out.println("invalid sub: " + substring3);
> String realSub1 = getRealSubstring(stringWithPlus2ByteCodePoints, 0, 
> 1);
> String realSub2 = getRealSubstring(stringWithPlus2ByteCodePoints, 0, 
> 2);
> String realSub3 = getRealSubstring(stringWithPlus2ByteCodePoints, 1, 
> 3);
> System.out.println("real sub: " + realSub1);
> System.out.println("real sub: " + realSub2);
> System.out.println("real sub: " + realSub3);
> }
> private static String getRealSubstring(String string, int beginIndex, int 
> endIndex) {
> if (string == null)
> throw new IllegalArgumentException("String should not be null");
> int length = string.length();
> if (endIndex < 0 || beginIndex > endIndex || beginIndex > length || 
> endIndex > length)
> throw new IllegalArgumentException("Invalid indices");
> int realBeginIndex = string.offsetByCodePoints(0, beginIndex);
> int realEndIndex = string.offsetByCodePoints(0, endIndex);
> return string.substring(realBeginIndex, realEndIndex);
> }
> }{code}
> The output is:
> {noformat}
> 
> invalid sub: ?
> invalid sub: 
> invalid sub: ??
> real sub: 
> real sub: 
> real sub: {noformat}
>  
> The same issues appear in Apache Commons Text's substring method.
> Should Apache Commons Text use this code or something similar in the 
> substring implementation, rather than the flawed Java substring method? Or at 
> least offer an additional utility method that does take a string with unicode 
> codepoints that require surrogate pairs and substrings it correctly?
>  I also posted my implementation at 
> [https://stackoverflow.com/questions/55663213/java-substring-by-code-point-indices-treating-pairs-of-surrogate-code-units-as/]
>  asking for advice and there is a more robust version as an answer.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Moved] (LANG-1451) Should there be a better implementation of substring that deals with Unicode surrogate pairs correctly?

[Rob Tompkins (JIRA)]

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

Rob Tompkins moved TEXT-161 to LANG-1451:
-

Affects Version/s: (was: 1.6)
   3.9
 Workflow: Default workflow, editable Closed status  (was: jira)
  Key: LANG-1451  (was: TEXT-161)
  Project: Commons Lang  (was: Commons Text)

> Should there be a better implementation of substring that deals with Unicode 
> surrogate pairs correctly?
> ---
>
> Key: LANG-1451
> URL: https://issues.apache.org/jira/browse/LANG-1451
> Project: Commons Lang
>  Issue Type: New Feature
>Affects Versions: 3.9
> Environment: Any
>Reporter: Sebastiaan
>Assignee: Rob Tompkins
>Priority: Minor
>  Labels: features
>
> There are some major problems with Java's substring implementation which 
> works using chars. For a brief overview read this blog post: 
> [https://codeahoy.com/2016/05/08/the-char-type-in-java-is-broken/]
>  
> I have some demo code showing the issues and a possible solution here:
> {code:java}
> public class SubstringTest {
> public static void main(String[] args) {
> String stringWithPlus2ByteCodePoints = "";
> String substring1 = stringWithPlus2ByteCodePoints.substring(0, 1);
> String substring2 = stringWithPlus2ByteCodePoints.substring(0, 2);
> String substring3 = stringWithPlus2ByteCodePoints.substring(1, 3);
> System.out.println(stringWithPlus2ByteCodePoints);
> System.out.println("invalid sub: " + substring1);
> System.out.println("invalid sub: " + substring2);
> System.out.println("invalid sub: " + substring3);
> String realSub1 = getRealSubstring(stringWithPlus2ByteCodePoints, 0, 
> 1);
> String realSub2 = getRealSubstring(stringWithPlus2ByteCodePoints, 0, 
> 2);
> String realSub3 = getRealSubstring(stringWithPlus2ByteCodePoints, 1, 
> 3);
> System.out.println("real sub: " + realSub1);
> System.out.println("real sub: " + realSub2);
> System.out.println("real sub: " + realSub3);
> }
> private static String getRealSubstring(String string, int beginIndex, int 
> endIndex) {
> if (string == null)
> throw new IllegalArgumentException("String should not be null");
> int length = string.length();
> if (endIndex < 0 || beginIndex > endIndex || beginIndex > length || 
> endIndex > length)
> throw new IllegalArgumentException("Invalid indices");
> int realBeginIndex = string.offsetByCodePoints(0, beginIndex);
> int realEndIndex = string.offsetByCodePoints(0, endIndex);
> return string.substring(realBeginIndex, realEndIndex);
> }
> }{code}
> The output is:
> {noformat}
> 
> invalid sub: ?
> invalid sub: 
> invalid sub: ??
> real sub: 
> real sub: 
> real sub: {noformat}
>  
> The same issues appear in Apache Commons Text's substring method.
> Should Apache Commons Text use this code or something similar in the 
> substring implementation, rather than the flawed Java substring method? Or at 
> least offer an additional utility method that does take a string with unicode 
> codepoints that require surrogate pairs and substrings it correctly?
>  I also posted my implementation at 
> [https://stackoverflow.com/questions/55663213/java-substring-by-code-point-indices-treating-pairs-of-surrogate-code-units-as/]
>  asking for advice and there is a more robust version as an answer.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (TEXT-161) Should there be a better implementation of substring that deals with Unicode surrogate pairs correctly?

[Rob Tompkins (JIRA)]

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

Rob Tompkins commented on TEXT-161:
---

Hm...this then feels like it should be an issue for LANG, and not TEXT? If we 
think that's best, then I'd be happy to move the issue over there and do the 
work.

> Should there be a better implementation of substring that deals with Unicode 
> surrogate pairs correctly?
> ---
>
> Key: TEXT-161
> URL: https://issues.apache.org/jira/browse/TEXT-161
> Project: Commons Text
>  Issue Type: New Feature
>Affects Versions: 1.6
> Environment: Any
>Reporter: Sebastiaan
>Assignee: Rob Tompkins
>Priority: Minor
>  Labels: features
>
> There are some major problems with Java's substring implementation which 
> works using chars. For a brief overview read this blog post: 
> [https://codeahoy.com/2016/05/08/the-char-type-in-java-is-broken/]
>  
> I have some demo code showing the issues and a possible solution here:
> {code:java}
> public class SubstringTest {
> public static void main(String[] args) {
> String stringWithPlus2ByteCodePoints = "";
> String substring1 = stringWithPlus2ByteCodePoints.substring(0, 1);
> String substring2 = stringWithPlus2ByteCodePoints.substring(0, 2);
> String substring3 = stringWithPlus2ByteCodePoints.substring(1, 3);
> System.out.println(stringWithPlus2ByteCodePoints);
> System.out.println("invalid sub: " + substring1);
> System.out.println("invalid sub: " + substring2);
> System.out.println("invalid sub: " + substring3);
> String realSub1 = getRealSubstring(stringWithPlus2ByteCodePoints, 0, 
> 1);
> String realSub2 = getRealSubstring(stringWithPlus2ByteCodePoints, 0, 
> 2);
> String realSub3 = getRealSubstring(stringWithPlus2ByteCodePoints, 1, 
> 3);
> System.out.println("real sub: " + realSub1);
> System.out.println("real sub: " + realSub2);
> System.out.println("real sub: " + realSub3);
> }
> private static String getRealSubstring(String string, int beginIndex, int 
> endIndex) {
> if (string == null)
> throw new IllegalArgumentException("String should not be null");
> int length = string.length();
> if (endIndex < 0 || beginIndex > endIndex || beginIndex > length || 
> endIndex > length)
> throw new IllegalArgumentException("Invalid indices");
> int realBeginIndex = string.offsetByCodePoints(0, beginIndex);
> int realEndIndex = string.offsetByCodePoints(0, endIndex);
> return string.substring(realBeginIndex, realEndIndex);
> }
> }{code}
> The output is:
> {noformat}
> 
> invalid sub: ?
> invalid sub: 
> invalid sub: ??
> real sub: 
> real sub: 
> real sub: {noformat}
>  
> The same issues appear in Apache Commons Text's substring method.
> Should Apache Commons Text use this code or something similar in the 
> substring implementation, rather than the flawed Java substring method? Or at 
> least offer an additional utility method that does take a string with unicode 
> codepoints that require surrogate pairs and substrings it correctly?
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (TEXT-161) Should there be a better implementation of substring that deals with Unicode surrogate pairs correctly?

[Rob Tompkins (JIRA)]

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

Rob Tompkins commented on TEXT-161:
---

In my initial look I would think that you're talking about {{StrBuilder}}, but 
if we explore a little more, we see that commons-lang probably has the same 
problems in the {{StringUtils}} particularly with things like {{lastIndexOf}} 
and the {{substring}} method over there. Just curious...where in particular in 
commons-text were you thinking about this issue?

> Should there be a better implementation of substring that deals with Unicode 
> surrogate pairs correctly?
> ---
>
> Key: TEXT-161
> URL: https://issues.apache.org/jira/browse/TEXT-161
> Project: Commons Text
>  Issue Type: New Feature
>Affects Versions: 1.6
> Environment: Any
>Reporter: Sebastiaan
>Assignee: Rob Tompkins
>Priority: Minor
>  Labels: features
>
> There are some major problems with Java's substring implementation which 
> works using chars. For a brief overview read this blog post: 
> [https://codeahoy.com/2016/05/08/the-char-type-in-java-is-broken/]
>  
> I have some demo code showing the issues and a possible solution here:
> {code:java}
> public class SubstringTest {
> public static void main(String[] args) {
> String stringWithPlus2ByteCodePoints = "";
> String substring1 = stringWithPlus2ByteCodePoints.substring(0, 1);
> String substring2 = stringWithPlus2ByteCodePoints.substring(0, 2);
> String substring3 = stringWithPlus2ByteCodePoints.substring(1, 3);
> System.out.println(stringWithPlus2ByteCodePoints);
> System.out.println("invalid sub: " + substring1);
> System.out.println("invalid sub: " + substring2);
> System.out.println("invalid sub: " + substring3);
> String realSub1 = getRealSubstring(stringWithPlus2ByteCodePoints, 0, 
> 1);
> String realSub2 = getRealSubstring(stringWithPlus2ByteCodePoints, 0, 
> 2);
> String realSub3 = getRealSubstring(stringWithPlus2ByteCodePoints, 1, 
> 3);
> System.out.println("real sub: " + realSub1);
> System.out.println("real sub: " + realSub2);
> System.out.println("real sub: " + realSub3);
> }
> private static String getRealSubstring(String string, int beginIndex, int 
> endIndex) {
> if (string == null)
> throw new IllegalArgumentException("String should not be null");
> int length = string.length();
> if (endIndex < 0 || beginIndex > endIndex || beginIndex > length || 
> endIndex > length)
> throw new IllegalArgumentException("Invalid indices");
> int realBeginIndex = string.offsetByCodePoints(0, beginIndex);
> int realEndIndex = string.offsetByCodePoints(0, endIndex);
> return string.substring(realBeginIndex, realEndIndex);
> }
> }{code}
> The output is:
> {noformat}
> 
> invalid sub: ?
> invalid sub: 
> invalid sub: ??
> real sub: 
> real sub: 
> real sub: {noformat}
>  
> The same issues appear in Apache Commons Text's substring method.
> Should Apache Commons Text use this code or something similar in the 
> substring implementation, rather than the flawed Java substring method? Or at 
> least offer an additional utility method that does take a string with unicode 
> codepoints that require surrogate pairs and substrings it correctly?
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (LANG-1447) FieldUtilsTest fails in Java 12

[Rob Tompkins (JIRA)]

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

Rob Tompkins resolved LANG-1447.

Resolution: Fixed

> FieldUtilsTest fails in Java 12
> ---
>
> Key: LANG-1447
> URL: https://issues.apache.org/jira/browse/LANG-1447
> Project: Commons Lang
>  Issue Type: Improvement
>Affects Versions: 3.8.1
>Reporter: Rob Tompkins
>Assignee: Rob Tompkins
>Priority: Major
> Fix For: 3.9
>
>
> {{FieldUtils.removeFinalModifier(Field, boolean)}} no longer removes the 
> {{final}} modifier because of a change in java 12. The email: 
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-November/056486.html
>  discusses this in the jcp. In java versions 12.0 or later we should throw sn 
> {{UnsupportedOperationException}}. Furthermore, we should deprecate the 
> method as it clearly won't have a use in the future.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (LANG-1450) Maven deploy doesn’t generate javadoc jar

[Rob Tompkins (JIRA)]

Rob Tompkins created LANG-1450:
--

 Summary: Maven deploy doesn’t generate javadoc jar
 Key: LANG-1450
 URL: https://issues.apache.org/jira/browse/LANG-1450
 Project: Commons Lang
  Issue Type: Bug
Reporter: Rob Tompkins
Assignee: Rob Tompkins






--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (TEXT-161) Should there be a better implementation of substring that deals with Unicode surrogate pairs correctly?

[Rob Tompkins (JIRA)]

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

Rob Tompkins commented on TEXT-161:
---

Looks like something up my alley

> Should there be a better implementation of substring that deals with Unicode 
> surrogate pairs correctly?
> ---
>
> Key: TEXT-161
> URL: https://issues.apache.org/jira/browse/TEXT-161
> Project: Commons Text
>  Issue Type: New Feature
>Affects Versions: 1.6
> Environment: Any
>Reporter: Sebastiaan
>Assignee: Rob Tompkins
>Priority: Minor
>  Labels: features
>
> There are some major problems with Java's substring implementation which 
> works using chars. For a brief overview read this blog post: 
> [https://codeahoy.com/2016/05/08/the-char-type-in-java-is-broken/]
>  
> I have some demo code showing the issues and a possible solution here:
> {code:java}
> public class SubstringTest {
> public static void main(String[] args) {
> String stringWithPlus2ByteCodePoints = "";
> String substring1 = stringWithPlus2ByteCodePoints.substring(0, 1);
> String substring2 = stringWithPlus2ByteCodePoints.substring(0, 2);
> String substring3 = stringWithPlus2ByteCodePoints.substring(1, 3);
> System.out.println(stringWithPlus2ByteCodePoints);
> System.out.println("invalid sub: " + substring1);
> System.out.println("invalid sub: " + substring2);
> System.out.println("invalid sub: " + substring3);
> String realSub1 = getRealSubstring(stringWithPlus2ByteCodePoints, 0, 
> 1);
> String realSub2 = getRealSubstring(stringWithPlus2ByteCodePoints, 0, 
> 2);
> String realSub3 = getRealSubstring(stringWithPlus2ByteCodePoints, 1, 
> 3);
> System.out.println("real sub: " + realSub1);
> System.out.println("real sub: " + realSub2);
> System.out.println("real sub: " + realSub3);
> }
> private static String getRealSubstring(String string, int beginIndex, int 
> endIndex) {
> if (string == null)
> throw new IllegalArgumentException("String should not be null");
> int length = string.length();
> if (endIndex < 0 || beginIndex > endIndex || beginIndex > length || 
> endIndex > length)
> throw new IllegalArgumentException("Invalid indices");
> int realBeginIndex = string.offsetByCodePoints(0, beginIndex);
> int realEndIndex = string.offsetByCodePoints(0, endIndex);
> return string.substring(realBeginIndex, realEndIndex);
> }
> }{code}
> The output is:
> {noformat}
> 
> invalid sub: ?
> invalid sub: 
> invalid sub: ??
> real sub: 
> real sub: 
> real sub: {noformat}
>  
> The same issues appear in Apache Commons Text's substring method.
> Should Apache Commons Text use this code or something similar in the 
> substring implementation, rather than the flawed Java substring method? Or at 
> least offer an additional utility method that does take a string with unicode 
> codepoints that require surrogate pairs and substrings it correctly?
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (TEXT-161) Should there be a better implementation of substring that deals with Unicode surrogate pairs correctly?

[Rob Tompkins (JIRA)]

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

Rob Tompkins updated TEXT-161:
--
Assignee: Rob Tompkins

> Should there be a better implementation of substring that deals with Unicode 
> surrogate pairs correctly?
> ---
>
> Key: TEXT-161
> URL: https://issues.apache.org/jira/browse/TEXT-161
> Project: Commons Text
>  Issue Type: New Feature
>Affects Versions: 1.6
> Environment: Any
>Reporter: Sebastiaan
>Assignee: Rob Tompkins
>Priority: Minor
>  Labels: features
>
> There are some major problems with Java's substring implementation which 
> works using chars. For a brief overview read this blog post: 
> [https://codeahoy.com/2016/05/08/the-char-type-in-java-is-broken/]
>  
> I have some demo code showing the issues and a possible solution here:
> {code:java}
> public class SubstringTest {
> public static void main(String[] args) {
> String stringWithPlus2ByteCodePoints = "";
> String substring1 = stringWithPlus2ByteCodePoints.substring(0, 1);
> String substring2 = stringWithPlus2ByteCodePoints.substring(0, 2);
> String substring3 = stringWithPlus2ByteCodePoints.substring(1, 3);
> System.out.println(stringWithPlus2ByteCodePoints);
> System.out.println("invalid sub: " + substring1);
> System.out.println("invalid sub: " + substring2);
> System.out.println("invalid sub: " + substring3);
> String realSub1 = getRealSubstring(stringWithPlus2ByteCodePoints, 0, 
> 1);
> String realSub2 = getRealSubstring(stringWithPlus2ByteCodePoints, 0, 
> 2);
> String realSub3 = getRealSubstring(stringWithPlus2ByteCodePoints, 1, 
> 3);
> System.out.println("real sub: " + realSub1);
> System.out.println("real sub: " + realSub2);
> System.out.println("real sub: " + realSub3);
> }
> private static String getRealSubstring(String string, int beginIndex, int 
> endIndex) {
> if (string == null)
> throw new IllegalArgumentException("String should not be null");
> int length = string.length();
> if (endIndex < 0 || beginIndex > endIndex || beginIndex > length || 
> endIndex > length)
> throw new IllegalArgumentException("Invalid indices");
> int realBeginIndex = string.offsetByCodePoints(0, beginIndex);
> int realEndIndex = string.offsetByCodePoints(0, endIndex);
> return string.substring(realBeginIndex, realEndIndex);
> }
> }{code}
> The output is:
> {noformat}
> 
> invalid sub: ?
> invalid sub: 
> invalid sub: ??
> real sub: 
> real sub: 
> real sub: {noformat}
>  
> The same issues appear in Apache Commons Text's substring method.
> Should Apache Commons Text use this code or something similar in the 
> substring implementation, rather than the flawed Java substring method? Or at 
> least offer an additional utility method that does take a string with unicode 
> codepoints that require surrogate pairs and substrings it correctly?
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (LANG-1448) Commons-Lang3; StringUtils JavaDoc page wrong for containsOnly and containsNone

[Rob Tompkins (JIRA)]

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

Rob Tompkins updated LANG-1448:
---
Assignee: Rob Tompkins

> Commons-Lang3; StringUtils JavaDoc page wrong for containsOnly and 
> containsNone
> ---
>
> Key: LANG-1448
> URL: https://issues.apache.org/jira/browse/LANG-1448
> Project: Commons Lang
>  Issue Type: Bug
>  Components: lang.*
>Affects Versions: 3.8.1
>Reporter: David W. Burhans
>Assignee: Rob Tompkins
>Priority: Minor
>
> TLDR: 'xxx' is not java and can never compile.
>  
> The descriptions of the 
> containsOnly([CharSequence|https://docs.oracle.com/javase/7/docs/api/java/lang/CharSequence.html?is-external=true]
>  cs, char... valid) and 
> containsNone([CharSequence|https://docs.oracle.com/javase/7/docs/api/java/lang/CharSequence.html?is-external=true]
>  cs, char... valid) methods contain incorrect examples.
>  
> One such bad example: 
> StringUtils.containsOnly("abab", 'abc') = true
>  
> This is not Java code and can never compile.
>  
> The description of the 
> containsAny([CharSequence|https://docs.oracle.com/javase/7/docs/api/java/lang/CharSequence.html?is-external=true]
>  cs, char... valid) method does contain correct examples.
>  
> One such correct example: 
> StringUtils.containsAny("zzabyycdxx",['z','a']) = true
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (LANG-1447) FieldUtilsTest fails in Java 12

[Rob Tompkins (JIRA)]

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

Rob Tompkins updated LANG-1447:
---
Description: {{FieldUtils.removeFinalModifier(Field, boolean)}} no longer 
removes the {{final}} modifier because of a change in java 12. The email: 
http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-November/056486.html 
discusses this in the jcp. In java versions 12.0 or later we should throw sn 
{{UnsupportedOperationException}}. Furthermore, we should deprecate the method 
as it clearly won't have a use in the future.  (was: 
{{FieldUtils.removeFinalModifier(Field, boolean)} no longer removes the 
{{final}} modifier because of a change in java 12. The email: 
http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-November/056486.html 
discusses this in the jcp. In java versions 12.0 or later we should throw sn 
{{UnsupportedOperationException}}. Furthermore, we should deprecate the method 
as it clearly won't have a use in the future.)

> FieldUtilsTest fails in Java 12
> ---
>
> Key: LANG-1447
> URL: https://issues.apache.org/jira/browse/LANG-1447
> Project: Commons Lang
>  Issue Type: Improvement
>Affects Versions: 3.8.1
>Reporter: Rob Tompkins
>Assignee: Rob Tompkins
>Priority: Major
> Fix For: 3.9
>
>
> {{FieldUtils.removeFinalModifier(Field, boolean)}} no longer removes the 
> {{final}} modifier because of a change in java 12. The email: 
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-November/056486.html
>  discusses this in the jcp. In java versions 12.0 or later we should throw sn 
> {{UnsupportedOperationException}}. Furthermore, we should deprecate the 
> method as it clearly won't have a use in the future.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (LANG-1446) Switch from Cobertura code coverage to Jacoco code coverage

[Rob Tompkins (JIRA)]

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

Rob Tompkins resolved LANG-1446.

Resolution: Fixed

Committed: 
https://github.com/apache/commons-lang/commit/d48e87e4f285d49e4b2c9091db9b56ac60751a29

> Switch from Cobertura code coverage to Jacoco code coverage
> ---
>
> Key: LANG-1446
> URL: https://issues.apache.org/jira/browse/LANG-1446
> Project: Commons Lang
>  Issue Type: New Feature
>Affects Versions: 3.8.1
>Reporter: Rob Tompkins
>Assignee: Rob Tompkins
>Priority: Major
> Fix For: 3.9
>
>
> We need to move the file `src/site/resources/profile.cobertura` to 
> `src/site/resources/profile.jacoco` to do this.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (LANG-1447) FieldUtilsTest fails in Java 12

[Rob Tompkins (JIRA)]

Rob Tompkins created LANG-1447:
--

 Summary: FieldUtilsTest fails in Java 12
 Key: LANG-1447
 URL: https://issues.apache.org/jira/browse/LANG-1447
 Project: Commons Lang
  Issue Type: Improvement
Affects Versions: 3.8.1
Reporter: Rob Tompkins
Assignee: Rob Tompkins
 Fix For: 3.9


{{FieldUtils.removeFinalModifier(Field, boolean)} no longer removes the 
{{final}} modifier because of a change in java 12. The email: 
http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-November/056486.html 
discusses this in the jcp. In java versions 12.0 or later we should throw sn 
{{UnsupportedOperationException}}. Furthermore, we should deprecate the method 
as it clearly won't have a use in the future.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (LANG-1446) Switch from Cobertura code coverage to Jacoco code coverage

[Rob Tompkins (JIRA)]

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

Rob Tompkins updated LANG-1446:
---
Affects Version/s: 3.8.1

> Switch from Cobertura code coverage to Jacoco code coverage
> ---
>
> Key: LANG-1446
> URL: https://issues.apache.org/jira/browse/LANG-1446
> Project: Commons Lang
>  Issue Type: New Feature
>Affects Versions: 3.8.1
>Reporter: Rob Tompkins
>Assignee: Rob Tompkins
>Priority: Major
>
> We need to move the file `src/site/resources/profile.cobertura` to 
> `src/site/resources/profile.jacoco` to do this.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (LANG-1446) Switch from Cobertura code coverage to Jacoco code coverage

[Rob Tompkins (JIRA)]

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

Rob Tompkins updated LANG-1446:
---
Fix Version/s: 3.9

> Switch from Cobertura code coverage to Jacoco code coverage
> ---
>
> Key: LANG-1446
> URL: https://issues.apache.org/jira/browse/LANG-1446
> Project: Commons Lang
>  Issue Type: New Feature
>Affects Versions: 3.8.1
>Reporter: Rob Tompkins
>Assignee: Rob Tompkins
>Priority: Major
> Fix For: 3.9
>
>
> We need to move the file `src/site/resources/profile.cobertura` to 
> `src/site/resources/profile.jacoco` to do this.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (LANG-1446) Switch from Cobertura code coverage to Jacoco code coverage

[Rob Tompkins (JIRA)]

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

Rob Tompkins updated LANG-1446:
---
Assignee: Rob Tompkins

> Switch from Cobertura code coverage to Jacoco code coverage
> ---
>
> Key: LANG-1446
> URL: https://issues.apache.org/jira/browse/LANG-1446
> Project: Commons Lang
>  Issue Type: New Feature
>Reporter: Rob Tompkins
>Assignee: Rob Tompkins
>Priority: Major
>
> We need to move the file `src/site/resources/profile.cobertura` to 
> `src/site/resources/profile.jacoco` to do this.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (LANG-1446) Switch from Cobertura code coverage to Jacoco code coverage

[Rob Tompkins (JIRA)]

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

Rob Tompkins updated LANG-1446:
---
Issue Type: Task  (was: New Feature)

> Switch from Cobertura code coverage to Jacoco code coverage
> ---
>
> Key: LANG-1446
> URL: https://issues.apache.org/jira/browse/LANG-1446
> Project: Commons Lang
>  Issue Type: Task
>Reporter: Rob Tompkins
>Priority: Major
>
> We need to move the file `src/site/resources/profile.cobertura` to 
> `src/site/resources/profile.jacoco` to do this.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (LANG-1446) Switch from Cobertura code coverage to Jacoco code coverage

[Rob Tompkins (JIRA)]

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

Rob Tompkins updated LANG-1446:
---
Issue Type: New Feature  (was: Task)

> Switch from Cobertura code coverage to Jacoco code coverage
> ---
>
> Key: LANG-1446
> URL: https://issues.apache.org/jira/browse/LANG-1446
> Project: Commons Lang
>  Issue Type: New Feature
>Reporter: Rob Tompkins
>Priority: Major
>
> We need to move the file `src/site/resources/profile.cobertura` to 
> `src/site/resources/profile.jacoco` to do this.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (LANG-1446) Switch from Cobertura code coverage to Jacoco code coverage

[Rob Tompkins (JIRA)]

Rob Tompkins created LANG-1446:
--

 Summary: Switch from Cobertura code coverage to Jacoco code 
coverage
 Key: LANG-1446
 URL: https://issues.apache.org/jira/browse/LANG-1446
 Project: Commons Lang
  Issue Type: New Feature
Reporter: Rob Tompkins


We need to move the file `src/site/resources/profile.cobertura` to 
`src/site/resources/profile.jacoco` to do this.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (LANG-1444) NumberUtils.createNumber() does not create BigDecimal for decimal fractions tending to zero

[Rob Tompkins (JIRA)]

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

Rob Tompkins commented on LANG-1444:


This happens because {{Double.valueOf("1.001") = 
1.001}} and {{Double.valueOf("1.0001") = 1.0}}. In the 
latter case because we've lost the precision, it no longer matters whether we 
store the number as a Double or a Float, so we use a Float because it's been 
truncated.

> NumberUtils.createNumber() does not create BigDecimal for decimal fractions 
> tending to zero
> ---
>
> Key: LANG-1444
> URL: https://issues.apache.org/jira/browse/LANG-1444
> Project: Commons Lang
>  Issue Type: Bug
>  Components: lang.math.*
>Affects Versions: 3.8.1
>Reporter: Costa Theodosiou
>Priority: Major
>
> The following code demonstrates the issue:
> {{System.out.println(NumberUtils.createNumber("1.1").getClass().getName());}}
> {{System.out.println(NumberUtils.createNumber("1.001").getClass().getName());}}
> {{System.out.println(NumberUtils.createNumber("1.1").getClass().getName());}}
> {{System.out.println(NumberUtils.createNumber("1.001").getClass().getName());}}
> {{System.out.println(NumberUtils.createNumber("1.1").getClass().getName());}}
> {{System.out.println(NumberUtils.createNumber("1.001").getClass().getName());}}
> {{System.out.println(NumberUtils.createNumber("1.1").getClass().getName());}}
> {{System.out.println(NumberUtils.createNumber("1.001").getClass().getName());}}
> {{System.out.println(NumberUtils.createNumber("1.1").getClass().getName());}}
> {{System.out.println(NumberUtils.createNumber("1.001").getClass().getName());}}
> {{System.out.println(NumberUtils.createNumber("1.1").getClass().getName());}}
> {{System.out.println(NumberUtils.createNumber("1.001").getClass().getName());}}
> will print:
> {{java.lang.Float}}
> {{java.lang.Float}}
> {{java.lang.Float}}
> {{java.lang.Float}}
> {{java.lang.Double}}
> {{java.lang.Double}}
> {{java.lang.Double}}
> {{java.lang.Double}}
> {{java.lang.Float}}
> {{java.lang.Float}}
> {{java.lang.Float}}
> {{java.lang.Float}}
> It seems the problem is towards the bottom of the createNumber method that 
> compares the float to double string representation:
> f.toString().equals(d.toString())
> For the misbehaving tests, the string "1.0".equals("1.0")



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (LANG-1442) RandomUtils is outdated

[Rob Tompkins (JIRA)]

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

Rob Tompkins resolved LANG-1442.

Resolution: Implemented

Comments are in {{RandomUtils}} and {{RandomStringUtils}}

> RandomUtils is outdated
> ---
>
> Key: LANG-1442
> URL: https://issues.apache.org/jira/browse/LANG-1442
> Project: Commons Lang
>  Issue Type: Wish
>  Components: lang.*
>Reporter: Gilles
>Assignee: Rob Tompkins
>Priority: Trivial
> Fix For: 3.9
>
>
> Class uses 
> [java.util.Random|http://commons.apache.org/proper/commons-rng/userguide/why_not_java_random.html]
>  internally.
>  Its Javadoc should advertise that "Commons RNG" provide [better 
> implementations|http://commons.apache.org/proper/commons-rng/commons-rng-simple/index.html].
> Moreover, since JDK 8, [another generator is 
> available|https://docs.oracle.com/javase/8/docs/api/java/util/SplittableRandom.html].



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (LANG-1442) RandomUtils is outdated

[Rob Tompkins (JIRA)]

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

Rob Tompkins updated LANG-1442:
---
Assignee: Rob Tompkins

> RandomUtils is outdated
> ---
>
> Key: LANG-1442
> URL: https://issues.apache.org/jira/browse/LANG-1442
> Project: Commons Lang
>  Issue Type: Wish
>  Components: lang.*
>Reporter: Gilles
>Assignee: Rob Tompkins
>Priority: Trivial
> Fix For: 3.9
>
>
> Class uses 
> [java.util.Random|http://commons.apache.org/proper/commons-rng/userguide/why_not_java_random.html]
>  internally.
>  Its Javadoc should advertise that "Commons RNG" provide [better 
> implementations|http://commons.apache.org/proper/commons-rng/commons-rng-simple/index.html].
> Moreover, since JDK 8, [another generator is 
> available|https://docs.oracle.com/javase/8/docs/api/java/util/SplittableRandom.html].



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Closed] (LANG-1441) RandomStringUtils, accommodate for passing in one's own instance of java.util.Random

[Rob Tompkins (JIRA)]

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

Rob Tompkins closed LANG-1441.
--
Resolution: Won't Fix

We aren't going to do this. In the future there may be something different that 
we do.

> RandomStringUtils, accommodate for passing in one's own instance of 
> java.util.Random
> 
>
> Key: LANG-1441
> URL: https://issues.apache.org/jira/browse/LANG-1441
> Project: Commons Lang
>  Issue Type: New Feature
>Affects Versions: 3.8.1
>Reporter: Rob Tompkins
>Assignee: Rob Tompkins
>Priority: Major
> Fix For: 3.9
>
>
> We want not only to have a default instance of {{java.util.Random}} that gets 
> passed in, but to also accommodate for passing in any subclass of 
> {{java.util.Random}}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (LANG-1441) RandomStringUtils, accommodate for passing in one's own instance of java.util.Random

[Rob Tompkins (JIRA)]

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

Rob Tompkins commented on LANG-1441:


We might also want to extend {{RandomUtils}} to do something similar here where 
we extend it to accommodate passing in an instance of {{java.util.Random}} into 
the {{static}} methods.

> RandomStringUtils, accommodate for passing in one's own instance of 
> java.util.Random
> 
>
> Key: LANG-1441
> URL: https://issues.apache.org/jira/browse/LANG-1441
> Project: Commons Lang
>  Issue Type: New Feature
>Affects Versions: 3.8.1
>Reporter: Rob Tompkins
>Assignee: Rob Tompkins
>Priority: Major
> Fix For: 3.9
>
>
> We want not only to have a default instance of {{java.util.Random}} that gets 
> passed in, but to also accommodate for passing in any subclass of 
> {{java.util.Random}}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Comment Edited] (LANG-1441) RandomStringUtils, accommodate for passing in one's own instance of java.util.Random

[Rob Tompkins (JIRA)]

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

Rob Tompkins edited comment on LANG-1441 at 4/1/19 12:32 PM:
-

We might also want to extend {{RandomUtils}} to do something similar here where 
we accommodate passing in an instance of {{java.util.Random}} into the 
{{static}} methods.


was (Author: chtompki):
We might also want to extend {{RandomUtils}} to do something similar here where 
we extend it to accommodate passing in an instance of {{java.util.Random}} into 
the {{static}} methods.

> RandomStringUtils, accommodate for passing in one's own instance of 
> java.util.Random
> 
>
> Key: LANG-1441
> URL: https://issues.apache.org/jira/browse/LANG-1441
> Project: Commons Lang
>  Issue Type: New Feature
>Affects Versions: 3.8.1
>Reporter: Rob Tompkins
>Assignee: Rob Tompkins
>Priority: Major
> Fix For: 3.9
>
>
> We want not only to have a default instance of {{java.util.Random}} that gets 
> passed in, but to also accommodate for passing in any subclass of 
> {{java.util.Random}}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (LANG-1441) RandomStringUtils, accommodate for passing in one's own instance of java.util.Random

[Rob Tompkins (JIRA)]

Rob Tompkins created LANG-1441:
--

 Summary: RandomStringUtils, accommodate for passing in one's own 
instance of java.util.Random
 Key: LANG-1441
 URL: https://issues.apache.org/jira/browse/LANG-1441
 Project: Commons Lang
  Issue Type: New Feature
Affects Versions: 3.8.1
Reporter: Rob Tompkins
Assignee: Rob Tompkins
 Fix For: 3.9


We want not only to have a default instance of {{java.util.Random}} that gets 
passed in, but to also accommodate for passing in any subclass of 
{{java.util.Random}}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (COMMONSSITE-129) [build-plugin, release-plugin] Merge codebases

[Rob Tompkins (JIRA)]

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

Rob Tompkins updated COMMONSSITE-129:
-
Labels: GSoC2019  (was: )

> [build-plugin, release-plugin] Merge codebases
> --
>
> Key: COMMONSSITE-129
> URL: https://issues.apache.org/jira/browse/COMMONSSITE-129
> Project: Commons All
>  Issue Type: New Feature
>  Components: Commons Build Plugin, Commons Release Plugin
>Reporter: Rob Tompkins
>Priority: Major
>  Labels: GSoC2019
>
> These need to both be in the same codebase. The only question remaining is 
> which codebase.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (JELLY-294) Update Jelly from Jenkins Fork

[Rob Tompkins (JIRA)]

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

Rob Tompkins updated JELLY-294:
---
Labels: GSoC2019  (was: )

> Update Jelly from Jenkins Fork
> --
>
> Key: JELLY-294
> URL: https://issues.apache.org/jira/browse/JELLY-294
> Project: Commons Jelly
>  Issue Type: New Feature
>Reporter: Rob Tompkins
>Assignee: Rob Tompkins
>Priority: Major
>  Labels: GSoC2019
>
> I think that the jenkins fork is: https://github.com/jenkinsci/jelly
> We want to pull their latest code in and do a 2.X jelly release so that we're 
> maintaining the code as opposed to jenkins having to maintain it.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (JELLY-294) Update Jelly from Jenkins Fork

[Rob Tompkins (JIRA)]

Rob Tompkins created JELLY-294:
--

 Summary: Update Jelly from Jenkins Fork
 Key: JELLY-294
 URL: https://issues.apache.org/jira/browse/JELLY-294
 Project: Commons Jelly
  Issue Type: New Feature
Reporter: Rob Tompkins
Assignee: Rob Tompkins


I think that the jenkins fork is: https://github.com/jenkinsci/jelly

We want to pull their latest code in and do a 2.X jelly release so that we're 
maintaining the code as opposed to jenkins having to maintain it.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (COMMONSSITE-129) [build-plugin, release-plugin] Merge codebases

[Rob Tompkins (JIRA)]

[ 
https://issues.apache.org/jira/browse/COMMONSSITE-129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16790632#comment-16790632
 ] 

Rob Tompkins commented on COMMONSSITE-129:
--

I honestly created the release plugin separately out of fear of messing up the 
build plugin. I'm less afraid now, so I'll merge release -> build, as I have no 
opinion on naming.

> [build-plugin, release-plugin] Merge codebases
> --
>
> Key: COMMONSSITE-129
> URL: https://issues.apache.org/jira/browse/COMMONSSITE-129
> Project: Commons All
>  Issue Type: New Feature
>  Components: Commons Build Plugin, Commons Release Plugin
>Reporter: Rob Tompkins
>Priority: Major
>
> These need to both be in the same codebase. The only question remaining is 
> which codebase.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Closed] (COMMONSSITE-95) Add mojo to commons-build-plugin to move dists out of deployment to nexus.

[Rob Tompkins (JIRA)]

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

Rob Tompkins closed COMMONSSITE-95.
---
Resolution: Fixed

Release plugin does this now

> Add mojo to commons-build-plugin to move dists out of deployment to nexus.
> --
>
> Key: COMMONSSITE-95
> URL: https://issues.apache.org/jira/browse/COMMONSSITE-95
> Project: Commons All
>  Issue Type: New Feature
>Affects Versions: 1.7
>Reporter: Rob Tompkins
>Assignee: Rob Tompkins
>Priority: Major
>
> Currently we have to log into the nexus after doing a release deployment and 
> delete the {{-bin.tar.gz}}, the {{-bin.zip}}, the {{-src.tar.gz}}, the 
> {{-src.zip}}, and their signature files. We want this to not happen 
> automatically. 
> Further, it could be nice if these artifacts were automatically staged in the 
> dev distribution svn repo, but this may require a new JIRA. For now I will 
> concern myself with creating a separate directory under {{./target}} that 
> will contain the dists.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (COMMONSSITE-110) [build-plugin] commons:download-page does not account for the artifact name being different from the project name

[Rob Tompkins (JIRA)]

[ 
https://issues.apache.org/jira/browse/COMMONSSITE-110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16790495#comment-16790495
 ] 

Rob Tompkins commented on COMMONSSITE-110:
--

[~garydgregory] - can you give this a read to see if it is done.

> [build-plugin] commons:download-page does not account for the artifact name 
> being different from the project name
> -
>
> Key: COMMONSSITE-110
> URL: https://issues.apache.org/jira/browse/COMMONSSITE-110
> Project: Commons All
>  Issue Type: Bug
>Reporter: Gary Gregory
>Priority: Major
>
> For components that have a number at then end of their artifact Id, the 
> plugin generates links using this number instead of without. For example, 
> DBCP uses
> [https://commons.apache.org/proper/commons-dbcp/download_dbcp.cgi]
> not
> [https://commons.apache.org/proper/commons-dbcp2/download_dbcp2.cgi]
>  
> We either need
>  * to allow for a component to say "use commons-dbcp in links instead of 
> commons-dbcp2" 
>  * change our distribution folders to use names like {{commons-dbcp2}} and 
> remove the old {{commons-dbcp}} 
> This applies to components:
>  * LANG with commons-lang3
>  * DBCP with commons-dbcp2
>  * POOL with commons-pool2
>  * CONFIGURATION with commons-configuration2
>  * COLLECTIONS with commons-collections4
>  * others?



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (COMMONSSITE-129) [build-plugin, release-plugin] Merge codebases

[Rob Tompkins (JIRA)]

Rob Tompkins created COMMONSSITE-129:


 Summary: [build-plugin, release-plugin] Merge codebases
 Key: COMMONSSITE-129
 URL: https://issues.apache.org/jira/browse/COMMONSSITE-129
 Project: Commons All
  Issue Type: New Feature
  Components: Commons Build Plugin, Commons Release Plugin
Reporter: Rob Tompkins


These need to both be in the same codebase. The only question remaining is 
which codebase.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Closed] (COMMONSSITE-128) Release plugin should work when SCM directories contain empty folders that twould be reused

[Rob Tompkins (JIRA)]

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

Rob Tompkins closed COMMONSSITE-128.


1.6 released

> Release plugin should work when SCM directories contain empty folders that 
> twould be reused
> ---
>
> Key: COMMONSSITE-128
> URL: https://issues.apache.org/jira/browse/COMMONSSITE-128
> Project: Commons All
>  Issue Type: Wish
>  Components: Commons Release Plugin
>Affects Versions: 1.5-SNAPSHOT
>Reporter: Gary Gregory
>Assignee: Rob Tompkins
>Priority: Major
> Fix For: 1.6
>
>
> Release plugin should work when SCM directories contain empty folders that 
> twould be reused.
>  For example:
> {noformat}
>  [ERROR] Failed to execute goal 
> org.apache.commons:commons-release-plugin:1.5-SNAPSHOT:stage-distributions 
> (stage-distributions) on project commons-vfs2-distribution: Failed to add 
> files to SCM: The svn command failed. [svn: warning: W150002: 
> 'C:\temp\rc\commons-vfs2-project-2.3-rc1\commons-vfs2-distribution\target\commons-release-plugin\scm\binaries'
>  is already under version control
>  [ERROR] svn: warning: W150002: 
> 'C:\temp\rc\commons-vfs2-project-2.3-rc1\commons-vfs2-distribution\target\commons-release-plugin\scm\source'
>  is already under version control
>  [ERROR] svn: E29: Could not add all targets because some targets are 
> already versioned
>  [ERROR] svn: E29: Illegal target for the requested operation
> {noformat}
> Either delete the empty folder before the svn operation or find a way to make 
> svn behave.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (COMMONSSITE-128) Release plugin should work when SCM directories contain empty folders that twould be reused

[Rob Tompkins (JIRA)]

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

Rob Tompkins resolved COMMONSSITE-128.
--
   Resolution: Fixed
Fix Version/s: 1.6

In git

> Release plugin should work when SCM directories contain empty folders that 
> twould be reused
> ---
>
> Key: COMMONSSITE-128
> URL: https://issues.apache.org/jira/browse/COMMONSSITE-128
> Project: Commons All
>  Issue Type: Wish
>  Components: Commons Release Plugin
>Affects Versions: 1.5-SNAPSHOT
>Reporter: Gary Gregory
>Assignee: Rob Tompkins
>Priority: Major
> Fix For: 1.6
>
>
> Release plugin should work when SCM directories contain empty folders that 
> twould be reused.
>  For example:
> {noformat}
>  [ERROR] Failed to execute goal 
> org.apache.commons:commons-release-plugin:1.5-SNAPSHOT:stage-distributions 
> (stage-distributions) on project commons-vfs2-distribution: Failed to add 
> files to SCM: The svn command failed. [svn: warning: W150002: 
> 'C:\temp\rc\commons-vfs2-project-2.3-rc1\commons-vfs2-distribution\target\commons-release-plugin\scm\binaries'
>  is already under version control
>  [ERROR] svn: warning: W150002: 
> 'C:\temp\rc\commons-vfs2-project-2.3-rc1\commons-vfs2-distribution\target\commons-release-plugin\scm\source'
>  is already under version control
>  [ERROR] svn: E29: Could not add all targets because some targets are 
> already versioned
>  [ERROR] svn: E29: Illegal target for the requested operation
> {noformat}
> Either delete the empty folder before the svn operation or find a way to make 
> svn behave.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (COMMONSSITE-128) Release plugin should work when SCM directories contain empty folders that twould be reused

[Rob Tompkins (JIRA)]

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

Rob Tompkins updated COMMONSSITE-128:
-
Assignee: Rob Tompkins

> Release plugin should work when SCM directories contain empty folders that 
> twould be reused
> ---
>
> Key: COMMONSSITE-128
> URL: https://issues.apache.org/jira/browse/COMMONSSITE-128
> Project: Commons All
>  Issue Type: Wish
>  Components: Commons Release Plugin
>Affects Versions: 1.5-SNAPSHOT
>Reporter: Gary Gregory
>Assignee: Rob Tompkins
>Priority: Major
>
> Release plugin should work when SCM directories contain empty folders that 
> twould be reused.
>  For example:
> {noformat}
>  [ERROR] Failed to execute goal 
> org.apache.commons:commons-release-plugin:1.5-SNAPSHOT:stage-distributions 
> (stage-distributions) on project commons-vfs2-distribution: Failed to add 
> files to SCM: The svn command failed. [svn: warning: W150002: 
> 'C:\temp\rc\commons-vfs2-project-2.3-rc1\commons-vfs2-distribution\target\commons-release-plugin\scm\binaries'
>  is already under version control
>  [ERROR] svn: warning: W150002: 
> 'C:\temp\rc\commons-vfs2-project-2.3-rc1\commons-vfs2-distribution\target\commons-release-plugin\scm\source'
>  is already under version control
>  [ERROR] svn: E29: Could not add all targets because some targets are 
> already versioned
>  [ERROR] svn: E29: Illegal target for the requested operation
> {noformat}
> Either delete the empty folder before the svn operation or find a way to make 
> svn behave.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Closed] (CODEC-250) Wrong value calculated by Cologne Phonetic if a special character is placed between equal letters

[Rob Tompkins (JIRA)]

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

Rob Tompkins closed CODEC-250.
--

> Wrong value calculated by Cologne Phonetic if a special character is placed 
> between equal letters
> -
>
> Key: CODEC-250
> URL: https://issues.apache.org/jira/browse/CODEC-250
> Project: Commons Codec
>  Issue Type: Bug
>Affects Versions: 1.5, 1.11
>Reporter: Alex Volodko
>Priority: Major
> Fix For: 1.12
>
> Attachments: CODEC250.patch, ColognePhonetic.java
>
>
> The algorith for cologne phonetic is (simpilied):
>  # Encode letter by letter from left to right according to the conversion 
> table.
>  # Remove all digits occurring more than once next to each other.
>  # Remove all code "0" except at the beginning.
> Characters which are not specified in conversion table (such as hyphens) are 
> ignored. See https://en.wikipedia.org/wiki/Cologne_phonetics
> If the input is "test-test" the step results will be:
>  # 20822082
>  # 2082082
>  # 28282
> The expected result for "test-test" is therefor 28282.
> The actual result for "test-test" is 282{color:#FF}2{color}82.
> This bug is caused by the fix from
> [https://github.com/apache/commons-codec/commit/72c8759a22c6552a2dfcdf61b29729f981752879]
> and is present since 1.5



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (CODEC-250) Wrong value calculated by Cologne Phonetic if a special character is placed between equal letters

[Rob Tompkins (JIRA)]

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

Rob Tompkins updated CODEC-250:
---
Fix Version/s: 1.12

> Wrong value calculated by Cologne Phonetic if a special character is placed 
> between equal letters
> -
>
> Key: CODEC-250
> URL: https://issues.apache.org/jira/browse/CODEC-250
> Project: Commons Codec
>  Issue Type: Bug
>Affects Versions: 1.5, 1.11
>Reporter: Alex Volodko
>Priority: Major
> Fix For: 1.12
>
> Attachments: CODEC250.patch, ColognePhonetic.java
>
>
> The algorith for cologne phonetic is (simpilied):
>  # Encode letter by letter from left to right according to the conversion 
> table.
>  # Remove all digits occurring more than once next to each other.
>  # Remove all code "0" except at the beginning.
> Characters which are not specified in conversion table (such as hyphens) are 
> ignored. See https://en.wikipedia.org/wiki/Cologne_phonetics
> If the input is "test-test" the step results will be:
>  # 20822082
>  # 2082082
>  # 28282
> The expected result for "test-test" is therefor 28282.
> The actual result for "test-test" is 282{color:#FF}2{color}82.
> This bug is caused by the fix from
> [https://github.com/apache/commons-codec/commit/72c8759a22c6552a2dfcdf61b29729f981752879]
> and is present since 1.5



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (CODEC-250) Wrong value calculated by Cologne Phonetic if a special character is placed between equal letters

[Rob Tompkins (JIRA)]

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

Rob Tompkins resolved CODEC-250.

Resolution: Fixed

> Wrong value calculated by Cologne Phonetic if a special character is placed 
> between equal letters
> -
>
> Key: CODEC-250
> URL: https://issues.apache.org/jira/browse/CODEC-250
> Project: Commons Codec
>  Issue Type: Bug
>Affects Versions: 1.5, 1.11
>Reporter: Alex Volodko
>Priority: Major
> Fix For: 1.12
>
> Attachments: CODEC250.patch, ColognePhonetic.java
>
>
> The algorith for cologne phonetic is (simpilied):
>  # Encode letter by letter from left to right according to the conversion 
> table.
>  # Remove all digits occurring more than once next to each other.
>  # Remove all code "0" except at the beginning.
> Characters which are not specified in conversion table (such as hyphens) are 
> ignored. See https://en.wikipedia.org/wiki/Cologne_phonetics
> If the input is "test-test" the step results will be:
>  # 20822082
>  # 2082082
>  # 28282
> The expected result for "test-test" is therefor 28282.
> The actual result for "test-test" is 282{color:#FF}2{color}82.
> This bug is caused by the fix from
> [https://github.com/apache/commons-codec/commit/72c8759a22c6552a2dfcdf61b29729f981752879]
> and is present since 1.5



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (CODEC-246) ColognePhoneticTest.testIsEncodeEquals missing assertions

[Rob Tompkins (JIRA)]

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

Rob Tompkins updated CODEC-246:
---
Fix Version/s: 1.12

> ColognePhoneticTest.testIsEncodeEquals missing assertions
> -
>
> Key: CODEC-246
> URL: https://issues.apache.org/jira/browse/CODEC-246
> Project: Commons Codec
>  Issue Type: Improvement
>Reporter: Oscar Luis Vera Pérez
>Priority: Trivial
> Fix For: 1.12
>
>
> The test method ColognePhoneticTest.isEncodeEquals  misses an assertion to 
> properly verify the ColognePhonetic.isEncodeEquals method. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (CODEC-252) Make B64 salt generator Random -> ThreadLocalRandom

[Rob Tompkins (JIRA)]

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

Rob Tompkins updated CODEC-252:
---
Fix Version/s: (was: 1.11.1)

> Make B64 salt generator Random -> ThreadLocalRandom
> ---
>
> Key: CODEC-252
> URL: https://issues.apache.org/jira/browse/CODEC-252
> Project: Commons Codec
>  Issue Type: Improvement
>Reporter: Rob Tompkins
>Assignee: Rob Tompkins
>Priority: Major
> Fix For: 1.12
>
>
> For the sake of performance, I want {{Random}} in {{B64.java}}, the salt 
> generator for our hashes, to be a {{ThreadLocalRandom}}.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (CODEC-240) Add Percent-Encoding Codec (described in RFC3986 and RFC7578)

[Rob Tompkins (JIRA)]

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

Rob Tompkins resolved CODEC-240.

Resolution: Fixed

> Add Percent-Encoding Codec (described in RFC3986 and RFC7578)
> -
>
> Key: CODEC-240
> URL: https://issues.apache.org/jira/browse/CODEC-240
> Project: Commons Codec
>  Issue Type: New Feature
>Reporter: Ioannis Sermetziadis
>Priority: Minor
> Fix For: 1.12
>
>
> Similar but more generic than the URLCodec.
> Reference: https://tools.ietf.org/html/rfc3986#section-2.1



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Closed] (CODEC-240) Add Percent-Encoding Codec (described in RFC3986 and RFC7578)

[Rob Tompkins (JIRA)]

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

Rob Tompkins closed CODEC-240.
--

> Add Percent-Encoding Codec (described in RFC3986 and RFC7578)
> -
>
> Key: CODEC-240
> URL: https://issues.apache.org/jira/browse/CODEC-240
> Project: Commons Codec
>  Issue Type: New Feature
>Reporter: Ioannis Sermetziadis
>Priority: Minor
> Fix For: 1.12
>
>
> Similar but more generic than the URLCodec.
> Reference: https://tools.ietf.org/html/rfc3986#section-2.1



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (CODEC-240) Add Percent-Encoding Codec (described in RFC3986 and RFC7578)

[Rob Tompkins (JIRA)]

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

Rob Tompkins updated CODEC-240:
---
Fix Version/s: 1.12

> Add Percent-Encoding Codec (described in RFC3986 and RFC7578)
> -
>
> Key: CODEC-240
> URL: https://issues.apache.org/jira/browse/CODEC-240
> Project: Commons Codec
>  Issue Type: New Feature
>Reporter: Ioannis Sermetziadis
>Priority: Minor
> Fix For: 1.12
>
>
> Similar but more generic than the URLCodec.
> Reference: https://tools.ietf.org/html/rfc3986#section-2.1



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (CODEC-252) Make B64 salt generator Random -> ThreadLocalRandom

[Rob Tompkins (JIRA)]

[ 
https://issues.apache.org/jira/browse/CODEC-252?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16762662#comment-16762662
 ] 

Rob Tompkins commented on CODEC-252:


I think for 1.11, to do this correctly, I need to upversion into java 7.

> Make B64 salt generator Random -> ThreadLocalRandom
> ---
>
> Key: CODEC-252
> URL: https://issues.apache.org/jira/browse/CODEC-252
> Project: Commons Codec
>  Issue Type: Improvement
>Reporter: Rob Tompkins
>Assignee: Rob Tompkins
>Priority: Major
> Fix For: 1.12, 1.11.1
>
>
> For the sake of performance, I want {{Random}} in {{B64.java}}, the salt 
> generator for our hashes, to be a {{ThreadLocalRandom}}.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (CODEC-252) Make B64 salt generator Random -> ThreadLocalRandom

[Rob Tompkins (JIRA)]

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

Rob Tompkins updated CODEC-252:
---
Fix Version/s: 1.11.1

> Make B64 salt generator Random -> ThreadLocalRandom
> ---
>
> Key: CODEC-252
> URL: https://issues.apache.org/jira/browse/CODEC-252
> Project: Commons Codec
>  Issue Type: Improvement
>Reporter: Rob Tompkins
>Assignee: Rob Tompkins
>Priority: Major
> Fix For: 1.12, 1.11.1
>
>
> For the sake of performance, I want {{Random}} in {{B64.java}}, the salt 
> generator for our hashes, to be a {{ThreadLocalRandom}}.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Reopened] (CODEC-253) Upgrade to Java 8

[Rob Tompkins (JIRA)]

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

Rob Tompkins reopened CODEC-253:


> Upgrade to Java 8
> -
>
> Key: CODEC-253
> URL: https://issues.apache.org/jira/browse/CODEC-253
> Project: Commons Codec
>  Issue Type: Improvement
>Reporter: Rob Tompkins
>Assignee: Rob Tompkins
>Priority: Major
> Fix For: 1.12
>
>
> Upgrade to java 8 as the target of of the build.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (CODEC-253) Upgrade to Java 8

[Rob Tompkins (JIRA)]

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

Rob Tompkins updated CODEC-253:
---
Fix Version/s: 1.12

> Upgrade to Java 8
> -
>
> Key: CODEC-253
> URL: https://issues.apache.org/jira/browse/CODEC-253
> Project: Commons Codec
>  Issue Type: Improvement
>Reporter: Rob Tompkins
>Assignee: Rob Tompkins
>Priority: Major
> Fix For: 1.12
>
>
> Upgrade to java 8 as the target of of the build.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (CODEC-253) Upgrade to Java 8

[Rob Tompkins (JIRA)]

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

Rob Tompkins resolved CODEC-253.

Resolution: Implemented

> Upgrade to Java 8
> -
>
> Key: CODEC-253
> URL: https://issues.apache.org/jira/browse/CODEC-253
> Project: Commons Codec
>  Issue Type: Improvement
>Reporter: Rob Tompkins
>Assignee: Rob Tompkins
>Priority: Major
> Fix For: 1.12
>
>
> Upgrade to java 8 as the target of of the build.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (CODEC-253) Upgrade to Java 8

[Rob Tompkins (JIRA)]

[ 
https://issues.apache.org/jira/browse/CODEC-253?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16761031#comment-16761031
 ] 

Rob Tompkins commented on CODEC-253:


I’m not sure about weak given that oracle just end of lifed  java 8, and the 
only reason OSS java can move forward with stability is the Corretto project

> Upgrade to Java 8
> -
>
> Key: CODEC-253
> URL: https://issues.apache.org/jira/browse/CODEC-253
> Project: Commons Codec
>  Issue Type: Improvement
>Reporter: Rob Tompkins
>Assignee: Rob Tompkins
>Priority: Major
>
> Upgrade to java 8 as the target of of the build.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (CODEC-253) Upgrade to Java 8

[Rob Tompkins (JIRA)]

[ 
https://issues.apache.org/jira/browse/CODEC-253?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16760910#comment-16760910
 ] 

Rob Tompkins commented on CODEC-253:


Java 7 was end of life-ed in April of 2015. And, the only existing long term 
support java versions are 8 and 11. That's my reasoning.

> Upgrade to Java 8
> -
>
> Key: CODEC-253
> URL: https://issues.apache.org/jira/browse/CODEC-253
> Project: Commons Codec
>  Issue Type: Improvement
>Reporter: Rob Tompkins
>Assignee: Rob Tompkins
>Priority: Major
>
> Upgrade to java 8 as the target of of the build.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (CODEC-253) Upgrade to Java 8

[Rob Tompkins (JIRA)]

Rob Tompkins created CODEC-253:
--

 Summary: Upgrade to Java 8
 Key: CODEC-253
 URL: https://issues.apache.org/jira/browse/CODEC-253
 Project: Commons Codec
  Issue Type: Improvement
Reporter: Rob Tompkins
Assignee: Rob Tompkins


Upgrade to java 8 as the target of of the build.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Closed] (FILEUPLOAD-110) MultipartStream's keep region padding is either unnecessary or untested (and undocumented)

[Rob Tompkins (JIRA)]

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

Rob Tompkins closed FILEUPLOAD-110.
---

> MultipartStream's keep region padding is either unnecessary or untested (and 
> undocumented)
> --
>
> Key: FILEUPLOAD-110
> URL: https://issues.apache.org/jira/browse/FILEUPLOAD-110
> Project: Commons FileUpload
>  Issue Type: Bug
>Affects Versions: 1.1 Final
>Reporter: Amichai Rothman
>Assignee: Jochen Wiedmann
>Priority: Minor
> Attachments: commons-fileupload-1.1-bug-removed-keep-region.patch
>
>
> MultipartStream has logic and constants related to a "keep region" which, 
> according to the docs, is
> "The amount of data, in bytes, that must be kept in the buffer in order to 
> detect delimiters reliably."
> However, why that region is needed, why the padding is set to 3, and what 
> makes it more reliable, is undocumented. Furthermore, when setting 
> KEEP_REGION_PAD to zero (which effectively bypasses the extra keep region 
> padding mechanism - it simply uses the boundary delimiter size, which makes 
> sense), all tests pass successfully. 
> so... either the extra padding is required but whatever it is required for is 
> untested and undocumented, which should be corrected, or it is indeed 
> unneeded, in which case all the keep region related code and constants can be 
> deleted, and the code where the actual delimiters are searched for can be 
> modified to simply use the boundary length instead of keepRegion.
> Note: I suspect the keep region pad may be a patch to compensate for the 
> skipPreamble() patch which modifies the global boundary, calls a method which 
> uses it, and the restores the global variable. If this is the case, this can 
> all be reorganized in a clear and straightforward manner (with no awkward 
> patches) by using an internal utility method that simply reads data into a 
> given outputstream until a given delimiter is reached. this can then be used 
> by readHeaders, readBodyData, discardBodyData, and skipPreamble, all of which 
> require this same basic underlying functionality. I'd be happy to provide 
> this code change, if this seems like a correct analysis to you...



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Closed] (FILEUPLOAD-230) ServletFileUpload.parseRequest with raw List return type

[Rob Tompkins (JIRA)]

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

Rob Tompkins closed FILEUPLOAD-230.
---

> ServletFileUpload.parseRequest with raw List return type
> 
>
> Key: FILEUPLOAD-230
> URL: https://issues.apache.org/jira/browse/FILEUPLOAD-230
> Project: Commons FileUpload
>  Issue Type: Wish
>Affects Versions: 1.2.2
> Environment: Any
>Reporter: Danilo Angeloni
>Assignee: Simone Tripodi
>Priority: Trivial
>
> ServletFileUpload.parseRequest returns a List of FileItem but the type in the 
> method declaration is raw



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Closed] (FILEUPLOAD-133) Refactor use of FileCleaner into plugable strategy to allow overriding.

[Rob Tompkins (JIRA)]

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

Rob Tompkins closed FILEUPLOAD-133.
---

> Refactor use of FileCleaner into plugable strategy to allow overriding.
> ---
>
> Key: FILEUPLOAD-133
> URL: https://issues.apache.org/jira/browse/FILEUPLOAD-133
> Project: Commons FileUpload
>  Issue Type: Improvement
>Affects Versions: 1.2
>Reporter: Ben Sommerville
>Priority: Minor
>
> For applications that do not want to use the FileCleaner service it would be 
> very useful to allow this to be overridden.
> This could be done by refactoring the use of the FileCleaner into a plugable 
> strategy.
> e..g
> interface TemporaryFileCleaner {
>  void register(FileItem item, File file );
> }
> The DiskFileItem could have a default implementation of the strategy that 
> invokes FileCleaner.track.  However if required an application could supply a 
> different stategy to the factory for use by all the items.
> I'll try to post a patch implementing this in the next couple of days



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (FILEUPLOAD-292) Don't create un-needed resources in FileUploadBase.java

[Rob Tompkins (JIRA)]

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

Rob Tompkins resolved FILEUPLOAD-292.
-
Resolution: Fixed

> Don't create un-needed resources in FileUploadBase.java
> ---
>
> Key: FILEUPLOAD-292
> URL: https://issues.apache.org/jira/browse/FILEUPLOAD-292
> Project: Commons FileUpload
>  Issue Type: Improvement
>Affects Versions: 1.3.3
>Reporter: Rob Tompkins
>Assignee: Rob Tompkins
>Priority: Trivial
> Fix For: 1.4
>
>
> When creating a {{FileItemStreamImpl}} we are creating an object even when 
> {{fileSizeMax == -1}} which allocates unneeded objects that will need to be 
> garbage collected later.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (CODEC-252) Make B64 salt generator Random -> ThreadLocalRandom

[Rob Tompkins (JIRA)]

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

Rob Tompkins resolved CODEC-252.

   Resolution: Fixed
Fix Version/s: 1.12

Prepping release

> Make B64 salt generator Random -> ThreadLocalRandom
> ---
>
> Key: CODEC-252
> URL: https://issues.apache.org/jira/browse/CODEC-252
> Project: Commons Codec
>  Issue Type: Improvement
>Reporter: Rob Tompkins
>Assignee: Rob Tompkins
>Priority: Major
> Fix For: 1.12
>
>
> For the sake of performance, I want {{Random}} in {{B64.java}}, the salt 
> generator for our hashes, to be a {{ThreadLocalRandom}}.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (CODEC-252) Make B64 salt generator Random -> ThreadLocalRandom

[Rob Tompkins (JIRA)]

[ 
https://issues.apache.org/jira/browse/CODEC-252?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16759814#comment-16759814
 ] 

Rob Tompkins commented on CODEC-252:


Maybe use {{ThreadLocal}} or some similar variation?

> Make B64 salt generator Random -> ThreadLocalRandom
> ---
>
> Key: CODEC-252
> URL: https://issues.apache.org/jira/browse/CODEC-252
> Project: Commons Codec
>  Issue Type: Improvement
>Reporter: Rob Tompkins
>Assignee: Rob Tompkins
>Priority: Major
>
> For the sake of performance, I want {{Random}} in {{B64.java}}, the salt 
> generator for our hashes, to be a {{ThreadLocalRandom}}.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (CODEC-252) Make B64 salt generator Random -> ThreadLocalRandom

[Rob Tompkins (JIRA)]

Rob Tompkins created CODEC-252:
--

 Summary: Make B64 salt generator Random -> ThreadLocalRandom
 Key: CODEC-252
 URL: https://issues.apache.org/jira/browse/CODEC-252
 Project: Commons Codec
  Issue Type: Improvement
Reporter: Rob Tompkins
Assignee: Rob Tompkins


For the sake of performance, I want {{Random}} in {{B64.java}}, the salt 
generator for our hashes, to be a {{ThreadLocalRandom}}.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (COMMONSSITE-127) [release-plugin] ReadmeHtmlVelocityDelegate chops up artifactId too much to get to componentId

[Rob Tompkins (JIRA)]

Rob Tompkins created COMMONSSITE-127:


 Summary: [release-plugin] ReadmeHtmlVelocityDelegate chops up 
artifactId too much to get to componentId
 Key: COMMONSSITE-127
 URL: https://issues.apache.org/jira/browse/COMMONSSITE-127
 Project: Commons All
  Issue Type: Improvement
Affects Versions: 1.5
Reporter: Rob Tompkins
 Fix For: 1.6


Instead of parsing out the {{componentId}} from the {{artifactId}}, it is 
likely simpler to add {{componentId}} to the builder such that we build 
Delegate in the following fashion:

{code:java}
ReadmeHtmlVelocityDelegate delegate = ReadmeHtmlVelocityDelegate.builder()
.withArtifactId("commons-lang3")
.withComponentId("lang")
.withVersion("3.8.1")
.withSiteUrl("http://commons.apache.org/text;)
.build();
{code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (FILEUPLOAD-292) Don't create un-needed resources in FileUploadBase.java

[Rob Tompkins (JIRA)]

Rob Tompkins created FILEUPLOAD-292:
---

 Summary: Don't create un-needed resources in FileUploadBase.java
 Key: FILEUPLOAD-292
 URL: https://issues.apache.org/jira/browse/FILEUPLOAD-292
 Project: Commons FileUpload
  Issue Type: Improvement
Affects Versions: 1.3.3
Reporter: Rob Tompkins
Assignee: Rob Tompkins
 Fix For: 1.4


When creating a {{FileItemStreamImpl}} we are creating an object even when 
{{fileSizeMax == -1}} which allocates unneeded objects that will need to be 
garbage collected later.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (TEXT-139) Improve JaccardSimilarity computational cost

[Rob Tompkins (JIRA)]

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

Rob Tompkins resolved TEXT-139.
---
Resolution: Fixed

Thanks [~nickwong]

> Improve JaccardSimilarity computational cost
> 
>
> Key: TEXT-139
> URL: https://issues.apache.org/jira/browse/TEXT-139
> Project: Commons Text
>  Issue Type: Improvement
>Reporter: nick wong
>Priority: Major
>   Original Estimate: 24h
>  Remaining Estimate: 24h
>
> Improve JaccardSimilarity computational cost from O(n*m) to O(n+m).
> I found two unnecessary loops in 
> JaccardSimilarity.calculateJaccardSimilarity() which can easy to be Improve.
> I would make a PR soon.
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (TEXT-118) JSON escaping incorrect for the delete control character

[Rob Tompkins (JIRA)]

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

Rob Tompkins resolved TEXT-118.
---
Resolution: Fixed

Thanks https://github.com/nandorKollar

> JSON escaping incorrect for the delete control character
> 
>
> Key: TEXT-118
> URL: https://issues.apache.org/jira/browse/TEXT-118
> Project: Commons Text
>  Issue Type: Bug
>Affects Versions: 1.2
> Environment: JDK8u162, Mac OS X 13.something.
>Reporter: Dan Wallach
>Assignee: Rob Tompkins
>Priority: Minor
>
> Here's a simple unit test. The assertion about backspace succeeds. The 
> assertion about the delete character fails. Instead, the delete character 
> shows up in the escaped text. This violates the JSON spec, which forbids 
> "control characters" in strings.
> {code:java}
> @Test
> public void testDeleteCharacter() {
>   String backspaceString = "Backspace: \b";
>   String deleteString = "Delete: \u007F";
>   assertEquals("Backspace: \\b", 
> StringEscapeUtils.escapeJson(backspaceString));
>   assertEquals("Delete: \\u007F", StringEscapeUtils.escapeJson(deleteString));
> }
> {code}
>  
> The JSON spec doesn't have a specific escape for a delete character, but it 
> does explicitly exclude control characters from passing through. I'd 
> recommend behavior as in the above unit test.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (TEXT-118) JSON escaping incorrect for the delete control character

[Rob Tompkins (JIRA)]

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

Rob Tompkins updated TEXT-118:
--
Assignee: Rob Tompkins

> JSON escaping incorrect for the delete control character
> 
>
> Key: TEXT-118
> URL: https://issues.apache.org/jira/browse/TEXT-118
> Project: Commons Text
>  Issue Type: Bug
>Affects Versions: 1.2
> Environment: JDK8u162, Mac OS X 13.something.
>Reporter: Dan Wallach
>Assignee: Rob Tompkins
>Priority: Minor
>
> Here's a simple unit test. The assertion about backspace succeeds. The 
> assertion about the delete character fails. Instead, the delete character 
> shows up in the escaped text. This violates the JSON spec, which forbids 
> "control characters" in strings.
> {code:java}
> @Test
> public void testDeleteCharacter() {
>   String backspaceString = "Backspace: \b";
>   String deleteString = "Delete: \u007F";
>   assertEquals("Backspace: \\b", 
> StringEscapeUtils.escapeJson(backspaceString));
>   assertEquals("Delete: \\u007F", StringEscapeUtils.escapeJson(deleteString));
> }
> {code}
>  
> The JSON spec doesn't have a specific escape for a delete character, but it 
> does explicitly exclude control characters from passing through. I'd 
> recommend behavior as in the above unit test.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Closed] (LANG-1419) Restore BundleSymbolicName / regression in version 3.8.0

[Rob Tompkins (JIRA)]

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

Rob Tompkins closed LANG-1419.
--

3.8.1 released.

> Restore BundleSymbolicName / regression in version 3.8.0
> 
>
> Key: LANG-1419
> URL: https://issues.apache.org/jira/browse/LANG-1419
> Project: Commons Lang
>  Issue Type: Bug
>  Components: General
>Affects Versions: 3.8
>Reporter: Philipp Ottlinger
>Assignee: Rob Tompkins
>Priority: Critical
> Fix For: 3.8.1
>
>
> In contrast to version 3.7.0 the BundleSymbolicName changed erroneously in 
> 3.8.0 to:
> {code:java}
> org.apache.commons.commons-lang3{code}
>  
> As this breaks existing installations the change should be reverted and a new 
> version with OSGi support should be released.
> h2. v3.8.0 - MetaData
> {code:java}
> Automatic-Module-Name    org.apache.commons.lang3 
>   
> Bnd-LastModified 1534383412565
>    
> Build-Jdk    1.8.0_172
>   
> Built-By chtompki 
>   
> Bundle-Description   Apache Commons Lang, a package of 
> Java utility classes for the  classes that are in java.lang's hierarchy, or 
> are considered to be so  standard as to justify existence in java.lang.
> Bundle-DocURL    
> http://commons.apache.org/proper/commons-lang/
> Bundle-License       
> https://www.apache.org/licenses/LICENSE-2.0.txt
> Bundle-ManifestVersion   2
>   
> Bundle-Name  Apache Commons Lang  
>   
> Bundle-SymbolicName  org.apache.commons.commons-lang3 
>   
> Bundle-Vendor    The Apache Software Foundation   
>   
> Bundle-Version   3.8.0
>   
> Created-By   Apache Maven Bundle Plugin   
>   
> Export-Package   
> org.apache.commons.lang3;version="3.8",org.apache.commons.lang3.arch;version="3.8",org.apache.commons.lang3.builder;version="3.8",org.apache.commons.lang3.concurrent;version="3.8",org.apache.commons.lang3.event;version="3.8",org.apache.commons.lang3.exception;version="3.8",org.apache.commons.lang3.math;version="3.8",org.apache.commons.lang3.mutable;version="3.8",org.apache.commons.lang3.reflect;version="3.8",org.apache.commons.lang3.text;version="3.8",org.apache.commons.lang3.text.translate;version="3.8",org.apache.commons.lang3.time;version="3.8",org.apache.commons.lang3.tuple;version="3.8"
> Implementation-Title Apache Commons Lang  
>   
> Implementation-URL   
> http://commons.apache.org/proper/commons-lang/
> Implementation-Vendor    The Apache Software Foundation   
>   
> Implementation-Vendor-Id org.apache.commons   
>   
> Implementation-Version   3.8  
>   
> Include-Resource 
> META-INF/NOTICE.txt=NOTICE.txt,META-INF/LICENSE.txt=LICENSE.txt
> Manifest-Version 1.0  
>   
> Require-Capability   
> osgi.ee;filter:="(&(osgi.ee=JavaSE)(version=1.7))"
> Specification-Title  Apache Commons Lang  
>   
> Specification-Vendor The Apache Software Foundation   
>   
> Specification-Version    3.8  
>   
> Tool Bnd-3.5.0.201709291849{code}
> h2. v3.7.0 - MetaData
> {code:java}
> Archiver-Version Plexus Archiver  
>   
> Automatic-Module-Name    org.apache.commons.lang3 
>   
> Bnd-LastModified 1509819256170
>   
> Build-Jdk    1.7.0_80 
>   
> Built-By ggregory 
>   
> Bundle-Description   Apache Commons Lang, a package of 
> Java utility classes for the  classes that are in java.lang's hierarchy, or 
> are considered to be so  standard as to justify existence in java.lang.
> Bundle-DocURL    
> http://commons.apache.org/proper/commons-lang/
> Bundle-License   
> https://www.apache.org/licenses/LICENSE-2.0.txt
> Bundle-ManifestVersion   2
>   
> Bundle-Name   

[jira] [Resolved] (LANG-1419) Restore BundleSymbolicName / regression in version 3.8.0

[Rob Tompkins (JIRA)]

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

Rob Tompkins resolved LANG-1419.

Resolution: Fixed

In tag LANG_3_8_1_RC1: 
https://github.com/apache/commons-lang/blob/LANG_3_8_1_RC1/pom.xml#L574

> Restore BundleSymbolicName / regression in version 3.8.0
> 
>
> Key: LANG-1419
> URL: https://issues.apache.org/jira/browse/LANG-1419
> Project: Commons Lang
>  Issue Type: Bug
>  Components: General
>Affects Versions: 3.8
>Reporter: Philipp Ottlinger
>Assignee: Rob Tompkins
>Priority: Critical
> Fix For: 3.8.1
>
>
> In contrast to version 3.7.0 the BundleSymbolicName changed erroneously in 
> 3.8.0 to:
> {code:java}
> org.apache.commons.commons-lang3{code}
>  
> As this breaks existing installations the change should be reverted and a new 
> version with OSGi support should be released.
> h2. v3.8.0 - MetaData
> {code:java}
> Automatic-Module-Name    org.apache.commons.lang3 
>   
> Bnd-LastModified 1534383412565
>    
> Build-Jdk    1.8.0_172
>   
> Built-By chtompki 
>   
> Bundle-Description   Apache Commons Lang, a package of 
> Java utility classes for the  classes that are in java.lang's hierarchy, or 
> are considered to be so  standard as to justify existence in java.lang.
> Bundle-DocURL    
> http://commons.apache.org/proper/commons-lang/
> Bundle-License       
> https://www.apache.org/licenses/LICENSE-2.0.txt
> Bundle-ManifestVersion   2
>   
> Bundle-Name  Apache Commons Lang  
>   
> Bundle-SymbolicName  org.apache.commons.commons-lang3 
>   
> Bundle-Vendor    The Apache Software Foundation   
>   
> Bundle-Version   3.8.0
>   
> Created-By   Apache Maven Bundle Plugin   
>   
> Export-Package   
> org.apache.commons.lang3;version="3.8",org.apache.commons.lang3.arch;version="3.8",org.apache.commons.lang3.builder;version="3.8",org.apache.commons.lang3.concurrent;version="3.8",org.apache.commons.lang3.event;version="3.8",org.apache.commons.lang3.exception;version="3.8",org.apache.commons.lang3.math;version="3.8",org.apache.commons.lang3.mutable;version="3.8",org.apache.commons.lang3.reflect;version="3.8",org.apache.commons.lang3.text;version="3.8",org.apache.commons.lang3.text.translate;version="3.8",org.apache.commons.lang3.time;version="3.8",org.apache.commons.lang3.tuple;version="3.8"
> Implementation-Title Apache Commons Lang  
>   
> Implementation-URL   
> http://commons.apache.org/proper/commons-lang/
> Implementation-Vendor    The Apache Software Foundation   
>   
> Implementation-Vendor-Id org.apache.commons   
>   
> Implementation-Version   3.8  
>   
> Include-Resource 
> META-INF/NOTICE.txt=NOTICE.txt,META-INF/LICENSE.txt=LICENSE.txt
> Manifest-Version 1.0  
>   
> Require-Capability   
> osgi.ee;filter:="(&(osgi.ee=JavaSE)(version=1.7))"
> Specification-Title  Apache Commons Lang  
>   
> Specification-Vendor The Apache Software Foundation   
>   
> Specification-Version    3.8  
>   
> Tool Bnd-3.5.0.201709291849{code}
> h2. v3.7.0 - MetaData
> {code:java}
> Archiver-Version Plexus Archiver  
>   
> Automatic-Module-Name    org.apache.commons.lang3 
>   
> Bnd-LastModified 1509819256170
>   
> Build-Jdk    1.7.0_80 
>   
> Built-By ggregory 
>   
> Bundle-Description   Apache Commons Lang, a package of 
> Java utility classes for the  classes that are in java.lang's hierarchy, or 
> are considered to be so  standard as to justify existence in java.lang.
> Bundle-DocURL    
> http://commons.apache.org/proper/commons-lang/
> Bundle-License   
> https://www.apache.org/licenses/LICENSE-2.0.txt
> 

[jira] [Updated] (LANG-1419) Restore BundleSymbolicName / regression in version 3.8.0

[Rob Tompkins (JIRA)]

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

Rob Tompkins updated LANG-1419:
---
Fix Version/s: 3.8.1

> Restore BundleSymbolicName / regression in version 3.8.0
> 
>
> Key: LANG-1419
> URL: https://issues.apache.org/jira/browse/LANG-1419
> Project: Commons Lang
>  Issue Type: Bug
>  Components: General
>Affects Versions: 3.8
>Reporter: Philipp Ottlinger
>Assignee: Rob Tompkins
>Priority: Critical
> Fix For: 3.8.1
>
>
> In contrast to version 3.7.0 the BundleSymbolicName changed erroneously in 
> 3.8.0 to:
> {code:java}
> org.apache.commons.commons-lang3{code}
>  
> As this breaks existing installations the change should be reverted and a new 
> version with OSGi support should be released.
> h2. v3.8.0 - MetaData
> {code:java}
> Automatic-Module-Name    org.apache.commons.lang3 
>   
> Bnd-LastModified 1534383412565
>    
> Build-Jdk    1.8.0_172
>   
> Built-By chtompki 
>   
> Bundle-Description   Apache Commons Lang, a package of 
> Java utility classes for the  classes that are in java.lang's hierarchy, or 
> are considered to be so  standard as to justify existence in java.lang.
> Bundle-DocURL    
> http://commons.apache.org/proper/commons-lang/
> Bundle-License       
> https://www.apache.org/licenses/LICENSE-2.0.txt
> Bundle-ManifestVersion   2
>   
> Bundle-Name  Apache Commons Lang  
>   
> Bundle-SymbolicName  org.apache.commons.commons-lang3 
>   
> Bundle-Vendor    The Apache Software Foundation   
>   
> Bundle-Version   3.8.0
>   
> Created-By   Apache Maven Bundle Plugin   
>   
> Export-Package   
> org.apache.commons.lang3;version="3.8",org.apache.commons.lang3.arch;version="3.8",org.apache.commons.lang3.builder;version="3.8",org.apache.commons.lang3.concurrent;version="3.8",org.apache.commons.lang3.event;version="3.8",org.apache.commons.lang3.exception;version="3.8",org.apache.commons.lang3.math;version="3.8",org.apache.commons.lang3.mutable;version="3.8",org.apache.commons.lang3.reflect;version="3.8",org.apache.commons.lang3.text;version="3.8",org.apache.commons.lang3.text.translate;version="3.8",org.apache.commons.lang3.time;version="3.8",org.apache.commons.lang3.tuple;version="3.8"
> Implementation-Title Apache Commons Lang  
>   
> Implementation-URL   
> http://commons.apache.org/proper/commons-lang/
> Implementation-Vendor    The Apache Software Foundation   
>   
> Implementation-Vendor-Id org.apache.commons   
>   
> Implementation-Version   3.8  
>   
> Include-Resource 
> META-INF/NOTICE.txt=NOTICE.txt,META-INF/LICENSE.txt=LICENSE.txt
> Manifest-Version 1.0  
>   
> Require-Capability   
> osgi.ee;filter:="(&(osgi.ee=JavaSE)(version=1.7))"
> Specification-Title  Apache Commons Lang  
>   
> Specification-Vendor The Apache Software Foundation   
>   
> Specification-Version    3.8  
>   
> Tool Bnd-3.5.0.201709291849{code}
> h2. v3.7.0 - MetaData
> {code:java}
> Archiver-Version Plexus Archiver  
>   
> Automatic-Module-Name    org.apache.commons.lang3 
>   
> Bnd-LastModified 1509819256170
>   
> Build-Jdk    1.7.0_80 
>   
> Built-By ggregory 
>   
> Bundle-Description   Apache Commons Lang, a package of 
> Java utility classes for the  classes that are in java.lang's hierarchy, or 
> are considered to be so  standard as to justify existence in java.lang.
> Bundle-DocURL    
> http://commons.apache.org/proper/commons-lang/
> Bundle-License   
> https://www.apache.org/licenses/LICENSE-2.0.txt
> Bundle-ManifestVersion   2
>   
> Bundle-Name