constructing a constant HashMap

[Roedy Green]

What is your preferred way of building a HashMap when all the values
are known at compile time?
--
Roedy Green Canadian Mind Products
http://mindprod.com
It should not be considered an error when the user starts something
already started or stops something already stopped. This applies
to browsers, services, editors... It is inexcusable to
punish the user by requiring some elaborate sequence to atone,
e.g. open the task editor, find and kill some processes.

 

[Arne Vajhøj]

What is your preferred way of building a HashMap when all the values
are known at compile time?

new
multiple put's
Collection unmodifiableMap

and move on to something more important.

Arne

 

[markspace]

What is your preferred way of building a HashMap when all the values
are known at compile time?

EnumMap is one possibility.

But I think the answer depends on how many values, how you intend to use
them, efficiency concerns, how the values are "known," etc.

In other words, it depends on requirements.

 

[Roedy Green]

What is your preferred way of building a HashMap when all the values
are known at compile time?

I have posted some options at
http://mindprod.com/jgloss/hashmap.html#INITIALISATION
--
Roedy Green Canadian Mind Products
http://mindprod.com
It should not be considered an error when the user starts something
already started or stops something already stopped. This applies
to browsers, services, editors... It is inexcusable to
punish the user by requiring some elaborate sequence to atone,
e.g. open the task editor, find and kill some processes.

 

[Roedy Green]

EnumMap is one possibility.

what does your init code look like?
--
Roedy Green Canadian Mind Products
http://mindprod.com
It should not be considered an error when the user starts something
already started or stops something already stopped. This applies
to browsers, services, editors... It is inexcusable to
punish the user by requiring some elaborate sequence to atone,
e.g. open the task editor, find and kill some processes.

 

[B1ll Gat3s]

If the map is a field, I often use an instance or static initializer
immediately after the map's declaration:

Map<String,String> myMap = new HashMap<String,String>();
{
myMap.put("aaa", "bbb");
...
}

Patricia

This works in ANY setting where an expression of type Map<String,String>
is appropriate:

new HashMap<String,String> () {
{
put("aaa", "bbb");
...
}}

 

[Arved Sandstrom]

If the map is a field, I often use an instance or static initializer
immediately after the map's declaration:

Map<String,String> myMap = new HashMap<String,String>();
{
myMap.put("aaa", "bbb");
...
}

Patricia

Same here, actually. Glad you pointed that out. Doing it this way is
more clear than having some init() method some place.

AHS

 

[Daniele Futtorovic]

new
multiple put's
Collection unmodifiableMap

and move on to something more important.

Arne

+1

 

[Daniel Pitts]

What is your preferred way of building a HashMap when all the values
are known at compile time?

public class StaticHash {
private static final Map<String, String> map;

static {
Map<String, String> mutableMap = new HashMap<String,String>();
mutableMap.put("First Key", "First Value");
mutableMap.put("Second Key", "Second Value");
mutableMap.put("Third Key", "Third Value");
map = Collections.unmodifiableMap(mutableMap);
}
}

Or

enum MyKeys {
FIRST("First Value"),
SECOND("Second Value"),
THIRD("Third Value")
;
private final String value;
private MyKeys(String value) { this.value = value; }
//... if you need a reverse look-up, static initializer (as above)
// that builds the reverse look-up map
}

 

[Tom Anderson]

For static final variables (suggested by "all the values are known at
compile time"), i would suggest a slight variation:

static final Map<String,String> myMap;
static {
Map<String,String> tmpMap = new HashMap<String,String>();
tmpMap.put("aaa", "bbb");
myMap = Collections.unmodifiableMap(tmpMap);
}

This works in ANY setting where an expression of type Map<String,String> is
appropriate:

new HashMap<String,String> () {
{
put("aaa", "bbb");
...
}}

This is called a 'double brace initializer', and it is a very useful but
also highly surprising construct (i love dropping one in front of my pair
when pair programming, and watching their brains trying to work out what's
going on - it takes a while to realise it's not a special syntax, just a
combination of two other bits of syntax). See:

http://c2.com/cgi/wiki?DoubleBraceInitialization

I use this form a lot in unit tests, when i need to set up a map quickly,
but less so in 'real' code. It creates lots of anonymous subclasses, which
i am nervous about doing.

tom

 

[Arne Vajhøj]

This works in ANY setting where an expression of type Map<String,String>
is appropriate:

new HashMap<String,String> () {
{
put("aaa", "bbb");
...
}}

But it is way more difficult to read and therefore be more
costly to maintain.

Will most likely be slower and use more memory (for the class).

And it may break some code that does a bad test on class.

Not a very attractive solution.

Arne

 

[B1ll Gat3s]

But it is way more difficult to read

No it isn't.

 

[Daniel Pitts]

No it isn't.

That is opinion.

The syntax in question is a bit esoteric and would therefor have a
greater potential to confuse maintainers with less experience.

Also, if someone doesn't think hard about what that really is doing,
they may not fully understand the consequences of that approach.

The more I think about this "problem", the more I think that a
properties file may be more appropriate than an "in code" solution for
most cases.

 

[David Lamb]

The more I think about this "problem", the more I think that a
properties file may be more appropriate than an "in code" solution for
most cases.

I also think you're right -- there's a basic principle of "late binding"
of decisions so they're easier to change, and "separation of concerns"
(so, for example, you keep the code separate from its data).

 

[Arne Vajhøj]

No it isn't.

Yes - it is.

Read what Tom wrote:

#and it is a very useful but also highly surprising construct (i love
#dropping one in front of my pair when pair programming, and watching
#their brains trying to work out what's going on - it takes a while to
#realise it's not a special syntax, just a combination of two other
#bits of syntax).

Arne

 

[Lew]

Yes - it is.

Read what Tom wrote:

#and it is a very useful but also highly surprising construct (i love
#dropping one in front of my pair when pair programming, and watching
#their brains trying to work out what's going on - it takes a while to
#realise it's not a special syntax, just a combination of two other
#bits of syntax).

Yeah, but once you're used to it it's quite readable. So you're both right..

The question of "readability" shouldn't be treated like an absolute - it isor it ain't. Readability is relative to experience and cognitive style. To someone not trained in computer programmers, none of it is readable. Toa junior programmer, anonymous classes are rather "unreadable". Should you eschew them for that reason? To a slightly less junior programmer the anonymous-class/initializer combination cited here is strange, but should youreally code to his level? Or maybe should that programmer up their skill a little and stop being so namby-pamby about legitimate, useful syntax?

There's also a relative readability between that idiom and alternatives to load a Map. There's gotta be an initializer somewhere, folks!

Personally, I don't like the overly-clever anonymous/initializer idiom. I prefer a stodgy old separate initializer block and a non-subclasses HashMap.. I think it's more readable that way than the tricky subclass way presented here.

 

[Arne Vajhøj]

Yeah, but once you're used to it it's quite readable. So you're both right.

The question of "readability" shouldn't be treated like an absolute - it is or it ain't. Readability is relative to experience and cognitive style. To someone not trained in computer programmers, none of it is readable. To a junior programmer, anonymous classes are rather "unreadable". Should you eschew them for that reason? To a slightly less junior programmer the anonymous-class/initializer combination cited here is strange, but should you really code to his level? Or maybe should that programmer up their skill a little and stop being so namby-pamby about legitimate, useful syntax?

There's also a relative readability between that idiom and alternatives to load a Map. There's gotta be an initializer somewhere, folks!

Personally, I don't like the overly-clever anonymous/initializer idiom. I prefer a stodgy old separate initializer block and a non-subclasses HashMap. I think it's more readable that way than the tricky subclass way presented here.

Readability is relative to the reader.

But let me rephrase to: this construct will puzzle significant
more developers than the other solutions suggested.

Arne

 

[Ian Pilcher]

But let me rephrase to: this construct will puzzle significant
more developers than the other solutions suggested.

Since that seems to be the goal of so many developers, the "double
brace" solution is obviously the best.

 

[Arne Vajhøj]

Since that seems to be the goal of so many developers, the "double
brace" solution is obviously the best.

Then the conclusion must be that there are too few axe murderers
around!



Arne

 

[B1ll Gat3s]

Yes - it is.

No - it's not.