Re: AW: [commons-lang3] NumberUtils feature

[Javen O';Neal]

I'm -1 for a static function as suggested by Lucas. It doesn't improve code
readability, and I'd argue that it decreases readability because of needing
to memorize operator order, ambiguous inclusivity of endpoints (unless you
add isStrictlyBetween), and doesn't gracefully handle mixed data types,
especially non-primitives like fixed precision decimals or fractions.

Even with better named endpoints x and y as min/max, lowerBound/upperBound.
What significant benefit does defining this function provide?

Java syntax might not be as concise as other languages like Python that
allow writing "lowerBound <= value <= upperBound", but a function call
doesn't seem right here.

BiInclusiveRange(lowerBound, upperBound).contains(value) seems like a
better approach.

On Dec 31, 2017 02:31, "Gilles"  wrote:

On Sat, 30 Dec 2017 14:25:32 +0100, Jan Matèrne wrote:

> Maybe open the comparators and use a fluent API?
> is(42).between(10).and(50) == true
> is(10).between(10).and(20) == false
> is(10).between(10).and(20).includingLeft() == true
> is(50).between(10).and(50) == false
> is(50).between(10).and(50).includingRight() == true
>

There is "Range":
  http://commons.apache.org/proper/commons-lang/javadocs/api-
release/org/apache/commons/lang3/Range.html

Is the original suggestion meant to create an implementation
for primitive types?

Gilles



>
> Just quick thoughts ...
>
> Jan
>
>
> -Ursprüngliche Nachricht-
>> Von: Gilles [mailto:gil...@harfang.homelinux.org]
>> Gesendet: Freitag, 29. Dezember 2017 22:46
>> An: dev@commons.apache.org
>> Betreff: Re: [commons-lang3] NumberUtils feature
>>
>> On Fri, 29 Dec 2017 16:19:05 -0200, Lucas Carvalho wrote:
>> > Gilles, thanks for you reply.
>> >
>> > I will consider your sugestions.
>> >
>> > So, can i open a issue in jira (apache commons) and implement this
>> > feature?
>>
>> Better wait for other opinions on the various suggestions, as it
>> impacts on which JIRA project you'd open the issue.
>>
>> Regards,
>> Gilles
>>
>> >
>> > Thanks.
>> >
>> > Lucas Carvalho
>> >
>> >
>> >
>> > On Fri, Dec 29, 2017 at 12:25 PM, Gilles
>> > 
>> > wrote:
>> >
>> >> Hi.
>> >>
>> >> On Fri, 29 Dec 2017 11:53:29 -0200, Lucas Carvalho wrote:
>> >>
>> >>> I`m sorry,
>> >>>
>> >>> Now code in "text":
>> >>>
>> >>> public static boolean between(final int value, final int x, final
>> >>> int y) {
>> >>>
>> >>>return value >= x && value <= y;
>> >>>
>> >>> }
>> >>>
>> >>>
>> >>> public static boolean between(final short value, final short x,
>> >>> final short
>> >>> y) {
>> >>>
>> >>>return value >= x && value <= y;
>> >>>
>> >>> }
>> >>>
>> >>
>> >> To comply with the Java convention, it should probably be
>> >> "isBetween".
>> >>
>> >> Incidently, this also shows a weakness of "Utils" classes: the
>> >> "target"
>> >> (which would normally be "this") is on the same footing as the other
>> >> arguments (the bounds of the interval here).
>> >>
>> >> Also the naming does not reflect whether bounds are included or not:
>> >> usually, one would assume that the left bound is included (>=) but
>> >> not the right one (<).
>> >>
>> >> Then, what about "between(15, 20, 10)"?
>> >>
>> >> Finally, we should consider whether to continue bloating
>> >> "NumberUtils"
>> >> in "Lang" or move some of it to the new "Numbers" component.[1]
>> >>
>> >> Regards,
>> >> Gilles
>> >>
>> >> [1]
>> >> https://git1-us-west.apache.org/repos/asf?p=commons-
>> numbers.git;a=tre
>> >> e
>> >>
>> >>
>> >>>
>> >>>
>> >>> Obrigado.
>> >>>
>> >>> Atenciosamente
>> >>>
>> >>> Lucas Carvalho
>> >>>
>> >>> *Fone *- 34 9 9903 4621
>> >>>
>> >>> On Fri, Dec 29, 2017 at 11:47 AM, Gilles
>> >>> 
>> >>> wrote:
>> >>>
>> >>> Hi.
>> 
>>  On Fri, 29 Dec 2017 09:51:59 -0200, Lucas Carvalho wrote:
>> 
>>  Hello everybody,
>> >
>> > I want know if the feature "between" in NumberUtils lib has be
>> > discussed?
>> > I
>> > use this methods a lot and i would like to share this code in
>> > apache commons.
>> >
>> > Below i share a example:
>> >
>> > [image: Inline image 1]
>> >
>> >
>>  All I can see is the above.
>>  [Perhaps the image was stripped.]
>> 
>>  I assume it is code; so, please write it here as "text".
>> 
>>  Thanks,
>>  Gilles
>> 
>> 
>>  Thanks.
>> >
>> > Lucas Carvalho
>>
>

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

Re: [lang][collections] SortedProperties

[Javen O';Neal]

+1 for Lang.

There aren't any persistent data structures in Collections, nor would I
think to look in Collections to find one.

Properties is a persistent hashtable. SortedProperties is a persistent
TreeMap.

Unless you're thinking about a new family of SortedProperties. Were you
thinking about letting the user provide the Map implementation and the
SortedProperties would handle the persistence?
For example, if I wanted to persist a MultiValuedMap or a BidiMap, could I
do that?
new PersistentMap>();
new PersistentMap>();
Is there a real scenario where this would be needed?

On Jul 18, 2017 00:19, "Amey Jadiye"  wrote:

> My opinion is this should go to *lang* because the fact is it's extended
> utility and not exactly as data structures though it looks like one. It's
> main purpose is to hold properties and not the data.  Commons collection
> aims to provide utlilities and extension to data structures and not to
> properties  related utilities. Properties is very basic thing no matter
> it's sorted or not sorted and should go to lang.
>
> Regards,
> Amey
>
> On Tue, Jul 18, 2017, 11:58 AM Gary Gregory 
> wrote:
>
> > Hi,
> >
> > I'd to have a new class called SortedProperties that extends
> > java.util.Properties.
> >
> > Should that go in [lang] or [collections]?
> >
> > I first thought [lang], but it _is_ a collection after all.
> >
> > Gary
> >
>

Re: [collections] How about a HashBidiMap?

[Javen O';Neal]

It wasn't a rhetorical question. I wanted to open discussion on your
contribution, and wanted to start with what folks on this mailing list are
most familiar with.

I'm not a Commons Collection maintainer, but I'm curious if you could
describe your implementation in a few sentences and how it differs from the
current DualHashBidiMap implementation. Is it faster than other
implementations? Does it have a lower memory footprint by sharing key and
value objects between two underlying HashMaps? Does it implement its own
HashMap interface implementing its own Map data structure?

Can you name one or two scenarios where your implementation would be
preferred over the existing implementations?

On Jul 6, 2017 11:56, "Efremov, Rodion"  wrote:

> From
> http://svn.apache.org/viewvc/commons/proper/collections/
> trunk/src/main/java/org/apache/commons/collections4/
> bidimap/DualHashBidiMap.java?view=markup
>
> "Commons Collections would welcome the addition of a direct hash-based
> implementation of the BidiMap interface"
>
> Guess I was wrong.
>
> 
> From: Javen O'Neal 
> Sent: Thursday, July 6, 2017 12:51:25 PM
> To: Commons Developers List
> Subject: Re: [collections] How about a HashBidiMap?
>
> How is this different from the existing DualHashBidiMap?
>
> https://commons.apache.org/proper/commons-collections/
> javadocs/api-release/org/apache/commons/collections4/
> bidimap/DualHashBidiMap.html
>
> On Jul 6, 2017 09:06, "Efremov, Rodion" 
> wrote:
>
> > Hello,
> >
> >
> > I am working on a hash table based BidiMap at
> > https://github.com/coderodde/BidirectionalHashMap/blob/
> > master/src/net/coderodde/util/BidirectionalHashMap.java
> >
> > and would like to contribute it to Commons Collections. Could someone
> > working on the project discuss my contribution attempt?
> >
> >
> > Best regards,
> >
> > Rodion
> >
> > [https://avatars2.githubusercontent.com/u/1770505?v=3&s=400] > github.com/coderodde/BidirectionalHashMap/blob/
> > master/src/net/coderodde/util/BidirectionalHashMap.java>
> >
> > coderodde/BidirectionalHashMap<https://github.com/coderodde/
> > BidirectionalHashMap/blob/master/src/net/coderodde/util/
> > BidirectionalHashMap.java>
> > github.com
> > BidirectionalHashMap - My implementation of a bidirectional bijective
> hash
> > map in Java
> >
> >
> >
>

Re: [collections] How about a HashBidiMap?

[Javen O';Neal]

How is this different from the existing DualHashBidiMap?

https://commons.apache.org/proper/commons-collections/javadocs/api-release/org/apache/commons/collections4/bidimap/DualHashBidiMap.html

On Jul 6, 2017 09:06, "Efremov, Rodion"  wrote:

> Hello,
>
>
> I am working on a hash table based BidiMap at
> https://github.com/coderodde/BidirectionalHashMap/blob/
> master/src/net/coderodde/util/BidirectionalHashMap.java
>
> and would like to contribute it to Commons Collections. Could someone
> working on the project discuss my contribution attempt?
>
>
> Best regards,
>
> Rodion
>
> [https://avatars2.githubusercontent.com/u/1770505?v=3&s=400] github.com/coderodde/BidirectionalHashMap/blob/
> master/src/net/coderodde/util/BidirectionalHashMap.java>
>
> coderodde/BidirectionalHashMap BidirectionalHashMap/blob/master/src/net/coderodde/util/
> BidirectionalHashMap.java>
> github.com
> BidirectionalHashMap - My implementation of a bidirectional bijective hash
> map in Java
>
>
>

Re: Pair of nulls

[Javen O';Neal]

+1

The of method should check if all elements are null, and if so to return
the NULL singleton. This would reduce the number of objects created and
garbage collected.

So long as ImmutablePair and ImmutableTriple classes are final (not
subclassable), then identity checking could be used in place of equality
checking when comparing against a null tuple. This would be marginally
faster.

Any preference of being explicit (redundant) here?
ImmutablePair.NULL_PAIR and ImmutableTriple.NULL_TRIPLE

On May 10, 2017 7:35 PM, "Gary Gregory"  wrote:

Hi All,

Any thoughts for or against adding the following to ImmutablePair:


/**
 * An immutable pair of nulls.
 */
// This is not defined with generics to avoid warnings in call sites.
@SuppressWarnings("rawtypes")
public static final ImmutablePair NULL = ImmutablePair.of(null, null);

Same for ImmutableTriple.

?

Thank you,
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: [Collections] UnmodifiableSet/UnmodifiableList

[Javen O';Neal]

If Read-only set/UnmodifiableSet doesn't implement the Set interface, you
won't be able to use it for functions with arguments of type Set. You won't
be able to cast back to a Set because a ReadOnlySet isn't a type of Set.

The only way this would work is if java.util.Set extended
ReadOnlySet/UnmodifiableSet, and that will probably never happen.

On Mar 24, 2017 8:57 AM, "Lukasz Lenart"  wrote:

> 2017-03-23 16:55 GMT+01:00 Javen O'Neal :
> > The best solution is to document where you return an UnmodifiableSet
> versus
> > a regular Set in your Javadocs.
>
> Disagree, compare these two examples:
>
> /**
>  * An immutable set, do not try to modify it
>  */
> private Set excluded;
>
> vs
>
> private UnmodifiableSet excluded;
>
>
> Regards
> --
> Łukasz
> + 48 606 323 122 http://www.lenart.org.pl/
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [Collections] UnmodifiableSet/UnmodifiableList

[Javen O';Neal]

Because either (1) UnmodifiableSet implents the Set interface and throws an
Invalid operations working at runtime for methods that would modify the set
or (2) UnmodifiableSet does not implement the full Set interface, making it
possible to catch errors at compile time, but also making it impossible to
treat an UnmodifiableSet as a Set.
The best solution is to document where you return an UnmodifiableSet versus
a regular Set in your Javadocs.

On Mar 23, 2017 08:35, "sebb"  wrote:

> On 23 March 2017 at 15:02, Lukasz Lenart  wrote:
> > 2017-03-23 14:37 GMT+01:00 sebb :
> >> Not sure I follow.
> >>
> >> What exactly can the compiler check?
> >
> > You can declare a variable or a field of type UnmodifiableSet but
> > there is no way to create instance of the type UnmodifiableSet - there
> > is no such constructor neither factory method :)
> >
>
> You can create an instance:
>
> UnmodifiableSet us = (UnmodifiableSet)
> UnmodifiableSet.unmodifiableSet(new java.util.HashSet());
> us.clear(); // The compiler is happy with this, but it fails at
> runtime
>
> AFAICT the only way the compiler can check is to create a class or
> interface that does not have the update methods.
>
> One could potentially create a ReadOnlySet interface that is
> implemented by UnmodifiableSet.
> Similarly for the other unmodifiable Collections.
>
> However would it be worth it?
>
> > Regards
> > --
> > Łukasz
> > + 48 606 323 122 http://www.lenart.org.pl/
> >
> > -
> > 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: Best Home for Checksum Implementations?

[Javen O';Neal]

[Crypto] is another possible home since hashing and crypto are commonly
used together, but a standalone component may be easier for other projects
to use with regard to technology export control and easier for [Checksum]
to grow without revving a more mature library like [Crypto].

On Jan 24, 2017 12:27, "Gary Gregory"  wrote:

> These two implement java.util.zip.Checksum BTW.
>
> Gary
>
> On Tue, Jan 24, 2017 at 12:25 PM, Gary Gregory 
> wrote:
>
> > Commons Codec already has:
> >
> > org.apache.commons.codec.digest.PureJavaCrc32
> > org.apache.commons.codec.digest.PureJavaCrc32C
> >
> > This is in SVN slated for 1.11.
> >
> > Gary
> >
> >
> > On Tue, Jan 24, 2017 at 1:08 AM, Stefan Bodewig 
> > wrote:
> >
> >> Hi
> >>
> >> inside of [compress] we've already got an implementation of CRC32C (used
> >> by Snappy, "borrowed" from Hadoop) and will soonish have xxhash32 (used
> >> by LZ4).
> >>
> >> I was wondering whether these implementations would belong in one of the
> >> other components (as well as - rather than instead of - compress) but
> >> I'm not sure where it would fit.
> >>
> >> [codec] and [io] could be candidates but neither holds any
> >> java.util.zip.Checksum implementations as of now.
> >>
> >> Neither CRC32C nor xxhash32 are cryptographic hashes so using codec's
> >> digest package feels wrong.
> >>
> >> Stefan
> >>
> >> -
> >> 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
> >  tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459&
> linkCode=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b1af9fe6a2b8>
> >
> >  1617290459>
> > JUnit in Action, Second Edition
> >  tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021&
> linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de418%22
> >
> >
> >  1935182021>
> > Spring Batch in Action
> >  tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951&
> linkCode=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B%
> 7Blink_id%7D%7D%22%3ESpring+Batch+in+Action>
> >  1935182951>
> > Blog: http://garygregory.wordpress.com
> > Home: http://garygregory.com/
> > Tweet! http://twitter.com/GaryGregory
> >
>
>
>
> --
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> Java Persistence with Hibernate, Second Edition
>  tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459&
> linkCode=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b1af9fe6a2b8>
>
>  1617290459>
> JUnit in Action, Second Edition
>  tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021&
> linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de418%22
> >
>
>  1935182021>
> Spring Batch in Action
>  tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951&
> linkCode=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B%
> 7Blink_id%7D%7D%22%3ESpring+Batch+in+Action>
>  1935182951>
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>

[collections] a list class with fast indexOf(Object) and contains(Object)

[Javen O';Neal]

On the Apache POI project (Java library to read and write Microsoft
Office files), we are using a List to store the fonts (XSSFFont) used
in an Excel workbook's style table (XSSFWorkbook.getStylesSource() ->
StyleTable) [1].

To avoid bloating the style table with duplicate fonts, we check if
the font is in the style table and return the index. Otherwise we add
the font and return the index. However, we do allow the list to
contain duplicate fonts.

The problem is ArrayList.indexOf(Object) and
ArrayList.contains(Object) are slow on large lists, described in bug
58740 [2]. Archie Cobbs' patch fixed the slowness by adding a reverse
mapping of list entry to list index (HashSetValuedHashMap [3]) in addition to the list (List). This works,
but I felt it would be better to capture this complexity in a data
structure to keep StylesTable as simple as possible.

I originally looked at the collections4.1 BidiMap [4] implementations,
but these did not offer the same iteration order as a list and do not
allow duplicate XSSFFonts.
I also saw ListOrderedMap [5], but this does not allow duplicates and
I would rather expose a List interface than a Map.
None of the collections4.1 List [6] implementations meet the
reverse-lookup need.

I am writing a class that implements the List interface that uses a
List and a HashSetValuedHashMap, but wanted to see if there are
similar or better existing implementations that can solve my problem.
All suggestions are appreciated.

Requirements:
1. Implements List interface
2. Iteration order is ascending list order
3. Fast (O(log n) or better) get(index), get(Object), add(Object),
indexOf(Object), lastIndexOf(Object), contains(Object), and
iterator().next() operations.
4. Not part of the list interface, but finding duplicate objects via
getIndices(Object)->Collection would be helpful.
5. Constant-time (O(1)) size()

Nice to have for a general-purpose class, but not needed for my application
4. Fast (O(log n) or better) set(index, Object), add(index, Object),
remove(index), remove(Object)


[1] list data structures used in StylesTable
https://svn.apache.org/viewvc/poi/trunk/src/ooxml/java/org/apache/poi/xssf/model/StylesTable.java?revision=1748898&view=markup#l70

[2] Increase StylesTable performance
https://bz.apache.org/bugzilla/show_bug.cgi?id=58740

[3] HashSetValuedHashMap
https://commons.apache.org/proper/commons-collections/javadocs/api-release/org/apache/commons/collections4/multimap/HashSetValuedHashMap.html

[4] BidiMap 
https://commons.apache.org/proper/commons-collections/javadocs/api-release/org/apache/commons/collections4/BidiMap.html

[5] ListOrderedMap
https://commons.apache.org/proper/commons-collections/javadocs/api-release/org/apache/commons/collections4/map/ListOrderedMap.html

[6] List 
https://commons.apache.org/proper/commons-collections/javadocs/api-release/org/apache/commons/collections4/list/package-summary.html

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