Re: [LANG] Releasing 3.6.1

2017-09-07 Thread Pascal Schumacher 

What I really wanted to say was:

I'm for keeping RandomStringUtils undeprecated in lang.

Sorry,
Pascal

Am 06.09.2017 um 21:20 schrieb Gary Gregory:

On Sep 6, 2017 12:31, "Pascal Schumacher"  wrote:

I'm for keeping RandomStringUtils in lang (at least in 3.x).


It has to stay in 3.x no matter what to maintain BC.

Gary



Am 06.09.2017 um 12:55 schrieb Rob Tompkins:


On Sep 6, 2017, at 3:34 AM, Amey Jadiye  wrote:

Hi Rob,

Looking at frequency I think more number of requests coming
for RandomStringUtils for its simplicity.

RandomStringGenerator is strong , flexible but one can't use it quickly.
Also I think this tool should belong in Commons text's arsenal. I'm not
only moving RandomStringUtils  to text but changing its core logic with
using
RandomStringGenerator which seems fair to me. So finally we should release
text-1.2 rather doing rollback of deprecation and release lang 3.6.1,
WDYT
?

I definitely lean this direction, but if I recall correctly we drew “line

between [lang] and [text]” to be: a piece of functionality should go in
[lang] if the arbitrary java developer would probably want it, whereas text
is geared towards folks actually doing text manipulation [1].

Personally I’m a +0 to +1 on doing this, but I wanted to gauge other
folks’ thoughts here because I feel like we’re in that grey area here. That
said, I’m perfectly willing to roll a 1.2 [text] release.

Cheers,
-Rob

[1] http://markmail.org/message/a2urysnxvxihfoto

Regards,

Amey

On Wed, Sep 6, 2017, 12:00 AM Rob Tompkins  wrote:

On Sep 5, 2017, at 11:00 AM, Amey Jadiye  wrote:

Hello Benedikt,

How about we keep that deprecated in lang and release Text-1.2 ?


[snip]

I’m on board with this if folks are complaining and the original intent
was to deprecate things in [lang]. Why not roll forward as opposed to
backwards?

But, that opens the question: Is RandomStringUtils something that most
folks would want (i.e. should it be in [lang] or [text])? I think that
question is more the heart of the problem here. Either direction seems
reasonable to me.

Thoughts?

-Rob

I will

submit changes [1] related to this in fact i'm fixing couple of failing
test cases ATM. If you are planning to release 3.6.1 just to remove
deprecation and  deprecate RandomStringUtils back in Lang - 3.7 I'm fine
with that as well.

[1]. https://issues.apache.org/jira/browse/TEXT-101

On Tue, Sep 5, 2017 at 10:47 AM, Benedikt Ritter 


wrote:


Hi,

since we’re getting more and more requests about the deprecation of
RandomStringUtils, I’m thinking about releasing the current state of
the
master branch as 3.6.1. I may have time to push an RC sometime this


week.
So if you have some fixes you want to include, please do so now.

Regards,
Benedikt
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org




--

-

To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org

For additional commands, e-mail: dev-h...@commons.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org




-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org




-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: commons-numbers git commit: NUMBERS-22: if block added to ensure that reciprocal of very small real numbers return an imaginary component of 0 rather than NaN

2017-09-07 Thread Gilles 

Hi Eric.

On Thu,  7 Sep 2017 13:18:46 + (UTC), ericbarnh...@apache.org 
wrote:

Repository: commons-numbers
Updated Branches:
  refs/heads/complex-dev ec3bb9ed9 -> f0d1b9cdc


NUMBERS-22: if block added to ensure that reciprocal of very small
real numbers return an imaginary component of 0 rather than NaN


Project: http://git-wip-us.apache.org/repos/asf/commons-numbers/repo
Commit:

http://git-wip-us.apache.org/repos/asf/commons-numbers/commit/f0d1b9cd
Tree: 
http://git-wip-us.apache.org/repos/asf/commons-numbers/tree/f0d1b9cd
Diff: 
http://git-wip-us.apache.org/repos/asf/commons-numbers/diff/f0d1b9cd


Branch: refs/heads/complex-dev
Commit: f0d1b9cdc279c5438a799d62b74effb7ece4958b
Parents: ec3bb9e
Author: Eric Barnhill 
Authored: Thu Sep 7 15:21:28 2017 +0200
Committer: Eric Barnhill 
Committed: Thu Sep 7 15:21:28 2017 +0200


--
 .../org/apache/commons/numbers/complex/Complex.java | 16 
++--

 1 file changed, 14 insertions(+), 2 deletions(-)

--



http://git-wip-us.apache.org/repos/asf/commons-numbers/blob/f0d1b9cd/commons-numbers-complex/src/main/java/org/apache/commons/numbers/complex/Complex.java

--
diff --git

a/commons-numbers-complex/src/main/java/org/apache/commons/numbers/complex/Complex.java

b/commons-numbers-complex/src/main/java/org/apache/commons/numbers/complex/Complex.java
index 7fcbbf4..d396619 100644
---

a/commons-numbers-complex/src/main/java/org/apache/commons/numbers/complex/Complex.java
+++

b/commons-numbers-complex/src/main/java/org/apache/commons/numbers/complex/Complex.java
@@ -355,11 +355,23 @@ in the
 if (Math.abs(real) < Math.abs(imaginary)) {
 double q = real / imaginary;


Constant should be "final".


 double scale = 1. / (real * q + imaginary);


"final"


-return new Complex(scale * q, -scale);
+double scaleQ;


Wouldn't it be better to assign 0 as default?
Seems to reduce code.


+if (q == 0 | scale == 0) {


Typo? Should be "||".


+scaleQ = 0;
+} else {
+scaleQ = scale * q;
+}
+return new Complex(scaleQ, -scale);
 } else {
 double q = imaginary / real;


"final"


 double scale = 1. / (imaginary * q + real);


"final"


-return new Complex(scale, -scale * q);
+double scaleQ;
+if (q == 0 | scale == 0) {


"||"


+scaleQ = 0;
+} else {
+scaleQ = scale * q;
+}
+return new Complex(scale, -scaleQ);
 }
 }


Regards,
Gilles


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Moving Java Forward Faster

2017-09-07 Thread Rory O'Donnell 

Hi Benedikt,

Oracle is proposing a rapid release model for Java SE going-forward.

The high points are highlighted below, details of the changes can be 
found on Mark Reinhold’s blog [1] , OpenJDK discussion email list [2].


Under the proposed release model, after JDK 9, we will adopt a strict, 
time-based model with a new major release every six months, update 
releases every quarter, and a long-term support release every three years.


The new JDK Project will run a bit differently than the past "JDK $N" 
Projects:


- The main development line will always be open but fixes, enhancements, 
and features will be merged only when they're nearly finished. The main 
line will be Feature Complete [3] at all times.


- We'll continue to use the JEP Process [4] for new features and other 
significant changes. The bar to target a JEP to a specific release will, 
however, be higher since the work must be Feature Complete in order to 
go in. Owners of large or risky features will be strongly encouraged to 
split such features up into smaller and safer parts, to integrate 
earlier in the release cycle, and to publish separate lines of 
early-access builds prior to integration.


The JDK Updates Project will run in much the same way as the past "JDK 
$N" Updates Projects, though update releases will be strictly limited to 
fixes of security issues, regressions, and bugs in newer features.


Related to this proposal, we intend to make a few changes in what we do:

- Starting with JDK 9 we'll ship OpenJDK builds under the GPL [5], to 
make it easier for developers to deploy Java applications to cloud 
environments. We'll initially publish OpenJDK builds for Linux/x64, 
followed later by builds for macOS/x64 and Windows/x64.


- We'll continue to ship proprietary "Oracle JDK" builds, which include 
"commercial features" [6] such as Java Flight Recorder and Mission 
Control [7], under a click-through binary-code license [8]. Oracle will 
continue to offer paid support for these builds.


- After JDK 9 we'll open-source the commercial features in order to make 
the OpenJDK builds more attractive to developers and to reduce the 
differences between those builds and the Oracle JDK. This will take some 
time, but the ultimate goal is to make OpenJDK and Oracle JDK builds 
completely interchangeable.


- Finally, for the long term we'll work with other OpenJDK contributors 
to establish an open build-and-test infrastructure. This will make it 
easier to publish early-access builds for features in development, and 
eventually make it possible for the OpenJDK Community itself to publish 
authoritative builds of the JDK.


Questions , comments, feedback to OpenJDK discuss mailing list [2]

Rgds,Rory

[1]https://mreinhold.org/blog/forward-faster
[2]http://mail.openjdk.java.net/pipermail/discuss/2017-September/004281.html
[3]http://openjdk.java.net/projects/jdk8/milestones#Feature_Complete
[4]http://openjdk.java.net/jeps/0
[5]http://openjdk.java.net/legal/gplv2+ce.html
[6]http://www.oracle.com/technetwork/java/javase/terms/products/index.html
[7]http://www.oracle.com/technetwork/java/javaseproducts/mission-control/index.html
[8]http://www.oracle.com/technetwork/java/javase/terms/license/index.html


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org