Re: [CSV] CSVMutableRecord

2017-08-17 Thread Simon Spero 
On Aug 15, 2017 8:01 PM, "Gilles"  wrote:

Saying that making record mutable is "breaking" is a bit unfair when we do
> NOT document the mutability of the class in the first place.
>

I'm stating a fact: class is currently immutable, change would make it
mutable; it is functionally breaking.
I didn't say that you are forbidden to do it; just that it would be unwise,
particularly if it would be to save a few bytes.


Exactly.

TL;DR. This is almost always a breaking semantic change; the safest  ways
of implementing it are binary breaking; it's unlikely to have a major
performance impact; it might be better to create a new API module for
enhancements, with current package as legacy or implementation.

If a class previously exposed no mutators, adding one is usually a major
change. This is especially true for final classes, but it still affects use
cases where an instance is owned by another class, which may rely on the
lack of mutability to avoid making defensive copies.
Of course, a final class that has a  package-private getter  to a shared
copy of its backing array could be considered to be sending mixed
messages...

It is possible that a mutable class might have significant performance
advantages over an immutable one beyond saving a few bytes. For example, if
the updates are simple, and depend on the previous value of the cell, then
a mutable version might have better cache behavior. If there's other
sources of cache pressure this might have a higher than expected impact.
The costs of copying the original values might also be relatively
significant.

For an ETL use case these issues are unlikely to be limiting factors; for a
start, there's a non-zero chance that a  CSVRecord was extracted  by
parsing a CSV file. Also a transform will require conversion to some sort
of Number (or String allocation).

The current API doesn't easily support adding alternate implementations of
the relevant types. Implementation classes are final, and important  return
types are concrete.

One solution might be to treat the current code as almost an implementation
module, define a separate API module, and add extra interfaces and
alternate  implementations to support  the target use case (mutable
records, streams, reactivex, transform functions or what have you).

Simon

Re: [CSV] CSVMutableRecord

2017-08-17 Thread Gary Gregory 
Not yet ;-)

On Aug 17, 2017 11:34, "nitin mahendru"  wrote:

> Hi All,
>
> Any consensus on this ?
>
> -Nitin
>
>
>
>
> On Tue, Aug 15, 2017 at 4:43 PM Gary Gregory 
> wrote:
>
> > On Tue, Aug 15, 2017 at 5:32 PM, Gilles 
> > wrote:
> >
> > > On Tue, 15 Aug 2017 22:52:32 +, nitin mahendru wrote:
> > >
> > >> On Tue, 15 Aug 2017 12:02:20 -0600, Gary Gregory wrote:
> > >>
> > >>> On Tue, Aug 15, 2017 at 10:38 AM, nitin mahendru
> > >>>  > >>>
> >  wrote:
> > 
> > >>>
> > >>> How about having a state in the class itself which says that it's
> >  mutable
> >  or not.
> >  If we call a setter on an immutable then it throws an exception.
> >  By default the records are immutable and you need to make them
> >  mutable
> >  using a new API.
> > 
> > >>>
> > >> A code example would be useful...
> > >>
> > >>
> > >>
> > >>
> > >> Below is the pull request I added.
> > >> https://github.com/apache/commons-csv/pull/21
> > >>
> > >
> > > As I indicated in the previous message, this is functionally
> > > breaking. [I'm diverting this discussion over to the "dev"
> > > mailing list.]
> > >
> >
> > Saying that making record mutable is "breaking" is a bit unfair when we
> do
> > NOT document the mutability of the class in the first place.
> >
> > Gary
> >
> >
> > >
> > > The following should be an interesting read:
> > >   http://markmail.org/message/6ytvmxvy2ndsfp7h
> > >
> > >
> > > Regards,
> > > Gilles
> > >
> > >
> > >
> > >
> > >> On Tue, Aug 15, 2017 at 11:17 AM Gilles  >
> > >> wrote:
> > >>
> > >> On Tue, 15 Aug 2017 12:02:20 -0600, Gary Gregory wrote:
> > >>> > On Tue, Aug 15, 2017 at 10:38 AM, nitin mahendru
> > >>> >  > >>> >> wrote:
> > >>> >
> > >>> >> How about having a state in the class itself which says that it's
> > >>> >> mutable
> > >>> >> or not.
> > >>> >> If we call a setter on an immutable then it throws an exception.
> > >>> >> By default the records are immutable and you need to make them
> > >>> >> mutable
> > >>> >> using a new API.
> > >>>
> > >>> A code example would be useful...
> > >>>
> > >>> >> pros: Saves memory, Keeps the immutability benefits
> > >>>
> > >>> What kind of usage are you considering that a single transient
> > >>> record matters (as compared to the ~300 MB of the JVM itself...)?
> > >>>
> > >>> >> cons: people using "mutable" records need to be careful.(While
> > >>> >> threading
> > >>> >> maybe)
> > >>> >>
> > >>> >
> > >>> > Interesting idea!
> > >>> >
> > >>> > But I think I like the idea of a subclass better if we are going to
> > >>> > split
> > >>> > the behavior b/w mutable and immutable.
> > >>>
> > >>> Once you have a subclass that is able to modify the state of
> > >>> its parent, it's a mutable object. Period.
> > >>> There is no such thing as a "split".
> > >>>
> > >>> >
> > >>> > For my money and the KISS principle, I would just add the put
> method
> > >>> > in
> > >>> > CSVRecord.
> > >>>
> > >>> Then, any use that assumes immutability will be broken.
> > >>>
> > >>>
> > >>> Gilles
> > >>>
> > >>>
> > >>> > Gary
> > >>> >
> > >>> >>
> > >>> >> -Nitin
> > >>> >>
> > >>> >>
> > >>> >>
> > >>> >>
> > >>> >> On Tue, Aug 15, 2017 at 9:01 AM Gilles
> > >>> >> 
> > >>> >> wrote:
> > >>> >>
> > >>> >> > On Tue, 15 Aug 2017 09:49:04 -0600, Gary Gregory wrote:
> > >>> >> > > That looks odd to me. What comes up for me is the use case
> where
> > >>> >> I
> > >>> >> > > want to
> > >>> >> > > ETL a file of 10,000,000 records and update, say, one column.
> If
> > >>> >> am
> > >>> >> > > forced
> > >>> >> > > to create a brand new record for every record read, that would
> > >>> >> be a
> > >>> >> > > shame.
> > >>> >> >
> > >>> >> > Why?
> > >>> >> >
> > >>> >> > > If I had a mutable record, I could just keep on updating it
> and
> > >>> >> using
> > >>> >> > > it to
> > >>> >> > > write each row. Read record, update it, write record. No extra
> > >>> >> memory
> > >>> >> > > needed.
> > >>> >> >
> > >>> >> > How is the size of 1 additional record going to matter compared
> to
> > >>> >> the
> > >>> >> > size of the whole program?
> > >>> >> >
> > >>> >> > > Either we can make the current record mutable (what's the
> harm?)
> > >>> >> or
> > >>> >> > > we can
> > >>> >> > > make the parser serve out mutable records based on a config
> > >>> >> setting.
> > >>> >> > > This
> > >>> >> > > could be a subclass of CSVRecord with the extra method I
> > >>> >> proposed.
> > >>> >> >
> > >>> >> > The harm is that you loose all the promises of immutability.
> > >>> >> >
> > >>> >> > Regards,
> > >>> >> > Gilles
> > >>> >> >
> > >>> >> > >
> > >>> >> > > Thoughts?
> > >>> >> > >
> > >>> >> > > Gary
> > >>> >> > >
> > >>> >> > > On Tue, Aug 15, 2017 at 8:33 AM, Gilles
> > >>> >> > > 
> > >>> >> > > wrote:
> >

[ANNOUNCE] Apache Commons JCS 2.2 Released

2017-08-17 Thread Thomas Vandahl 
The Apache Commons Team is pleased to announce the availability of:

Apache Commons JCS 2.2

Apache Commons JCS is a distributed, versatile caching system.

The release notes can be reviewed at:
http://www.apache.org/dist/commons/jcs/RELEASE-NOTES.txt

Distribution packages can be downloaded from:
https://commons.apache.org/proper/commons-jcs/download_jcs.cgi

When downloading, please verify signatures using the KEYS file available
at:
http://www.apache.org/dist/commons

More information and comprehensive documentation is available at:
https://commons.apache.org/proper/commons-jcs/

Maven artifacts are also available in the central Maven repository:
http://repo1.maven.org/maven2/org/apache/commons/

The Apache Commons Team


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

Re: [All] Jenkins nonsense (?)

2017-08-17 Thread Gilles 

On Thu, 17 Aug 2017 08:56:51 -0500, Brent Worden wrote:
The last success in the build log indicates the last execution of 
Maven was

successful and not that the entire Jenkins build was successful.

Sprinkled throughout the build log are messages of the form 'Skipping
reporter since build result is FAILURE.'  The first such message 
appeared

shortly after the first occurrence of:
[CHECKSTYLE] Successfully parsed file

/home/jenkins/jenkins-slave/workspace/Commons_RNG__Java8/target/checkstyle-result.xml
of module Apache Commons RNG with 0 unique warnings and 0 duplicates.
java.io.EOFException
at java.io.DataInputStream.readInt(DataInputStream.java:392)
at

java.io.ObjectInputStream$BlockDataInputStream.readInt(ObjectInputStream.java:3139)
at java.io.ObjectInputStream.readInt(ObjectInputStream.java:1023)
at 
com.google.common.collect.Serialization.readCount(Serialization.java:50)
at 
com.google.common.collect.HashMultimap.readObject(HashMultimap.java:134)

at sun.reflect.GeneratedMethodAccessor15682.invoke(Unknown Source)

[PMD] Skipping reporter since build result is FAILURE

So, the build if failing trying to either generate the checkstyle 
report or

generate the PMD report.  I say this because it is not clear from the
exception what Maven stage is actually running at the moment of 
failure.
Adding --debug to the Maven command might provide better insight into 
the

actual cause.


With "--debug" option:
  
https://builds.apache.org/view/A-D/view/Commons/job/Commons_RNG__Java8/52/console



Gilles




Brent

On Thu, Aug 17, 2017 at 7:38 AM, Gilles 


wrote:


Hello.

Does someone know why Jenkins reports a build as "Failed" while
the last line of the console output is:
---CUT---
Finished: SUCCESS
---CUT---

See e.g.
  https://builds.apache.org/view/A-D/view/Commons/job/Commons_
RNG__Java8/50/console

Note that for the same code Jenkins reports success in another job:
  https://builds.apache.org/view/A-D/view/Commons/job/Commons_
Rng/138/console

The only (intended) difference is "Java 8" vs "Java 6".


Regards,
Gilles




-
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"?

2017-08-17 Thread Rob Tompkins 
+1 with the thought of Benedikt's point about trying to lift one project at a 
time. 

> On Aug 17, 2017, at 11:15 AM, Jörg Schaible  
> wrote:
> 
> +1
> 
> Looks good to me.
> 
> Gilles wrote:
> 
>> Hello.
>> 
>> [Time for a new episode in our "Ripping CM" series.]
>> 
>> How about creating "Commons Geometry"?
>> 
>> The rationale is comprised of the usual suspects:
>>  * Smaller and more focused component, hence:
>>- Consistent development and maintenance.
>>- Consistent release schedule, not encumbered by
>>  changes (and endless discussions) in _totally_
>>  unrelated code.
>>- Potential for attracting contributors not
>>  interested in maintaining the (growing) backlog
>>  of CM.
>>  * Self-contained: 96.3% of the "o.a.c.math4.geometry"
>>package have no dependency except:
>>- 4 classes now in "Commons Numbers".
>>- 2 methods and 1 constant in "MathUtils".
>>- CM exceptions. [Creating alternatives for those
>>  will probably be the most time-consuming part of
>>  the porting work.]
>> 
>> Moreover, none of the code in the "o.a.c.math4.geometry"
>> package is used by another package of CM.
>> 
>> A new component would give the "geometry" codes a much
>> better chance of being (confidently[1]) released, since
>> CM is "stuck" for the foreseeable future.[2]
>> 
>> WDYT?
>> 
>> Gilles
>> 
>> [1] There seems to be only one issue reported in JIRA
>> that pertains to "geometry".
>> [2] 54 issues yet to be fixed before the 4.0 release;
>> which, at the current rate, would lead to after 2025
>> (a very rough guess, I admit).
> 
> 
> 
> -
> 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"?

2017-08-17 Thread Jörg Schaible 
+1

Looks good to me.

Gilles wrote:

> Hello.
> 
> [Time for a new episode in our "Ripping CM" series.]
> 
> How about creating "Commons Geometry"?
> 
> The rationale is comprised of the usual suspects:
>   * Smaller and more focused component, hence:
> - Consistent development and maintenance.
> - Consistent release schedule, not encumbered by
>   changes (and endless discussions) in _totally_
>   unrelated code.
> - Potential for attracting contributors not
>   interested in maintaining the (growing) backlog
>   of CM.
>   * Self-contained: 96.3% of the "o.a.c.math4.geometry"
> package have no dependency except:
> - 4 classes now in "Commons Numbers".
> - 2 methods and 1 constant in "MathUtils".
> - CM exceptions. [Creating alternatives for those
>   will probably be the most time-consuming part of
>   the porting work.]
> 
> Moreover, none of the code in the "o.a.c.math4.geometry"
> package is used by another package of CM.
> 
> A new component would give the "geometry" codes a much
> better chance of being (confidently[1]) released, since
> CM is "stuck" for the foreseeable future.[2]
> 
> WDYT?
> 
> Gilles
> 
> [1] There seems to be only one issue reported in JIRA
>  that pertains to "geometry".
> [2] 54 issues yet to be fixed before the 4.0 release;
>  which, at the current rate, would lead to after 2025
>  (a very rough guess, I admit).



-
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"?

2017-08-17 Thread Gilles 

Hi Benedikt.

On Thu, 17 Aug 2017 15:48:45 +0200, Benedikt Ritter wrote:

Hello Gilles,

Am 15.08.2017 um 16:26 schrieb Gilles 
:


Hello.

[Time for a new episode in our "Ripping CM" series.]

How about creating "Commons Geometry"?

The rationale is comprised of the usual suspects:
* Smaller and more focused component, hence:
  - Consistent development and maintenance.
  - Consistent release schedule, not encumbered by
changes (and endless discussions) in _totally_
unrelated code.
  - Potential for attracting contributors not
interested in maintaining the (growing) backlog
of CM.
* Self-contained: 96.3% of the "o.a.c.math4.geometry"
  package have no dependency except:
  - 4 classes now in "Commons Numbers".
  - 2 methods and 1 constant in "MathUtils".
  - CM exceptions. [Creating alternatives for those
will probably be the most time-consuming part of
the porting work.]

Moreover, none of the code in the "o.a.c.math4.geometry"
package is used by another package of CM.

A new component would give the "geometry" codes a much
better chance of being (confidently[1]) released, since
CM is "stuck" for the foreseeable future.[2]

WDYT?


I want to see the initial release of Commons Numbers before breaking
more components out of CM.


+1
I'm among those who most want to see that release rather sooner
than later.  [IIRC, I posted regularly to inquire about the status
of the pending issues.  Is there more *I* can do at this point?]

I've no problem with serializing the "CM ripping[1]" project.

However, I wish to know what people think of the purely technical,
code-oriented, arguments which I've put forward above.

My suggestion would be to have a "beta" release of the new component
in order to let a community of expert/interested users voice its
opinion on the expected API.  [I think there is a lot of good and
broadly useful code in the "geometry" package (otherwise I wouldn't
ask for a new component) but I also suspect that the API can be
improved.]

Regards,
Gilles

[1] For its own good, and ours. ;-)


Regards,
Benedikt



Gilles

[1] There seems to be only one issue reported in JIRA
   that pertains to "geometry".
[2] 54 issues yet to be fixed before the 4.0 release;
   which, at the current rate, would lead to after 2025
   (a very rough guess, I admit).




-
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"?

2017-08-17 Thread Gary Gregory 
On Thu, Aug 17, 2017 at 7:48 AM, Benedikt Ritter  wrote:

> Hello Gilles,
>
> > Am 15.08.2017 um 16:26 schrieb Gilles :
> >
> > Hello.
> >
> > [Time for a new episode in our "Ripping CM" series.]
> >
> > How about creating "Commons Geometry"?
> >
> > The rationale is comprised of the usual suspects:
> > * Smaller and more focused component, hence:
> >   - Consistent development and maintenance.
> >   - Consistent release schedule, not encumbered by
> > changes (and endless discussions) in _totally_
> > unrelated code.
> >   - Potential for attracting contributors not
> > interested in maintaining the (growing) backlog
> > of CM.
> > * Self-contained: 96.3% of the "o.a.c.math4.geometry"
> >   package have no dependency except:
> >   - 4 classes now in "Commons Numbers".
> >   - 2 methods and 1 constant in "MathUtils".
> >   - CM exceptions. [Creating alternatives for those
> > will probably be the most time-consuming part of
> > the porting work.]
> >
> > Moreover, none of the code in the "o.a.c.math4.geometry"
> > package is used by another package of CM.
> >
> > A new component would give the "geometry" codes a much
> > better chance of being (confidently[1]) released, since
> > CM is "stuck" for the foreseeable future.[2]
> >
> > WDYT?
>
> I want to see the initial release of Commons Numbers before breaking more
> components out of CM.
>

Sounds reasonable to me.

Gary


>
> Regards,
> Benedikt
>
> >
> > Gilles
> >
> > [1] There seems to be only one issue reported in JIRA
> >that pertains to "geometry".
> > [2] 54 issues yet to be fixed before the 4.0 release;
> >which, at the current rate, would lead to after 2025
> >(a very rough guess, I admit).
> >
> >
> > -
> > 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] Jenkins nonsense (?)

2017-08-17 Thread Brent Worden 
The last success in the build log indicates the last execution of Maven was
successful and not that the entire Jenkins build was successful.

Sprinkled throughout the build log are messages of the form 'Skipping
reporter since build result is FAILURE.'  The first such message appeared
shortly after the first occurrence of:
[CHECKSTYLE] Successfully parsed file
/home/jenkins/jenkins-slave/workspace/Commons_RNG__Java8/target/checkstyle-result.xml
of module Apache Commons RNG with 0 unique warnings and 0 duplicates.
java.io.EOFException
at java.io.DataInputStream.readInt(DataInputStream.java:392)
at
java.io.ObjectInputStream$BlockDataInputStream.readInt(ObjectInputStream.java:3139)
at java.io.ObjectInputStream.readInt(ObjectInputStream.java:1023)
at com.google.common.collect.Serialization.readCount(Serialization.java:50)
at com.google.common.collect.HashMultimap.readObject(HashMultimap.java:134)
at sun.reflect.GeneratedMethodAccessor15682.invoke(Unknown Source)

[PMD] Skipping reporter since build result is FAILURE

So, the build if failing trying to either generate the checkstyle report or
generate the PMD report.  I say this because it is not clear from the
exception what Maven stage is actually running at the moment of failure.
Adding --debug to the Maven command might provide better insight into the
actual cause.


Brent

On Thu, Aug 17, 2017 at 7:38 AM, Gilles 
wrote:

> Hello.
>
> Does someone know why Jenkins reports a build as "Failed" while
> the last line of the console output is:
> ---CUT---
> Finished: SUCCESS
> ---CUT---
>
> See e.g.
>   https://builds.apache.org/view/A-D/view/Commons/job/Commons_
> RNG__Java8/50/console
>
> Note that for the same code Jenkins reports success in another job:
>   https://builds.apache.org/view/A-D/view/Commons/job/Commons_
> Rng/138/console
>
> The only (intended) difference is "Java 8" vs "Java 6".
>
>
> Regards,
> Gilles
>
>
> -
> 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"?

2017-08-17 Thread Benedikt Ritter 
Hello Gilles,

> Am 15.08.2017 um 16:26 schrieb Gilles :
> 
> Hello.
> 
> [Time for a new episode in our "Ripping CM" series.]
> 
> How about creating "Commons Geometry"?
> 
> The rationale is comprised of the usual suspects:
> * Smaller and more focused component, hence:
>   - Consistent development and maintenance.
>   - Consistent release schedule, not encumbered by
> changes (and endless discussions) in _totally_
> unrelated code.
>   - Potential for attracting contributors not
> interested in maintaining the (growing) backlog
> of CM.
> * Self-contained: 96.3% of the "o.a.c.math4.geometry"
>   package have no dependency except:
>   - 4 classes now in "Commons Numbers".
>   - 2 methods and 1 constant in "MathUtils".
>   - CM exceptions. [Creating alternatives for those
> will probably be the most time-consuming part of
> the porting work.]
> 
> Moreover, none of the code in the "o.a.c.math4.geometry"
> package is used by another package of CM.
> 
> A new component would give the "geometry" codes a much
> better chance of being (confidently[1]) released, since
> CM is "stuck" for the foreseeable future.[2]
> 
> WDYT?

I want to see the initial release of Commons Numbers before breaking more 
components out of CM.

Regards,
Benedikt

> 
> Gilles
> 
> [1] There seems to be only one issue reported in JIRA
>that pertains to "geometry".
> [2] 54 issues yet to be fixed before the 4.0 release;
>which, at the current rate, would lead to after 2025
>(a very rough guess, I admit).
> 
> 
> -
> 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] Jenkins nonsense (?)

2017-08-17 Thread Gilles 

Hello.

Does someone know why Jenkins reports a build as "Failed" while
the last line of the console output is:
---CUT---
Finished: SUCCESS
---CUT---

See e.g.
  
https://builds.apache.org/view/A-D/view/Commons/job/Commons_RNG__Java8/50/console


Note that for the same code Jenkins reports success in another job:
  
https://builds.apache.org/view/A-D/view/Commons/job/Commons_Rng/138/console


The only (intended) difference is "Java 8" vs "Java 6".


Regards,
Gilles


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