Re: [math] Preparing for v3.6.2 release

[Stephen Colebourne]

The build upgrade has been merged, and the branch passes Travis and
Jenkins now. If anyone finds anything else broken on the MATH_3_X
branch I'd like to know.

I'll merge the Java 9 module name stuff soonish unless someone objects.
https://github.com/apache/commons-math/pull/107

Stephen

On Mon, 16 Sep 2019 at 20:08, Stephen Colebourne  wrote:
>
> As far as I can tell, mvn site works on the branch with my PR. Shall I merge 
> it?
> I wasn't planning on fixing master.
> Stephen
>
>
> On Mon, 16 Sep 2019 at 18:26, Gary Gregory  wrote:
> >
> > Note that right now, builds like 'mvn clean site' in git master fail
> > because of Checkstyle violations:
> >
> > [ERROR] Failed to execute goal
> > org.apache.maven.plugins:maven-site-plugin:3.7.1:site (default-site) on
> > project commons-rng-parent: failed to get report for
> > org.apache.maven.plugins:maven-javadoc-plugin: Failed to execute goal
> > org.apache.maven.plugins:maven-checkstyle-plugin:3.0.0:check (validate) on
> > project commons-rng-parent: You have 10 Checkstyle violations. -> [Help 1]
> >
> > Can someone please fix those so we can run simple builds from the command
> > line?
> >
> > Gary
> >
> >
> >
> > On Mon, Sep 16, 2019 at 1:16 PM sebb  wrote:
> >
> > > On Mon, 16 Sep 2019 at 16:58, Stephen Colebourne 
> > > wrote:
> > > >
> > > > I've started to try and get a release out on the branch to get the
> > > > Java module name in. Since I haven't committed in many years this
> > > > isn't going to be easy.
> > > >
> > > > I've successfully pushed a small fix directly to the MATH_3_X branch.
> > > > I've seen something suggesting that branches can't be deleted, which
> > > > makes me concerned, although I was able to delete my branch. Can
> > > > branches actually be deleted on git?
> > >
> > > AFAIK, yes.
> > >
> > > The refs/tags/rel tree is protected; I think that's about it.
> > >
> > > > I've tried to bring the branch up to date with the v48 parent, https
> > > > and so on, but would appreciate someone more knowledgable checking for
> > > > anything stupid:
> > > > https://github.com/apache/commons-math/pull/113
> > > >
> > > > The build passes on Travis, but it doesn't look like the Jenkins build
> > > > is triggered except by commits on MATH_3_X itself. And since I can't
> > > > see the setup of the Jenkins build, I have no way of knowing if I have
> > > > actually fixed the Jenkins build. Am I missing something?
> > > >
> > > > In general, are we pushing straight to "master" or using PRs?
> > > >
> > > > thanks
> > > > Stephen
> > > >
> > > > -
> > > > 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: [math] Preparing for v3.6.2 release

[Stephen Colebourne]

As far as I can tell, mvn site works on the branch with my PR. Shall I merge it?
I wasn't planning on fixing master.
Stephen


On Mon, 16 Sep 2019 at 18:26, Gary Gregory  wrote:
>
> Note that right now, builds like 'mvn clean site' in git master fail
> because of Checkstyle violations:
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-site-plugin:3.7.1:site (default-site) on
> project commons-rng-parent: failed to get report for
> org.apache.maven.plugins:maven-javadoc-plugin: Failed to execute goal
> org.apache.maven.plugins:maven-checkstyle-plugin:3.0.0:check (validate) on
> project commons-rng-parent: You have 10 Checkstyle violations. -> [Help 1]
>
> Can someone please fix those so we can run simple builds from the command
> line?
>
> Gary
>
>
>
> On Mon, Sep 16, 2019 at 1:16 PM sebb  wrote:
>
> > On Mon, 16 Sep 2019 at 16:58, Stephen Colebourne 
> > wrote:
> > >
> > > I've started to try and get a release out on the branch to get the
> > > Java module name in. Since I haven't committed in many years this
> > > isn't going to be easy.
> > >
> > > I've successfully pushed a small fix directly to the MATH_3_X branch.
> > > I've seen something suggesting that branches can't be deleted, which
> > > makes me concerned, although I was able to delete my branch. Can
> > > branches actually be deleted on git?
> >
> > AFAIK, yes.
> >
> > The refs/tags/rel tree is protected; I think that's about it.
> >
> > > I've tried to bring the branch up to date with the v48 parent, https
> > > and so on, but would appreciate someone more knowledgable checking for
> > > anything stupid:
> > > https://github.com/apache/commons-math/pull/113
> > >
> > > The build passes on Travis, but it doesn't look like the Jenkins build
> > > is triggered except by commits on MATH_3_X itself. And since I can't
> > > see the setup of the Jenkins build, I have no way of knowing if I have
> > > actually fixed the Jenkins build. Am I missing something?
> > >
> > > In general, are we pushing straight to "master" or using PRs?
> > >
> > > thanks
> > > Stephen
> > >
> > > -
> > > 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

[math] Preparing for v3.6.2 release

[Stephen Colebourne]

I've started to try and get a release out on the branch to get the
Java module name in. Since I haven't committed in many years this
isn't going to be easy.

I've successfully pushed a small fix directly to the MATH_3_X branch.
I've seen something suggesting that branches can't be deleted, which
makes me concerned, although I was able to delete my branch. Can
branches actually be deleted on git?

I've tried to bring the branch up to date with the v48 parent, https
and so on, but would appreciate someone more knowledgable checking for
anything stupid:
https://github.com/apache/commons-math/pull/113

The build passes on Travis, but it doesn't look like the Jenkins build
is triggered except by commits on MATH_3_X itself. And since I can't
see the setup of the Jenkins build, I have no way of knowing if I have
actually fixed the Jenkins build. Am I missing something?

In general, are we pushing straight to "master" or using PRs?

thanks
Stephen

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

Re: [math] MATH-1486 and release 3.6.2

[Stephen Colebourne]

On Fri, 7 Jun 2019 at 15:16, Gilles Sadowski  wrote:
> drive such a maintenance/security release.
> If the build process works on your machine, you are a better
> RM candidate. ;-)

Given I haven't committed to commons for 10+ years (at a guess), I'm
not a PMC member and probably don't have permission to push anymore, I
don't see how it is realistic for me to be RM.
Stephen

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

Re: [math] MATH-1486 and release 3.6.2

[Stephen Colebourne]

On Thu, 6 Jun 2019 at 23:21, Gilles Sadowski  wrote:
> I was about to merge the PR but, on my machine, the build fails.
> Did you try?

`mvn clean verify` works for me (maven running on Java 7 and on Java 8).

> Back then (pre-fork), I was in favour of maintaining both lines (3.X
> and 4.X); but the 3.X branch has not been maintained for more than
> 3 years, and it shows.  Now (post-fork), my opinion is that the effort
> would be better placed in getting the new dependencies of the
> development version of Commons Math released, and release CM
> 4.0 thereafter.

Its great that there is a plan to move forward. But that doesn't solve
the key issue here. Commons-Math 3 is used by over 2300 open source
repos on GitHub [1]. Of course not all are significant projects, but
some are. While some of those projects may be able to move to
Commons-Math 4 when it completes, others will not be able to (because
of their own compatibility constraints). And some of those projects
may want/need to use Java 9 modules, but can't because Commons-Math 3
doesn't have a module name. I'm trying to provide a minimum effort way
for you or another release manager to satisfy that need. I'm very
definitely NOT trying to fix bugs or maintain the branch - in fact my
proposed approach is closer to a security patch in scope.

Stephen

[1] https://github.com/apache/commons-math/network/dependents

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

[math] MATH-1486 and release 3.6.2

[Stephen Colebourne]

I've raised a GitHub PR [1] to add the Java 9 module name to [math] on
the MATH_3_X branch. Assuming that is merged, I'm willing to raise
another PR with the necessary bits to prepare the repo to release
v3.6.2.

This approach sidesteps all issues with commons-4 and does the minimum
necessary for downstream users to use the project as a module in Java
9 onwards. (At my day job we produce open source that depends on
commons-math, which means I can't add a module-info.java until
commons-math has a module name.)

While I'm technically still a commons committer, I think it would be
highly innappropriate for me to try and shepherd the actual v3.6.2
release. Is anyone willing to work with me to do the release? A v3.6.2
release would contain just the module name change and one performance
improvement that was added to the repo in 2016, so it should be a case
of cranking the handle providing not too much has changed in the
process since 2016.

thanks
Stephen
[1] https://github.com/apache/commons-math/pull/107

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

Re: [commons-numbers] [...] NUMBERS-91: Added ofInt() factory methods [...]

[Stephen Colebourne]

I'd suggest `of` and `ofXxx` for factories that perform little work,
such as assigning to instance fields, and `from` and `fromXxx` for
factories that perform meaningful work or conversion.

Stephen


On Fri, 28 Dec 2018 at 17:24, Eric Barnhill  wrote:
>
> Fractions are constructed using either ints or doubles. In the case of
> ints, the numerator and denominator are passed (or the denominator is
> assumed to be one). Constructing fractions from doubles is more algorithmic
> work: if I pass a known fixed quantity such as 0.6 of course it will not be
> hard for the constructor to determine that is the equivalent of 3 / 5 .
> However if doubles are being passed of unknown precision, then I may want
> to request a max value on the denominator, or a precision within which the
> simplest fraction should be returned, or even the maximum iterations in the
> computation.
>
> I think of those as qualitatively very different activities so I called
> them ofInt and ofDouble. The example I had in mind was probably Complex,
> where we have ofPolar and ofCartesian. I suppose you are right, in this
> case the hard typing of the passed variables alone could invoke either an
> int or double based method while with Complex, both constructors are taking
> doubles.
>
> You do then have some very similar methods, for example of(int a, int b)
> will be an integer fraction with a on top and b on bottom; while calling
> of(double a, int b) will produce a fraction that approximates double a with
> max denominator b.
>
> Those two processes are so different that it might be more clarifying to
> distinguish them as ofInt(int a, int b) and ofDouble(double a, int b)
>
> Eric
>
>
> On Fri, Dec 28, 2018 at 4:33 AM Gilles  wrote:
>
> > Hello Eric.
> >
> > On Thu, 27 Dec 2018 17:00:15 -0800, Eric Barnhill wrote:
> > > I am overloading:
> > >
> > > public static BigFraction ofInt(final BigInteger num) {
> > > return new BigFraction(num, BigInteger.ONE);
> > > }
> > >
> > > public static BigFraction ofInt(BigInteger num, BigInteger den) {
> > > return new BigFraction(num, den);
> > > }
> > >
> > > private BigFraction(BigInteger num, BigInteger den) {
> > >
> > > Did my comment not give that impression?
> >
> > I was in fact wondering why "ofInt" rather than just "of".
> >
> > Best,
> > Gilles
> >
> > >> [...]
> >
> >
> > -
> > 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: [Numbers] Inheritance and ValJO ?

[Stephen Colebourne]

I can see the paragraph I wrote way back when, but I'd disagree with myself
now. To be a VALJO you can't be abstract nor have subclasses, even a closed
set. I say this on the basis that AFAICT, future value types will also have
the same restrictions.

That said, VALJO rules are intended as a guide to best practice that may be
beneficial when value types arrive. I don't think the code you've got is
fundamentally wrong - its a reasonable way to share logic. An alternative
would be an enum `QuaternianType` that has methods.

final class Quaternion {
  private final QuaternionType type;
  private final double w;
private final double x;
private final double y;
private final double z;

 public double norm() {
   return type.norm(w, x, y, z);
 }

 public double normSq() {
   return type.norm(w, x, y, z);
 }
 // and so on
}

By delegating the methods via the type enum, you get flexible behaviour
without subclass.
Stephen




On Wed, 12 Dec 2018 at 23:20, Gilles  wrote:

> Hi.
>
> On Wed, 12 Dec 2018 22:48:54 +, Stephen Colebourne wrote:
> > I think this has already been worked out, but the main reason for no
> > inheritance is that is probably blocks future conversion to value
> > types.
> > Composition instead of inheritance is usually the right solution.
>
> Thanks for the reply.
>
> Do you think that the implementation here:
>
>
> https://gitbox.apache.org/repos/asf?p=commons-numbers.git;a=blob;f=commons-numbers-quaternion/src/main/java/org/apache/commons/numbers/quaternion/Quaternion.java
> still counts as ValJO, despite allowing (mandating even) inheritance
> by inner classes (as per your paragraph that ends with "The need for
> this is rare however.")
>
> What I don't quite see is the consequences of the class not being
> final...
>
>
> Gilles
>
> >
> > Stephen
> >
> >
> > On Sun, 9 Dec 2018 at 10:21, Gilles 
> > wrote:
> >
> >> Hello.
> >>
> >> After the discussion quote below, the conclusion was to go with
> >> inheritance:
> >>https://issues.apache.org/jira/browse/NUMBERS-80
> >>
> >> However, it would make "Quaternion" fail the "ValJO" definition[1]
> >> that mandates that all constructors be private.
> >>
> >> Would a protected constructor really be an issue?
> >> [In the case of "Quaternion", the subclass constructor would only
> >> perform additional validation (cf. below for details).]
> >>
> >>
> >> Thanks,
> >> Gilles
> >>
> >> [1] https://blog.joda.org/2014/03/valjos-value-java-objects.html
> >>
> >> On Mon, 03 Dec 2018 10:31:42 +0100, Gilles wrote:
> >> > Hi.
> >> >
> >> > On Mon, 3 Dec 2018 03:56:02 +, Matt Juntunen wrote:
> >> >> I was just thinking from a practical standpoint. My current
> >> >> QuaternionRotation class is still in my working branch for
> >> >> GEOMETRY-14
> >> >> and so isn't really accessible to anyone. If I can finish it up
> >> in
> >> >> its
> >> >> current state (hopefully very soon) and get it merged, then
> >> someone
> >> >> else will be able to work with it and blend the functionality
> >> with
> >> >> commons-numbers.
> >> >
> >> > Someone else?
> >> >
> >> >>
> >> >> Here are some notes on your questions from before:
> >> >>
> >> >>   * Should "QuaternionRotation" inherit from "Quaternion"?
> >> >>
> >> >> That would work conceptually. The quaternions in the
> >> >> QuaternionRotation class are standard quaternions that meet two
> >> >> other
> >> >> criteria: 1) they are unit length, and 2) their scalar component
> >> is
> >> >> greater than or equal to zero (in order to standardize the angles
> >> >> involved).
> >> >
> >> > It seems indeed the perfect case for inheritance.
> >> >
> >> >> The one sticking point here is that I'm not sure how this
> >> >> fits with the VALJO concept. If we can get this sorted, then this
> >> >> very
> >> >> well may be the best option.
> >> >
> >> > What do you see as a potential issue?
> >> >
> >> >>
> >> >>   * Should "Quaternion" be defined in [Geometry] (and removed
> >> from
> >> >> [Numbers])?
> >> >>
> >> >> Perhaps. I've certainly only used 

Re: [Numbers] Inheritance and ValJO ? (Was: Where to define "quaternion"?)

[Stephen Colebourne]

I think this has already been worked out, but the main reason for no
inheritance is that is probably blocks future conversion to value types.
Composition instead of inheritance is usually the right solution.

Stephen


On Sun, 9 Dec 2018 at 10:21, Gilles  wrote:

> Hello.
>
> After the discussion quote below, the conclusion was to go with
> inheritance:
>https://issues.apache.org/jira/browse/NUMBERS-80
>
> However, it would make "Quaternion" fail the "ValJO" definition[1]
> that mandates that all constructors be private.
>
> Would a protected constructor really be an issue?
> [In the case of "Quaternion", the subclass constructor would only
> perform additional validation (cf. below for details).]
>
>
> Thanks,
> Gilles
>
> [1] https://blog.joda.org/2014/03/valjos-value-java-objects.html
>
> On Mon, 03 Dec 2018 10:31:42 +0100, Gilles wrote:
> > Hi.
> >
> > On Mon, 3 Dec 2018 03:56:02 +, Matt Juntunen wrote:
> >> I was just thinking from a practical standpoint. My current
> >> QuaternionRotation class is still in my working branch for
> >> GEOMETRY-14
> >> and so isn't really accessible to anyone. If I can finish it up in
> >> its
> >> current state (hopefully very soon) and get it merged, then someone
> >> else will be able to work with it and blend the functionality with
> >> commons-numbers.
> >
> > Someone else?
> >
> >>
> >> Here are some notes on your questions from before:
> >>
> >>   * Should "QuaternionRotation" inherit from "Quaternion"?
> >>
> >> That would work conceptually. The quaternions in the
> >> QuaternionRotation class are standard quaternions that meet two
> >> other
> >> criteria: 1) they are unit length, and 2) their scalar component is
> >> greater than or equal to zero (in order to standardize the angles
> >> involved).
> >
> > It seems indeed the perfect case for inheritance.
> >
> >> The one sticking point here is that I'm not sure how this
> >> fits with the VALJO concept. If we can get this sorted, then this
> >> very
> >> well may be the best option.
> >
> > What do you see as a potential issue?
> >
> >>
> >>   * Should "Quaternion" be defined in [Geometry] (and removed from
> >> [Numbers])?
> >>
> >> Perhaps. I've certainly only used them to represent 3D rotations.
> >> Are
> >> there any other use cases from commons-numbers?
> >
> > Not within [Numbers], but that's the point of those very low-level
> > components/modules: they are common utilities used by higher-level
> > components/libraries/applications.
> >
> > Given that "QuaternionRotation" is a special case of "Quaternion",
> > it is logical to keep the latter at a lower-level, namely in
> > [Numebers], and make [Geometry] depend on it.
> >
> >>
> >>   * Are some utilities defined in "QuaternionRotation" general
> >> such that they could be part of the [Numbers] "Quaternion" API.
> >> An example might be the transformation between quaternion and
> >> matrix (represented as a double[3][3])?
> >>
> >> The conversion to rotation matrix and slerp are the best candidates
> >> here. The other methods rely on core classes from commons-geometry,
> >> namely Vector3D.
> >
> > Is "slerp" applicable to a general "Quaternion", or does it assume
> > the additional requirements of "QuaternionRotation"?
> > [Same question applies to all utilities in order to decide where to
> > define them.]
> >
> >>
> >> One more note: I decided to make a separate package for 3D rotations
> >> in my working branch for GEOMETRY-14, so QuaternionRotation is now
> >> at
> >>
> >>
> https://github.com/darkma773r/commons-geometry/blob/transforms/commons-geometry-euclidean/src/main/java/org/apache/commons/geometry/euclidean/threed/rotation/QuaternionRotation.java
> .
> >
> > Could you please update it so that it inherits from "Quaternion"?
> >
> > Thanks,
> > Gilles
> >
> >>
> >> -Matt
> >> 
> >> From: Gilles 
> >> Sent: Sunday, December 2, 2018 3:57 PM
> >> To: dev@commons.apache.org
> >> Subject: Re: [Numbers][Geometry] Where to define "quaternion" (Was:
> >> Making Quaternion a VALJO)
> >>
> >> On Sun, 2 Dec 2018 19:20:03 +, Matt Juntunen wrote:
> >>> Unless anyone objects, I'm going to continue with what I'm working
> >>> on
> >>
> >> I certainly don't object on your working to improve the geometry
> >> code, but wherever that work overlaps with code being worked on
> >> elsewhere (in this case, the "Quaternion" class), then we'd
> >> rather have a discussion happening here first.
> >>
> >>> with QuaternionRotation and create a merge request. That way, we'll
> >>> at
> >>> least have a reference implementation and baseline functionality
> >>> for
> >>> commons-geometry that we can modify later based on what's decided
> >>> here.
> >>
> >> My questions below are a start; I'm waiting for answers.
> >> Code duplication is bad (TM).
> >>
> >> Regards,
> >> Gilles
> >>
> >>>
> >>> -Matt
> >>> 
> >>> From: Gilles 
> >>> Sent: Saturday, December 1, 2018 9:40 PM
> >>> To: 

Re: [numbers] Making fractions VALJOs

[Stephen Colebourne]

As the author of the blog and term VALJO, here are some comments on Fraction:

You should use `of()` (overloading allowed) when the factory normally succeeds.
You should use `from` (overloading allowed) when the factory methods
are performing a conversion and have a reasonable chance of failure.

The `int` methods should use `of`. The `double` methods could use
either, it is a judgement call as top whether it is a conversion or a
construction (does it normally succeed or not).

Looking at this code
https://git-wip-us.apache.org/repos/asf?p=commons-numbers.git;a=blob;f=commons-numbers-fraction/src/main/java/org/apache/commons/numbers/fraction/Fraction.java;h=308f93033853ca8815663c576f7c38e6770dc3c3;hb=HEAD

In the `abs()` method, there is no need for a local variable - just
return from each branch of the if statement or use a ternary.

The method order in the class is strange. I would recommend putting
the getters first. I would also recommend grouping the methods
compareTo, equals, hashCode and toString in that order at the end of
the class. See `LocalDate` for example.

The order of the static constants is also strange - I'm sure a more
logical order could be chosen.

The method `getReducedFraction` is not a getter, so it should not
start with `get`. Maybe `ofReduced()` ? Alternatively, have an
instance method `reduced()` that can be called on any fraction, so
users do `of(2, 4).reduce()`.

The recommended naming approach for methods on immutable VALJO classes
is to use the past tense:
 multiply -> multipliedBy
 divide -> dividedBy
 add -> plus
 subtract -> minus
 negate -> negated
No doubt this would apply widely in the project

HTH
Stephen


On Thu, 18 Oct 2018 at 11:45, Gilles  wrote:
>
> On Wed, 17 Oct 2018 16:33:58 -0700, Eric Barnhill wrote:
> > Oh right, that is the convention. I knew there was something off.
> >
> > As far as you understand, is to within VALJO standards to overload
> > factory
> > methods,
>
> I don't think that it is ValJO-related; method overload is a
> feature, so better use it rather than duplicate what the compiler
> can do by itself. ;-)
>
> Gilles
>
> > so long as they are not private constructors? All that is
> > specified on the page is that VALJOs must have all constructors
> > private. So
> > I am not sure whether it is in the spirit of VALJOs to overload, but
> > coming
> > up with elaborate names for each constructor doesn't seem like a very
> > streamlined coding practice.
> >
> > On Tue, Oct 16, 2018 at 5:56 PM Gilles 
> > wrote:
> >
> >> On Tue, 16 Oct 2018 16:55:02 -0700, Eric Barnhill wrote:
> >> > The Fraction class is IMO looking good (in better shape than
> >> Complex
> >> > was
> >> > in) and is already quite close to fulfilling the standards for a
> >> > VALJO.
> >> > Equals() and CompareTo() are well designed and consistent. I see
> >> two
> >> > missing steps. The easy one is a parse() method which mirrors the
> >> > toString() method. The harder one is the wide range of public
> >> > constructors.
> >> >
> >> > To be a VALJO all constructors must be private and accessed with
> >> > static
> >> > factory methods. If these factory methods themselves can be
> >> > overloaded, I
> >> > think a decent schema emerges:
> >> >
> >> > current constructor -> proposed factory method
> >> > 
> >> > public Fraction(double value) -> public fromDouble(double value)
> >> > public Fraction(double value, double epsilon, int maxIterations)
> >> ->
> >> > public
> >> > fromDouble(double value, double epsilon, int maxIterations)
> >> > public Fraction(double value,int maxDenominator)  ->  public
> >> > fromDouble
> >> > (double value,int maxDenominator)
> >> > public Fraction(int value) -> public fromInt(int value)
> >> > public Fraction(int num, int denom) -> public fromInt(int num, int
> >> > denom)
> >>
> >> Why not call them all "of(...)" ?
> >>
> >> Gilles
> >>
> >> >
> >> > so this is what I propose to go with.
> >> >
> >> > If disambiguation in the double cases is still a problem, the
> >> second
> >> > and
> >> > third of the double constructors could be fromDoubleEpsMaxInt and
> >> > fromDoubleMaxDenom .
> >> >
> >> > Eric
> >> >
> >> >
> >> > On Thu, Oct 11, 2018 at 7:00 AM Gilles
> >> 
> >> > wrote:
> >> >
> >> >> On Wed, 10 Oct 2018 16:18:50 -0700, Eric Barnhill wrote:
> >> >> > I am interested in moving forward on making the Fraction
> >> classes
> >> >> > VALJOs
> >> >> > [NUMBERS-75].
> >> >> >
> >> >> > Just a preliminary question for now, are we otherwise happy
> >> with
> >> >> the
> >> >> > Fraction class in the context of commons-numbers? Or should I
> >> look
> >> >> > around
> >> >> > for any odd behaviors leftover from commons-math (Complex had a
> >> >> lot
> >> >> > of
> >> >> > those) that might also be improved?
> >> >>
> >> >> AFAIK, there was no in-depth review as was done for "Complex".
> >> >> So it would indeed be quite useful to check what the Javadoc
> >> >> states, whether it seems 

Re: [Math] Beta release (Was: [All] What's in a "beta" release?)

[Stephen Colebourne]

What I would love to see it a release of commons-math 3 with an
Automatic-Module-Name for Java 9 modules (potentially the only
change). You could use the release as a way of advertising the
progress towards v4.

Stephen


On Thu, 30 Aug 2018 at 19:16, Gilles  wrote:
>
> On Thu, 30 Aug 2018 07:35:12 -0700, Gary Gregory wrote:
> > But SNAPSHOT builds _are_ publicly available on
> > repository.apache.org. Sure
> > they come and go and you cannot rely on their permanence.
>
> And, perhaps, developers do not check what's available there...
> Reports keep coming showing that they don't know about the status
> of "Commons Math".
>
> Thus the idea that a beta release might draw to the rejuvenation
> attempt.  A "beta" because it is still a lot of work to fix all
> the identified issues and we need extra help; a "release" because
> a lot of work has been done since the last release, providing many
> bug fixes and other improvements.
>
> A release of the development version of CM requires the release
> of its dependencies: "Commons Numbers" and "Commons Statistics".[1]
> Both would be "beta" too.
>
>
> Regards,
> Gilles
>
> [1] And also "Commons Geometry" if the code is in a state that's
>  able to replace the "o.a.c.math4.geometry" package.
>
> > Gary
> >
> > On Thu, Aug 30, 2018, 04:50 sebb  wrote:
> >
> >> SNAPSHOT builds must only be published to Commons developers.
> >> They cannot be published on public download pages.
> >>
> >> Also they may disappear or be replaced at any time.
> >>
> >> Beta builds are subject to a release VOTE, and so can be published
> >> in
> >> the usual way.
> >> Once published, they are permanently available.
> >>
> >> On 30 August 2018 at 09:38, Benedikt Ritter 
> >> wrote:
> >> > What's the difference to a nightly build being published to the
> >> Apache
> >> > Snapshot repo?
> >> >
> >> > Benedikt
> >> >
> >> > Am Mi., 29. Aug. 2018 um 21:51 Uhr schrieb Gary Gregory <
> >> > garydgreg...@gmail.com>:
> >> >
> >> >> We do not have hard rules for betas AFAIK. IMO, only a beta can
> >> depend
> >> on
> >> >> another beta, for example see HttpComponents. We should not
> >> release a
> >> >> non-beta that depends on a beta. I think breaking BC is to be
> >> expected
> >> in
> >> >> an alpha and less so in a beta. Changing package names and
> >> coordinates
> >> from
> >> >> one beta to the next seems a bit excessive but I would not object
> >> to it.
> >> >>
> >> >> Gary
> >> >>
> >> >> On Wed, Aug 29, 2018, 10:36 Gilles 
> >> wrote:
> >> >>
> >> >> > Hello.
> >> >> >
> >> >> > Do you have an idea of what it would take to automate "beta"
> >> >> > releases?
> >> >> > By this I mean: take a component (at some state) and create
> >> >> > a  branch (with all the necessary adaptations) to become an
> >> >> > official release.
> >> >> >
> >> >> > Are "beta" releases subject to the same BC requirements as
> >> >> > "ordinary" ones?  Concretely, suppose that several releases
> >> >> > will be necessary: Do they have to change top-level package
> >> >> > name?
> >> >> >
> >> >> > Can a (non-"beta") release (of some component) depend on a
> >> >> > "beta" release (of another component)?  Or has the former to
> >> >> > be a "beta" too?
> >> >> >
> >> >> > Rationale: I imagine that uploading to "Maven Central" may
> >> >> > help correcting the misrepresentation of resources available
> >> >> > from this project.
> >> >> >
> >> >> >
> >> >> > Regards,
> >> >> > Gilles
> >> >> >
>
>
> -
> 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: Java 11 Compatibility check: Commons-beanutils, Commons-cli, Commons-codec, Commons-collections, Commons-csv, Commons-digester, Commons-discovery, Commons-fileupload, Commons-io, Commons-lang, Com

[Stephen Colebourne]

Spamming multiple open source projects with the same question is not
appropriate behaviour for a company. Open source does not have
"support". Its up to users to try the code, see if it works and report
issues. Please cease and desist your spamming.
Stephen


On 17 August 2018 at 08:37, Dragan, Krzysztof  wrote:
> Hi,
> We are reaching out to you to check Java 11 compatibility of the following 
> libraries:
> Commons-beanutils, Commons-cli, Commons-codec, Commons-collections, 
> Commons-csv, Commons-digester, Commons-discovery, Commons-fileupload, 
> Commons-io, Commons-lang, Commons-lang3, Commons-logging, Commons-net.
>
> Could you help us by answering the following questions of :
>
> 1. Library Name: 
> 2. Latest version: 
> 3. Latest version Is the library compatible with Java 11 Compatible? (Y/N)
> 4. Is the library supported with Java 11? (Y/N)
> 5. (If "N" in compatibility or support) What is the versions that would be 
> compatible and Supported?
> 6. Date of support availability?
>
> Appreciate your response by 20.08.2018.
>
> Thanks,
> Krzysztof Dragan,
> PTC Inc. Contractor
>

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

Re: [all] java release cycle predicament

[Stephen Colebourne]

At present, everything works in Java 11, and thats not released yet.
Here is day job project with similar setup running Java 11 on Travis
https://travis-ci.org/OpenGamma/Strata/builds/401792237

Ultimately, all builds are dependent on many other teams, but while
Java 9 was bad, 10 and 11 have generally been fine.
Stephen


On 10 July 2018 at 18:00, Rob Tompkins  wrote:
>
>
>> On Jul 10, 2018, at 12:53 PM, Stephen Colebourne  
>> wrote:
>>
>> Look at Joda-Convert/Joda-Parent for example. A Java 6 project that
>> builds on Java 8 or later, and has a module-info.java.
>>
>> Cobertura just needs replacing with JaCoCo.
>>
>> FindBugs replaced by SpotBugs
>>
>> Lots of plugin versions updated.
>>
>> And lots of profiles, as per Joda-Convert/Joda-Parent
>>
>> Stephen
>> https://github.com/JodaOrg/joda-convert
>> https://github.com/JodaOrg/joda-parent
>
> Thanks Stephen. How far behind the java release cycle (in months) do you find 
> that you are?
>
>>
>>
>>
>> On 10 July 2018 at 17:32, Rob Tompkins  wrote:
>>> Hello all,
>>>
>>> It occurs to me that we are in a bit of a predicament in terms of being 
>>> able to remain current with java, if the projected 6-month release to EOL 
>>> cycle for major versions of java indeed continues. For example, as of now 
>>> java9 is EOL, yet we still don’t have sufficient build tools (maybe almost) 
>>> to even think about doing a release building with java9, let alone the 
>>> current version of java, v10. For example, [lang] fails on mvn -Prelease 
>>> -Ptest-deploy clean test site deploy on java10 with the following error:
>>>
>>> [ERROR] Failed to execute goal 
>>> org.apache.maven.plugins:maven-site-plugin:3.7.1:site (default-site) on 
>>> project commons-lang3: failed to get report for 
>>> org.codehaus.mojo:cobertura-maven-plugin: Plugin 
>>> org.codehaus.mojo:cobertura-maven-plugin:2.7 or one of its dependencies 
>>> could not be resolved: Could not find artifact com.sun:tools:jar:0 at 
>>> specified path 
>>> /Library/Java/JavaVirtualMachines/jdk-10.0.1.jdk/Contents/Home/../lib/tools.jar
>>>
>>> What are we to do if they keep up this cycle? Depressing as it may seem, I 
>>> don’t see the current OSS java ecosystem sustainable. We won’t get stable 
>>> maven build plugins fast enough to keep up. We can keep building to java8, 
>>> but I don’t know what to do with higher versions.
>>>
>>> Any thoughts or ideas? Everything that I can think of is ugly at best.
>>>
>>> -Rob
>>> -
>>> 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: [all] java release cycle predicament

[Stephen Colebourne]

Look at Joda-Convert/Joda-Parent for example. A Java 6 project that
builds on Java 8 or later, and has a module-info.java.

Cobertura just needs replacing with JaCoCo.

FindBugs replaced by SpotBugs

Lots of plugin versions updated.

And lots of profiles, as per Joda-Convert/Joda-Parent

Stephen
https://github.com/JodaOrg/joda-convert
https://github.com/JodaOrg/joda-parent



On 10 July 2018 at 17:32, Rob Tompkins  wrote:
> Hello all,
>
> It occurs to me that we are in a bit of a predicament in terms of being able 
> to remain current with java, if the projected 6-month release to EOL cycle 
> for major versions of java indeed continues. For example, as of now java9 is 
> EOL, yet we still don’t have sufficient build tools (maybe almost) to even 
> think about doing a release building with java9, let alone the current 
> version of java, v10. For example, [lang] fails on mvn -Prelease 
> -Ptest-deploy clean test site deploy on java10 with the following error:
>
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-site-plugin:3.7.1:site (default-site) on 
> project commons-lang3: failed to get report for 
> org.codehaus.mojo:cobertura-maven-plugin: Plugin 
> org.codehaus.mojo:cobertura-maven-plugin:2.7 or one of its dependencies could 
> not be resolved: Could not find artifact com.sun:tools:jar:0 at specified 
> path 
> /Library/Java/JavaVirtualMachines/jdk-10.0.1.jdk/Contents/Home/../lib/tools.jar
>
> What are we to do if they keep up this cycle? Depressing as it may seem, I 
> don’t see the current OSS java ecosystem sustainable. We won’t get stable 
> maven build plugins fast enough to keep up. We can keep building to java8, 
> but I don’t know what to do with higher versions.
>
> Any thoughts or ideas? Everything that I can think of is ugly at best.
>
> -Rob
> -
> 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: [LANG] Java 9 problems because of dependencies to java.desktop (Was: Re: [LANG] Thoughts about Lang 4.0)

[Stephen Colebourne]

Good spot. I think that means [lang] would have to have its own copy
of the JDK interfaces. or just deprecate the functionality without
replacement.
Stephen

On 10 June 2018 at 22:11, Gilles  wrote:
> Hello.
>
> On Sun, 10 Jun 2018 21:34:49 +0200, Oliver Heger wrote:
>>
>> Hi Bruno,
>>
>> Am 10.06.2018 um 00:52 schrieb Bruno P. Kinoshita:
>>>
>>> Hi all,
>>>
>>> There is a patch [1] for LANG-1339 [2] that I would like to merge. The
>>> discussion around this issue can be found in the rest of this e-mail thread.
>>>
>>> The patch basically deprecates the existing classes that depend on
>>> java.desktop, and provide alternative implementations. The previous classes
>>> used java.desktop classes for the PropertyChangeListener. And the
>>> alternative ones instead use Java 7's java.util.Observer.
>
>
> Is it a good idea to use deprecated classes[1] in new code?
>
> Regards,
> Gilles
>
> [1] https://docs.oracle.com/javase/9/docs/api/java/util/Observable.html
>
>
>>>
>>>
>>> This will make it easier to provide [lang] as java 9, without requiring
>>> users to include a dependency to java.desktop.
>>> Planning to merge it during the next week if there are no objections
>>> here.
>>>
>>> Thanks,
>>> Bruno
>>
>>
>> agreed. This seems to be the best what we can do.
>>
>> Oliver
>>
>>>
>>>
>>> [1] https://github.com/apache/commons-lang/pull/275
>>>
>>> [2] https://issues.apache.org/jira/browse/LANG-1339
>>>
>>>
>>>
>>> ____From: Benedikt Ritter
>>> 
>>> To: Commons Developers List 
>>> Sent: Monday, 5 June 2017 10:49 PM
>>> Subject: [LANG] Java 9 problems because of dependencies to java.desktop
>>> (Was: Re: [LANG] Thoughts about Lang 4.0)
>>>
>>>
>>>
>>>
>>>> Am 25.05.2017 um 18:23 schrieb Oliver Heger
>>>> :
>>>>
>>>>
>>>>
>>>> Am 24.05.2017 um 13:55 schrieb Stephen Colebourne:
>>>>>
>>>>> On 23 May 2017 at 17:17, sebb  wrote:
>>>>>>>
>>>>>>> Yes, the
>>>>>>> code compiles and both can be on the classpath, but it is a pain to
>>>>>>> use, just a different kind of hell.
>>>>>>
>>>>>>
>>>>>> I don't see what the problem is here.
>>>>>
>>>>>
>>>>> Library A that depends on lang3 returns a Pair.
>>>>> Library B that depends on lang4 takes a Pair.
>>>>> Application cannot pass Pair from A to the B without conversion.
>>>>>
>>>>> My point is that it is possible to over-worry about jar hell.
>>>>> Joda-Time removed some methods when it went from v1.x to v2.x, but
>>>>> didn't change package name or maven co-ordinates. It was far more
>>>>> important that end-users didn't have two different LocalDate classes
>>>>> (a problem that couldn't be avoided when moving to Java 8). I've never
>>>>> seen any feedback about the incompatibility causing jar hell.
>>>>>
>>>>> The same is true here. It is vital to think properly about which is
>>>>> the worse choice, not just assume that jar hell must always be
>>>>> avoided.
>>>>>
>>>>> I remain completely unconvinced that removing these two problematic
>>>>> methods justifies the lang4 package name, forcing end-users to have
>>>>> three copies of the library on the classpath. It should need much,
>>>>> much more to justify lang4 package name. In fact I've yet to hear
>>>>> anything else much in this thread that justifies a major release.
>>>>
>>>>
>>>> I also think that a new major release just to fix this problem would be
>>>> overkill and cause clients even more trouble.
>>>>
>>>> Would the following approach work as a compromise:
>>>>
>>>> - [lang] declares an optional dependency to the desktop module.
>>>> - All affected classes (AbstractCircuitBreaker and its two sub classes)
>>>> are marked as deprecated.
>>>> - Copies are created from the original classes with slightly changed
>>>> names or in a new package (tbd). These copies use a new change listener
>>>> mechanism.
>>>>
>>>> IIUC, the resulting [lang] module can now be used without the dependency
>>>> to desktop when the new classes are used. The dependency will only be
>>>> needed for the deprecated versions.
>>>
>>>
>>> Let’s do it like this. Sounds like the right way to me.
>>>
>>> Benedikt
>>>
>>>>
>>>> Oliver
>>>>
>>>>>
>>>>> Stephen
>>>>>
>
>
> -
> 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: [LANG] Java 9 problems because of dependencies to java.desktop (Was: Re: [LANG] Thoughts about Lang 4.0)

[Stephen Colebourne]

On 10 June 2018 at 00:02, Bruno P. Kinoshita
 wrote:
> Yes, that's my understanding. We would use require static on java.desktop, 
> but users wouldn't have any issues as long as they did not use the version of 
> the class that requires java.desktop.
>
> If the user want/needs to use those classes, then they have to add the 
> dependency to java.desktop in their code.

When [lang] is used in classpath mode, there is no problem as
java.desktop is included anyway.

When [lang] is used in module mode, the user should get a compile
error unless they add the java.desktop dependency (because their code
will be using the java.desktop classes directly, so their code won't
compile).

Stephen

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

Re: [all] Maven Build with Java 10/11?

[Stephen Colebourne]

Just to note that surefire v2.21.0 is out now. No idea if that helps.
Stephen

On 9 March 2018 at 08:22, Stefan Bodewig  wrote:
> Hi all
>
> I wanted to see whether anything was broken in COMPRESS with the Java10
> RC or the EA version of Java11 - unfortunately the build fails with
> NullPointerException inside of Surefire.
>
> I run
>
> $ mvn clean test '-P!jacoco'
>
> as Jacoco doesn't seem to work for Java10+ either. I end up with
>
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-surefire-plugin:2.20.1:test (default-test) on 
> project commons-compress: Execution default-test of goal 
> org.apache.maven.plugins:maven-surefire-plugin:2.20.1:test failed.: 
> NullPointerException -> [Help 1]
> [ERROR]
>
> The stack trace I see with -X gets me to
>
> Caused by: java.lang.NullPointerException
> at 
> org.apache.maven.surefire.shade.org.apache.commons.lang3.SystemUtils.isJavaVersionAtLeast(SystemUtils.java:1626)
>
> which I'm afraid has just been fixed a few days ago for Java11.
>
> IIUC this means it is impossible to run tests with Maven on Java11+ at
> all until we (1) cut a new release of LANG and (2) get Surefire to use
> that.
>
> For Java10 I'd probably need to force Surefire to use LANG in version
> 3.7 (which according to the changelog fixes the NPE). I thought I'd add
> an explicit dependency on lang 3.7 inside pluginManagement. Doing so I
> see maven download LANG 3.7 but I still run into the same NPE. Obviously
> Surefire does still use a different version of LANG as the line number
> for the NPE is still the same, but this is a comment line inside the 3.7
> tag.
>
> Here is what I tried in COMPRESS' pom and still get the NPE with Java10:
>
> @@ -253,6 +253,18 @@ Brotli, Zstandard and ar, cpio, jar, tar, zip, dump, 7z, 
> arj.
>maven-bundle-plugin
>${commons.felix.version}
>  
> +
> +  org.apache.maven.plugins
> +  maven-surefire-plugin
> +  ${commons.surefire.version}
> +  
> +
> +  org.apache.commons
> +  commons-lang3
> +  3.7
> +
> +  
> +
>
>  
>  
>
> Any ideas?
>
> Stefan
>
> -
> 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: Prepare commons to JDK 9

[Stephen Colebourne]

On 7 March 2018 at 18:56, Ralph Goers  wrote:
> Actually, you really do need to use a multi-release jar to include a 
> module-info class file. Otherwise it may be sitting alongside of classes 
> compiled for an earlier java release and various tools will fail because of 
> it.

Then those tools need fixing.

Using multi-release jar files doesn't really help either, as other
tools don't understand those.

Stephen

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

Re: Prepare commons to JDK 9

[Stephen Colebourne]

1) Moving to Java 9 as a base would be a terrible choice. Java 9 is a
six-month release which is about to be replaced by Java 10, which will
then be replaced by Java 11. Thus, Java 8 is the only sensible
baseline right now.

2) Compiling a single jar file such that it works on Java 8 but has a
module-info.class for Java 9 using Maven is a right pain in the
backside. Most maven plugins cannot seamlessly handle it making the
pom.xml much more complex. Note that you do not need a multi-release
jar file to make it work. See
https://github.com/ThreeTen/threeten-extra/blob/master/pom.xml

3) It is yet to be demonstrated that JPMS is going to be widely used.
To release a jar file with JPMS module-info.class, it requires that
ALL dependencies are also JPMS modules with either module-info.class
or Automatic-Module-Name in the manifest. Most projects are nowhere
near this position yet.

Right now the plan for commons should be simple:

- add Automatic-Module-Name to MANIFEST.mf to lock down the module name
- if the project has no dependencies and runs on Java 6 or later,
consider adding a module-info.java, with the awareness that this is a
complex task

Stephen


On 7 March 2018 at 03:46, Kamila Molina Orellana
 wrote:
> Dear all,
>
> As an idea for GSoC that came up in [1], we want to settle some guidelines
> that other commons projects might follow to make the shift. We came up with
> some ideas in [2]. I wanted to ask about some experience you have had while
> moving to JDK 9 in other commons-projects.
>
> I wanted to propose this:
>
>1. Make the movement of commons-rdf to JDK 9 generating modules
>descriptions automatically through Maven.
>2. Generate integration tests to guarantee that modules are working as
>expected with JDK 9.
>3. Maybe have multi-release JARs?
>
> Since other commons projects follow a similar structure, we can generate
> some documentation in a wiki-like media. So, they can make the shit to JPMS
> or at least have a guideline. Or I can contribute :D.
>
> Wha do you think?
>
> Regards,
> ~Kamila.
>
>
> [1] https://issues.apache.org/jira/browse/COMMONSSITE-103
> [2] https://issues.apache.org/jira/browse/COMMONSRDF-75

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

Re: [Numbers] Make "Complex" a "final" class? (Was: [...] API of "Complex")

[Stephen Colebourne]

Some of the classes you are talking about are what I call VALJOs.
Follow these guidelines and your class will be well placed for the
future.
http://blog.joda.org/2014/03/valjos-value-java-objects.html
Stephen

On 2 February 2018 at 12:45, Gilles  wrote:
> On Thu, 1 Feb 2018 08:30:00 -0700, Gary Gregory wrote:
>>
>> Hi All:
>>
>> I like the "of" prefix but I think it might be odd to force the convention
>> for ALL factories. It might be an English language thing for me.
>>
>> For example, (picking a made up example) this reads really well to me:
>> Pair.of(foo, bar) because that what you'd use in spoken English.
>>
>> OTOH, this does not read well to me: Fraction.of(num, denum); this would
>> be
>> better: Fraction.from(num, denum)
>>
>> All of this to say that we should make sure that the factory method "reads
>> well" for that class. I know it might feel subjective.
>>
>> I like the idea of a private ctor but it does not have to be unique in my
>> mind. Sure, it's nice if there is one.
>>
>> I also like the idea of the ctor being private because we can open it up
>> later to protected if we want to allow for subclassing.
>>
>> I would also consider making classes final, especially if the ctor is
>> private.
>
>
> Any caveat on doing that?  Is this a final (!) decision or can one
> change one's mind in a later release?
> What are the benefits?
>
> Thanks,
> Gilles
>
>>
>> Gary
>>
>>
>> On Thu, Feb 1, 2018 at 7:07 AM, Gilles 
>> wrote:
>>
>>> On Thu, 01 Feb 2018 13:59:13 +0100, Gilles wrote:
>>>
 Hi.

 IMHO, there are too many accessor and factory methods.
 We should strive for a lean and consistent API.

 For the factory methods, I suggest the "of" convention:
  public static Complex ofCartesian(double re, double im)
  public static Complex ofPolar(double abs, double arg)
 And, as syntactic sugar:
  public static Complex ofCis(double arg)

>>>
>>> Those are useful too:
>>>public ofReal(double re)
>>>public ofImaginary(double im)
>>>
>>>
 For the accessors:
  public double re() { return real }
  public double im() { return imaginary }

 I'd have
   public double arg()
   public double abs()
 in order to compute the polar coordinates.

 I'm -0 to have others as syntactic sugar since they are
 misleading (a.o. when "implying" the read of a field when
 a computation is performed).

 WDYT?

>>>
>>> In addition to the above, I propose
>>> * to have a single, "private", constructor:
>>> private Complex(double re, double im)
>>> * to remove the "protected" method "createComplex" (
>>>   unless there is a case for inheritance).
>>>
>>> Regards,
>>> Gilles
>
>
>
> -
> 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: [Numbers] API of "Complex"

[Stephen Colebourne]

On 1 February 2018 at 15:30, Gary Gregory  wrote:
> For example, (picking a made up example) this reads really well to me:
> Pair.of(foo, bar) because that what you'd use in spoken English.
>
> OTOH, this does not read well to me: Fraction.of(num, denum); this would be
> better: Fraction.from(num, denum)

In JSR-310, of() is used when there is little work performed in the
factory, and relatively low chance of an error. from() is used when
performing a complex conversion, that has a higher chance of failure,

Stephen

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

Re: Parent POM and automatic module name

[Stephen Colebourne]

This seems a lot more effort than just adding something to the pom.xml
in the child project.
Stephen

On 9 January 2018 at 12:11, Gilles  wrote:
> Hi.
>
> My suggestion would be
>   "profile.java_automatic_module_name"
> in the top directory.
>
> Gilles
>
>
> On Mon, 8 Jan 2018 22:23:08 -0800, Chas Honton wrote:
>>
>> Profile triggers in src/profiles?
>>
>> Chas
>>
>>> On Jan 8, 2018, at 4:27 PM, sebb  wrote:
>>>
 On 8 January 2018 at 23:14, Jörg Schaible  wrote:
 Am Mon, 08 Jan 2018 00:48:08 + schrieb sebb:

> On 8 January 2018 at 00:25, Jörg Schaible 
> wrote:


 [snip]

>>> The component poms I checked all include a comment like "Temporary
>>> fix, remove this after this has implemented in parent pom". As these
>>> comments are not true anymore I will remove those I find.
>>
>>
>> It is possible to define a profile in parent and trigger it as opt-in
>> based on the existence of a file.
>>
>> Do we have any precedence for triggering profiles based on file
>> existence in commons? Typical name patterns used are:
>> - profile/ - profiles/
>> - .profile
>
>
> Yes, e.g. jacoco


 Found it:

 - src/site/resources/profile.

 However the location for these profile files does not make sense in
 general. And definitely not for a profile
 adding the module name :-/

 Alternatives? Common location for such a profile activation?
>>>
>>>
>>> src/site/resources was chosen because Jacoco is used for the site build.
>>> I don't think such files should should be moved.
>>>
>>> But by all means find somewhere else for new profile triggers.
>>>
 Cheers,
 Jörg


>
>
> -
> 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: [beanutils] Toward 2.0.0

[Stephen Colebourne]

On 28 December 2017 at 19:49, Gary Gregory  wrote:
> Hi All,
>
> - BeanUtils now has a new package o.a.c.beanutils2.
> - BeanUtils now depends on Apache Commons Collection 4 (instead of 3),
> which caused the above.
>
> What more do we want before releasing 2.0.0?
>
> Updating from BU 1.x to 2.x should be "simple" for now: Just update your
> imports.

This can make things far worse for end users. If jar file A updates to
v2.0 but jar file B does not, an application C that depends on A and B
cannot pass the output of [beanutils] around. Instead, it gets the
same class names repeated twice, and horrid conversion code. While I
understand the jar hell problem fully, I'm not sure that package
renaming the whole jar is really any better - its just a different
kind of hell.

If only one class exposes one problem return type in a method that not
everyone uses, it seems _on balance_ better to change the method
without changing the package names. The bump to v2.0 would still be a
sufficient indication of the potential compatibility issue (rarely hit
in reality). However, if the method in question is a vital part of the
main API, it might be worth changing the package name.

In other words, I think the presumption that all breaking changes
require a package name change is damaging - the package name change
should be an action of last resort.

Stephen

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

Re: [dbcp] Releasing 2.2.0

[Stephen Colebourne]

Just to note that commons-pool v2.5.0 did not have
Automatic-Module-Name added, which is sad.
Stephen


On 20 December 2017 at 17:31, Gary Gregory  wrote:
> Hi All,
>
> Now that Apache Commons Pool 2.5.0 and builds cleanly with Commons DBCP
> master, I'd like to release Commons DBCP 2.2.
>
> I plan on creating an RC soon. Hopefully today at best or tomorrow at worst.
>
> Gary

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

Re: [All] "Commons Math" is not a component

[Stephen Colebourne]

This all seems reasonable. One things I'd suggest is getting at least
one new component to a full release as soon as possible to demonstrate
that the plan can work. This suggests that step 1 involves a full
release for [numbers]

Stephen


On 9 December 2017 at 01:59, Gilles <gil...@harfang.homelinux.org> wrote:
> Hi all.
>
> Stephen Colebourne correctly summarized the situation[1]:
> Project management must be based on life-cycle, not the
> other way around.
>
> Here below, a concrete plan is proposed in answer to the
> suggestion (of a fork) made by Martijn Verburg[2].
>
> 1. Initial (beta?) release of "Commons Numbers".[3][4]
> 2. Create separate git repositories for functionalities
>that have independent life-cycles and move the codes
>out of "Commons Math".
> 3. Modularize "Commons Math" into
>a. A set of "supported" modules: functionalities having
>   undergone a review in order to define a stable API.
>b. A set of "experimental"/"beta" modules: functionalities
>   that have been modified since the last release (e.g.
>   bug fixes[5]) but are expected to undergo API changes.
>c. A "legacy" module for heavily used functionalities known
>   to harbour difficult design issues.
> 4. Initial (beta?) release of codes in category (2) as new
>components.
> 5. First non-beta release of "Commons Numbers".
> 6. Release v4.0 of "Commons Math".
> 7. First non-beta release of codes in category (2).
> 8. Progressively move code from category (3c) to (3b) and
>from (3b) to (3a), or to (2). And RERO accordingly.
>
> Do you (PMC, committers, developers and users) foresee any
> show-stoppers in the above sequence?
>
> Regards,
> Gilles
>
> [1] http://markmail.org/message/w3imqvbf3wphvokj
> [2] http://markmail.org/message/rribnh3tiikqtllf
> [3] https://git1-us-west.apache.org/repos/asf?p=commons-numbers.git
> [4] https://issues.apache.org/jira/projects/NUMBERS
> [5] https://issues.apache.org/jira/projects/MATH
>
>
> -
> 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: [All][Math] New component: "Commons Geometry"?

[Stephen Colebourne]

Frankly, as an observer, this issue seems to be handled pretty poorly.
Commons-Math is currently dead. There are people willing to put in
effort to work on parts of it, but they are blocked at every turn.
Various options are put forward, but nothing ever happens.

In technical terms, if Commons-Math were a TLP, it would no doubt
release multiple separate releases, just like commons does. Thus,
separate commons projects seems like a good model.

Commons-VFS is not a good comparator, as it is a single "narrow and
deep" library with plugins. Commons-Math is a "broad and shallow"
library by comparison [1]. Subdivisions of a "broad and shallow"
library are best managed with separate release cycles, as each part is
independent of the others. (commons [lang], [collections] and [io] are
not forced to be multi-module simply because they all release to the
java.base module).

Anyway, the original rules for Commons [2] required a majority
approval vote (more +1 than -1) to create a new component, which has
already happended AFAICT. So, I think those that want to create a new
component should JFDI.

Stephen


[1] https://marc.info/?l=jakarta-commons-dev=108601577728628=2
[2] http://commons.apache.org/oldcharter.html (item 15)



On 6 December 2017 at 12:59, Gilles  wrote:
> Hi Ralph.
>
> On Tue, 5 Dec 2017 22:38:06 -0700, Ralph Goers wrote:
>>
>> I don’t know
>
>
> Then please _read_ the ML archive.
>
>> why you are ignoring
>
>
> I do not (willingly) "ignore" any proposal. [Gentle
> reminders are welcome if/when I lost track of a pending
> issue that is waiting for my input.]
>
> It's rather the opposite: a few PMC people keep turning
> a blind eye to arguably constructive proposals (see below
> and ML archive).
>
>> option 3, which is what many have
>> suggested many times.
>
>
> With strings attached. See ML archive.
>
>> 3) Modify CM to be a multi-module project
>
>
> See below; what don't you understand in "issues which
> maven modules will not solve"?
> [See ML archive for a many times reiterated detailed
> description of the CM problems, the difference between
> CM and other components (modular or not), here and
> elsewhere, and how we do not have (never had) the human
> resources to correctly handle such a large and diverse
> code base.]
>
>> that contains only the
>> modules you want to support.
>
>
> That condition was explicitly rejected  when *I* first
> evoked it (see ML archive).
>
> Later discussions (see ML archive) clarified (?!) that
> modularizing CM would certainly not suffice to revive
> the project.
>
> Other options were (see ML archive)
> 4. create an Apache TLP (proposed by James Carman),
> 5. go through the Incubator.
>
> Either one required the PMC to relinquish the code base
> (no internal fork allowed IIUC), which it refused (see ML
> archive).
>
> The now visible consequences of renewed obstruction to
> the refactoring of CM were not difficult to predict (see
> ML archive).
>
> Gilles
>
>
>
>> Ralph
>>
>>> On Dec 3, 2017, at 4:51 AM, Gilles  wrote:
>>>
>>> On Sun, 3 Dec 2017 11:18:18 +0100, Jochen Wiedmann wrote:

 On Fri, Dec 1, 2017 at 2:26 PM, Gilles 
 wrote:

> There hasn't been any progress towards a decision.
> There isn't even a consensus on one of the central tenets of
> Apache ("Those who do the work..."): how sad/strange (?).


 Those who do the work are welcome to decide on their own, if they do
 not involve others.
>>>
>>>
>>> The conditional is not part of the well-known mantra.
>>>
>>> The issue here is to answer the question of what to do with
>>> a non-trivial code base.  My stance is to try and fix the
>>> problem(s), a.o. difficult management, by rooting out its
>>> main cause: CM has become an aggregate of components with
>>> completely different subject matters, scopes, designs,
>>> efficiencies, provisions for extension, etc.
>>> [An array of issues which "maven" modules will not solve.]
>>>
>>> We are seemingly faced with a choice between:
>>> 1. Maintain CM as the huge library that it is now.
>>> 2. Incrementally create maintainable components.
>>>
>>> A long time has passed since these alternatives were first
>>> exposed, only proving that none of the people who informally
>>> chose option(1) invested work to make it a reality.
>>>
>>> Refusing option (2) not only "involves others"; it is harming
>>> them (very real people, having done a lot of work here, on
>>> that code base).
>>>
 Establishing a new commons component doesn't
 qualify, IMO.
>>>
>>>
>>> True; that's why we are stalled, despite that a majority
>>> of the PMC did not explicitly oppose option (2).
>>>
>>> A handful of PMC people prefer to let the code base become
>>> "dormant" rather than give any chance to an alternate view.
>>> [If, say, you looked at the "Commons RNG" project, and
>>> concluded that, decidedly, this is not how a component
>>> should look 

Re: [lang] release 3.7

[Stephen Colebourne]

You'd need https://github.com/apache/commons-lang/pull/304 too for Java 9

Stephen

On 3 November 2017 at 17:36, Gary Gregory  wrote:
> Hi All:
>
> I propose we release 3.7 principally to pick up
> https://issues.apache.org/jira/browse/LANG-1365 to support those brave
> souls trying out Java 10 EA.
>
> Gary

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

Re: [LOGGING] Logging is Java 1.2 but required Java 1.4 code

[Stephen Colebourne]

Does commons-logging need to be a full module with a module-info.java?
Probably not at this point. Adding Automatic-Module-Name is probably
sufficient. However, if someone wants to do the work, then adding
module-info shouldn't be blocked IMO.

I don't believe that module-info.java requires Java 6 or later. It
would be possible to create the module-info.class file using java 9
and then use a much earlier compiler version to build the rest of the
jar. Or the module-info.class binary bytecode file could be checked
into git (probably simpler!).

Stephen


On 28 October 2017 at 21:31, Ralph Goers  wrote:
> Gary,
>
> As you know Log4j has a maven module for Java 9. It contains the 
> module-info.java file. That module compiles with Java 9 and targets Java 9 as 
> there isn’t much point targeting anything earlier.  That class files produced 
> are then overlaid on top of the classes produced for Log4j-api, which is 
> targeted at 1.7 and uses the 1.7 compiler. Commons Logging could do exactly 
> the same thing and just have a maven module for the Java 9 support and then 
> use whatever compiler it wants for the current commons logging classes.
>
> That said, why does commons logging need to be a “real” module anyway?
>
> Ralph
>
>> On Oct 28, 2017, at 10:07 AM, Gary Gregory  wrote:
>>
>> From a pragmatic POV, the oldest Java byte codes you can get Java 9 to emit
>> are for Java 1.6. Since we will want, I assume, to produce a module info
>> class in the jar, we will need to use Java 9 for that (to keep an RM's life
>> manageable.)
>>
>> This means to me that we should set the bar at Java 1.6 for the bare
>> minimum, which seams reasonable in 2017 soon to be 2018 and considering
>> Java 6 and 7 are EOL.
>>
>> Gary
>>
>> On Sat, Oct 28, 2017 at 10:32 AM, Benedikt Ritter 
>> wrote:
>>
>>> Hello,
>>>
>>> maybe we should decide on what we want to achieve here, before I start the
>>> endeavor of creating an RC for such an old component.
>>>
>>> My understanding of Logging is, that it is in semi dormant mode. That we
>>> don’t want to add any new features and instead point users to Log4j2. Since
>>> Logging has a wide installation base we decided not to upgrade the Java
>>> version requirement and instead stay at Java 1.2 and only release super
>>> critical fixes/updates.
>>> Upgrading to Java 6 seems to contradict this plan. So where do we want to
>>> go with Logging?
>>>
>>> Regards,
>>> Benedikt
>>>
 Am 28.10.2017 um 18:20 schrieb Ralph Goers :

 That isn’t strictly true Gary, There are ways to build the module-info
>>> without upgrading the main code to Java 9. That said, it is a bit of a hack
>>> to do it.

 Ralph

> On Oct 28, 2017, at 8:19 AM, Gary Gregory 
>>> wrote:
>
> Let's update to at least a minimum of Java 6 such that the build can run
> with Java 9. Builing with Java 9 will be a requirement to add module
>>> info.
>
> Gary
>
> On Oct 28, 2017 01:21, "Benedikt Ritter"  wrote:
>
>> Hi all,
>>
>> After I was able to update the the build to the latest parent POM, I’m
>> running into animal sniffer problems. The build is defined to target
>>> Java
>> 1.2 but there are classes which require later JDKs:
>>
>> - Jdk13LumberjackLogger
>> - Jdk14Logger
>>
>> This breaks the build because animal sniffer reports that these classes
>> don’t work on Java 1.2. I don’t understand how this is supposed to
>>> work.
>> Did we ship those classes and users have to decide whether they want to
>> load them or not depending on the JRE they are running on? Do we want
>>> to
>> exclude the two classes from animal sniffer?
>>
>> 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

Re: [VOTE] Release Apache Commons Pool 2.4.3 based on RC1

[Stephen Colebourne]

Just to note that there is no Automatic-Module-Name in the MANIFEST

On 25 October 2017 at 04:19, Gary Gregory  wrote:
> We have fixed a few bugs since Apache Commons Pool 2.4.2 was released, so I
> would like to release Apache Commons Pool 2.4.3.
>
> Apache Commons Pool 2.4.3 RC1 is available for review here:
> https://dist.apache.org/repos/dist/dev/commons/pool at revision: 22662
> Get it like this: svn co
> https://dist.apache.org/repos/dist/dev/commons/pool
>
> The tag is here:
>
> https://git-wip-us.apache.org/repos/asf?p=commons-pool.git;a=tag;h=c893fa532be0b06e105d3a5adcb7d5fdd9cba979
>
> Maven artifacts are here:
>
> https://repository.apache.org/service/local/repositories/orgapachecommons-1284
>
> These are the artifacts and their SHA1 hashes:
>
> /org/apache/commons/commons-pool2/2.4.3/commons-pool2-2.4.3-javadoc.jar.asc
> (SHA1: 1c3b8f36822f25880aaad2b148e98bdee898882a)
> /org/apache/commons/commons-pool2/2.4.3/commons-pool2-2.4.3-test-sources.jar
> (SHA1: 8894b161255af399029e30cf7a0add23d9b09ca6)
> /org/apache/commons/commons-pool2/2.4.3/commons-pool2-2.4.3-bin.tar.gz
> (SHA1: 6193d385d80d79a81e3d393c9aa1fb1b12cd)
> /org/apache/commons/commons-pool2/2.4.3/commons-pool2-2.4.3-sources.jar
> (SHA1: f25308f7512e59d78b24a058a30fc9d3af401690)
> /org/apache/commons/commons-pool2/2.4.3/commons-pool2-2.4.3-tests.jar.asc
> (SHA1: 2244c06e77d3424d930893b8e4884f804654e828)
> /org/apache/commons/commons-pool2/2.4.3/commons-pool2-2.4.3-javadoc.jar
> (SHA1: 6ec182b30e2148b1295c2024c6fac3a1c568)
> /org/apache/commons/commons-pool2/2.4.3/commons-pool2-2.4.3-bin.tar.gz.asc
> (SHA1: a9c685d6191d09ea2c7d82beca82a813a0aa1613)
> /org/apache/commons/commons-pool2/2.4.3/commons-pool2-2.4.3-src.tar.gz
> (SHA1: 688a1b5bc9011f27197423a1ffe0c3aeacbbfceb)
> /org/apache/commons/commons-pool2/2.4.3/commons-pool2-2.4.3-test-sources.jar.asc
> (SHA1: 3a8d18397c140a63b1ffdbe74e8fa2f3a2732f9c)
> /org/apache/commons/commons-pool2/2.4.3/commons-pool2-2.4.3-src.tar.gz.asc
> (SHA1: 347b72198684885faeb262f48457a8270d5125b0)
> /org/apache/commons/commons-pool2/2.4.3/commons-pool2-2.4.3-bin.zip
> (SHA1: dd5f761b471bbd7481955d6e5f64c6b6ea1c97e2)
> /org/apache/commons/commons-pool2/2.4.3/commons-pool2-2.4.3.jar.asc
> (SHA1: f1734672cc7200780e0b3fcb785d12398bee8af3)
> /org/apache/commons/commons-pool2/2.4.3/commons-pool2-2.4.3.pom
> (SHA1: b5813ddd4dd19ac6809bacbb54cbfb2d35a8df73)
> /org/apache/commons/commons-pool2/2.4.3/commons-pool2-2.4.3-src.zip.asc
> (SHA1: aaa30959ddbf184fff7e1ab22cc1a3b4a4ee87a0)
> /org/apache/commons/commons-pool2/2.4.3/commons-pool2-2.4.3-bin.zip.asc
> (SHA1: eae94976483c0958ade6e10e834095fea349e5b0)
> /org/apache/commons/commons-pool2/2.4.3/commons-pool2-2.4.3.pom.asc
> (SHA1: 37879823c0428d906ad9acaf3770aad48fa950d8)
> /org/apache/commons/commons-pool2/2.4.3/commons-pool2-2.4.3-sources.jar.asc
> (SHA1: 3153937a96a7828ea080888b8e02151662e9cce2)
> /org/apache/commons/commons-pool2/2.4.3/commons-pool2-2.4.3-src.zip
> (SHA1: 2ea2a543889f2011e3d73a8f579cfeece8efb600)
> /org/apache/commons/commons-pool2/2.4.3/commons-pool2-2.4.3.jar
> (SHA1: e7ab2a5143cb4e0b21d8ca81c265095e4567dd22)
> /org/apache/commons/commons-pool2/2.4.3/commons-pool2-2.4.3-tests.jar
> (SHA1: 795621ba371106cf1043c1b8520998e9d4e175a3)
>
> I tested this RC using 'mvn clean verify' on Microsoft Windows [Version
> 10.0.16299.19] with:
>
> - Oracle Java 6
> - Oracle Java 7
> - Oracle Java 8
> - Oracle Java 9: To run the build on Oracle Java 9, you need to override
> the Maven Animal Sniffer plugin with 'mvn -V clean verify
> -Dcommons.animal-sniffer.version=1.16'
> - IBM Java 8
>
> Apache Maven 3.0.5 (r01de14724cdef164cd33c7c8c2fe155faf9602da; 2013-02-19
> 06:51:28-0700)
> Maven home: C:\Java\apache-maven-3.0.5
> Java version: 1.6.0_45, vendor: Sun Microsystems Inc.
> Java home: C:\Program Files\Java\jdk1.6.0_45\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 8", version: "6.2", arch: "amd64", family: "windows"
>
> Apache Maven 3.5.2 (138edd61fd100ec658bfa2d307c43b76940a5d7d;
> 2017-10-18T01:58:13-06:00)
> Maven home: C:\Java\apache-maven-3.5.2\bin\..
> Java version: 1.7.0_80, vendor: Oracle Corporation
> Java home: C:\Program Files\Java\jdk1.7.0_80\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 8.1", version: "6.3", arch: "amd64", family: "windows"
>
> Apache Maven 3.5.2 (138edd61fd100ec658bfa2d307c43b76940a5d7d;
> 2017-10-18T01:58:13-06:00)
> Maven home: C:\Java\apache-maven-3.5.2\bin\..
> Java version: 1.8.0_144, vendor: Oracle Corporation
> Java home: C:\Program Files\Java\jdk1.8.0_144\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
>
> Apache Maven 3.5.2 (138edd61fd100ec658bfa2d307c43b76940a5d7d;
> 2017-10-18T01:58:13-06:00)
> Maven home: C:\Java\apache-maven-3.5.2\bin\..
> Java version: 9.0.1, vendor: Oracle Corporation
> Java home: C:\Program Files\Java\jdk-9.0.1
> Default 

Re: [lang] Module Info

[Stephen Colebourne]

Done, although more complex than expected as clirr and Javadoc needed work.
Stephen

On 17 October 2017 at 20:53, Pascal Schumacher <pascalschumac...@gmx.net> wrote:
> Thanks for the update!
>
> With your changes travis now executes "mvnclean install" as the main script.
>
> Before it was executing the default goal of the pom ("mvn clean verify
> apache-rat:check clirr:check checkstyle:check findbugs:check
> javadoc:javadoc")
>
> It would be nice if you could update the pull request, so that we do not
> lose these additional automated checks.
>
> Thanks,
> Pascal
>
>
> Am 17.10.2017 um 20:08 schrieb Stephen Colebourne:
>>
>> See latest changes.
>>
>> https://github.com/apache/commons-lang/pull/299/files
>>
>> https://travis-ci.org/apache/commons-lang/builds/289148663
>>
>> It now builds on Java 7, 8 and 9, varying what it does on each JDK.
>>
>> Releases will need to be on Java 9 for the jar file, but 8 for the
>> site plugin if I understand correctly.
>>
>> Stephen
>>
>> -
>> 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

[lang] Module Info

[Stephen Colebourne]

See latest changes.

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

https://travis-ci.org/apache/commons-lang/builds/289148663

It now builds on Java 7, 8 and 9, varying what it does on each JDK.

Releases will need to be on Java 9 for the jar file, but 8 for the
site plugin if I understand correctly.

Stephen

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

Re: [LANG] Add module-info.java?

[Stephen Colebourne]

On 16 October 2017 at 14:14, Simon Spero  wrote:
> [In regards to original question, -0.0  (harmless, but pointless, since
> applications should not use lang as a jpms module.

Huh? Of course they should.

> To be usable as a jpms
> module, EVERY  release that has ANY api change must use new module and
> package names).[1]  ]
> [1] A module can only appear in the modpath once. A package can only come
> from one module. If an application uses multiple third party dependencies,
> which use different versions of a fourth party module,  "*Lasciate ogne
> speranza, voi ch'intrate".*

Adding a package is fine so long as it is under the same root package
(that is why I argued for module names to be the same as the root
package name - to ensure ownership). Modules are supposed to be
shared, but they do place a high bar on backwards compatibility, which
[lang] already meets.

Changing the module name every release would be horrific for users and
make problems worse not better.

Stephen

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

Re: [LANG] Add module-info.java?

[Stephen Colebourne]

Log4J is adding module-info.java now, and its not overly complicated
to do here either. The main question seems to be around the maven site
plugin, but thats likely to be fixed soon. ie. I'd like to get to the
point where all the basic commons projects have module-info.java
(because proper modularization is going to occur bottom up, so the
earlier we can get these out the better).

FWIW, its up to Android to sort out its tooling - Java 9 is not going away!

I'd like to establish if there are any fundamental objections to the
concept of building only on Java 9. I'm also willing to try and find a
way to get the build to still work on Java 7, but that releases have
to be on Java 9.

Stephen



On 15 October 2017 at 10:49, Benedikt Ritter <brit...@apache.org> wrote:
> Okay, let’s get back to topic. I feel that the community want’s to wait some 
> more until at least all maven plugins we use work with Java 9?
>
> Regards,
> Benedikt
>
>> Am 15.10.2017 um 01:30 schrieb Matt Sicker <boa...@gmail.com>:
>>
>> Which is mainly because the version of Java in Android is intentionally
>> lacking about half of the standard library. Perhaps this will improve in
>> the future now that they're adopting OpenJDK, though.
>>
>> On 14 October 2017 at 17:04, Ralph Goers <ralph.go...@dslextreme.com> wrote:
>>
>>> I need to point out that even after removing that there would be a lot of
>>> stuff in log4j-core that doesn’t work in Android.
>>>
>>> Ralph
>>>
>>>> On Oct 14, 2017, at 12:02 PM, Gary Gregory <garydgreg...@gmail.com>
>>> wrote:
>>>>
>>>> I am wondering if this is a little too early. A lot of tooling our there
>>>> does not play well with Java 9 class files.
>>>>
>>>> The last time I tried to use Log4j 2 (which contains Java 9 classes files
>>>> in the right multi-jar spot) with an Android app, the Android tooling
>>> threw
>>>> up all over itself because it was incorrectly trying to do something with
>>>> these Java 9 class file :-(
>>>>
>>>> Gary
>>>>
>>>> On Sat, Oct 14, 2017 at 7:53 AM, Stephen Colebourne <
>>> scolebou...@joda.org>
>>>> wrote:
>>>>
>>>>> On 14 October 2017 at 14:05, Rob Tompkins <chtom...@gmail.com> wrote:
>>>>>>> On Oct 14, 2017, at 8:43 AM, Benedikt Ritter <brit...@apache.org>
>>>>> wrote:
>>>>>> Feels like a change that would warrant a major version change, but that
>>>>> would have us maintaining another major version branch.
>>>>>
>>>>> No need for a major version change. Its just one more .class file in
>>>>> the jar file. The jar file is still usable on Java 7 and 8, its just
>>>>> that the *build* is Java 9 specific.
>>>>>
>>>>> As Pascal says, really we want all the maven plugins to be ready for
>>>>> this, but we don't control those timescales.
>>>>>
>>>>> Options to fix the site plugin problem:
>>>>>
>>>>> 1) Alter the PR so that releases have to be in two stages - jar file
>>>>> build/deploy on Java 9 and site on Java 8. The risk is that someone
>>>>> forgets to do the release using Java 9.
>>>>>
>>>>> 2) Compile the module-info.java file on Java 9 and check it in (as a
>>>>> binary module-info.class file). Then the build could stay on Java 7/8.
>>>>> The problem however is that whenever a new package is added, the
>>>>> module-info.class file would have to be recreated and re-checked in,
>>>>> an error-prone process.
>>>>>
>>>>> Stephen
>>>>>
>>>>> -
>>>>> 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
>>>
>>>
>>
>>
>> --
>> Matt Sicker <boa...@gmail.com>
>
>
> -
> 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: [LANG] Add module-info.java?

[Stephen Colebourne]

On 14 October 2017 at 14:05, Rob Tompkins  wrote:
>> On Oct 14, 2017, at 8:43 AM, Benedikt Ritter  wrote:
> Feels like a change that would warrant a major version change, but that would 
> have us maintaining another major version branch.

No need for a major version change. Its just one more .class file in
the jar file. The jar file is still usable on Java 7 and 8, its just
that the *build* is Java 9 specific.

As Pascal says, really we want all the maven plugins to be ready for
this, but we don't control those timescales.

Options to fix the site plugin problem:

1) Alter the PR so that releases have to be in two stages - jar file
build/deploy on Java 9 and site on Java 8. The risk is that someone
forgets to do the release using Java 9.

2) Compile the module-info.java file on Java 9 and check it in (as a
binary module-info.class file). Then the build could stay on Java 7/8.
The problem however is that whenever a new package is added, the
module-info.class file would have to be recreated and re-checked in,
an error-prone process.

Stephen

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

Re: [lang] Commons Lang 2.x release for Java 9

[Stephen Colebourne]

Looks good AFAICT
Stephen

On 9 October 2017 at 14:39, Emmanuel Bourg  wrote:
> Le 29/09/2017 à 10:08, Emmanuel Bourg a écrit :
>
>> I'd like to prepare a new release of Commons Lang 2 that addresses the
>> Java 9 compatibility. I have two items in mind for this update, the
>> automatic module name in the manifest of course, but also the
>> SystemUtils.isJavaVersionAtLeast() method that is broken with Java 9 and
>> throws an Exception. This would be a minimal update branched off the
>> latest 2.6 release.
>
> I prepared the changes on GitHub:
>
>   https://github.com/ebourg/commons-lang/tree/LANG_2_X
>
> I started from the 2.x branch since it contained a few fixes worth
> keeping. The exception I was seeing with SystemUtils
> isJavaVersionAtLeast() was actually fixed in 2.6, so I just added the
> automatic module name to the manifest (I used org.apache.commons.lang as
> name assuming commons-lang3 would use org.apache.commons.lang3). I
> updated the release notes but not the site since it's published from the
> master branch.
>
> Please review, I intend to merge the changes and roll the release next week.
>
> Emmanuel Bourg
>
> -
> 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: [LOGGING] Release with Java 9 Module support

[Stephen Colebourne]

On 1 October 2017 at 11:34, Stefan Bodewig  wrote:
> - only add the automatic module name to commons-logging and release api
> and adapter as they are.

Exactly. This is the right approach.
Stephen

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

Re: [LOGGING] Release with Java 9 Module support

[Stephen Colebourne]

On 27 September 2017 at 00:01, Emmanuel Bourg  wrote:
> I wonder if we should do the same for commons-lang 2.x, it's still
> commonly used.

Yes. This would be very helpful
Stephen

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

Re: [LOGGING] Release with Java 9 Module support

[Stephen Colebourne]

The contents of pom.xml look OK. I can't seem to browse to see if you
changed anything else in that commit.

I would suggest being extra cautious when releasing, as a newer
version of maven may have changed some of the config, and you don't
want to release the two extra jars to maven central. (In fact, why not
just delete their creation in pom.xml ?)
Stephen

On 26 September 2017 at 22:05, Benedikt Ritter <brit...@apache.org> wrote:
>
>> Am 26.09.2017 um 22:54 schrieb Stephen Colebourne <scolebou...@joda.org>:
>>
>> On 26 September 2017 at 18:48, Jörg Schaible <joerg.schai...@gmx.de> wrote:
>>> AFAICS we have only commons-logging. The other artifacts have not been part
>>> of any release in the last decade.
>>
>> Simple then!
>
> Please review revision 1809785. The build still creates all those jars, the 
> Automatic-Module-Name header is added to commons-logging.jar MANIFEST.MF with 
> value org.apache.commons.logging.
>
> Regards,
> Benedikt
>
>> Stephen
>>
>> -
>> 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: [LOGGING] Release with Java 9 Module support

[Stephen Colebourne]

On 26 September 2017 at 18:48, Jörg Schaible  wrote:
> AFAICS we have only commons-logging. The other artifacts have not been part
> of any release in the last decade.

Simple then!
Stephen

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

Re: [LOGGING] Release with Java 9 Module support

[Stephen Colebourne]

On 26 September 2017 at 16:06, Benedikt Ritter  wrote:
> commons-logging.jar
> commons-logging-adapters.jar
> commons-logging-api.jar
>
> All jars have org.apache.commons.logging as root package, so if I understand 
> correctly we can’t do the Automatic-Module-Name trick, because this would 
> require the build producing a single jar with one top level package.

Is the user allowed to have all three on the classpath at the same time?

I'd expect the api jar probably gets the Automatic-Module-Name, and
maybe the other two can't be modularised.
Stephen

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

Re: [COLLECTIONS] module-info.java and Java 9 (Was: [COLLECTIONS] Time for 4.2)

[Stephen Colebourne]

On 20 September 2017 at 17:12, Benedikt Ritter <brit...@apache.org> wrote:
>> Von: Stephen Colebourne <scolebou...@joda.org>
>> I've not got maven to work with actual module-info.java files yet on
>> the Joda projects, but they are a more complex setup. Maybe
>> [collections] could be the first to get a real module-info? There are
>> no dependencies, right?
>
> There are test dependencies.
>
> And I wonder how we can create a jar that is also valid on JVM 7 and 8. Do 
> they ignore the module-info.class which would be included? Or do we have to 
> create a Multi-Release jar? The build will definitely require Java 9.

I've not managed to get this pattern to work on my projects yet:
http://maven.apache.org/plugins/maven-compiler-plugin/examples/module-info.html

There should be no need for a multi-release jar - the
module-info.class file will just be ignored (not class loaded) by
previous versions even though it is in the jar file.
Stephen

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

Re: [COLLECTIONS] Time for 4.2

[Stephen Colebourne]

On 20 September 2017 at 17:21, Matt Benson <mben...@apache.org> wrote:
> On Sep 20, 2017 11:08 AM, "Stephen Colebourne" <scolebou...@joda.org> wrote:
>
> I think its worth the extra step of checking the conditions are right
> for adding the Automatic-Module-Name manifest entry.
>
>
> Wouldn't that just offload the decision to "when to update the parent
> version in the component?"

No, I expect that not all commons components will be suitable to be modules.
Stephen

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

Re: [COLLECTIONS] Time for 4.2

[Stephen Colebourne]

I think its worth the extra step of checking the conditions are right
for adding the Automatic-Module-Name manifest entry.

I've not got maven to work with actual module-info.java files yet on
the Joda projects, but they are a more complex setup. Maybe
[collections] could be the first to get a real module-info? There are
no dependencies, right?

Stephen



On 20 September 2017 at 17:03, Benedikt Ritter <brit...@apache.org> wrote:
> Hi,
>
>> Am 20.09.2017 um 15:33 schrieb Gary Gregory <garydgreg...@gmail.com>:
>>
>> How about dealing with the Automatic-Module-Name MANIFEST header in the
>> parent POM and releasing that POM first?
>
> Stephen Colebourne said that we have to check on a per component basis 
> whether the component is ready to be released as Java 9 module. For this 
> reason we wanted to add this to every component individually. At least that 
> is what I recall.
>
> Benedikt
>
>>
>> Gary
>>
>> On Wed, Sep 20, 2017 at 1:20 AM, Benedikt Ritter <brit...@apache.org> wrote:
>>
>>> Hi,
>>>
>>> I’d like to release Commons Collections 4.2 soon, because I want to get
>>> COLLECTIONS-658 [1] (Automatic-Module-Name MANIFEST header) out of the
>>> door. Please let me know if you want to add something.
>>>
>>> Regards,
>>> Benedikt
>>>
>>> [1] https://issues.apache.org/jira/browse/COLLECTIONS-658
>>> -
>>> 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: Ready for JDK 9 ?

[Stephen Colebourne]

I didn't get the chance to reply when this thread happened, but really
a project should only be viewed as JDK 9 ready when it has had a
release with the Automatic-Module-Name entry in the manifest file.
AFAIK, only common-lang has this (Although commons-csv, email and jcs
were released recently I don't believe they have the entry).

Stephen



On 8 August 2017 at 21:48, Pascal Schumacher  wrote:
> Hello everybody,
>
> commons-lang and commons-text are build and tested with JDK 9 on traivs-ci,
> e.g.:
>
> https://travis-ci.org/apache/commons-text/jobs/259838032
> https://travis-ci.org/apache/commons-lang/jobs/258653445
>
> so I guess these components are ready for JDK 9.
>
> Cheers,
> Pascal
>
> Am 08.08.2017 um 12:09 schrieb Rory O'Donnell:
>>
>>
>> Hi Benedikt,
>>
>> Thank you very much for all your testing of JDK 9 during its development!
>> Such contributions have significantly helped shape and improve JDK 9.
>>
>> Now that we have reached the JDK 9 Final Release Candidate phase [1] , I
>> would like to ask if your project can be considered to be 'ready for JDK 9',
>> or if there are any remaining show stopper issues which you've encountered
>> when testing with the JDK 9 release candidate.
>>
>> JDK 9  b181 is available at http://jdk.java.net/9/
>>
>> If you have a public web page, mailing list post, or even a tweet
>> announcing you project's readiness for JDK 9, I'd love to add the URL to the
>> upcoming JDK 9 readiness page on the Quality Outreach wiki.
>>
>>
>> Looking forward to hearing from you,
>> Rory
>>
>> [1] http://openjdk.java.net/projects/jdk9/
>>
>
>
> -
> 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: [LANG] Add Automatic-Module-Name MANIFEST entry

[Stephen Colebourne]

This looks fine in terms of what it does. Obviously not ideal to have
the copying, but that is the right choice to make right now.
Stephen


On 7 June 2017 at 09:25, Benedikt Ritter  wrote:
> Hi,
>
> here [1] is my proposal on how to add the Automatic-Module-Name entry to 
> MANIFEST. This just duplicates the maven-jar-plugin configuration from parent 
> pom. I don’t want to wait much longer to release 3.6. After we have 
> implemented a more general solution in parent pom, we can revert this fix.
>
> If nobody objects, I’m going to merge this later this week and prepare RC3.
>
> Cheers,
> Benedikt
>
> [1] https://github.com/apache/commons-lang/pull/270
> -
> 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: [PARENT][PROPOSAL] Add Automatic-Module-Name MANIFEST entry

[Stephen Colebourne]

On 5 June 2017 at 09:35, Benedikt Ritter  wrote:
> Is there some documentation on how to check validity?

I'm sure there is info in various places, but I've not seen a checklist.

Off the top of my head:
- all packages under a single super-package that is the module name
- jdeps shows no use of internal APIs in the JDK
- no circular dependencies

Once Java 9 is out properly, we can start adding module-info.java
files and creating some proper dependencies.

Stephen

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

Re: [LANG] Thoughts about Lang 4.0

[Stephen Colebourne]

On 23 May 2017 at 10:13, Jochen Wiedmann  wrote:
> I am -0 to -1 regarding the introduction of new components. I'd rather
> see us redefine the purpose of commons-lang. The experience of
> commons-math has demonstrated, IMO, that such new components will most
> likely increase the noise without an associated increase of the
> output.
>
> IMO, c-lang is running well, as it is.

I'm not personally convinced that smaller components solves anything.
It gives end users more dependencies to manage, with more potential
for clashes. Plus, no-one should be adding a dependency for just a
couple of simple methods - thus [lang] needs to be a certain size to
have enough useful methods to justify itself. The "competition" is
Guava, and that is also a decent size library.

Looking to Java 10 and beyond, we might see a way to have one artifact
(jar file) contain multiple modules, allowing end-users to depend on
parts of [lang] package by package. In such a scenario, it would
actually be better to lump more into a single jar file, not less.

Stephen

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

Re: [all] Java 9 module names

[Stephen Colebourne]

On 24 April 2017 at 11:08, Jörg Schaible <joerg.schai...@bpm-inspire.com> wrote:
> Stephen Colebourne wrote:
>
>> Sounds like you could use --add-modules to add the module separately
>> from the command line, or add the module to the application's
>> module-info rather than the libraries.
>>
>> In general, I suspect a library module-info.java should depend only on
>> the other modules it really needs (eg. the API of slf4j), while
>> something else, such as the application, adds the implementation
>> module (eg. the SLF4J implementation).
>
> Which will create another chaos. Currently I can use the the xx-over-yy
> artifacts to replace a hard coded dependency of an artifact if it is
> required to embed it in a larger system.

You still can. See my latest blog for the mental model you need:
http://blog.joda.org/2017/04/java-se-9-jpms-modules-are-not-artifacts.html

TL;DR, modules != artifacts. Depending on a module does not imply
depending on exactly the same artifact that was used at compile time.
Thus, the xx-over-yy jar files are still useful, provided they have
the same module name as the module they are faking. See
https://jira.qos.ch/browse/SLF4J-408 for how slf4j needs tweaking.

Stephen

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

Re: [all] Java 9 module names

[Stephen Colebourne]

Sounds like you could use --add-modules to add the module separately
from the command line, or add the module to the application's
module-info rather than the libraries.

In general, I suspect a library module-info.java should depend only on
the other modules it really needs (eg. the API of slf4j), while
something else, such as the application, adds the implementation
module (eg. the SLF4J implementation).

Stephen



On 23 April 2017 at 18:14, Ralph Goers <ralph.go...@dslextreme.com> wrote:
> Yes, I know it doesn't replace Maven, but in this case I have a dependency 
> that is not required to compile but is required to run. It appears I have to 
> convert my runtime scopes to compile in order to get the module to compile 
> and build properly.
>
> That sucks.
>
> Sent from my iPhone
>
>> On Apr 23, 2017, at 7:43 AM, Stephen Colebourne <scolebou...@joda.org> wrote:
>>
>> I've never used that myself, but  don't see anything similar.
>> Remember though that JPMS isn't trying to replace Maven. It just
>> intends there to be a reliable set of modules when running in the
>> platform.
>> Stephen
>>
>>
>>> On 23 April 2017 at 08:57, Ralph Goers <ralph.go...@dslextreme.com> wrote:
>>> How does the module system support Maven’s runtime scope?
>>>
>>> Ralph
>>>
>>>> On Apr 21, 2017, at 10:48 PM, Stephen Colebourne <scolebou...@joda.org> 
>>>> wrote:
>>>>
>>>> See http://blog.joda.org/2017/04/java-9-modules-jpms-basics.html and
>>>> https://www.slideshare.net/scolebourne/java-se-9-modules-jpms-an-introduction
>>>>
>>>> Basically, you need "requires static" for optional dependencies. The
>>>> exception if for a module where the dependency is an annotation where
>>>> you don't need the annotation to be present at runtime. eg. @NonNull
>>>> from FindBugs
>>>>
>>>> Depending on things that haven't been modularized yet is risky. It is
>>>> allowed however, and its known as "automatic modules". Basically, it
>>>> looks exactly like a normal "requires" clause, its just that you are
>>>> _guessing_ what the module name of the dependency will be!
>>>>
>>>> This is why I started this thread. By saying _now_what the module name
>>>> will be, you greatly reduce the chance of people guessing wrongly.
>>>> Getting everyone to usesuper-package reverse DNS naming helps too.
>>>>
>>>> Stephen
>>>>
>>>>
>>>>> On 22 April 2017 at 02:11, Ralph Goers <ralph.go...@dslextreme.com> wrote:
>>>>> On to the next question - which I apologize for asking as it may not 
>>>>> apply to Commons.  Log4j has lots of optional components to support lots 
>>>>> of third party stuff (some ASF projects and some not). How do we handle 
>>>>> things that haven’t yet been modularized? Normally I would expect to have 
>>>>> requires directives.
>>>>>
>>>>> Ralph
>>>>>
>>>>>> On Apr 21, 2017, at 6:04 PM, Ralph Goers <ralph.go...@dslextreme.com> 
>>>>>> wrote:
>>>>>>
>>>>>> Thanks for taking a look Stephen. I appreciate the guidance. I will be 
>>>>>> sure to submit a PR when I get something going with Log4j 2.
>>>>>>
>>>>>> Ralph
>>>>>>
>>>>>>> On Apr 21, 2017, at 3:01 PM, Stephen Colebourne <scolebou...@joda.org> 
>>>>>>> wrote:
>>>>>>>
>>>>>>> Some rules:
>>>>>>> - Each module contains a set of packages, each of which must be
>>>>>>> specified explicitly.
>>>>>>> - Modules depend on other modules, but must not form a cycle of 
>>>>>>> dependencies.
>>>>>>> - No package can be in two modules
>>>>>>>
>>>>>>> Looking at the Javadoc here -
>>>>>>> https://logging.apache.org/log4j/2.x/javadoc.html - it seems like each
>>>>>>> jar file has a separate set of packages it contains, with an obvious
>>>>>>> super-package for each jar file*. Furthermore, the super-packages of
>>>>>>> the jar files do not clash, so I think you are fine in naming terms.
>>>>>>> What I can't be sure from the Javadoc is whether there is a cycle of
>>>>>>> dependencies.
>>>>>>>
&

Re: [all] Java 9 module names

[Stephen Colebourne]

I've never used that myself, but  don't see anything similar.
Remember though that JPMS isn't trying to replace Maven. It just
intends there to be a reliable set of modules when running in the
platform.
Stephen


On 23 April 2017 at 08:57, Ralph Goers <ralph.go...@dslextreme.com> wrote:
> How does the module system support Maven’s runtime scope?
>
> Ralph
>
>> On Apr 21, 2017, at 10:48 PM, Stephen Colebourne <scolebou...@joda.org> 
>> wrote:
>>
>> See http://blog.joda.org/2017/04/java-9-modules-jpms-basics.html and
>> https://www.slideshare.net/scolebourne/java-se-9-modules-jpms-an-introduction
>>
>> Basically, you need "requires static" for optional dependencies. The
>> exception if for a module where the dependency is an annotation where
>> you don't need the annotation to be present at runtime. eg. @NonNull
>> from FindBugs
>>
>> Depending on things that haven't been modularized yet is risky. It is
>> allowed however, and its known as "automatic modules". Basically, it
>> looks exactly like a normal "requires" clause, its just that you are
>> _guessing_ what the module name of the dependency will be!
>>
>> This is why I started this thread. By saying _now_what the module name
>> will be, you greatly reduce the chance of people guessing wrongly.
>> Getting everyone to usesuper-package reverse DNS naming helps too.
>>
>> Stephen
>>
>>
>> On 22 April 2017 at 02:11, Ralph Goers <ralph.go...@dslextreme.com> wrote:
>>> On to the next question - which I apologize for asking as it may not apply 
>>> to Commons.  Log4j has lots of optional components to support lots of third 
>>> party stuff (some ASF projects and some not). How do we handle things that 
>>> haven’t yet been modularized? Normally I would expect to have requires 
>>> directives.
>>>
>>> Ralph
>>>
>>>> On Apr 21, 2017, at 6:04 PM, Ralph Goers <ralph.go...@dslextreme.com> 
>>>> wrote:
>>>>
>>>> Thanks for taking a look Stephen. I appreciate the guidance. I will be 
>>>> sure to submit a PR when I get something going with Log4j 2.
>>>>
>>>> Ralph
>>>>
>>>>> On Apr 21, 2017, at 3:01 PM, Stephen Colebourne <scolebou...@joda.org> 
>>>>> wrote:
>>>>>
>>>>> Some rules:
>>>>> - Each module contains a set of packages, each of which must be
>>>>> specified explicitly.
>>>>> - Modules depend on other modules, but must not form a cycle of 
>>>>> dependencies.
>>>>> - No package can be in two modules
>>>>>
>>>>> Looking at the Javadoc here -
>>>>> https://logging.apache.org/log4j/2.x/javadoc.html - it seems like each
>>>>> jar file has a separate set of packages it contains, with an obvious
>>>>> super-package for each jar file*. Furthermore, the super-packages of
>>>>> the jar files do not clash, so I think you are fine in naming terms.
>>>>> What I can't be sure from the Javadoc is whether there is a cycle of
>>>>> dependencies.
>>>>>
>>>>> Possible modules:
>>>>> - org.apache.logging.log4j
>>>>> - org.apache.logging.log4j.core
>>>>> - org.apache.logging.log4j.io
>>>>> - org.apache.logging.log4j.taglib
>>>>> - org.apache.logging.log4j.jcl
>>>>> - org.apache.logging.log4j.jul
>>>>> - org.apache.logging.log4j.flume.appender
>>>>> - org.apache.logging.log4j.jmx.gui
>>>>> - org.apache.logging.log4j.web
>>>>> - org.apache.logging.log4j.nosql.appender
>>>>>
>>>>> * the slf4j bridge is problematic, but is being addressed by changes in 
>>>>> slf4j.
>>>>> * the logf4 v1 bridge probably can't be modularized
>>>>>
>>>>> Bernd has addressed the point about the need to export all packages
>>>>> individually, allowing the modules above.
>>>>>
>>>>> Stephen
>>>>>
>>>>> On 21 April 2017 at 21:34, Ralph Goers <ralph.go...@dslextreme.com> wrote:
>>>>>> I am having a hard time figuring out how Log4j is going to be able to 
>>>>>> support this.  The API itself is in org.apache.logging.log4j and some 
>>>>>> packages under that.  All the main implementation is under 
>>>>>> org.apache.logging.log4j.core.  These obviously ov

Re: [all] Java 9 module names

[Stephen Colebourne]

On 22 April 2017 at 09:00, Emmanuel Bourg <ebo...@apache.org> wrote:
> Le 22/04/2017 à 01:02, Stephen Colebourne a écrit :
>> I've started a page here:
>> https://github.com/jodastephen/jpms-module-names/blob/master/README.md
>> Feel free to raise a PR with more projects at commons or elsewhere in
>> Apache - I'm just checking the Javadoc and releases to ensure there
>> are no problems.
>
> Seeing Commons Lang 2 in the list I realize we'll have to dust off the
> old branches and publish new releases (lang 2.x, configuration 1.x, jexl
> 2.x, math 3.x, pool 1.x, etc).

Not necessarily. So long as you specify what the module name would be,
people can in theory use them via the "automatic module" feature. This
may require some changes to maven to map artifacts to modules.

Stephen

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

Re: [all] Java 9 module names

[Stephen Colebourne]

On 22 April 2017 at 05:18, Matt Sicker  wrote:
> Despite all the shit the Java champions talk about OSGi, Jigsaw is still a
> simplified version of OSGi basically, so anything already supported via
> OSGi will generally port extremely easily to Java 9 modules.

JPMS (Jigsaw) is not a simplified OSGi. The two really have very
little in common at this point. It is also nigh on impossible to run
OSGi and JPMS modules together. JPMS does not have dynamic behaviour,
the cornerstone of OSGi. It also does not have any way for a consumer
of modules to fix bad metadata.

As such, I don't think this is a helpful comparison at this point. My
goal (as a Java Champion) is to try and ensure that the community
works the best it can with JPMS, even is I think JPMS has real flaws.

Stephen

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

Re: [all] Java 9 module names

[Stephen Colebourne]

See http://blog.joda.org/2017/04/java-9-modules-jpms-basics.html and
https://www.slideshare.net/scolebourne/java-se-9-modules-jpms-an-introduction

Basically, you need "requires static" for optional dependencies. The
exception if for a module where the dependency is an annotation where
you don't need the annotation to be present at runtime. eg. @NonNull
from FindBugs

Depending on things that haven't been modularized yet is risky. It is
allowed however, and its known as "automatic modules". Basically, it
looks exactly like a normal "requires" clause, its just that you are
_guessing_ what the module name of the dependency will be!

This is why I started this thread. By saying _now_what the module name
will be, you greatly reduce the chance of people guessing wrongly.
Getting everyone to usesuper-package reverse DNS naming helps too.

Stephen


On 22 April 2017 at 02:11, Ralph Goers <ralph.go...@dslextreme.com> wrote:
> On to the next question - which I apologize for asking as it may not apply to 
> Commons.  Log4j has lots of optional components to support lots of third 
> party stuff (some ASF projects and some not). How do we handle things that 
> haven’t yet been modularized? Normally I would expect to have requires 
> directives.
>
> Ralph
>
>> On Apr 21, 2017, at 6:04 PM, Ralph Goers <ralph.go...@dslextreme.com> wrote:
>>
>> Thanks for taking a look Stephen. I appreciate the guidance. I will be sure 
>> to submit a PR when I get something going with Log4j 2.
>>
>> Ralph
>>
>>> On Apr 21, 2017, at 3:01 PM, Stephen Colebourne <scolebou...@joda.org> 
>>> wrote:
>>>
>>> Some rules:
>>> - Each module contains a set of packages, each of which must be
>>> specified explicitly.
>>> - Modules depend on other modules, but must not form a cycle of 
>>> dependencies.
>>> - No package can be in two modules
>>>
>>> Looking at the Javadoc here -
>>> https://logging.apache.org/log4j/2.x/javadoc.html - it seems like each
>>> jar file has a separate set of packages it contains, with an obvious
>>> super-package for each jar file*. Furthermore, the super-packages of
>>> the jar files do not clash, so I think you are fine in naming terms.
>>> What I can't be sure from the Javadoc is whether there is a cycle of
>>> dependencies.
>>>
>>> Possible modules:
>>> - org.apache.logging.log4j
>>> - org.apache.logging.log4j.core
>>> - org.apache.logging.log4j.io
>>> - org.apache.logging.log4j.taglib
>>> - org.apache.logging.log4j.jcl
>>> - org.apache.logging.log4j.jul
>>> - org.apache.logging.log4j.flume.appender
>>> - org.apache.logging.log4j.jmx.gui
>>> - org.apache.logging.log4j.web
>>> - org.apache.logging.log4j.nosql.appender
>>>
>>> * the slf4j bridge is problematic, but is being addressed by changes in 
>>> slf4j.
>>> * the logf4 v1 bridge probably can't be modularized
>>>
>>> Bernd has addressed the point about the need to export all packages
>>> individually, allowing the modules above.
>>>
>>> Stephen
>>>
>>> On 21 April 2017 at 21:34, Ralph Goers <ralph.go...@dslextreme.com> wrote:
>>>> I am having a hard time figuring out how Log4j is going to be able to 
>>>> support this.  The API itself is in org.apache.logging.log4j and some 
>>>> packages under that.  All the main implementation is under 
>>>> org.apache.logging.log4j.core.  These obviously overlap.  Most of our 
>>>> other jars have packages that are in org.apache.logging.log4j.xxx where 
>>>> xxx matches the jar name.  We aren’t going to change the API to support 
>>>> modules.
>>>>
>>>> Is there some reasonable way around this?
>>>>
>>>> Ralph
>>>>
>>>>> On Apr 21, 2017, at 6:16 AM, Stephen Colebourne <scolebou...@joda.org> 
>>>>> wrote:
>>>>>
>>>>> On 21 April 2017 at 13:59, sebb <seb...@gmail.com> wrote:
>>>>>> What happens when there is a API break which necessitates a package name 
>>>>>> change?
>>>>>> I assume that the module name will also need to change to the new 
>>>>>> super-package.
>>>>>> e.g.
>>>>>>
>>>>>> Commons-Lang4
>>>>>> -> super-package org.apache.commons.lang4
>>>>>> -> module org.apache.commons.lang4
>>>>>
>>>>> Yes, thats right.
>>>>>

Re: [all] Java 9 module names

[Stephen Colebourne]

I've started a page here:
https://github.com/jodastephen/jpms-module-names/blob/master/README.md
Feel free to raise a PR with more projects at commons or elsewhere in
Apache - I'm just checking the Javadoc and releases to ensure there
are no problems.

Stephen



On 21 April 2017 at 13:49, Stephen Colebourne <scolebou...@joda.org> wrote:
> Right now, I don't recommend adding a module-info.java file. Java 9 is
> not released, the tools are still under development, and the binary
> format may yet change. All we are agreeing is that the module name
> will be `org.apache.commons.lang3`, which doesn't change the release
> :-)
>
> What we need is a page, either on each subproject website, or on the
> main website (probably simpler) that lists the module names for each
> project. I can try to find time to work on such a page, but although I
> technically have commit access, I certainly don't in practical terms,
> so I'd probably submit a GitHub PR instead.
>
> When the time comes, the module-info.java file will be something like this:
>
> module org.apache.commons.lang3 {
>  exports org.apache.commons.lang3;
>  exports org.apache.commons.lang3.builder;
>  exports org.apache.commons.lang3.concurrent;
>  exports org.apache.commons.lang3.event;
>  exports org.apache.commons.lang3.exception;
>  exports org.apache.commons.lang3.math;
>  exports org.apache.commons.lang3.mutable;
>  exports org.apache.commons.lang3.reflect;
>  exports org.apache.commons.lang3.text;
>  exports org.apache.commons.lang3.text.translate;
>  exports org.apache.commons.lang3.time;
>  exports org.apache.commons.lang3.tuple;
> }
>
> Stephen
>
> On 21 April 2017 at 13:31, Emmanuel Bourg <ebo...@apache.org> wrote:
>> Le 21/04/2017 à 14:00, Stephen Colebourne a écrit :
>>
>>> Comments? Questions?
>>
>> Hi Stephen,
>>
>> Thank you for stopping by and enlightening us about JPMS. The new module
>> system looks like a huge mess. I understand the need for modularization
>> at the JRE level, but I haven't figured out yet how this extra
>> complexity will improve my applications. I know you've followed the
>> development of this feature thoroughly and I trust your judgment. You
>> still have commit access to the Commons components, so I'd encourage you
>> to go ahead and implement your suggestion directly. Commons Lang 3.6 is
>> about to be released, we could start with this one and use it as an
>> example for the other components.
>>
>> Emmanuel Bourg
>>
>>
>> -
>> 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: [all] Java 9 module names

[Stephen Colebourne]

Some rules:
- Each module contains a set of packages, each of which must be
specified explicitly.
- Modules depend on other modules, but must not form a cycle of dependencies.
- No package can be in two modules

Looking at the Javadoc here -
https://logging.apache.org/log4j/2.x/javadoc.html - it seems like each
jar file has a separate set of packages it contains, with an obvious
super-package for each jar file*. Furthermore, the super-packages of
the jar files do not clash, so I think you are fine in naming terms.
What I can't be sure from the Javadoc is whether there is a cycle of
dependencies.

Possible modules:
- org.apache.logging.log4j
- org.apache.logging.log4j.core
- org.apache.logging.log4j.io
- org.apache.logging.log4j.taglib
- org.apache.logging.log4j.jcl
- org.apache.logging.log4j.jul
- org.apache.logging.log4j.flume.appender
- org.apache.logging.log4j.jmx.gui
- org.apache.logging.log4j.web
- org.apache.logging.log4j.nosql.appender

* the slf4j bridge is problematic, but is being addressed by changes in slf4j.
* the logf4 v1 bridge probably can't be modularized

Bernd has addressed the point about the need to export all packages
individually, allowing the modules above.

Stephen

On 21 April 2017 at 21:34, Ralph Goers <ralph.go...@dslextreme.com> wrote:
> I am having a hard time figuring out how Log4j is going to be able to support 
> this.  The API itself is in org.apache.logging.log4j and some packages under 
> that.  All the main implementation is under org.apache.logging.log4j.core.  
> These obviously overlap.  Most of our other jars have packages that are in 
> org.apache.logging.log4j.xxx where xxx matches the jar name.  We aren’t going 
> to change the API to support modules.
>
> Is there some reasonable way around this?
>
> Ralph
>
>> On Apr 21, 2017, at 6:16 AM, Stephen Colebourne <scolebou...@joda.org> wrote:
>>
>> On 21 April 2017 at 13:59, sebb <seb...@gmail.com> wrote:
>>> What happens when there is a API break which necessitates a package name 
>>> change?
>>> I assume that the module name will also need to change to the new 
>>> super-package.
>>> e.g.
>>>
>>> Commons-Lang4
>>> -> super-package org.apache.commons.lang4
>>> -> module org.apache.commons.lang4
>>
>> Yes, thats right.
>>
>>> AFAICT Commons generally has obvious and unique super-packages for
>>> each component.
>>> This should make it easier than for larger projects with lots of jars
>>> and potentially overlapping package names.
>>>
>>> However even Commons has some code that uses a different package structure.
>>> e.g. NET uses examples as the super-package.
>>> This includes working examples that are included in the release.
>>> I guess that will have to change (which is probably a good idea anyway).
>>
>> Yes, as it stands, [net] would be a bad modular citizen, because it
>> exposes the "examples" package, and thus prevents any other module
>> from using that package. Just move it to
>> org.apache.commons.net.examples.
>>
>> Stephen
>>
>> -
>> 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: [all] Java 9 module names

[Stephen Colebourne]

On 21 April 2017 at 13:59, sebb  wrote:
> What happens when there is a API break which necessitates a package name 
> change?
> I assume that the module name will also need to change to the new 
> super-package.
> e.g.
>
> Commons-Lang4
> -> super-package org.apache.commons.lang4
> -> module org.apache.commons.lang4

Yes, thats right.

> AFAICT Commons generally has obvious and unique super-packages for
> each component.
> This should make it easier than for larger projects with lots of jars
> and potentially overlapping package names.
>
> However even Commons has some code that uses a different package structure.
> e.g. NET uses examples as the super-package.
> This includes working examples that are included in the release.
> I guess that will have to change (which is probably a good idea anyway).

Yes, as it stands, [net] would be a bad modular citizen, because it
exposes the "examples" package, and thus prevents any other module
from using that package. Just move it to
org.apache.commons.net.examples.

Stephen

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

Re: [all] Java 9 module names

[Stephen Colebourne]

Right now, I don't recommend adding a module-info.java file. Java 9 is
not released, the tools are still under development, and the binary
format may yet change. All we are agreeing is that the module name
will be `org.apache.commons.lang3`, which doesn't change the release
:-)

What we need is a page, either on each subproject website, or on the
main website (probably simpler) that lists the module names for each
project. I can try to find time to work on such a page, but although I
technically have commit access, I certainly don't in practical terms,
so I'd probably submit a GitHub PR instead.

When the time comes, the module-info.java file will be something like this:

module org.apache.commons.lang3 {
 exports org.apache.commons.lang3;
 exports org.apache.commons.lang3.builder;
 exports org.apache.commons.lang3.concurrent;
 exports org.apache.commons.lang3.event;
 exports org.apache.commons.lang3.exception;
 exports org.apache.commons.lang3.math;
 exports org.apache.commons.lang3.mutable;
 exports org.apache.commons.lang3.reflect;
 exports org.apache.commons.lang3.text;
 exports org.apache.commons.lang3.text.translate;
 exports org.apache.commons.lang3.time;
 exports org.apache.commons.lang3.tuple;
}

Stephen

On 21 April 2017 at 13:31, Emmanuel Bourg <ebo...@apache.org> wrote:
> Le 21/04/2017 à 14:00, Stephen Colebourne a écrit :
>
>> Comments? Questions?
>
> Hi Stephen,
>
> Thank you for stopping by and enlightening us about JPMS. The new module
> system looks like a huge mess. I understand the need for modularization
> at the JRE level, but I haven't figured out yet how this extra
> complexity will improve my applications. I know you've followed the
> development of this feature thoroughly and I trust your judgment. You
> still have commit access to the Commons components, so I'd encourage you
> to go ahead and implement your suggestion directly. Commons Lang 3.6 is
> about to be released, we could start with this one and use it as an
> example for the other components.
>
> Emmanuel Bourg
>
>
> -
> 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

[all] Java 9 module names

[Stephen Colebourne]

Hi All,
Java 9 is coming soon (unless it is delayed again, but that seems
unlikely). The major feature is JPMS, the Java Platform Module System.
While JPMS is far from ideal, projects like Apache Commons and mine
Joda-* are going to be key to getting some adoption. This is
particularly true as Commons projects tend to be at the base of the
dependency tree.

I've written up my recommendations for naming modules here:
http://blog.joda.org/2017/04/java-se-9-jpms-module-naming.html
Basically, it strongly recommends reverse-DNS naming based on the
super-package of a project.

What is needed now?

Apache Commons, and Apache in general, needs to agree to use a
consistent naming strategy for modules. As per my writeup, I strongly
recommend using the super-package name as the module name, as most
Apache projects already have good separation by package name.

It will be important to ensure complete separation however, as JPMS
does not allow the same package to be in two modules.

Finally, it is important to note that modules are not the same as
artifacts. Modules, and thus their names, represent the JVMs view of
the structure of an application. Artifacts are a transport mechanism
(jar file), and many different artifacts can provide the same module.
This becomes apparent when considering the Apache branded JSR jar
files, for example the module name might be javax.servlet (ie. not
referencing Apache), but the artifactId is apache-jsr-360 (which does
reference Apache).


So, how to apply this to Commons (and Apache in general)?

Well, I haven't examined each commons subproject, but from my time
contributing years ago, each subproject has its own package name.
Thus:

Commons-IO
-> super-package org.apache.commons.io
-> module org.apache.commons.io

Commons-Lang3
-> super-package org.apache.commons.lang3
-> module org.apache.commons.lang3


If everyone agrees, the module name for each project should be
documented somewhere on the website. Note that this should be done
_now_, but does not require creating a module-info.java file, or
otherwise preparing for Java 9.

Comments? Questions?
thanks
Stephen

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

Re: [OT] Anyone going to JavaOne?

[Stephen Colebourne]

I'll be there talking three times. Usually best to find me after one
of the talks...
http://blog.joda.org/2013/09/speaking-at-javaone2013.html
Stephen

On 19 September 2013 20:50, James Carman ja...@carmanconsulting.com wrote:
 Is anyone planning on going?  It would be great to meet some of you
 guys face-to-face for once, if you're going to be there.

 James

 -
 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: [ALL] How to handle static imports [was: Re: svn commit: r1441784 - /commons/sandbox/beanutils2/trunk/src/main/java/org/apache/commons/beanutils2/PropertyDescriptorsRegistry.java]

[Stephen Colebourne]

FYI, the Project Lambda Streams code and JSR-310 in JDK 1.8 are both
written with static imports in mind. Moreover, with support for static
methods in interfaces being added, this is likely to increase as a
pattern. Those facts may or may not affect decisions in commons.

Stephen


On 4 February 2013 21:32, Benedikt Ritter brit...@apache.org wrote:
 Hi,

 we had a little discussion in BeanUtils2, regarding static imports (see
 below). To increase visibility and get some more feedback, I'm forwarding
 this to [ALL]

 We haven't decided yet how to handle static imports. To form some rules,
 we'd like to hear what others think about static imports and what rules of
 thumb you use in your projects.

 I'm exited to hear your opinions :)
 Regards,
 Benedikt


 2013/2/4 Jörg Schaible joerg.schai...@scalaris.com

 Hi,

 Benedikt Ritter wrote:

  Hi Simo,
 
  thanks for sharing your thoughts! I personally try to avoid static
  imports. Especially when you come to a legacy code base IMHO it makes the
  code harder to understand. You always have to look, where a method comes
  from.

 Actually I avoid static imports for the same reason.

  Also you may have the problem, that you accidentally override
  imported static methods, when defining a new static method with the same
  name. BU2 is a very small code base, so it would be okay for me to revert
  the change.
 
  Nevertheless I'd be interested to hear what others thing about this
 topic.

 my 2¢

 - Jörg


 -
 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: [weaver]/[bcel] WAS [privilizer] promotion plan

[Stephen Colebourne]

On 4 December 2012 23:05, Gary Gregory garydgreg...@gmail.com wrote:
 I like the name weaver.

 Does it make sense to allow different libs to be plugged in? BCEL,
 ASM... Or do do we have to pick one?

Based on what I see in various projects, ASM won, BCEL lost. Main
problem tends to be different versions of ASM being incompatible.

Stephen

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

Re: [csv] CSVFormat API names

[Stephen Colebourne]

On 16 October 2012 17:44, Matt Benson gudnabr...@gmail.com wrote:
 On Tue, Oct 16, 2012 at 11:42 AM, James Carman
 ja...@carmanconsulting.com wrote:
 On Tue, Oct 16, 2012 at 12:38 PM, Matt Benson gudnabr...@gmail.com wrote:

 Are these specific examples not the words you would actually use were
 you having a discussion on the subject in English?  :P


 Why not just support both?  The with* methods would just be aliases
 for the more natural language method names.

I would categorise first in two
- mutable builders producing immutable objects
- immutable objects

The former should generally have short methods without prefixes, the
latter is more complex.

For the latter, as a general rule, I use
withXxx()/plusXxx()/minusXxx() for items that affect the state and
past participle for other methods that manipulate the object in other
ways:

// affects state (year/month/day)
 date = date.withYear(2012)
 date = date.plusYears(6)
// aftect multiple pieces of state, so past participle
 period = period.multipliedBy(6)
 period = period.negated()

This is simply an extension of when you might use setXxx() on a bean,
and when you might use a named method.

Stephen

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

Re: [collections] Cleanup of trunk

[Stephen Colebourne]

To clarify what I've said before, there are two user requirements here;
- adding generics to the last release while maintaining compatibility
- rethinking some APIs to get the best design features for Java 5+
(non-compatible)

ATM, no one is working on the first that I can see, yet that is what
the existing user base actually wants. The users won't be able to
upgrade to a non-compatible release, due to the fact that other open
source projects depend on the current release.

Thus, for me, any non-compatible release is effectively a new project.
It would be clearer to rename the project and start again at version
1.0 for the non-compatible codebase. Maybe [collectionsplus]. A lot
clearer than what happened with [lang3].

Bear in mind that [lang] (version 2) and [collections] are number 6
and 7 on the most downloaded artifacts list
http://search.maven.org/#stats

However, the big issue here is that the whole library will need
rewriting for JDK 8 due to lambdas. So what does a non-compatible
release now actually accomplish?

Well, since I'm not being active, I'm not going to stop people. But I
am trying to speak up for the users, who just want a compatible
bug-fixed, generified version (even if it can't be fully generifed,
some generics are better than none).

Note that none of this is about Java 5 vs 6. Its about compatibility
and what users actually want (remember the maven download stats!!).

Stephen



On 4 July 2012 11:30, Gary Gregory garydgreg...@gmail.com wrote:
 +1 to java 6 and using the new interfaces, removing classes that can
 be replaced with Java 6 code.

 Gary

 On Jul 4, 2012, at 4:32, Simone Tripodi simonetrip...@apache.org wrote:

 FWIW, +1 as well!!! :)

 -Simo

 http://people.apache.org/~simonetripodi/
 http://simonetripodi.livejournal.com/
 http://twitter.com/simonetripodi
 http://www.99soft.org/


 On Wed, Jul 4, 2012 at 9:59 AM, Jörg Schaible
 joerg.schai...@scalaris.com wrote:
 Stephen Colebourne wrote:

 On Java 5/6, I'm in favour of Java 6 at this point. To justify it for
 Sebb, someone needs to check to see if any collections in
 [collections] could implement the new interfaces added in Java 6 -
 NavigableSet, NavigableMap and so on.

 I am definitely +1 here. Java 6 comes with more interesting  interfaces
 (Deque) and implementations (ArrayDeque explicitly as replacement for Stack)
 that make more of our stuff obsolete.

 Anyone who still uses Java 5 has either made the best of 4-year-old cc3 or
 switched to a different library. And in the light that Java 6 is probably
 EOL before we release cc4, I see also no reason to stick with Java 5.

 - Jörg


 -
 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: [collections] Cleanup of trunk

[Stephen Colebourne]

On Java 5/6, I'm in favour of Java 6 at this point. To justify it for
Sebb, someone needs to check to see if any collections in
[collections] could implement the new interfaces added in Java 6 -
NavigableSet, NavigableMap and so on.

Stephen



On 24 June 2012 12:25, sebb seb...@gmail.com wrote:
 On 24 June 2012 10:28, Thomas Neidhart thomas.neidh...@gmail.com wrote:
 Hi,

 I recently started to work more on collections and cleaning up the trunk
 to make it a candidate for a release and would like to ask a few questions:

  - there is still lots of javadoc missing, moving the source code level
   to Java 1.6 would allow the use of @Override in more places (instead
   of putting a /** {inheritDoc} */ everywhere)

 AFAICT Javadoc is automatically inherited for methods that implement
 an interface.
 Being able to add @Override to an interface implementation does not
 gain anything.

   this has been discussed for vfs a few weeks ago, and my
   understanding was that this proposal was well received, so what do
   you think about doing the same for collections?

 No, we should only require Java 6 if strictly necessary for some new
 functionality it provides.
 Javadoc is not a good enough reason.

  - unit tests: there are currently two unit tests for certain classes
   that are almost similar, e.g. TestListOrderedMap and
   TestListOrderedMap2. Does anybody know why this exists?

   also I would like to go to annotation based unit tests like in the
   other components and rename the tests to the common style:
   ClassNameTest.

 OK.

  - consistency with commons rules. There are several things that are
   different to other components atm:

   o authors contained in source files

 OK, but original authors still need to be creditted e.g. in pom.xml.

   o no changes.xml to track changes
   o since and version tags are a bit different
   o package.html should be package-info.java

 OK.

   and I guess other things too that I have not spotted yet.


 Are there any objections / suggestions to continue with the cleanup?

 I object to moving to Java 6 without a compelling reason.

 Thomas

 -
 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: Conversion utility class

[Stephen Colebourne]

On 4 February 2012 05:38, ma...@nimp.co.uk ma...@nimp.co.uk wrote:
 Apache Commons Lang seems to be the right place for that kind of utility
 class, however, my utility class is coded in Scala, is that ok ?

Not in my opinion No.

I have no problem with a Scala-only commons component, but I think
mixing two languages in the same component to be a bad choice. It
complicates maintanance, raises the kind of documentation issue you're
looking at, and is generally just wholly unnecessary (just rewrite it
in Java if its a Java component).

The simple library-style Commons components are just that, very
simple. They code should be relatively obvious to those new to Java.

Stephen

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

Re: [lang] 3.2?

[Stephen Colebourne]

On 31 December 2011 08:45, Henri Yandell flame...@gmail.com wrote:
 Three changes of interest. Two are the removal of final on public
 methods. The other is the addition of Serializable to StrBuilder.

As described above, those are source and binary compatible.

Stephen


 Which is the worry? And is it a big enough worry to not keep the change?

 Hen

 On Wed, Dec 28, 2011 at 6:07 AM, Gary Gregory garydgreg...@gmail.com wrote:
 Fire it up! :)

 Despite what Clirr reports, are the changes really binary compatible?

 Gary

 On Wed, Dec 28, 2011 at 2:48 AM, Henri Yandell flame...@gmail.com wrote:

 Of course, I mean 3.2. :)

 On Tue, Dec 27, 2011 at 11:46 PM, Henri Yandell flame...@gmail.com
 wrote:
  Heads up that I'm thinking that 3.3 is ready to be released. 10 issues
  resolved in trunk.
 
  Hen

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




 --
 E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
 JUnit in Action, 2nd Ed: http://goog_1249600977http://bit.ly/ECvg0
 Spring Batch in Action: http://s.apache.org/HOqhttp://bit.ly/bqpbCK
 Blog: http://garygregory.wordpress.com
 Home: http://garygregory.com/
 Tweet! http://twitter.com/GaryGregory

 -
 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: [jira] [Commented] (LANG-577) Add ObjectReference interface and two implementations

[Stephen Colebourne]

Oracle advise using AtomicReference for any threaded cases, and we
have MutableObject for other cases. I'm very dubious about adding a
second version of the same class.
Stephen
Limited mobile access

On 11/09/2011, Henri Yandell (JIRA) j...@apache.org wrote:

 [
 https://issues.apache.org/jira/browse/LANG-577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13102209#comment-13102209
 ]

 Henri Yandell commented on LANG-577:
 

 Also, iiuc, while the interface might be the overlapping, the
 implementations won't be.

 I'm +1 for the feature.

 Matt called it a StrongReference - would that be a better name? Or is that
 implementation dependent (ie: MemoryReference would be a strong reference,
 but ObjectReference could be multiple types?)

 Add ObjectReference interface and two implementations
 -

 Key: LANG-577
 URL: https://issues.apache.org/jira/browse/LANG-577
 Project: Commons Lang
  Issue Type: New Feature
  Components: lang.*
Reporter: Joerg Schaible
Assignee: Joerg Schaible
Priority: Minor
 Fix For: 3.x

 Attachments: reference.diff


 In some situations it would be helpful to use a reference to an object,
 e.g. for parameters by reference
 {code:java}
 void doSomething(ObjectReferenceString ref) {
 ref.set(Hello);
 }
 {code}
 or for anonymous methods
 {code:java}
 final ObjectReferenceString ref = new MemoryReferenceString();
 final Runnable r = new Runnable() {
 void run() {
 ref.set(Hello);
 }
 }
 r.run();
 {code}
 Additionally it is sometimes useful to keep the reference in other places
 than in shared memory, e.g. in a ThreadLocal or in case of a web
 application in a scoped reference or even in combination with some other
 persistence mechanism. Basically I am proposing the interface
 ObjectReference:
 {code:Java}
 /**
  * Interface to reference an object.
  *
  * @param T the type of the referenced object
  * @author Apache Software Foundation
  * @since 3.0
  */
 public interface ObjectReferenceT {
 /**
  * Getter for the referenced object.
  *
  * @return the object or codenull/code
  */
 T get();
 /**
  * Setter for the reference.
  *
  * @param object the object to reference (may be codenull/code)
  */
 void set(T object);
 }
 {code}
 and the two implementations MemoryReference and ThreadLocalReference in
 the new package org.apache.commons.lang3.reference. I've seen such or
 similar types in various libraries.
 Comments?
 Unit test will be provided also.

 --
 This message is automatically generated by JIRA.
 For more information on JIRA, see: http://www.atlassian.com/software/jira




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

Re: [lang] Running lang under a security manager and LANG-744

[Stephen Colebourne]

On 2 September 2011 01:20, Gary Gregory garydgreg...@gmail.com wrote:
 Specifically for StringUtils, should we have a SunStringUtils? This would
 let you know that you are depending on com.sun code.

I really don't like that idea!

Generally, it is non-Sun JVMs including Android that are the problem.
Lets just do the best we can on those.

Stephen

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

Re: [codec] Encoder / Decoder interface

[Stephen Colebourne]

On 17 August 2011 13:44, Matthew Pocock turingatemyhams...@gmail.com wrote:
 It seems to me that the Encoder/Decoder interfaces are screaming out to be
 generified, and the current sub-interfaces should be removed unless there's
 a compelling reason for them e.g. if they add extra methods. It is no
 hardship in your code to write EncoderString, String rather than
 StringEncoder. I realise that in any one application it may be the case that
 they use only one family of encoders (e.g. String = String), but I don't
 see why this means we should be introducing a Java interface explicitly for
 this use case.

I prefer StringEncoder to EncoderString, String. Its shorter and clearer.
Overall, I'd say focus users on the concrete versions like StringEncoder.

On 16 August 2011 21:38, Gary Gregory garydgreg...@gmail.com wrote:
 I am not a fan of these interfaces because they are not typed, Object
 encode(Object) is too vague now that Generics have been an option for
 years.

The Object encode(Object) approach is still valid if the primary use
case of the interface is for frameworks. In a framework, objects are
generally treated as of type Object, so the API is fine. User code
should use concrete versions.

Stephen

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

Re: [codec] getting the bmpm code out there

[Stephen Colebourne]

I've just noticed this thread.

I'd like to ask those involved to consider if they can find a route
where the package name and group do *not* change.

- Changing to JDK 5 does not require a a package name change (generics
are backward compatible if the erased signatures don't change).
- Removing deprecated methods does not require a package name change
(and potentially, we should just leave them in)
- It is far far more user friendly to not have a new codec and an
old codec in their path.

Looking back at [lang], I think that a different focus might have
allowed 90% of the code to have been compatible and in the same
package, with 10% in a new package. [codec] might well fit that model
too.

For example, if a method needs its signature changing, create a new
method alongside and deprecate the original. Yes, it isn't as pretty,
but it is generally better for users. Only if there are too many cases
like this to keep the API sane, should a new codec (or any other
commons lib) be created.

Stephen


On 11 August 2011 23:44, Gary Gregory garydgreg...@gmail.com wrote:
 On Thu, Aug 11, 2011 at 4:10 PM, sebb seb...@gmail.com wrote:
 On 11 August 2011 20:56, Gary Gregory garydgreg...@gmail.com wrote:
 Hello All!

 Topic 1: Housekeeping: package name and POM.

 The next codec release out of trunk will be major release labeled 2.0,
 the current release is 1.5.

 In trunk, I've removed deprecated methods and the project now requires
 Java 5. This means 2.0 will not be a drop-in binary compatible release
 for 1.5.

 I'd like to confirm or deny that this means the package name will
 change to o.a.c.codec2 and that the POM groupId will have to change
 from commons-codec to org.apache.commons. 2.0 and 1.5 would be able to
 live side by side.

 Yes, the name changes are necessary to avoid problems with incompatible jars.

 I'd like to get this out of the way first hence topic 1.


 Topic 2: Beider-Morse (BM) Encoder API
 https://issues.apache.org/jira/browse/CODEC-125

 BM is a new codec for 2.0.

 The encode API returns a set of encodings.

 In trunk, this is currently a String in the format s1|s2|s3.

 I think this is not the best design, a set should be a Set, in this
 case, an ordered set. Or, a List. Generally, it should be a Collection
 of Strings.

 There was concern with call sites that generically use a [codec]
 Encoder with the signature Object encoder(Object) and call
 toString() on the result.

 If we set the API to CharSequence encode(SetCharSequence) or
 String encode(SetString), doing a toString() on a HashSet will
 yield a usable String similar as to what trunk does now. For example,
 for a HashSet of Strings a, b and c, HashSet.toString() returns
 [a, b, c] which no worse than a|b|c IMO. At least it is a
 documented and stable format.

 +1

 Topic 3: Generics

 This will be in a separate thread but I'd like to get this in 2.0
 because this will likely break the API and I only want to break things
 once and not have to do a codec3 for generics.

 +1.

 I'll work on a generified codec2 over the next couple of days and
 present what that looks like, maybe in a branch, or a patch.

 Gary


 Thank you all,
 Gary

 On Thu, Aug 11, 2011 at 2:38 PM, Matthew Pocock
 turingatemyhams...@gmail.com wrote:
 Hi,

 As those of you who've been following the CODEC-125 ticket will know, with
 Greg's help I've got a port of the beider morse phonetic
 matching (bmpm) algorithm in as a string encoder. As far as I can tell, 
 it's
 ready for people to use and abuse. It ideally needs more test-case words,
 but to the best of my knowledge it doesn't have any horrendous bugs or
 performance issues.

 The discussion on the ticket started to stray off bmpm and on to policy for
 releases and changing APIs, and Sebb said we should discuss it on the list.
 So, here we are.

 Ideally, I'd like there to be a release of commons-codec some time soon so
 that users can start to try out bmpm right away, and so that we can start
 the process of adding it to the list of supported indexing methods in solr.
 What do people think?

 Matthew

 --
 Dr Matthew Pocock
 Visitor, School of Computing Science, Newcastle University
 mailto: turingatemyhams...@gmail.com
 gchat: turingatemyhams...@gmail.com
 msn: matthew_poc...@yahoo.co.uk
 irc.freenode.net: drdozer
 tel: (0191) 2566550
 mob: +447535664143




 --
 Thank you,
 Gary

 http://garygregory.wordpress.com/
 http://garygregory.com/
 http://people.apache.org/~ggregory/
 http://twitter.com/GaryGregory

 -
 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





 --
 Thank you,
 Gary

 http://garygregory.wordpress.com/
 http://garygregory.com/
 

Re: [codec] getting the bmpm code out there

[Stephen Colebourne]

On 12 August 2011 11:19, sebb seb...@gmail.com wrote:
 - Removing deprecated methods does not require a package name change

 How so?

 If there are any external references to them in an application that
 cannot be removed, then both old and new jars will need to be
 deployed.
 Which cannot be done safely in a single classloader (no guarantee
 which instance of duplicated classes will be loaded).
 AFAIK Maven prevents duplicates anyway.

In Joda-Time v2.0 I removed some deprecated methods and left others in
(no package name change). Those that I removed were methods that were
deprecated for a very long time (probably4years+), with multiple later
versions with the deprecation and easy alternates. Those that I did
not remove were classes and methods that were probably still in use by
people as they were once a primary API. This is a judgement call.

And yes, removing a deprecated element means that another project that
still uses the deprecation can no longer run. But if you've had
something deprecated for over 3 years, that doesn't seem too harsh,
unless it used to be a key/primary API.

In hard cases, I'd rather see NewFoo of Foo2 replacing Foo
within the same package name, or a new sub-package within the same
o.a.c.codec package space rather than o.a.c.codec2 for everything.

Stephen

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

Re: [codec] getting the bmpm code out there

[Stephen Colebourne]

On 12 August 2011 14:54, sebb seb...@gmail.com wrote:
 We have lang3 and digester3 under our belts now with new packages. Are
 we going to change policy again? I hope not. We sure spent a lot of
 time on this and thought we made a sane decision as a community.
 Joda-time is its own world can do what it wants but I'd like to keep
 my sanity in commons land with clear and consistent policies ;)

 It's not a change in policy; lang3 and digester3 are exceptions.

I think of the rule as if there are any significant (non long
deprecated) backwards incompatibilities, then a new package name is
needed, otherwise try as hard as possible to retain the same package
name.

Stephen

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

Re: [collections] 4.0 release path

[Stephen Colebourne]

I agree with this. And I think it serves users better, many of whom
have migrated to Google Guava.

1) New bug fix only release, JDK 1.4 compatible
2) New release with some generics, backwards compatible
3) Re-evaluate whether an incompatible release makes sense

Stephen


On 5 August 2011 07:12, Henri Yandell flame...@gmail.com wrote:
 I think we should move the current trunk off and call it generics-RnD.

 Then we should copy 3.2 over to trunk (or maybe 3.3, I seem to recall
 that prior to merging the generics in we had a 3.3 ready for release).

 We then release 3.3.

 Then we start 3.4. We genericize some tiny part of it in a binary
 compat way. Release.
 3.5. Genericize a bit more. Release.
 3.6... etc.

 We use generics-RnD code, pulling it over (and maybe deleting when
 considered happy).

 Somewhere around about 3.28 we can decide to start on 4.0, pulling
 over the remainder of generics-RnD.

 Hen


 On Wed, Aug 3, 2011 at 8:23 AM, Stephen Colebourne scolebou...@joda.org 
 wrote:
 I think that a key mistake was trying to do both generics and
 refactoring. I'd suggest that quite a few users would simply like a
 generified [collections] 3.5 that is fully backwards compatible (as
 the JDK was) and with no refactoring.

 Now, some of the API cannot be generified correctly, so  for a v3.5,
 those should simply be left as raw types.

 Of course doing the above isn't fun, as it involves going back
 (again), but it it probably the right approach.

 Stephen



 On 3 August 2011 16:01, Paul Benedict pbened...@apache.org wrote:
 Or do a pure generics release as 3.5 to satisfy that need... which
 allows 4.0 to have generics plus the benefit of major refactoring if
 necessary (could also be called 4.0 and 5.0).

 On Wed, Aug 3, 2011 at 9:55 AM, Matt Benson gudnabr...@gmail.com wrote:
 On Wed, Aug 3, 2011 at 9:48 AM, Gary Gregory garydgreg...@gmail.com 
 wrote:
 The most important theme IMO is generics. That's what has come up at
 work recently in fact. Everything else except showstopper bugs can
 wait IMO.

 Indeed, this seems to resonate with Hen's recent treatise on
 (paraphrased) why the hell we take so long.

 Matt


 Gary

 On Wed, Aug 3, 2011 at 9:16 AM, Simone Tripodi simonetrip...@apache.org 
 wrote:
 Hi all guys,
 I'm (re)starting having a good slot of spare time, I volunteered to
 help Matt on finalizing the [collections] release, but after had a
 look at the open issues I think we should agree on what including and
 what not.
 Does anyone already have a good overview/idea of collections roadmap?
 Many thanks in advance, have a nice day!!!
 Simo

 http://people.apache.org/~simonetripodi/
 http://www.99soft.org/

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





 --
 Thank you,
 Gary

 http://garygregory.wordpress.com/
 http://garygregory.com/
 http://people.apache.org/~ggregory/
 http://twitter.com/GaryGregory

 -
 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: [collections] 4.0 release path

[Stephen Colebourne]

I don't mind multiple releases with (2), thats a see how it goes type approach.
Stephen

On 5 August 2011 08:38, Henri Yandell flame...@gmail.com wrote:
 Repeating myself just to make sure you're in full agreement; there
 would be multiple releases within your 2) state. ie) Maybe we
 genericize one method and then release [to take it to extremes].

 Hen

 On Fri, Aug 5, 2011 at 12:33 AM, Stephen Colebourne
 scolebou...@joda.org wrote:
 I agree with this. And I think it serves users better, many of whom
 have migrated to Google Guava.

 1) New bug fix only release, JDK 1.4 compatible
 2) New release with some generics, backwards compatible
 3) Re-evaluate whether an incompatible release makes sense

 Stephen


 On 5 August 2011 07:12, Henri Yandell flame...@gmail.com wrote:
 I think we should move the current trunk off and call it generics-RnD.

 Then we should copy 3.2 over to trunk (or maybe 3.3, I seem to recall
 that prior to merging the generics in we had a 3.3 ready for release).

 We then release 3.3.

 Then we start 3.4. We genericize some tiny part of it in a binary
 compat way. Release.
 3.5. Genericize a bit more. Release.
 3.6... etc.

 We use generics-RnD code, pulling it over (and maybe deleting when
 considered happy).

 Somewhere around about 3.28 we can decide to start on 4.0, pulling
 over the remainder of generics-RnD.

 Hen


 On Wed, Aug 3, 2011 at 8:23 AM, Stephen Colebourne scolebou...@joda.org 
 wrote:
 I think that a key mistake was trying to do both generics and
 refactoring. I'd suggest that quite a few users would simply like a
 generified [collections] 3.5 that is fully backwards compatible (as
 the JDK was) and with no refactoring.

 Now, some of the API cannot be generified correctly, so  for a v3.5,
 those should simply be left as raw types.

 Of course doing the above isn't fun, as it involves going back
 (again), but it it probably the right approach.

 Stephen



 On 3 August 2011 16:01, Paul Benedict pbened...@apache.org wrote:
 Or do a pure generics release as 3.5 to satisfy that need... which
 allows 4.0 to have generics plus the benefit of major refactoring if
 necessary (could also be called 4.0 and 5.0).

 On Wed, Aug 3, 2011 at 9:55 AM, Matt Benson gudnabr...@gmail.com wrote:
 On Wed, Aug 3, 2011 at 9:48 AM, Gary Gregory garydgreg...@gmail.com 
 wrote:
 The most important theme IMO is generics. That's what has come up at
 work recently in fact. Everything else except showstopper bugs can
 wait IMO.

 Indeed, this seems to resonate with Hen's recent treatise on
 (paraphrased) why the hell we take so long.

 Matt


 Gary

 On Wed, Aug 3, 2011 at 9:16 AM, Simone Tripodi 
 simonetrip...@apache.org wrote:
 Hi all guys,
 I'm (re)starting having a good slot of spare time, I volunteered to
 help Matt on finalizing the [collections] release, but after had a
 look at the open issues I think we should agree on what including and
 what not.
 Does anyone already have a good overview/idea of collections roadmap?
 Many thanks in advance, have a nice day!!!
 Simo

 http://people.apache.org/~simonetripodi/
 http://www.99soft.org/

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





 --
 Thank you,
 Gary

 http://garygregory.wordpress.com/
 http://garygregory.com/
 http://people.apache.org/~ggregory/
 http://twitter.com/GaryGregory

 -
 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



 -
 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

Re: [logging] logging vs slf4j

[Stephen Colebourne]

My thought is that there might be some java.util.logging helpers that
could be written, and perhaps they might go in [lang] if there are 5
or fewer classes.

I assume that slf4j and log4j have their own j.u.logging connections,
so that end is dealt with.

The time of [logging] has probably passed.

Stephen


On 3 August 2011 06:50, Henri Yandell flame...@gmail.com wrote:
 On Tue, Aug 2, 2011 at 1:59 AM, Emmanuel Bourg ebo...@apache.org wrote:
 Le 28/07/2011 22:01, Henri Yandell a écrit :

 Personally I'm happy for commons-logging to die. :)

 Yeah let's use java.util.logging instead :)

 Primarily that I don't get the feeling we have a major community of
 developers on c-logging. We implemented it because we needed something
 for our other components (though many simply chose not to log), but it
 was never the passion of anybody here (hopefully not an incorrect
 statement). Robert, Simon and others put in tons of good work, but I
 feel that was duty not passion.

 So happy to see it die because it's something that's headed to
 dormancy (be it stable or not).

 Hen

 -
 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: [collections] 4.0 release path

[Stephen Colebourne]

I think that a key mistake was trying to do both generics and
refactoring. I'd suggest that quite a few users would simply like a
generified [collections] 3.5 that is fully backwards compatible (as
the JDK was) and with no refactoring.

Now, some of the API cannot be generified correctly, so  for a v3.5,
those should simply be left as raw types.

Of course doing the above isn't fun, as it involves going back
(again), but it it probably the right approach.

Stephen



On 3 August 2011 16:01, Paul Benedict pbened...@apache.org wrote:
 Or do a pure generics release as 3.5 to satisfy that need... which
 allows 4.0 to have generics plus the benefit of major refactoring if
 necessary (could also be called 4.0 and 5.0).

 On Wed, Aug 3, 2011 at 9:55 AM, Matt Benson gudnabr...@gmail.com wrote:
 On Wed, Aug 3, 2011 at 9:48 AM, Gary Gregory garydgreg...@gmail.com wrote:
 The most important theme IMO is generics. That's what has come up at
 work recently in fact. Everything else except showstopper bugs can
 wait IMO.

 Indeed, this seems to resonate with Hen's recent treatise on
 (paraphrased) why the hell we take so long.

 Matt


 Gary

 On Wed, Aug 3, 2011 at 9:16 AM, Simone Tripodi simonetrip...@apache.org 
 wrote:
 Hi all guys,
 I'm (re)starting having a good slot of spare time, I volunteered to
 help Matt on finalizing the [collections] release, but after had a
 look at the open issues I think we should agree on what including and
 what not.
 Does anyone already have a good overview/idea of collections roadmap?
 Many thanks in advance, have a nice day!!!
 Simo

 http://people.apache.org/~simonetripodi/
 http://www.99soft.org/

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





 --
 Thank you,
 Gary

 http://garygregory.wordpress.com/
 http://garygregory.com/
 http://people.apache.org/~ggregory/
 http://twitter.com/GaryGregory

 -
 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: [LANG] Commons Lang 3.0

[Stephen Colebourne]

You will need both versions of commons-lang, the new and the old.
Stephen

On 27 July 2011 11:17, Rohan Kadam roha...@cybage.com wrote:
 Hi All,

 We have upgraded our common lang jar to 3.0 version. We have replaced package 
 name lang to lang3. But since it has already been mentioned on apache 
 website that Common Lang 3.0 is not backward compatible, we are facing some 
 compilation issues.

 After replacing Apache Commons Lang 2.1 with Apache Commons Lang 3.0 we get 
 some compilation errors since the class 
 org.apache.commons.lang.exception.NestableException is being referred 
 internally in the class files of  
 org.apache.commons.configuration.ConfigurationException.

 To summarize the common lang jar to 3.0 version is not compatible with common 
 configuration jar latest version.

 Please suggest.

 Thanks.

 Legal Disclaimer: This electronic message and all contents contain 
 information from Cybage Software Private Limited which may be privileged, 
 confidential, or otherwise protected from disclosure. The information is 
 intended to be for the addressee(s) only. If you are not an addressee, any 
 disclosure, copy, distribution, or use of the contents of this message is 
 strictly prohibited. If you have received this electronic message in error 
 please notify the sender by reply e-mail to and destroy the original message 
 and all copies. Cybage has taken every reasonable precaution to minimize the 
 risk of malicious content in the mail, but is not liable for any damage you 
 may sustain as a result of any malicious content in this e-mail. You should 
 carry out your own malicious content checks before opening the e-mail or 
 attachment.
 www.cybage.com



 -
 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

[lang] IOUtils in tests [Re: [VOTE] [LANG] Release Commons Lang 3.0 (based on RC4)]

[Stephen Colebourne]

Personally, I'm OK with using JUnit and mocking utilities as they are
both specifically intended for testing. I think using IOUtils in
testing [lang] is distinctly dubious, especially for a single method,
and I'd much rather see the code copied. This isn't a -1 veto, but its
a strong disapproval.

Stephen


On 19 July 2011 15:13, Gary Gregory garydgreg...@gmail.com wrote:
 On Tue, Jul 19, 2011 at 9:28 AM, Paul Benedict pbened...@apache.org wrote:

 As long as Commons IO is marked as a test dependency, I am okay with
 it. I just don't want it to be a compile-time dependency for the main
 source.


 It is specified in the test scope in the POM.

 Gary



 On Tue, Jul 19, 2011 at 8:24 AM, Gary Gregory garydgreg...@gmail.com
 wrote:
  On Mon, Jul 18, 2011 at 9:25 PM, Henri Yandell flame...@gmail.com
 wrote:
 
  Interesting issue; though thankfully it's post RC4 so not an issue wrt
  releasing 3.0.
 
  Assuming (for argument's sake) that IO Test depends on Lang  Lang
  Test depends on IO; is this bad? I'm not convinced it is. Dealing with
  something like that is something the build system needs to know how to
  do.
 
 
  We depend on JUnit and EasyMock for testing, so I really think it is OK
 to
  also depend on [io] for testing as well. CP'ing code is lame in this
 case
  IMO.
 
  Gary
 
 
  Hen
 
  On Mon, Jul 18, 2011 at 3:50 PM, Stephen Colebourne
  scolebou...@joda.org wrote:
   StringEscapeUtils test includes IOUtils, which it shouldn't. (If its
   been added as a dependency, then it needs to be removed, even for
   testing)
  
   Stephen
  
   On 18 July 2011 23:41, Gary Gregory garydgreg...@gmail.com wrote:
   On Jul 18, 2011, at 18:36, Stephen Colebourne scolebou...@joda.org
  wrote:
  
   I'm willing to vote +1
   Although I haven't checked every recent change, but AFAIK recent
   changes have been minor and my previous issues are resolved.
  
   I would note that the svn as of right now does not compile, due to
 an
   IOUtils reference that shouldn't be
  
   Hi Stephen,
  
   Can you specify what your error is? I check both the maven and ant
   builds before my commit.
  
   Gary
  
  
   Stephen
  
  
   On 16 July 2011 01:18, Henri Yandell flame...@gmail.com wrote:
   Thanks Gary.
  
   So 4 +1s.
  
   Stephen, Niall, Paul, Phil, Sebb, James - nudge to consider voting
   (apologies if I missed anyone else who has committed to Lang 3.0)?
  
   Hen
  
   On Fri, Jul 15, 2011 at 12:32 PM, Gary Gregory 
  garydgreg...@gmail.com wrote:
   That's true too. In the spirit of release early, release often, I
  remove my
   -1 :)
  
   Gary
  
  
   On Fri, Jul 15, 2011 at 10:54 AM, Henri Yandell 
 flame...@gmail.com
  wrote:
  
   Less that it is painful (though I agree that it is), more that
 if
  you
   hold up a release for every bug that comes in then you
 continually
  sit
   in a non-releasing state. We have a really bad habit of that in
   Commons, constantly polishing and polishing before a release.
  
   Hen
  
   On Fri, Jul 15, 2011 at 6:58 AM, Gary Gregory 
  garydgreg...@gmail.com
   wrote:
   Here is my main issue: we are releasing a major new version and
  there is
   a
   known bug reported by a user which has been fixed in SVN. It
 feels
  like
   we
   are unwilling to cut a new RC because our build process and
  validation
   is
   painful (it is so in my experience at least, your mileage may
 vary
  using
   custom scripts, Nexus, or other incantations.) This is not a
 good
  reason
   IMO
   to avoid rebuilding. In the case of a major release like 3.0, I
 do
  not
   want
   to leave a bad taste in a user's mouth with a class that is not
  fully
   baked,
   especially in code new to 3.0. I like that we are planning a
  3.0.1, but
   I do
   not see why we should not include something that is already
 fixed
  for
   3.0.
   It's not like this issue needs more time on investigating,
 coding,
  and
   testing.
  
   Now, if you all really think I am being unreasonable, I'll be
  happy to
   go
   with the flow and reverse -1, but for now, I wanted to express
 my
  full
   POV.
  
   Thank you for reading and talking :)
  
   Gary
  
   On Fri, Jul 15, 2011 at 3:44 AM, Henri Yandell 
  flame...@gmail.com
   wrote:
  
   Waiting on you to determine whether your -1 is still there on
  LANG-720.
  
   Then need to poke Niall, Stephen et al to do a review :)
  
   On Thu, Jul 14, 2011 at 11:54 AM, Gary Gregory 
  garydgreg...@gmail.com
  
   wrote:
   -1, let's pick up the committed fix for
   https://issues.apache.org/jira/browse/LANG-720
  
   I recall seeing traffic in the escape/unescape area so it
 makes
  sense
   to
   polish this new code as much as possible IMO.
  
   Gary
  
   On Thu, Jul 14, 2011 at 12:47 AM, Henri Yandell 
  flame...@gmail.com
   wrote:
  
   Lang is ready to consider 3.0 release again.
  
   RC4 is available here:
  
    http://people.apache.org/~bayard/commons-lang3-3.0-RC4/
  
   SVN:
  
  
  
  http://svn.apache.org/repos/asf/commons/proper/lang/tags

Re: [lang] IOUtils in tests [Re: [VOTE] [LANG] Release Commons Lang 3.0 (based on RC4)]

[Stephen Colebourne]

On 19 July 2011 16:32, Gary Gregory garydgreg...@gmail.com wrote:
 When you say Personally, I'm OK with using JUnit and mocking utilities as
 they are both specifically intended for testing. are you thinking that
 there are alternative solutions?. IMO, JUnit is a requirement, not something
 we should even consider cutting and pasting, not something that is just OK
 to depend on, it is an established standard for this project.

That was an 'ok' as in good. We should depend on JUnit/mocking, not copy them!

IOUtils is an end user library, and depending on it makes the test
more of an integration test.

Stephen

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

Re: [VOTE] [LANG] Release Commons Lang 3.0 (based on RC4)

[Stephen Colebourne]

I'm willing to vote +1
Although I haven't checked every recent change, but AFAIK recent
changes have been minor and my previous issues are resolved.

I would note that the svn as of right now does not compile, due to an
IOUtils reference that shouldn't be there.

Stephen


On 16 July 2011 01:18, Henri Yandell flame...@gmail.com wrote:
 Thanks Gary.

 So 4 +1s.

 Stephen, Niall, Paul, Phil, Sebb, James - nudge to consider voting
 (apologies if I missed anyone else who has committed to Lang 3.0)?

 Hen

 On Fri, Jul 15, 2011 at 12:32 PM, Gary Gregory garydgreg...@gmail.com wrote:
 That's true too. In the spirit of release early, release often, I remove my
 -1 :)

 Gary


 On Fri, Jul 15, 2011 at 10:54 AM, Henri Yandell flame...@gmail.comwrote:

 Less that it is painful (though I agree that it is), more that if you
 hold up a release for every bug that comes in then you continually sit
 in a non-releasing state. We have a really bad habit of that in
 Commons, constantly polishing and polishing before a release.

 Hen

 On Fri, Jul 15, 2011 at 6:58 AM, Gary Gregory garydgreg...@gmail.com
 wrote:
  Here is my main issue: we are releasing a major new version and there is
 a
  known bug reported by a user which has been fixed in SVN. It feels like
 we
  are unwilling to cut a new RC because our build process and validation
 is
  painful (it is so in my experience at least, your mileage may vary using
  custom scripts, Nexus, or other incantations.) This is not a good reason
 IMO
  to avoid rebuilding. In the case of a major release like 3.0, I do not
 want
  to leave a bad taste in a user's mouth with a class that is not fully
 baked,
  especially in code new to 3.0. I like that we are planning a 3.0.1, but
 I do
  not see why we should not include something that is already fixed for
 3.0.
  It's not like this issue needs more time on investigating, coding, and
  testing.
 
  Now, if you all really think I am being unreasonable, I'll be happy to
 go
  with the flow and reverse -1, but for now, I wanted to express my full
 POV.
 
  Thank you for reading and talking :)
 
  Gary
 
  On Fri, Jul 15, 2011 at 3:44 AM, Henri Yandell flame...@gmail.com
 wrote:
 
  Waiting on you to determine whether your -1 is still there on LANG-720.
 
  Then need to poke Niall, Stephen et al to do a review :)
 
  On Thu, Jul 14, 2011 at 11:54 AM, Gary Gregory garydgreg...@gmail.com
 
  wrote:
   -1, let's pick up the committed fix for
   https://issues.apache.org/jira/browse/LANG-720
  
   I recall seeing traffic in the escape/unescape area so it makes sense
 to
   polish this new code as much as possible IMO.
  
   Gary
  
   On Thu, Jul 14, 2011 at 12:47 AM, Henri Yandell flame...@gmail.com
   wrote:
  
   Lang is ready to consider 3.0 release again.
  
   RC4 is available here:
  
    http://people.apache.org/~bayard/commons-lang3-3.0-RC4/
  
   SVN:
  
  
 http://svn.apache.org/repos/asf/commons/proper/lang/tags/LANG_3_0_RC4/
  
   Maven artifacts:
  
    http://people.apache.org/~bayard/commons-lang3-3.0-RC4/maven/
  
   Website:
  
    http://people.apache.org/~bayard/commons-lang3-3.0-RC4/site/
  
   Note that there is a 2.6-3.0 Clirr report in the site that may
 prove
   useful:
  
  
  
  
 http://people.apache.org/~bayard/commons-lang3-3.0-RC4/site/lang2-lang3-clirr--report.html
  
   This vote will close no sooner than in 72 hours time, 0500 GMT 16
 July
   2011.
  
   
    [ ] +1
    [ ] -1, with reason
   
  
   Hen
  
   *fingers crossed - two of my children are younger than the Lang 3.0
   effort*
  
  
 -
   To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
   For additional commands, e-mail: dev-h...@commons.apache.org
  
  
  
  
   --
   Thank you,
   Gary
  
   http://garygregory.wordpress.com/
   http://garygregory.com/
   http://people.apache.org/~ggregory/
   http://twitter.com/GaryGregory
  
 
 
 
  --
  Thank you,
  Gary
 
  http://garygregory.wordpress.com/
  http://garygregory.com/
  http://people.apache.org/~ggregory/
  http://twitter.com/GaryGregory
 




 --
 Thank you,
 Gary

 http://garygregory.wordpress.com/
 http://garygregory.com/
 http://people.apache.org/~ggregory/
 http://twitter.com/GaryGregory




 --
 Thank you,
 Gary

 http://garygregory.wordpress.com/
 http://garygregory.com/
 http://people.apache.org/~ggregory/
 http://twitter.com/GaryGregory


 -
 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: [VOTE] [LANG] Release Commons Lang 3.0 (based on RC4)

[Stephen Colebourne]

StringEscapeUtils test includes IOUtils, which it shouldn't. (If its
been added as a dependency, then it needs to be removed, even for
testing)

Stephen

On 18 July 2011 23:41, Gary Gregory garydgreg...@gmail.com wrote:
 On Jul 18, 2011, at 18:36, Stephen Colebourne scolebou...@joda.org wrote:

 I'm willing to vote +1
 Although I haven't checked every recent change, but AFAIK recent
 changes have been minor and my previous issues are resolved.

 I would note that the svn as of right now does not compile, due to an
 IOUtils reference that shouldn't be

 Hi Stephen,

 Can you specify what your error is? I check both the maven and ant
 builds before my commit.

 Gary


 Stephen


 On 16 July 2011 01:18, Henri Yandell flame...@gmail.com wrote:
 Thanks Gary.

 So 4 +1s.

 Stephen, Niall, Paul, Phil, Sebb, James - nudge to consider voting
 (apologies if I missed anyone else who has committed to Lang 3.0)?

 Hen

 On Fri, Jul 15, 2011 at 12:32 PM, Gary Gregory garydgreg...@gmail.com 
 wrote:
 That's true too. In the spirit of release early, release often, I remove my
 -1 :)

 Gary


 On Fri, Jul 15, 2011 at 10:54 AM, Henri Yandell flame...@gmail.comwrote:

 Less that it is painful (though I agree that it is), more that if you
 hold up a release for every bug that comes in then you continually sit
 in a non-releasing state. We have a really bad habit of that in
 Commons, constantly polishing and polishing before a release.

 Hen

 On Fri, Jul 15, 2011 at 6:58 AM, Gary Gregory garydgreg...@gmail.com
 wrote:
 Here is my main issue: we are releasing a major new version and there is
 a
 known bug reported by a user which has been fixed in SVN. It feels like
 we
 are unwilling to cut a new RC because our build process and validation
 is
 painful (it is so in my experience at least, your mileage may vary using
 custom scripts, Nexus, or other incantations.) This is not a good reason
 IMO
 to avoid rebuilding. In the case of a major release like 3.0, I do not
 want
 to leave a bad taste in a user's mouth with a class that is not fully
 baked,
 especially in code new to 3.0. I like that we are planning a 3.0.1, but
 I do
 not see why we should not include something that is already fixed for
 3.0.
 It's not like this issue needs more time on investigating, coding, and
 testing.

 Now, if you all really think I am being unreasonable, I'll be happy to
 go
 with the flow and reverse -1, but for now, I wanted to express my full
 POV.

 Thank you for reading and talking :)

 Gary

 On Fri, Jul 15, 2011 at 3:44 AM, Henri Yandell flame...@gmail.com
 wrote:

 Waiting on you to determine whether your -1 is still there on LANG-720.

 Then need to poke Niall, Stephen et al to do a review :)

 On Thu, Jul 14, 2011 at 11:54 AM, Gary Gregory garydgreg...@gmail.com

 wrote:
 -1, let's pick up the committed fix for
 https://issues.apache.org/jira/browse/LANG-720

 I recall seeing traffic in the escape/unescape area so it makes sense
 to
 polish this new code as much as possible IMO.

 Gary

 On Thu, Jul 14, 2011 at 12:47 AM, Henri Yandell flame...@gmail.com
 wrote:

 Lang is ready to consider 3.0 release again.

 RC4 is available here:

  http://people.apache.org/~bayard/commons-lang3-3.0-RC4/

 SVN:


 http://svn.apache.org/repos/asf/commons/proper/lang/tags/LANG_3_0_RC4/

 Maven artifacts:

  http://people.apache.org/~bayard/commons-lang3-3.0-RC4/maven/

 Website:

  http://people.apache.org/~bayard/commons-lang3-3.0-RC4/site/

 Note that there is a 2.6-3.0 Clirr report in the site that may
 prove
 useful:




 http://people.apache.org/~bayard/commons-lang3-3.0-RC4/site/lang2-lang3-clirr--report.html

 This vote will close no sooner than in 72 hours time, 0500 GMT 16
 July
 2011.

 
  [ ] +1
  [ ] -1, with reason
 

 Hen

 *fingers crossed - two of my children are younger than the Lang 3.0
 effort*


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




 --
 Thank you,
 Gary

 http://garygregory.wordpress.com/
 http://garygregory.com/
 http://people.apache.org/~ggregory/
 http://twitter.com/GaryGregory




 --
 Thank you,
 Gary

 http://garygregory.wordpress.com/
 http://garygregory.com/
 http://people.apache.org/~ggregory/
 http://twitter.com/GaryGregory





 --
 Thank you,
 Gary

 http://garygregory.wordpress.com/
 http://garygregory.com/
 http://people.apache.org/~ggregory/
 http://twitter.com/GaryGregory




 --
 Thank you,
 Gary

 http://garygregory.wordpress.com/
 http://garygregory.com/
 http://people.apache.org/~ggregory/
 http://twitter.com/GaryGregory


 -
 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

Re: [graph collections] Fibonacci Heap implementation

[Stephen Colebourne]

I think from the quiet reply its apparent that [collections] is pretty
quiet these days. I think [collections] development must focus first
on a release of a Java 5 version of what it has, rather than new code.
Stephen

On 14 July 2011 01:19, Simone Tripodi simonetrip...@apache.org wrote:
 Hi all guys,
 in order to improve graph algorithms performances, I started
 implementing in [graph] an advanced priority queue called Fibonacci
 Heap[1], based on detailed description of University of Science and
 Technology of China's lessons[2].
 You can find initial implementation on 'collections'[3] package in
 [graph] (sandbox) - it is still a little bugged, indeed A* and
 Dijkstra implementations are working with it while Prim  Kruskal, not
 - but I think that it could be added in [collections] once completed
 (I'm trying to implement it as java.util.Queue).
 Is there anyone from [collections] interested on that topic that wants
 to join efforts?
 TIA, all the best!!!
 Simo

 [1] http://en.wikipedia.org/wiki/Fibonacci_heap
 [2] http://staff.ustc.edu.cn/~csli/graduate/algorithms/book6/chap21.htm
 [3] 
 https://svn.apache.org/repos/asf/commons/sandbox/graph/trunk/src/main/java/org/apache/commons/graph/collections

 http://people.apache.org/~simonetripodi/
 http://www.99soft.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: [lang] RC4 heads up

[Stephen Colebourne]

On 12 July 2011 18:56, Jörg Schaible joerg.schai...@gmx.de wrote:
 1/ FastDateFormat
 The date format  yyy yy y is formatted with JDK 7 as 2003 2003 03
 2003 instead of 2003 03 03 03. So, should FastDateFormat follow the JDK
 in any case and adjust its result according the runtime? Interestingly
 Javadoc states already for Java 6: For formatting, if the number of pattern
 letters is 2, the year is truncated to 2 digits; otherwise it is interpreted
 as a number.

I think that since this release is not compatible with previous
releases, then [lang] should follow JDK 7 conventions only, with good
javadoc about what it does.

Stephen

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

[lang] Contexted exception [Re: [lang] Time for RC3?]

[Stephen Colebourne]

On 7 July 2011 00:57, Jörg Schaible joerg.schai...@gmx.de wrote:
 Proposed changes done. Please review, especially also Javadoc as I'm a non-
 native speaker.

Done. I think you could remove the add/set methods taking a Pair. The
other add/set methods taking two arguments is sufficient, and I can't
see when the Pair one would be used.

Stephen

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

Re: [lang] Contexted exception [Re: [lang] Time for RC3?]

[Stephen Colebourne]

On 7 July 2011 11:48, Jörg Schaible joerg.schai...@scalaris.com wrote:
 One last opinion about the output? Originally we had e.g.:

  [Handler = PersonConverter]
  [Current Element = Person]
  [Role = COO]
  [Handler[1] = CompanyConverter]
  [Current Element[1] = Company]

 The current output does no longer have the [1] numbering at the keys.
 However, I wonder if the plain output sequence is now enough for easy
 analysis, whether I should add those indexes again (for the formatted
 message only) or should add an additional element numbering e.g. like:

  [1:Handler = PersonConverter]
  [2:Current Element = Person]
  [3:Role = COO]
  [4:Handler = CompanyConverter]
  [5:Current Element = Company]

The default message should probably have numbering as per  [1:Handler
= PersonConverter]
Stephen

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

Re: [lang] Time for RC3?

[Stephen Colebourne]

On 4 July 2011 23:13, Jörg Schaible joerg.schai...@gmx.de wrote:
 Sorry, why is setValue more vague - isn't it the other way round?
As a method name, replace is explicit, set slightly less so. Either
work here, so if you want to change it go ahead.

More generally, I now think the index suffix scheme is wrong. It
should collect a list of data for the same key, because otherwise you
can't look up the data later (as the key has been silently changed
behind your back). API methods:

ListString getValues(String key)
String getFirstValue(String key)

If its pluggable then an alternative implementation could not use a
list and only keep the first or last value. The default implementation
should keep all the values.

Stephen

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

Re: [lang] Time for RC3?

[Stephen Colebourne]

On 6 July 2011 09:52, Jörg Schaible joerg.schai...@scalaris.com wrote:
 I can traverse now the set of keys to get this list when it is internally
 implemented with a LinkedHashMap. Remember, one important element of a
 contexted exception is a more informational and structured message. In the
 list above I can see quite immediately where the problem is and in which way
 the application flow failed. Any idea how we could improve the API to
 support this with an implementation? Something like:

  ListPairString, Object getEntries();

This could be the main API with convenience methods for
getFirstValue() and getValues(). You would store data internally in
this format, not as a map. Lookups by key are then O(n) but that is
unlikely to be a problem in exceptional code.

Stephen

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

Re: [lang] Time for RC3?

[Stephen Colebourne]

On 6 July 2011 21:45, Jörg Schaible joerg.schai...@gmx.de wrote:
 Since the ExceptionContext is especially designed for an exception mix-in, I
 wonder if we better use more qualifying names for this use case:

 interface ExceptionContext {
  addContextValue(...);
  setContextValue(...);
  getContextValues(...);
 ...
 };

 Opinions?

Yes. It needs to be the longer names for clarity.
Stephen

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

Re: [lang] Time for RC3?

[Stephen Colebourne]

On 3 July 2011 22:04, Gary Gregory garydgreg...@gmail.com wrote:
 * Email thread - what else should implement Formattable?

 I would look at this differently to get 3.0 out the door: Let's make
 sure we do not make anything Formattable that we might have to back
 out later.

Currently, nothing implements Formattable. Two classes (Range and
Pair) use Formattable as an optional toString() form.

I see this as NO ACTION for [lang] 3.0

Stephen

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

Re: [lang] Time for RC3?

[Stephen Colebourne]

On 3 July 2011 19:07, Gary Gregory garydgreg...@gmail.com wrote:

 http://markmail.org/message/ml7efpvqezysvs2p?q=Validate+list:org%2Eapache%2Ecommons%2Edev/

 Since this has gone quiet, I was going to follow through and rename the
 validate* method (which are all @since 3.0) to check*. Someone else like it
 it ;)

 But have two different verbs is smelly: Validate.check*(), As I mention in
 the thread, a validator validates a state, so I like best:
 Validator.validate*().

 But changing an existing class name seems more controversial and possibly
 more trouble than it is worth. If it were just up to me, I would just bite
 the bullet and do it for the sake of nice and pretty, but I am concerned
 about downstream users.

I have reviewed Validate, and am happy with it as currently written.
It is also widely used, so I would recommend against change.

It is an assertion class to replace the assert keyword in Java. The
class name and method names all read OK in that context.

Stephen

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

Re: [lang] Time for RC3?

[Stephen Colebourne]

On 2 July 2011 15:28, Jörg Schaible joerg.schai...@gmx.de wrote:
 Can somebody else give the ContextedException stuff a review? I used in the
 meanwhile a copy of it in a project, but a method name is bugging me.

The structure looks reasonable to me.

While you could rename replaceValue() to setValue(), I don't see that
change as essential. replaceValue() is utterly clear about what it
will do, whereas setValue() is slightly more vague. So, I think I'd
just leave it as is.

Stephen

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

Re: [DISCUSS] codebase looking for a place to be contributed to commons

[Stephen Colebourne]

I've used scannotation before, which is reasonably well known I
believe, but could probably be improved on. I think with multiple
versions at Apache, it is a perfect concept for commons. I would check
out [discovery] first to see if that has a similar goal.

I'd set it up separately to [lang] first, to see how big it is. It
feels a little frameworky, but may be suitable for inclusion.

I also think that we should look to include ideas from the old [id]
project into [lang], as [id] is never going to be released.

Stephen


On 10 June 2011 06:19, Ralph Goers ralph.go...@dslextreme.com wrote:

 On Jun 9, 2011, at 1:29 PM, Simone Tripodi wrote:

 Hi all guys,
 before start working on Digester3 I experimented on GitHub, taking
 inspiration from Google Guice APIs, embedded EDSLs in configuration
 classess to solve 2 different kind of problems:

 * ClassPath scanning[1]: declare with fluent APIs a class path
 scanner, filering classes users are interested in via fluent logic
 language, and declaring actions have to be performed, once interested
 classes have found. We already discussed about that idea time ago, but
 it has been improved;

 * Class scanning[2]: Java users often create framework/libraries
 based on Java5 MetaData Annotations interpreted at runtime, the
 pattern they usually have to apply is: given a class, visiting all the
 class inheritance hierarchy, and getting fields/constructors/methods
 for each class; once found an (AnnotatedElement, Annotation) pair,
 they have to perform an action.
 So, the implemented classes aim to reduce the boilerplate and
 redundant code simply by declaring actions that have to be performed
 once the pairs  (AnnotatedElement, Annotation) are found.


 I accomplished this in the work I've been doing on Log4J 2.0 by borrowing on 
 some code I found somewhere else at Apache. You can see it at 
 https://svn.apache.org/repos/asf/logging/log4j/branches/BRANCH_2_0_EXPERIMENTAL/rgoers/log4j2-core/src/main/java/org/apache/logging/log4j/core/config/plugins/ResolverUtil.java.
  It is used by 
 https://svn.apache.org/repos/asf/logging/log4j/branches/BRANCH_2_0_EXPERIMENTAL/rgoers/log4j2-core/src/main/java/org/apache/logging/log4j/core/config/plugins/PluginManager.java.

 Of course, I have no idea if these bear any relationship to what you have 
 done.

 Ralph



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

Re: svn commit: r1127546 - in /commons/proper/lang/trunk/src: main/java/org/apache/commons/lang3/tuple/Pair.java test/java/org/apache/commons/lang3/text/FormattableUtilsTest.java

[Stephen Colebourne]

The discussion threads ended with both th notion that Formattable was
adding no value and final was best added for safety. I checked before
making the change.
Feel free to propse alternatives...
Stephen

On 25 May 2011 15:48, Matt Benson gudnabr...@gmail.com wrote:
 Way to make unilateral decisions in the name of progress, Stephen!  ;P

 Matt

 On Wed, May 25, 2011 at 9:44 AM,  scolebou...@apache.org wrote:
 Author: scolebourne
 Date: Wed May 25 14:44:04 2011
 New Revision: 1127546

 URL: http://svn.apache.org/viewvc?rev=1127546view=rev
 Log:
 Remove Formattable from Pair

 Modified:
    
 commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/tuple/Pair.java
    
 commons/proper/lang/trunk/src/test/java/org/apache/commons/lang3/text/FormattableUtilsTest.java

 Modified: 
 commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/tuple/Pair.java
 URL: 
 http://svn.apache.org/viewvc/commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/tuple/Pair.java?rev=1127546r1=1127545r2=1127546view=diff
 ==
 --- 
 commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/tuple/Pair.java
  (original)
 +++ 
 commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/tuple/Pair.java
  Wed May 25 14:44:04 2011
 @@ -18,12 +18,10 @@ package org.apache.commons.lang3.tuple;

  import java.io.Serializable;
  import java.util.Formattable;
 -import java.util.Formatter;
  import java.util.Map;

  import org.apache.commons.lang3.ObjectUtils;
  import org.apache.commons.lang3.builder.CompareToBuilder;
 -import org.apache.commons.lang3.text.FormattableUtils;

  /**
  * pA pair consisting of two elements./p
 @@ -42,17 +40,12 @@ import org.apache.commons.lang3.text.For
  * @since Lang 3.0
  * @version $Id$
  */
 -public abstract class PairL, R implements Map.EntryL, R, 
 ComparablePairL, R, Formattable, Serializable {
 +public abstract class PairL, R implements Map.EntryL, R, 
 ComparablePairL, R, Serializable {

     /** Serialization version */
     private static final long serialVersionUID = 4954918890077093841L;

     /**
 -     * Basic format pattern.
 -     */
 -    private static final String DEFAULT_FORMAT_STRING = (%1$s,%2$s);
 -
 -    /**
      * pObtains an immutable pair of from two objects inferring the 
 generic types./p
      *
      * pThis factory allows the pair to be created using inference to
 @@ -167,23 +160,14 @@ public abstract class PairL, R impleme
     }

     /**
 -     * pFormat this {@link Pair}.  Basic format is in the form: (L,R)./p
 +     * pFormats the receiver using the given format./p
      *
 -     * @param formatter  the target formatter to append to, not null
 -     * @param flags  the flags for output format, see {@code Formattable}
 -     * @param width  the width of the output, see {@code Formattable}
 -     * @param precision the precision of the output, see {@code Formattable}
 -     */
 -    public void formatTo(Formatter formatter, int flags, int width, int 
 precision) {
 -        FormattableUtils.append(String.format(DEFAULT_FORMAT_STRING, 
 getLeft(), getRight()),
 -                formatter, flags, width, precision);
 -    }
 -
 -    /**
 -     * Formats the receiver using the given string.
 +     * pThis uses {@link Formattable} to perform the formatting. Two 
 variable may
 +     * be used to embed the left and right elements. Use {@code %1$} for 
 the left
 +     * element (key) and {@code %2$} for the right element (value).
 +     * The default format used by {@code toString()} is {@code 
 (%1$s,%2$s)}./p
      *
 -     * @param format  the {@code Formattable} format string, where {@code 
 %1$} is
 -     *  the left element (key) and {@code %2$} is the right element 
 (value), not null
 +     * @param format  the format string, optionally containing {@code %1$} 
 and {@code %2$}, not null
      * @return the formatted string, not null
      */
     public Object toString(String format) {

 Modified: 
 commons/proper/lang/trunk/src/test/java/org/apache/commons/lang3/text/FormattableUtilsTest.java
 URL: 
 http://svn.apache.org/viewvc/commons/proper/lang/trunk/src/test/java/org/apache/commons/lang3/text/FormattableUtilsTest.java?rev=1127546r1=1127545r2=1127546view=diff
 ==
 --- 
 commons/proper/lang/trunk/src/test/java/org/apache/commons/lang3/text/FormattableUtilsTest.java
  (original)
 +++ 
 commons/proper/lang/trunk/src/test/java/org/apache/commons/lang3/text/FormattableUtilsTest.java
  Wed May 25 14:44:04 2011
 @@ -21,7 +21,6 @@ import static org.junit.Assert.assertEqu

  import java.util.Formatter;

 -import org.apache.commons.lang3.tuple.Pair;
  import org.junit.Test;

  /**
 @@ -115,8 +114,4 @@ public class FormattableUtilsTest {
         assertEquals(+*___, FormattableUtils.append(foo, new 
 Formatter(), LEFT_JUSTIFY, 5, 2, '_', +*).toString());
     }

 -    @Test
 -    public void 

Re: [math] [sandbox] merging Apache Commons BSP into Apache Commons Math

[Stephen Colebourne]

On 18 May 2011 09:11, Luc Maisonobe luc.maison...@free.fr wrote:
 Should I replace with one-d, two-d and three-d ?

 Of course this should read: one_d, two_d and three_d ...

In the variety of Java source I've seen, multiple words are scrunched
together, giving oned, twod, threed.

Stephen

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

[lang] Immutable classes (Pair/Range etc)

[Stephen Colebourne]

This issue about what immutable means wrt final on the class has
bounced around a few threads.

In my view, immutable has a specific meaning, whereby the object is
unequivically safe to use and share between threads. To do so, there
are certain rules. One that is disputed is whether the class must be
final. eg. http://www.javapractices.com/topic/TopicAction.do?Id=29

Josh Bloch in Effective Java recommends using final on the class where
possible, but offers the alternative of a private or package scoped
constructor with a public static factory. He does not recommend a
public constructor (even when accompanied by defining all the methods
as final).

The issue arises with a method that takes an ImmutableFoo as an
argument where ImmutableFoo is supposed to be immutable.

  public void doStuff(ImmutableFoo foo) {...}

This author of this method might pass the object to another thread for
processing following the expectation that the class is immutable (from
the class name and/or Javadoc).

But, someone could pass in the following class to that method:

  public EvilFoo extends ImmutableFoo {
public StringBuilder buf;
public EvilFoo(StringBuilder buf) {
  this.buf = buf;
}
  }

The user can now access EvilFoo in multiple threads at the same time.

This problem afflicts BigDecimal and BigInteger. The only way to
safely use those classes (wrt threading) is to write the following:

  public void processNumber(BigDecimal bd) {
if (bd.getClass() != BigDecimal.class) {
  bd = new BigDecimal(bd.toString());  // or some other conversion technique
}

  }

Most users do not do this, so their usage of BigDecimal is not
actually thread-safe (or safe against a clever hack).

Given all the above, we in Commons and [lang] should take the lead,
and only declare something as immutable if it really is - which
generally means final fields and final class.

Stephen

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

Re: [LANG] Is a Range a kind of Pair?

[Stephen Colebourne]

On 18 May 2011 17:46, Matt Benson gudnabr...@gmail.com wrote:
 On Wed, May 18, 2011 at 11:32 AM, Gary Gregory garydgreg...@gmail.com wrote:
 Why doesn't a Range does extend Pair? It's pretty clear (to me at least)
 that a range is a pair of values.

 Because the Pair is in our tuple package, it means that it should follow
 tuple logic and be thought of as an ordered list of elements, in this case
 two elements.

 The methods that Range has that are not in Pair could be moved there.


 IMHO a Range is not precisely a Pair, though it could define its
 _limits_ in those terms.

The combined opinion of all at OpenGamma ($dayjob) is that a Range is
a very different beast to a Pair. Simply because there are two data
points, does not make it a pair :-)

Stephen

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

Re: [lang] Immutable classes (Pair/Range etc)

[Stephen Colebourne]

On 18 May 2011 17:58, Matt Benson gudnabr...@gmail.com wrote:
 On Wed, May 18, 2011 at 11:47 AM, Stephen Colebourne
 scolebou...@joda.org wrote:
 This issue about what immutable means wrt final on the class has
 bounced around a few threads.

 In my view, immutable has a specific meaning, whereby the object is
 unequivically safe to use and share between threads. To do so, there
 are certain rules. One that is disputed is whether the class must be
 final. eg. http://www.javapractices.com/topic/TopicAction.do?Id=29

 Josh Bloch in Effective Java recommends using final on the class where
 possible, but offers the alternative of a private or package scoped
 constructor with a public static factory. He does not recommend a
 public constructor (even when accompanied by defining all the methods
 as final).

 The issue arises with a method that takes an ImmutableFoo as an
 argument where ImmutableFoo is supposed to be immutable.

  public void doStuff(ImmutableFoo foo) {...}

 This author of this method might pass the object to another thread for
 processing following the expectation that the class is immutable (from
 the class name and/or Javadoc).

 But, someone could pass in the following class to that method:

  public EvilFoo extends ImmutableFoo {
    public StringBuilder buf;
    public EvilFoo(StringBuilder buf) {
      this.buf = buf;
    }
  }

 The user can now access EvilFoo in multiple threads at the same time.

 This problem afflicts BigDecimal and BigInteger. The only way to
 safely use those classes (wrt threading) is to write the following:

  public void processNumber(BigDecimal bd) {
    if (bd.getClass() != BigDecimal.class) {
      bd = new BigDecimal(bd.toString());  // or some other conversion 
 technique
    }
    
  }

 Most users do not do this, so their usage of BigDecimal is not
 actually thread-safe (or safe against a clever hack).

 Given all the above, we in Commons and [lang] should take the lead,
 and only declare something as immutable if it really is - which
 generally means final fields and final class.


 I generally agree that this makes sense.  Our ImmutablePair is part of
 the way there in that its left/right _fields_ are final, assigned from
 the single constructor offered.  The only danger points I can
 currently see are the implementations of
 getLeft()/getRight()/setValue().  Now, AIUI, Gary's interest in
 extending ImmutablePair is overriding stuff like toString().  Can we
 satisfy everyone by making these methods final, such that an
 ImmutablePair will behave as Stephen recommends, while permitting
 subclasses to perform unrelated operations?

See the EvilFoo example above. Any ability to subclass, even with safe
methods, means its not completely thread-safe.

Stephen

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

Re: [lang] Immutable classes (Pair/Range etc)

[Stephen Colebourne]

On 18 May 2011 18:09, Stephen Colebourne scolebou...@joda.org wrote:
 See the EvilFoo example above. Any ability to subclass, even with safe
 methods, means its not completely thread-safe.

More info:

StringBuilder evilBuf = new StringBuilder();
EvilFoo evilFoo = new EvilFoo(evilBuf);

doStuff(evilFoo);
// evilFoo has now been passed to another thread/queued/somewhere else entirely

evilBuf.append(Shared object);
// this append is being done on an object that had been shared between
two threads
// that is a Bad Thing, although it only affects the caller here

I'm sure there are worse things that can be done here too. For
example, the end consumer of the evilFoo in another thread might
access the buffer (via a cast or reflection). Or the subclass might do
something during serialization/deserialization when it could change
the stored values, completely invalidating the original object.

So, making the supplied methods final helps (its a minimum), making
the class final really goes to avoid a whole slew of potential issues.
Safety by design.

Stephen

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

Re: [VOTE] [LANG] Release Commons Lang 3.0 (based on RC3)

[Stephen Colebourne]

(review now back from holiday)

-1

I'm unhappy with the change in FastDateFormat from new
GregorianCalendar() to Calendar.getInstance(). This will pick up
alternate calendar systems based on the default locale, and probably
mess up the rest of the code which I expect relies on it being
gregorian.  (DONE in SVN)

I'm still looking for ImmutablePair to be final too, but perhaps I
missed the conclusion of that debate... (NOT DONE in SVN)

I also made some minor javadoc changes.

Stephen



On 29 April 2011 07:47, Henri Yandell flame...@gmail.com wrote:
 Lang is ready to consider 3.0 release again.

 RC3 is available here:

  http://people.apache.org/~bayard/commons-lang3-3.0-RC3/

 Maven artifacts:

  http://people.apache.org/~bayard/commons-lang3-3.0-RC3/maven/

 Website:

  http://people.apache.org/~bayard/commons-lang3-3.0-RC3/site/

 Note that there is a 2.6-3.0 Clirr report in the site that may prove useful:

  http://people.apache.org/~bayard/commons-lang3-3.0-RC3/site/lang2-lang3-clirr--report.html

 This vote will close no sooner than in 72 hours time, 0700 GMT 2-May 2011.

 
   [ ] +1
   [ ] -1, with reason
 

 Hen

 -
 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: FormattableUtils

[Stephen Colebourne]

So

While I can see the benefits of toString(String format), I'm
struggling to understand what formatTo(...) gains Pair.

I've added a test (in svn), and removed the Formattable interface from
Pair (not in svn), and get the same output, so implementing
Formattable appears to be pointless to me.

I am happy to retain FormattableUItils.

(needs to be decided pre release)

Stephen




On 25 April 2011 21:40, Matt Benson gudnabr...@gmail.com wrote:
 On Mon, Apr 25, 2011 at 8:39 AM, Matt Benson gudnabr...@gmail.com wrote:
 On Mon, Apr 25, 2011 at 2:17 AM, Henri Yandell flame...@gmail.com wrote:
 On Fri, Apr 22, 2011 at 11:32 PM, Henri Yandell flame...@gmail.com wrote:
 On Fri, Apr 22, 2011 at 8:58 AM, Gary Gregory garydgreg...@gmail.com 
 wrote:
 On Fri, Apr 22, 2011 at 9:58 AM, Matt Benson gudnabr...@gmail.com wrote:

 On Fri, Apr 22, 2011 at 8:56 AM, Gary Gregory garydgreg...@gmail.com
 wrote:
  Hi All:
 
  Now that we have the shiny and new FormattableUtils class, what are the
  other opportunities in [lang] to eat our own dog food?
 

 What did you have in mind?


 I am just wondering what other [lang] classes should be Formattable.
 StopWatch for example?

 Having hijacked the thread; possible Formattables that jump out:

 Fraction
 Range
 StopWatch
 The Mutables (or maybe Formatter knows special things about Number already)
 BitField

 So I think the full potential list is the above plus StrBuilder,
 CharSet and JavaVersion.

 I'm not sure if it makes sense for each; but those are our current
 custom business objects.

 I'm scratching my head over Pair a bit though. What benefit did we add
 by implementing Formattable? My off-hand comment was hoping we would
 replace Gary's need to have his own subclass just to change the
 format, but he still needs that.


 I don't know of any way to use the Formattable interface to accomplish
 what you suggest, hence my initial confused comment.  Having gone back
 to reread the Javadoc examples, I concluded your intent was that if we
 were going to provide custom interactivity with the formatter APIs we
 should do it in a way conforming to the design of those classes.  The
 current example does this, but--you are correct--returns us to the
 state of affairs wherein a subclass is needed to customize an object's
 format.

 I'm also not sure of the benefit of FormattableUtils.append. We pass a
 CharSequence in and do much what the JDK would do on the toString?

 If you look at the Formattable API and example implementation in the
 class javadoc, the takeaway is that every Formattable implementation
 must handle width (number of characters to fill), precision (maximum
 width of meaningful data), and justification (provided simply as
 pad-left or, by exclusion, -right).  It was my feeling that 95% of
 implementations would therefore embed redundant code, with the main
 potential for divergence (due to their being unspecified by the
 interface) being the pad character used, and the form taken by the
 ellipsis when the meaningful output overflows the specified
 precision.  For this reason I extracted FormattableUtils.append to
 handle what I saw as the redundant part of implementing Formattable.
 This strikes me as a perfect fit for [lang].  Note that the way in
 which I am *least* satisfies with this method's implementation is
 that, like the example in Formattable's javadoc,
 Formatter.format(CharSequence) is called as part of the
 implementation.  I would have preferred the implementation to write
 directly to the Formatter's Appender; however I could find no
 specification as to how to handle any theoretically encountered
 IOExceptions, which are somehow swallowed by Formatter.format().  I
 therefore opted for consistency by virtue of dropping back into the
 formatter APIs as suggested by the designers (I personally think this
 is a somewhat flawed design at least in this respect).


 It almost feels that we need to add our own Formattable interface, but
 instead of formatTo we would have toString(String format). That's a
 weak API though. Users can't dictate whether the left or right comes
 first for the Pair example, they're stuck with left then right. The
 'better' solution is to have a PairFormat class that has its own
 custom pattern language (%L and %R etc).

 It does seem as though the old Format APIs might be more appropriate
 to custom formatting.  My hesitation there is that most often you're
 going to encounter the situation where you're providing a
 self-consciously incomplete implementation because what you can
 format, you can't necessarily parse.


 What am I missing?

 Currently I feel that we can dump FormattableUtils

 I hope I've explained why I feel #append is useful.  Further, if you
 agree with the idea that it would be predictable for a Formattable to
 use its own basic format as its toString(), providing a quick
 shorthand to format a Formattable to a string seems like a harmless
 opportunity to eliminate boilerplate; hence,