Henning,
The changes I just made were to conform with API changes for Google
Collections 0.8. I didn't arbitrarily make any "changes" here. The
code uses exactly the same amount of Google Collections it did 12
hours ago.
If you had taken a few minutes to look at the actual usage of Google
Collections you might have realized that the use is pervasive:
35 import com.google.common.collect.Maps;
21 import com.google.common.collect.Lists;
11 import com.google.common.collect.Sets;
4 import com.google.common.collect.ImmutableSet;
4 import com.google.common.collect.ImmutableMap;
1 import com.google.common.collect.ReferenceMap;
1 import com.google.common.collect.Iterables;
1 import com.google.common.collect.ImmutableSortedSet;
1 import com.google.common.collect.*;
Now, if you want this to change you're going to have to use a little
diplomacy and tact and not jump to conclusions.
Also, specifically to address your comments.
* Re: Maps.immutableMap vs Collections.singletonMap:
public static <K,V> ImmutableMap<K,V> of (K k1, V v1)
Returns an immutable map containing a single entry. This map behaves
and performs comparably to Collections.singletonMap() but will not
accept a null key or value. It is preferable mainly for consistency
and maintainability of your code.
* Collections.unmodifiableMap(... stuff ...) vs ImmutableMap.of(...)
Collections.unmodifiableMap only provides a wrapper on top of an
existing Map, whereas the ImmutableMap uses it's own optimized
internal datastrctures.
Personally I like Google Collections. The Immutable objects are
compact and fast. The static helper methods increase code
readability. The filters, iterators, and functions are very
"functional". I feel like using more of these features now!
-- Paul
On Dec 9, 2008, at 7:55 PM, Henning P. Schmiedehausen wrote:
[EMAIL PROTECTED] writes:
try {
-
decoder
.createToken
(Maps.immutableMap(SecurityTokenDecoder.SECURITY_TOKEN_NAME,
encrypted));
+
decoder
.createToken
(ImmutableMap.of(SecurityTokenDecoder.SECURITY_TOKEN_NAME,
encrypted));
That makes no sense. This is a change for the sake of changing. If you
want to change this, please use
Collections.singletonMap(SecurityTokenDecoder.SECURITY_TOKEN_NAME,
encrypted) from the JDK. Adding dependencies just for the sake of
adding them makes no sense at all.
-
decoder
.createToken
(Maps.immutableMap(SecurityTokenDecoder.SECURITY_TOKEN_NAME,
encrypted));
+
decoder
.createToken
(ImmutableMap.of(SecurityTokenDecoder.SECURITY_TOKEN_NAME,
encrypted));
Collections.singletonMap()
+
decoder
.createToken
(ImmutableMap.of(SecurityTokenDecoder.SECURITY_TOKEN_NAME,
encrypted));
Collections.singletonMap()
-
decoder
.createToken
(Maps.immutableMap(SecurityTokenDecoder.SECURITY_TOKEN_NAME, "foo"));
+
decoder
.createToken
(ImmutableMap.of(SecurityTokenDecoder.SECURITY_TOKEN_NAME, "foo"));
Collections.singletonMap()
- Map<String, String> empty = Maps.immutableMap();
+ Map<String, String> empty = ImmutableMap.of();
Collections.emptyMap();
[...]
- Map<String, String> map = Maps.immutableMap("hello", "world",
"foo", "bar");
+ Map<String, String> map = ImmutableMap.of("hello", "world",
"foo", "bar");
If this is the *only* reason we are dragging in the Google collections
stuff, we should replace this with a helper that uses
Collections.unmodifiableMap(... stuff ...) and rip it out completely.
Ciao
Henning
--
Henning P. Schmiedehausen - Palo Alto, California, U.S.A.
[EMAIL PROTECTED] "We're Germans and we use Unix.
[EMAIL PROTECTED] That's a combination of two demographic
groups
known to have no sense of humour
whatsoever."
-- Hanno Mueller,
de.comp.os.unix.programming
Paul Lindner
[EMAIL PROTECTED]
