Goldstein Lyor commented on SSHD-824:

[~gnt] I have read the links you provided and while they make some valid 
arguments, I do not agree that they apply for the
public static final X = Collections.unmodifiable(new Something() { ... 
initialize ...});
use case. However, like I said, I have no objection to the type of refactoring 
you are proposing, and don't mind adhering to this pattern on the SSHD project.

Of the 2 options you show I strongly favor the 1st one that uses a fluent 
language. In this context, we should have different map/set builders - for 
{{HashMap/Set}} vs. {{TreeMap/Set}} vs. {{EnumSet/Map}} - e.g.:
// add a navigableMapBuilder() method that simply invokes the one with the 
comparator argument using Comparator.naturalOrder()
public static final NavigableMap<X, Y> sortedMap = 
     .build() or .immutable();

// add hashMapBuilder(), hashMapBuilder(int size) methods that delegate calls 
to the hashMapBuilder(size, factor) method
public static final Map<X, Y> hashedMap = GenericUtils.hashMapBuilder(size, 
     .build() or .immutable();

public static final Set<MyEnum> enumSet = 
   .build() or .immutable();

public static final Map<MyEnum, MyValue> enumSet = 
   .build() or .immutable();

// add similar navigableSetBuilder(comparator) and hashSetBuilder(size) methods
// ditto for listBuilder() -> delegate to listBuilder(capacity)
Please consider using a new utility class instead of {{GenericUtils}} since 
{{GenericUtils}} is becoming too cluttered - if you agree, please feel free to 
call the new utility class however you like.

In this context, please consider also adding

* _linkedListBuilder()_ that returns a _LinkedList<>_ and not just a 
_Collection<>_ - this is because _LinkedList_ also implements _Deque<E>_ which 
is a useful interface, and the user might want to say
Deque<X> q = GenericUtils.linkedListBuilder().add(..).add(...).build();
* _addAll_ and _putAll_ methods for the _set/list/mapBuilder_ respectively
* Consider adding _build(Supplier<? extends M> map/set/listCreator)_ method to 
allow users to decide which list/map/set they want to create (similar to the 

> Do not use anonymous inner classes to initialize collections
> ------------------------------------------------------------
>                 Key: SSHD-824
>                 URL: https://issues.apache.org/jira/browse/SSHD-824
>             Project: MINA SSHD
>          Issue Type: Task
>            Reporter: Guillaume Nodet
>            Priority: Major
> This is an abuse of the Object model.
> If needed, introduce a collection builder, especially for immutable 
> collections.

This message was sent by Atlassian JIRA

Reply via email to