hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Doug Cutting (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HADOOP-24) make Configuration an interface
Date Fri, 19 May 2006 19:26:30 GMT
    [ http://issues.apache.org/jira/browse/HADOOP-24?page=comments#action_12412580 ] 

Doug Cutting commented on HADOOP-24:

API back-compatibility is important.  We'd like folks to be able to upgrade to new releases
without having to change their code.  The convention we've had is that, code which compiles
against release 0.X without deprecation warnings will still compile against release 0.X+1,
but may require changes to compile against release 0.X+2.  Is that reasonable?

If so, then 'new Configuration()' must still create a usable configuration and not a compilation
error in release 0.3.  It may be deprecated, but it should still work.  Yes, this is a pain,
since Configuration would be a great name for the interface, but there's code out there (more
than just Nutch) that we should try not to break.  Nutch is a good, public test case for this
sort of back-compatibility, that's the reason I mention it.

Another approach might be to use a new package.  We could put the new classes in org.apache.hadoop.config,
and then have org.apache.hadoop.conf.Configuration be a deprecated subclass of org.apache.hadoop.config.ConfigurationImpl.
 Then, after 0.3 is released, we could remove the entire org.apache.hadoop.conf package.

> make Configuration an interface
> -------------------------------
>          Key: HADOOP-24
>          URL: http://issues.apache.org/jira/browse/HADOOP-24
>      Project: Hadoop
>         Type: Improvement

>   Components: conf
>     Reporter: Doug Cutting
>  Attachments: HADOOP-24-2.patch, HADOOP-24-3.patch, HADOOP-24-4.patch, HADOOP-24.patch,
> The Configuration class should become an interface, e.g.:
> public interface Configuration {
>   String get(String nam);
>   String set(String name, String value);
>   int getInt(String name);
>   void setInt(String name, int value);
>   float getFloat(String name);
>   void setFloat(String name, float value);
>   //... other utility methods based on get(String) and set(String,String) ...
> }
> An abstract class named ConfigurationBase should be implemented as follows:
> public abstract class ConfigurationBase implements Configuration {
>   abstract public String get(String nam);
>   abstract public String set(String name, String value);
>   public  int getInt(String name) { ... implementation in terms of get(String) ... }
>   public void setInt(String name, int value) {... implementation in terms of set(String,
String) ...}
>   public float getFloat(String name)  { ... implementation in terms of get(String) ...
>   public void setFloat(String name, float value)  {... implementation in terms of set(String,
String) ...}
>   //... other utility methods based on get(String) and set(String,String) ...
> }
> A concrete, default implementation will be provided as follows:
> public class ConfigurationImpl implements Writable extends ConfigurationBase {
>   private Properties properties;
>   // implement abstract methods from ConfigurationBase
>   public String get(String name) { ... implemented in terms of props ...}
>   public String set(String name, String value) { .. implemented in terms of props ...
>   // Writable methods
>   public write(DataOutputStream out);
>   public readFields(DataInputStream in);
>   // permit chaining of configurations
>   public Configuration getDefaults();
>   public void setDefaults(Configuration defaults);
> }
> Only code which creates configurations should need to be updated, so this shouldn't be
a huge change.

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:

View raw message