From user-return-27245-apmail-commons-user-archive=commons.apache.org@commons.apache.org Wed Mar 21 17:45:02 2012
Return-Path:
X-Original-To: apmail-commons-user-archive@www.apache.org
Delivered-To: apmail-commons-user-archive@www.apache.org
Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
by minotaur.apache.org (Postfix) with SMTP id 244519DC3
for ; Wed, 21 Mar 2012 17:45:02 +0000 (UTC)
Received: (qmail 70200 invoked by uid 500); 21 Mar 2012 17:45:00 -0000
Delivered-To: apmail-commons-user-archive@commons.apache.org
Received: (qmail 70111 invoked by uid 500); 21 Mar 2012 17:45:00 -0000
Mailing-List: contact user-help@commons.apache.org; run by ezmlm
Precedence: bulk
List-Help:
List-Unsubscribe:
List-Post:
List-Id:
Reply-To: "Commons Users List"
Delivered-To: mailing list user@commons.apache.org
Received: (qmail 70103 invoked by uid 99); 21 Mar 2012 17:45:00 -0000
Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136)
by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 21 Mar 2012 17:45:00 +0000
X-ASF-Spam-Status: No, hits=2.2 required=5.0
tests=HTML_MESSAGE,SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (athena.apache.org: local policy)
Received: from [80.237.132.241] (HELO wp234.webpack.hosteurope.de) (80.237.132.241)
by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 21 Mar 2012 17:44:54 +0000
Received: from hsi-kbw-149-172-169-13.hsi13.kabel-badenwuerttemberg.de ([149.172.169.13] helo=[192.168.10.159]); authenticated
by wp234.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32)
id 1SAPaK-0005HJ-Ce; Wed, 21 Mar 2012 18:44:32 +0100
Message-ID: <4F6A137D.5080308@chrismay.de>
Date: Wed, 21 Mar 2012 18:44:29 +0100
From: Christof May
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7
MIME-Version: 1.0
To: user@commons.apache.org
Subject: [configuration] Enum constants as keys
Content-Type: multipart/alternative;
boundary="------------050802060508080208020909"
X-bounce-key: webpack.hosteurope.de;mail@chrismay.de;1332351894;89e90794;
X-Virus-Checked: Checked by ClamAV on apache.org
--------------050802060508080208020909
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
Hi all,
I'm not sure if this issue has been discussed before (couldn't find
anything on the mail list thou...), but what do you guys think of using
type-safe enum constants as keys instead of plain String values?
I assume there is a general understanding here that using enum constants
instead of strings is the "right thing" to do, but obviously there are
also important reasons not do so (legacy code, interface changes,
pre-Java1.5 stuff etc...). But I guess the most important one is that
Java enums never have been designed to work in a generic form (namely:
no abstract enums and/or enum inheritance). So there is no way to put an
enum placeholder in a library, and provide the concrete enum values in
the implementing application. An issue which I and other people already
have bemoaned (see
http://java.dzone.com/articles/java-should-have-extended for example),
but it is nevertheless a given fact we have to live with in the
foreseeable future... :(
Having said that, I just see two ways of using enum constants for
fetching config values. For one just using a lame
config.getWhatever(MyEnum.key.name()) everywhere. It would be a start,
but well.. not really what I was searching for...
The other solution I see would be to mark the enums with a marker
interface, and take that as the key placeholder, such as:
public interface Configurable {
public String name();
}
public interface Configuration {
boolean getBoolean(Configurable key);
(other methods follow here...)
}
In the application you would define the keys in an enum such as that:
public enum MyKeys implements Configurable {
FOO,
BAR,
...;
}
Then you could access the config values in real type-safe way:
boolean myValue = config.getBoolean(MyKeys.BAR);
Another advantage would be that enum constants can be easily enriched
with meta-data (via a custom annotation), for example:
public enum MyKeys implements Configurable {
@ConfigData(
defaultValue="foo",
type=String.class,
mandatory=true,
pattern="[a-z]{1,4}",
reload=false)
FOO,
...;
}
The possibilities here are endless (see also my pet project at
www.soplets.org exploring more in-depth the meta-data aspects of
annotations), but for a beginning having just enum constants alone would
be a good start in my view...
What do you think about that proposal, does that make any sense? Any
other options I have overlooked so far? Looking forward hearing your
opinions...
regards,
Chris May
--------------050802060508080208020909--