In theory we should be entirely on new, undeprecated Hadoop APIs (the 0.20.x+ APIs). In practice that's not so and I don't know how or when the stragglers will be updated. But the goal is most certainly to not use JobConf at all.
However as we've agreed to require 0.20.2, it's fair game to use Configuration where possible. I'll have a look to see just how much can be updated. My code inspections ought to have picked up a lot of those already. On Mon, Dec 20, 2010 at 3:54 AM, Lance Norskog <[email protected]> wrote: > The old Hadoop JobConf class is a subclass of the new Configuration > class. Unforch, some classes still require the JobConf class when they > don't use any of it's methods, and use it as a Configuration. This > means that when your code uses Configuration, you can't use one of the > old-school classes when really you could. > > The org.apache.mahout.common.parameters.Parameter classes should all > take Configuration in the constructors, if they have constructors > (some don't). Some still take JobConif and then upcast them with the > super() call. > > This make it hard to write a DistanceMeasure that takes a parameter: > TanimotoDistanceMeasure takes two: PathParameter is in the second > list, and it makes a Vector Parameter using the ClassParameter > extension which is also in the second list. I'm using the > ClassParameter dodge to make a Double Parameter that works with a > Configuration. > > These take a JobConf in the constructor: > StringParameter > IntegerParameter > FileParameter > DoubleParameter > > This takes a Configuration in some methods: > Parametered Interface > > These take a Configuration in the constructor: > PathParameter > CompositeParameter > ClassParameter > AbstractParameter > > I have not done a sweep of the source base to find other instances of > this. Not being a committer, it's not really pointful. > > -- > Lance Norskog > [email protected] >
