In our particular case. Hadoop mapreduce creates the issue
On Sun, Feb 14, 2010 at 3:25 AM, Benson Margulies <bimargul...@gmail.com>wrote:
> Ted: I agree. I forgot about that case.
>
> Robin: There is a strange general habit in Java of this situation.
> Consider Thread. I'm perfectly happy to add the throws clause, but one
> might wonder why the 'classic' examples all have the problem you cite.
>
>
> On Sat, Feb 13, 2010 at 4:20 PM, Robin Anil <robin.a...@gmail.com> wrote:
> > On the topic of code cleanup.
> >
> > Current OpenXXYYhashmaps has to throw runtime exception on an IOException
> in
> > Hadoop
> >
> > This will make that statement clear
> >
> > void map(Text key, Text value, final OutputCollector output){
> >
> > forEachPair(function(){
> > @Override
> > bool apply(key, value){
> > try {
> > do something;
> > output.collect(key1,value1);
> > }
> > catch(IOException e){
> > throw new RuntimeException(e);
> > }
> > return true;
> > }
> > }
> >
> > }
> >
> >
> > What to do here? Why not let ObjectProcedure class throw Exception ?
> >
> >
> >
> >
> > On Sun, Feb 14, 2010 at 2:37 AM, Robin Anil <robin.a...@gmail.com>
> wrote:
> >
> >> final doesnt necessarily mean mutable right?
> >>
> >>
> >> On Sun, Feb 14, 2010 at 2:35 AM, Benson Margulies <
> bimargul...@gmail.com>wrote:
> >>
> >>> I'm not very fond of a plague of finals. Here's why.
> >>>
> >>> Consider
> >>>
> >>> final int[] x = new int[10];
> >>>
> >>> That doesn't, sadly, prevent
> >>>
> >>> x[2] = 1;
> >>>
> >>> So, to me, final is too weak to be useful. I put them in code when
> >>> required due to the rules about anonymous functions capturing locals,
> >>> but never otherwise.
> >>>
> >>> Just my 1cent on this subject.
> >>>
> >>>
> >>> On Sat, Feb 13, 2010 at 3:21 PM, Robin Anil <robin.a...@gmail.com>
> wrote:
> >>> > Only done for local fields. And handpicked ones in bayes for local
> >>> variables
> >>> > due to openXXYYHashMap.foreach() requiring final objects
> >>> >
> >>> >
> >>> > On Sun, Feb 14, 2010 at 1:47 AM, Ted Dunning <ted.dunn...@gmail.com>
> >>> wrote:
> >>> >
> >>> >> I find final slightly helpful on fields, very helpful on static
> fields,
> >>> but
> >>> >> not very helpful at all on local variables. The issue is scale.
> With
> >>> a
> >>> >> field there are lots of places you can bugger it up. If the scope
> of a
> >>> >> local is large enough for similar confusion, you have a different
> >>> problem
> >>> >> anyway.
> >>> >>
> >>> >> I am generally -1 to too many final declarations on parameters and
> >>> local
> >>> >> variables, but I don't go to the trouble of deleting them if I see
> >>> them.
> >>> >>
> >>> >> On Sat, Feb 13, 2010 at 11:03 AM, Sean Owen <sro...@gmail.com>
> wrote:
> >>> >>
> >>> >> > I'm late on this but have a question about the final business. I
> >>> >> understand
> >>> >> > the style it is promoting and even like it and used to do it. I
> >>> stopped
> >>> >> > because it does get harder to read and its not usual in java code.
> >>> Any
> >>> >> > thoughts on that.
> >>> >> >
> >>> >> > On Feb 13, 2010 2:55 PM, "Robin Anil" <robin.a...@gmail.com>
> wrote:
> >>> >> >
> >>> >> > I just did a mass code cleanup.
> >>> >> >
> >>> >> > Mainly comprising of
> >>> >> > -Extra blank line removal
> >>> >> > -Organize Imports across all packages.
> >>> >> > -Making local variables final
> >>> >> >
> >>> >> > No reordering of methods or code style changes are applied.
> >>> >> >
> >>> >> > Any objections or any particular class to withhold from
> committing.
> >>> >> >
> >>> >> > Robin
> >>> >> >
> >>> >>
> >>> >>
> >>> >>
> >>> >> --
> >>> >> Ted Dunning, CTO
> >>> >> DeepDyve
> >>> >>
> >>> >
> >>>
> >>
> >>
> >
>
