Re: [proxy] toward a v2.0 release

[sebb]

On 27 March 2014 04:29, Matt Benson  wrote:
> This is the notice that I intend to serve as release manager and begin
> cutting release candidates in the very near future after a very small
> amount of remaining cleanup. Those of you who wish to formulate and express
> opinions on the state of the codebase before the v2 API is set in stone
> should probably go ahead and begin doing so.

I took a quick look, and Eclipse complains that the interface
implementations are not flagged with @Override, even though the
compiler is set to 1.6.
Is that intentional? [Obviously does not affect the API]

Also, I spotted at least one instance of

@SuppressWarnings("unchecked")

with no explanation as to why it is safe to ignore the warning.

Since such warnings can indicate a generics issue which may be tricky
to fix later I think they need to be addressed before fixing the API.

My other main concern regarding API petrification is mutable public or
protected variables.
Not yet scanned to see if there are any of these.

> Matt

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

Re: [proxy] toward a v2.0 release

[Matt Benson]

On Mar 27, 2014 6:43 AM, "sebb"  wrote:
>
> On 27 March 2014 04:29, Matt Benson  wrote:
> > This is the notice that I intend to serve as release manager and begin
> > cutting release candidates in the very near future after a very small
> > amount of remaining cleanup. Those of you who wish to formulate and
express
> > opinions on the state of the codebase before the v2 API is set in stone
> > should probably go ahead and begin doing so.
>
> I took a quick look, and Eclipse complains that the interface
> implementations are not flagged with @Override, even though the
> compiler is set to 1.6.
> Is that intentional? [Obviously does not affect the API]

Not intentional; thanks for spotting and addressing. We should potentially
add these items to one of our static code checker configurations.

>
> Also, I spotted at least one instance of
>
> @SuppressWarnings("unchecked")
>
> with no explanation as to why it is safe to ignore the warning.
>
> Since such warnings can indicate a generics issue which may be tricky
> to fix later I think they need to be addressed before fixing the API.
>

If you see it again, let me know and/or add a TODO in the code.

> My other main concern regarding API petrification is mutable public or
> protected variables.
> Not yet scanned to see if there are any of these.

Again, if these can be caught by a tool, let's set it up. The current
configs are minimal.

Thanks,
Matt

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

Re: [proxy] toward a v2.0 release

[sebb]

On 27 March 2014 13:16, Matt Benson  wrote:
> On Mar 27, 2014 6:43 AM, "sebb"  wrote:
>>
>> On 27 March 2014 04:29, Matt Benson  wrote:
>> > This is the notice that I intend to serve as release manager and begin
>> > cutting release candidates in the very near future after a very small
>> > amount of remaining cleanup. Those of you who wish to formulate and
> express
>> > opinions on the state of the codebase before the v2 API is set in stone
>> > should probably go ahead and begin doing so.
>>
>> I took a quick look, and Eclipse complains that the interface
>> implementations are not flagged with @Override, even though the
>> compiler is set to 1.6.
>> Is that intentional? [Obviously does not affect the API]
>
> Not intentional; thanks for spotting and addressing. We should potentially
> add these items to one of our static code checker configurations.

Well, I've fixed the Java 5 ones so far; I can fix the Java 6 ones soon.

>>
>> Also, I spotted at least one instance of
>>
>> @SuppressWarnings("unchecked")
>>
>> with no explanation as to why it is safe to ignore the warning.
>>
>> Since such warnings can indicate a generics issue which may be tricky
>> to fix later I think they need to be addressed before fixing the API.
>>
>
> If you see it again, let me know and/or add a TODO in the code.

There are quite a lot; none are commented in-line.
So rather than me adding TODO it's probably quicker to search for

@SuppressWarnings("unchecked")

>> My other main concern regarding API petrification is mutable public or
>> protected variables.
>> Not yet scanned to see if there are any of these.
>
> Again, if these can be caught by a tool, let's set it up.

I don't have a working tool; at present I just look for ^package and
visually scan the Outline in Eclipse.
Rather tedious!

> The current configs are minimal.

Yes, I noticed only the following mutable fields

SingletonProvider.instance
ProviderDecorator.inner
TrainingContext.TrainingContextFrame.matcher

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

Re: [proxy] toward a v2.0 release

[sebb]

Also just noticed that there are a lot of @author tags.
These are deprecated, and should ideally be removed (the authors can
be credited elsewhere).

One is yours, the rest are James Carman.

On 27 March 2014 14:13, sebb  wrote:
> On 27 March 2014 13:16, Matt Benson  wrote:
>> On Mar 27, 2014 6:43 AM, "sebb"  wrote:
>>>
>>> On 27 March 2014 04:29, Matt Benson  wrote:
>>> > This is the notice that I intend to serve as release manager and begin
>>> > cutting release candidates in the very near future after a very small
>>> > amount of remaining cleanup. Those of you who wish to formulate and
>> express
>>> > opinions on the state of the codebase before the v2 API is set in stone
>>> > should probably go ahead and begin doing so.
>>>
>>> I took a quick look, and Eclipse complains that the interface
>>> implementations are not flagged with @Override, even though the
>>> compiler is set to 1.6.
>>> Is that intentional? [Obviously does not affect the API]
>>
>> Not intentional; thanks for spotting and addressing. We should potentially
>> add these items to one of our static code checker configurations.
>
> Well, I've fixed the Java 5 ones so far; I can fix the Java 6 ones soon.
>
>>>
>>> Also, I spotted at least one instance of
>>>
>>> @SuppressWarnings("unchecked")
>>>
>>> with no explanation as to why it is safe to ignore the warning.
>>>
>>> Since such warnings can indicate a generics issue which may be tricky
>>> to fix later I think they need to be addressed before fixing the API.
>>>
>>
>> If you see it again, let me know and/or add a TODO in the code.
>
> There are quite a lot; none are commented in-line.
> So rather than me adding TODO it's probably quicker to search for
>
> @SuppressWarnings("unchecked")
>
>>> My other main concern regarding API petrification is mutable public or
>>> protected variables.
>>> Not yet scanned to see if there are any of these.
>>
>> Again, if these can be caught by a tool, let's set it up.
>
> I don't have a working tool; at present I just look for ^package and
> visually scan the Outline in Eclipse.
> Rather tedious!
>
>> The current configs are minimal.
>
> Yes, I noticed only the following mutable fields
>
> SingletonProvider.instance
> ProviderDecorator.inner
> TrainingContext.TrainingContextFrame.matcher

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

Re: [proxy] toward a v2.0 release

[Matt Benson]

FTR, I agree these should be removed, but out of common courtesy we should
probably seek James's acquiescence.

Matt
On Mar 27, 2014 9:43 AM, "sebb"  wrote:

> Also just noticed that there are a lot of @author tags.
> These are deprecated, and should ideally be removed (the authors can
> be credited elsewhere).
>
> One is yours, the rest are James Carman.
>
> On 27 March 2014 14:13, sebb  wrote:
> > On 27 March 2014 13:16, Matt Benson  wrote:
> >> On Mar 27, 2014 6:43 AM, "sebb"  wrote:
> >>>
> >>> On 27 March 2014 04:29, Matt Benson  wrote:
> >>> > This is the notice that I intend to serve as release manager and
> begin
> >>> > cutting release candidates in the very near future after a very small
> >>> > amount of remaining cleanup. Those of you who wish to formulate and
> >> express
> >>> > opinions on the state of the codebase before the v2 API is set in
> stone
> >>> > should probably go ahead and begin doing so.
> >>>
> >>> I took a quick look, and Eclipse complains that the interface
> >>> implementations are not flagged with @Override, even though the
> >>> compiler is set to 1.6.
> >>> Is that intentional? [Obviously does not affect the API]
> >>
> >> Not intentional; thanks for spotting and addressing. We should
> potentially
> >> add these items to one of our static code checker configurations.
> >
> > Well, I've fixed the Java 5 ones so far; I can fix the Java 6 ones soon.
> >
> >>>
> >>> Also, I spotted at least one instance of
> >>>
> >>> @SuppressWarnings("unchecked")
> >>>
> >>> with no explanation as to why it is safe to ignore the warning.
> >>>
> >>> Since such warnings can indicate a generics issue which may be tricky
> >>> to fix later I think they need to be addressed before fixing the API.
> >>>
> >>
> >> If you see it again, let me know and/or add a TODO in the code.
> >
> > There are quite a lot; none are commented in-line.
> > So rather than me adding TODO it's probably quicker to search for
> >
> > @SuppressWarnings("unchecked")
> >
> >>> My other main concern regarding API petrification is mutable public or
> >>> protected variables.
> >>> Not yet scanned to see if there are any of these.
> >>
> >> Again, if these can be caught by a tool, let's set it up.
> >
> > I don't have a working tool; at present I just look for ^package and
> > visually scan the Outline in Eclipse.
> > Rather tedious!
> >
> >> The current configs are minimal.
> >
> > Yes, I noticed only the following mutable fields
> >
> > SingletonProvider.instance
> > ProviderDecorator.inner
> > TrainingContext.TrainingContextFrame.matcher
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

[Math] MATH-1114

[Gilles]

On Thu, 27 Mar 2014 13:42:14 + (UTC), Gilles (JIRA) wrote:

Gilles created MATH-1114:


 Summary: Accuracy of "FastMath" and "Math"
 Key: MATH-1114
 URL: https://issues.apache.org/jira/browse/MATH-1114
 Project: Commons Math
  Issue Type: Wish
Reporter: Gilles
Priority: Minor
 Fix For: 3.3


It would be useful to be able to assess the advantage(s) of Commons
Math's "FastMath" over "java.lang.Math".



Do you have suggestions on how to produce the data in a most useful 
way?



Thanks,
Gilles


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

[PROXY] Dependency updates

[sebb]

There are newer versions of the following:

cglib:cglib-nodep ... 2.1_3 -> 3.1

 org.ow2.asm:asm-commons . 4.2 -> 5.0.1
 org.ow2.asm:asm . 4.2 -> 5.0.1

jmock:jmock .. 1.0.1 -> 1.2.0


Should the pom be updated for any of these?

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

Re: [PROXY] Dependency updates

[Gary Gregory]

I'm always for living in the present ;) +1.

Gary


On Thu, Mar 27, 2014 at 10:53 AM, sebb  wrote:

> There are newer versions of the following:
>
> cglib:cglib-nodep ... 2.1_3 -> 3.1
>
>  org.ow2.asm:asm-commons . 4.2 -> 5.0.1
>  org.ow2.asm:asm . 4.2 -> 5.0.1
>
> jmock:jmock .. 1.0.1 -> 1.2.0
>
>
> Should the pom be updated for any of these?
>
> -
> 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
Java Persistence with Hibernate, Second Edition
JUnit in Action, Second Edition 
Spring Batch in Action 
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

[proxy] @author tags

[Matt Benson]

James:
  As you are no doubt aware, the recommended practice in ASF Java code
is to dispense with @author tags. You are, of course, listed in the
Commons Proxy POM with the roles of admin/designer/developer. Do you
take issue with the removal of your @author tags from the source code?

br,
Matt

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

Re: [proxy] @author tags

[James Carman]

Of course not.  Feel free.  Sorry for including them.  I guess I
didn't realize I did it or something.

On Thu, Mar 27, 2014 at 10:57 AM, Matt Benson  wrote:
> James:
>   As you are no doubt aware, the recommended practice in ASF Java code
> is to dispense with @author tags. You are, of course, listed in the
> Commons Proxy POM with the roles of admin/designer/developer. Do you
> take issue with the removal of your @author tags from the source code?
>
> br,
> Matt

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

Re: [PROXY] Dependency updates

[Matt Benson]

Probably so. My intent is to rename the asm stuff from ASM4* to ASM*.

Matt

On Thu, Mar 27, 2014 at 9:53 AM, sebb  wrote:
> There are newer versions of the following:
>
> cglib:cglib-nodep ... 2.1_3 -> 3.1
>
>  org.ow2.asm:asm-commons . 4.2 -> 5.0.1
>  org.ow2.asm:asm . 4.2 -> 5.0.1
>
> jmock:jmock .. 1.0.1 -> 1.2.0
>
>
> Should the pom be updated for any of these?
>
> -
> 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: [proxy] @author tags

[sebb]

On 27 March 2014 14:58, James Carman  wrote:
> Of course not.  Feel free.

Thanks, will do!

> Sorry for including them.  I guess I didn't realize I did it or something.

Possibly your IDE did it for you.

> On Thu, Mar 27, 2014 at 10:57 AM, Matt Benson  wrote:
>> James:
>>   As you are no doubt aware, the recommended practice in ASF Java code
>> is to dispense with @author tags. You are, of course, listed in the
>> Commons Proxy POM with the roles of admin/designer/developer. Do you
>> take issue with the removal of your @author tags from the source code?
>>
>> br,
>> Matt
>
> -
> 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: [proxy] @author tags

[Matt Benson]

Thanks, James!

Take care,
Matt and Commons

On Thu, Mar 27, 2014 at 10:12 AM, sebb  wrote:
> On 27 March 2014 14:58, James Carman  wrote:
>> Of course not.  Feel free.
>
> Thanks, will do!
>
>> Sorry for including them.  I guess I didn't realize I did it or something.
>
> Possibly your IDE did it for you.
>
>> On Thu, Mar 27, 2014 at 10:57 AM, Matt Benson  wrote:
>>> James:
>>>   As you are no doubt aware, the recommended practice in ASF Java code
>>> is to dispense with @author tags. You are, of course, listed in the
>>> Commons Proxy POM with the roles of admin/designer/developer. Do you
>>> take issue with the removal of your @author tags from the source code?
>>>
>>> br,
>>> Matt
>>
>> -
>> 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

[PROXY] @since markers

[sebb]

Whilst removing the @author tags I noticed that there are 39 @since
markers, all are @since 1.0.

I think we should remove these.

If not, then we need to add @since markers to identify what has been
added since.

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

Re: [PROXY] @since markers

[Paul Benedict]

I don't know if removing @since 1.0 should be pursued. Coming from a
research perspective, the lack of them either indicates (1) since 1.0 or
(2) an omission. There's no way to know how someone would interpret their
omission so I would recommend keeping them so it's clear which methods
existed since the beginning.


On Thu, Mar 27, 2014 at 10:22 AM, sebb  wrote:

> Whilst removing the @author tags I noticed that there are 39 @since
> markers, all are @since 1.0.
>
> I think we should remove these.
>
> If not, then we need to add @since markers to identify what has been
> added since.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>


-- 
Cheers,
Paul

Re: [PROXY] @since markers

[Matt Benson]

+1. Due to the package change and fundamental shift from ProxyFactory
as abstract class to interface, arguably everything (or very nearly
so) is @since 2.0 anyway.

Matt

On Thu, Mar 27, 2014 at 10:22 AM, sebb  wrote:
> Whilst removing the @author tags I noticed that there are 39 @since
> markers, all are @since 1.0.
>
> I think we should remove these.
>
> If not, then we need to add @since markers to identify what has been
> added since.
>
> -
> 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: [PROXY] @since markers

[sebb]

Indeed.

The point about not knowing where a missing annotation means it was
forgotten or whether it means ab initio may perhaps work with classes.

However once a class has an @since marker, there's no way of telling
whether its method and field @since markers are deliberately or
accidentally omitted.

The only way to deal with that would be to insist on @since markers
for every class, method and field.


On 27 March 2014 15:27, Matt Benson  wrote:
> +1. Due to the package change and fundamental shift from ProxyFactory
> as abstract class to interface, arguably everything (or very nearly
> so) is @since 2.0 anyway.
>
> Matt
>
> On Thu, Mar 27, 2014 at 10:22 AM, sebb  wrote:
>> Whilst removing the @author tags I noticed that there are 39 @since
>> markers, all are @since 1.0.
>>
>> I think we should remove these.
>>
>> If not, then we need to add @since markers to identify what has been
>> added since.
>>
>> -
>> 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: [PROXY] @since markers

[Paul Benedict]

Sebb, maybe I missed the context of the proposal. If the @since 1.0 is on
the class, there's no need for it to be on methods unless the methods are
of another version. I think that's the standard javadoc way from Oracle
anyway.


On Thu, Mar 27, 2014 at 10:35 AM, sebb  wrote:

> Indeed.
>
> The point about not knowing where a missing annotation means it was
> forgotten or whether it means ab initio may perhaps work with classes.
>
> However once a class has an @since marker, there's no way of telling
> whether its method and field @since markers are deliberately or
> accidentally omitted.
>
> The only way to deal with that would be to insist on @since markers
> for every class, method and field.
>
>
> On 27 March 2014 15:27, Matt Benson  wrote:
> > +1. Due to the package change and fundamental shift from ProxyFactory
> > as abstract class to interface, arguably everything (or very nearly
> > so) is @since 2.0 anyway.
> >
> > Matt
> >
> > On Thu, Mar 27, 2014 at 10:22 AM, sebb  wrote:
> >> Whilst removing the @author tags I noticed that there are 39 @since
> >> markers, all are @since 1.0.
> >>
> >> I think we should remove these.
> >>
> >> If not, then we need to add @since markers to identify what has been
> >> added since.
> >>
> >> -
> >> 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
>
>


-- 
Cheers,
Paul

[CSV] ASCII Delimited Text – Not CSV or TAB delimited text

[Gary Gregory]

FYI:

Has anyone seen this?

https://ronaldduncan.wordpress.com/2009/10/31/text-file-formats-ascii-delimited-text-not-csv-or-tab-delimited-text/

It actually makes sense. Good luck editing such files though...

I wonder if we should add a built-in format for this format?

Gary
-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition
JUnit in Action, Second Edition 
Spring Batch in Action 
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: [CSV] ASCII Delimited Text – Not CSV or TAB delimited text

[Hasan Diwan]

Python (at least, maybe Ruby/perl as well) has a csv class whose
constructor takes a delimiter, defaulting to ","; R accomplishes the same
using read.table's sep parameter. OpenCSV, a Java class for manipulating
CSVs, also has a notion of a separator. It's not too difficult to add, I'd
be willing to do so, if there are enough "+1"s, let's say 4 in addition to
myself.


On 27 March 2014 08:49, Gary Gregory  wrote:

> FYI:
>
> Has anyone seen this?
>
>
> https://ronaldduncan.wordpress.com/2009/10/31/text-file-formats-ascii-delimited-text-not-csv-or-tab-delimited-text/
>
> It actually makes sense. Good luck editing such files though...
>
> I wonder if we should add a built-in format for this format?
>
> Gary
> --
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> Java Persistence with Hibernate, Second Edition<
> http://www.manning.com/bauer3/>
> JUnit in Action, Second Edition 
> Spring Batch in Action 
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>



-- 
Sent from my mobile device
Envoyé de mon portable

Re: [PROXY] @since markers

[sebb]

On 27 March 2014 15:47, Paul Benedict  wrote:
> Sebb, maybe I missed the context of the proposal. If the @since 1.0 is on
> the class, there's no need for it to be on methods unless the methods are
> of another version. I think that's the standard javadoc way from Oracle
> anyway.

Yes.

But the only way to identify subsequent additional methods on a class
is to add an @since marker to them.

What about all the other methods in the class?
Do they then all have to have @since 1.0 added?

Otherwise how can one tell if a missing @since marker on a method is
deliberately omiited (because it's the same as the class) or
accidentally omitted?

That's not to say that @since markers aren't useful.
But I don't buy the argument that the starting classes need to be tagged.

>
> On Thu, Mar 27, 2014 at 10:35 AM, sebb  wrote:
>
>> Indeed.
>>
>> The point about not knowing where a missing annotation means it was
>> forgotten or whether it means ab initio may perhaps work with classes.
>>
>> However once a class has an @since marker, there's no way of telling
>> whether its method and field @since markers are deliberately or
>> accidentally omitted.
>>
>> The only way to deal with that would be to insist on @since markers
>> for every class, method and field.
>>
>>
>> On 27 March 2014 15:27, Matt Benson  wrote:
>> > +1. Due to the package change and fundamental shift from ProxyFactory
>> > as abstract class to interface, arguably everything (or very nearly
>> > so) is @since 2.0 anyway.
>> >
>> > Matt
>> >
>> > On Thu, Mar 27, 2014 at 10:22 AM, sebb  wrote:
>> >> Whilst removing the @author tags I noticed that there are 39 @since
>> >> markers, all are @since 1.0.
>> >>
>> >> I think we should remove these.
>> >>
>> >> If not, then we need to add @since markers to identify what has been
>> >> added since.
>> >>
>> >> -
>> >> 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
>>
>>
>
>
> --
> Cheers,
> Paul

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

Re: [CSV] ASCII Delimited Text - Not CSV or TAB delimited text

[sebb]

On 27 March 2014 15:49, Gary Gregory  wrote:
> FYI:
>
> Has anyone seen this?
>
> https://ronaldduncan.wordpress.com/2009/10/31/text-file-formats-ascii-delimited-text-not-csv-or-tab-delimited-text/
>
> It actually makes sense. Good luck editing such files though...

Yes, how is one supposed to create them?

I think those ASCII characters were used quite a lot in the early days
of teletypes which had the appropriate keys.
Also they were used in some serial line protocols.

But of course once people needed to send binary data, escape codes or
encoding had to be used.

> I wonder if we should add a built-in format for this format?

Are there (m)any files that use the format?

Otherwise why bother ...

> Gary
> --
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> Java Persistence with Hibernate, Second 
> Edition
> JUnit in Action, Second Edition 
> Spring Batch in Action 
> 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

Re: [CSV] ASCII Delimited Text – Not CSV or TAB delimited text

[Gary Gregory]

On Thu, Mar 27, 2014 at 11:58 AM, Hasan Diwan  wrote:

> Python (at least, maybe Ruby/perl as well) has a csv class whose
> constructor takes a delimiter, defaulting to ","; R accomplishes the same
> using read.table's sep parameter. OpenCSV, a Java class for manipulating
> CSVs, also has a notion of a separator. It's not too difficult to add, I'd
> be willing to do so, if there are enough "+1"s, let's say 4 in addition to
> myself.
>

I am not sure what you are taking about because [csv] already does all
this. The question is, more precisely, should we have a CSVFormat.ASCII
constant using the ASCII codes from the blog post.

Gary

>
>
> On 27 March 2014 08:49, Gary Gregory  wrote:
>
> > FYI:
> >
> > Has anyone seen this?
> >
> >
> >
> https://ronaldduncan.wordpress.com/2009/10/31/text-file-formats-ascii-delimited-text-not-csv-or-tab-delimited-text/
> >
> > It actually makes sense. Good luck editing such files though...
> >
> > I wonder if we should add a built-in format for this format?
> >
> > Gary
> > --
> > E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> > Java Persistence with Hibernate, Second Edition<
> > http://www.manning.com/bauer3/>
> > JUnit in Action, Second Edition 
> > Spring Batch in Action 
> > Blog: http://garygregory.wordpress.com
> > Home: http://garygregory.com/
> > Tweet! http://twitter.com/GaryGregory
> >
>
>
>
> --
> Sent from my mobile device
> Envoyé de mon portable
>



-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition
JUnit in Action, Second Edition 
Spring Batch in Action 
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: [PROXY] @since markers

[Paul Benedict]

I think starting the classes should be @since tagged; that's standard
procedure in the javadoc world, as far as i know. Regarding what's
forgotten, I never worried about that and fixing it is easy.


On Thu, Mar 27, 2014 at 11:18 AM, sebb  wrote:

> On 27 March 2014 15:47, Paul Benedict  wrote:
> > Sebb, maybe I missed the context of the proposal. If the @since 1.0 is on
> > the class, there's no need for it to be on methods unless the methods are
> > of another version. I think that's the standard javadoc way from Oracle
> > anyway.
>
> Yes.
>
> But the only way to identify subsequent additional methods on a class
> is to add an @since marker to them.
>
> What about all the other methods in the class?
> Do they then all have to have @since 1.0 added?
>
> Otherwise how can one tell if a missing @since marker on a method is
> deliberately omiited (because it's the same as the class) or
> accidentally omitted?
>
> That's not to say that @since markers aren't useful.
> But I don't buy the argument that the starting classes need to be tagged.
>
> >
> > On Thu, Mar 27, 2014 at 10:35 AM, sebb  wrote:
> >
> >> Indeed.
> >>
> >> The point about not knowing where a missing annotation means it was
> >> forgotten or whether it means ab initio may perhaps work with classes.
> >>
> >> However once a class has an @since marker, there's no way of telling
> >> whether its method and field @since markers are deliberately or
> >> accidentally omitted.
> >>
> >> The only way to deal with that would be to insist on @since markers
> >> for every class, method and field.
> >>
> >>
> >> On 27 March 2014 15:27, Matt Benson  wrote:
> >> > +1. Due to the package change and fundamental shift from ProxyFactory
> >> > as abstract class to interface, arguably everything (or very nearly
> >> > so) is @since 2.0 anyway.
> >> >
> >> > Matt
> >> >
> >> > On Thu, Mar 27, 2014 at 10:22 AM, sebb  wrote:
> >> >> Whilst removing the @author tags I noticed that there are 39 @since
> >> >> markers, all are @since 1.0.
> >> >>
> >> >> I think we should remove these.
> >> >>
> >> >> If not, then we need to add @since markers to identify what has been
> >> >> added since.
> >> >>
> >> >> -
> >> >> 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
> >>
> >>
> >
> >
> > --
> > Cheers,
> > Paul
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>


-- 
Cheers,
Paul

Re: [CSV] ASCII Delimited Text – Not CSV or TAB delimited text

[Hasan Diwan]

Greg,
I misunderstood the thrust of your question. I disagree we need a
specialised format for this, as the first I've heard of these codes was in
your initial email. I've not seen them used "in the wild", as it were,
either. However, if there's enough pushback in the other direction, I'll
keep my views to myself. -- H


On 27 March 2014 09:43, Gary Gregory  wrote:

> On Thu, Mar 27, 2014 at 11:58 AM, Hasan Diwan 
> wrote:
>
> > Python (at least, maybe Ruby/perl as well) has a csv class whose
> > constructor takes a delimiter, defaulting to ","; R accomplishes the same
> > using read.table's sep parameter. OpenCSV, a Java class for manipulating
> > CSVs, also has a notion of a separator. It's not too difficult to add,
> I'd
> > be willing to do so, if there are enough "+1"s, let's say 4 in addition
> to
> > myself.
> >
>
> I am not sure what you are taking about because [csv] already does all
> this. The question is, more precisely, should we have a CSVFormat.ASCII
> constant using the ASCII codes from the blog post.
>
> Gary
>
> >
> >
> > On 27 March 2014 08:49, Gary Gregory  wrote:
> >
> > > FYI:
> > >
> > > Has anyone seen this?
> > >
> > >
> > >
> >
> https://ronaldduncan.wordpress.com/2009/10/31/text-file-formats-ascii-delimited-text-not-csv-or-tab-delimited-text/
> > >
> > > It actually makes sense. Good luck editing such files though...
> > >
> > > I wonder if we should add a built-in format for this format?
> > >
> > > Gary
> > > --
> > > E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> > > Java Persistence with Hibernate, Second Edition<
> > > http://www.manning.com/bauer3/>
> > > JUnit in Action, Second Edition 
> > > Spring Batch in Action 
> > > Blog: http://garygregory.wordpress.com
> > > Home: http://garygregory.com/
> > > Tweet! http://twitter.com/GaryGregory
> > >
> >
> >
> >
> > --
> > Sent from my mobile device
> > Envoyé de mon portable
> >
>
>
>
> --
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> Java Persistence with Hibernate, Second Edition<
> http://www.manning.com/bauer3/>
> JUnit in Action, Second Edition 
> Spring Batch in Action 
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>



-- 
Sent from my mobile device
Envoyé de mon portable

[collections] MultiValuedMap interface discussion

[Thomas Neidhart]

Hi,

we are currently working on a new MultiValuedMap interface for
collections, see https://issues.apache.org/jira/browse/COLLECTIONS-508.

During the work we stumbled across an issue we would like to discuss.
The MultiValuedMap is basically a Map that can hold multiple values
associated to a given key. Thus the get(K key) method will normally
return a Collection.

In case no mapping for the key is stored in the map, it may either
return null (like a normal map), or an empty collection.

I would be in favor to define that get() always returns a collection and
never returns null. The advantage being that the result of get() can
safely be used for further operations, e.g. size(), iterator(), ...
keeping the interface of MultiValuedMap smaller and simple (i.e. no need
to add additional methods there like size(K key) or iterator(K key)).

The containsKey method would have to check if there is either no mapping
at all for the key or the stored collection is empty:

public boolean containsKey(K key) {
  Collection coll = decoratedMap().get(key);
  return coll != null && coll.size > 0;
}

The downside would be that read operations may also alter the map thus
leading to unexpected ConcurrentModificationExceptions when iterating on
e.g. value().

So, I would be interested on opinions about this.

Thomas

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

Re: [collections] MultiValuedMap interface discussion

[Paul Benedict]

The downside of it returning an empty collection is you either have (1) to
instantiate a collection just to say you have nothing or (2) you use an
immutable collection. #1 is bad in itself and #2 is only as bad if the
collection is otherwise writable. For example, it would be really strange
for the returned collection to be mutable if you have something but
immutable if you have nothing.

My preference is you return null. That's the most rational answer, imo.


On Thu, Mar 27, 2014 at 4:44 PM, Thomas Neidhart
wrote:

> Hi,
>
> we are currently working on a new MultiValuedMap interface for
> collections, see https://issues.apache.org/jira/browse/COLLECTIONS-508.
>
> During the work we stumbled across an issue we would like to discuss.
> The MultiValuedMap is basically a Map that can hold multiple values
> associated to a given key. Thus the get(K key) method will normally
> return a Collection.
>
> In case no mapping for the key is stored in the map, it may either
> return null (like a normal map), or an empty collection.
>
> I would be in favor to define that get() always returns a collection and
> never returns null. The advantage being that the result of get() can
> safely be used for further operations, e.g. size(), iterator(), ...
> keeping the interface of MultiValuedMap smaller and simple (i.e. no need
> to add additional methods there like size(K key) or iterator(K key)).
>
> The containsKey method would have to check if there is either no mapping
> at all for the key or the stored collection is empty:
>
> public boolean containsKey(K key) {
>   Collection coll = decoratedMap().get(key);
>   return coll != null && coll.size > 0;
> }
>
> The downside would be that read operations may also alter the map thus
> leading to unexpected ConcurrentModificationExceptions when iterating on
> e.g. value().
>
> So, I would be interested on opinions about this.
>
> Thomas
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>


-- 
Cheers,
Paul

Re: [collections] MultiValuedMap interface discussion

[Ted Dunning]

Following Guava on this has something to be said for it.

https://code.google.com/p/guava-libraries/wiki/NewCollectionTypesExplained

Their decision is that Multimap#get returns a collection always.  If there
are no values, then an empty collection is returned so that you can always
do

  m.get(key).size()

or

 m.get(key).add(foo)

The value returned is a magical view which only takes up space on demand so
there is little consing done.  There is an asMap method for which get will
return null on missing keys.




On Thu, Mar 27, 2014 at 2:55 PM, Paul Benedict  wrote:

> The downside of it returning an empty collection is you either have (1) to
> instantiate a collection just to say you have nothing or (2) you use an
> immutable collection. #1 is bad in itself and #2 is only as bad if the
> collection is otherwise writable. For example, it would be really strange
> for the returned collection to be mutable if you have something but
> immutable if you have nothing.
>
> My preference is you return null. That's the most rational answer, imo.
>
>
> On Thu, Mar 27, 2014 at 4:44 PM, Thomas Neidhart
> wrote:
>
> > Hi,
> >
> > we are currently working on a new MultiValuedMap interface for
> > collections, see https://issues.apache.org/jira/browse/COLLECTIONS-508.
> >
> > During the work we stumbled across an issue we would like to discuss.
> > The MultiValuedMap is basically a Map that can hold multiple values
> > associated to a given key. Thus the get(K key) method will normally
> > return a Collection.
> >
> > In case no mapping for the key is stored in the map, it may either
> > return null (like a normal map), or an empty collection.
> >
> > I would be in favor to define that get() always returns a collection and
> > never returns null. The advantage being that the result of get() can
> > safely be used for further operations, e.g. size(), iterator(), ...
> > keeping the interface of MultiValuedMap smaller and simple (i.e. no need
> > to add additional methods there like size(K key) or iterator(K key)).
> >
> > The containsKey method would have to check if there is either no mapping
> > at all for the key or the stored collection is empty:
> >
> > public boolean containsKey(K key) {
> >   Collection coll = decoratedMap().get(key);
> >   return coll != null && coll.size > 0;
> > }
> >
> > The downside would be that read operations may also alter the map thus
> > leading to unexpected ConcurrentModificationExceptions when iterating on
> > e.g. value().
> >
> > So, I would be interested on opinions about this.
> >
> > Thomas
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
> >
>
>
> --
> Cheers,
> Paul
>