I did a quick grep through 3.1 and found these for consideration, too: HessianUtil.java [1] DataObjectUtils.java [2] JoinTreeNode.java [3] FlattenedArcKey.java [3] PropertyComparator.java [1] ConversionUtil.java [1] LinkedDeque.java [1]
[1] Yes [2] Yes, even though deprecated. [3] Perhaps, didn't search for usage patterns. mrg On Sat, Mar 9, 2013 at 2:02 AM, Christian Grobmeier <[email protected]>wrote: > On Fri, Mar 8, 2013 at 10:01 PM, Michael Gentry <[email protected]> > wrote: > > Cool. Should I remove it in 3.1 and 3.2 both? > > > > BTW, I was curious how other utility packages worked and Apache Commons > > doesn't do final, either: > > > > > http://commons.apache.org/proper/commons-lang//apidocs/org/apache/commons/lang3/StringUtils.html > > When I remember correctly there was a discussion on Commons on final > before ages and i think the outcome was final classes are usually not > needed and should be avoided. > > Personally I think final is not so nice, because you can't know what > people do. If there are not really good reasons for a final class, > like extending String would probably mess up the string constant pool > or so, I prefer to avoid it. > > If it is only there because of compiler optimization, I think modern > compilers can optimize a static method only class without the final > modifier - but I have no reference to prove it. > > Cheers > Christian > > > > Thanks, > > > > mrg > > > > > > On Fri, Mar 8, 2013 at 2:50 PM, Andrus Adamchik <[email protected] > >wrote: > > > >> BTW, even though this won't be my coding style to extend o.a.c.Cayenne, > I > >> have nothing against removing "final" from it. > >> > >> > >> On Mar 8, 2013, at 6:45 PM, Michael Gentry <[email protected]> > wrote: > >> > Well, they "inherit" in the ability to call them. For example, if you > >> had: > >> > > >> > public class CayenneUtil extends Cayenne > >> > { > >> > // Many more static utility methods here > >> > } > >> > > >> > You could still then still call: > >> > > >> > CayenneUtil.intPKForObject(artist) > >> > > >> > This will call the "inherited" Cayenne.java method, plus you can call > >> your > >> > project-defined utilities with the same class. I see this as being > more > >> > user-friendly. I'm not talking about redefining the static methods, > but > >> > compositing new static methods in a subclass for simplification of > >> calling > >> > Cayenne-supplied utility methods and project-supplied utility methods. > >> > > >> > Thanks, > >> > > >> > mrg > >> > > >> > > >> > On Fri, Mar 8, 2013 at 10:27 AM, Andrus Adamchik < > [email protected] > >> >wrote: > >> > > >> >> Yeah. All its methods are static. There's no static inheritance in > Java > >> >> (unlike in say Objective C, you can't truly redefine a static > method). > >> So > >> >> there's no instance behavior to inherit. In my mind this is a good > >> reason > >> >> to not ever want to subclass "Cayenne". > >> >> > >> >> Of course API style often comes down to personal preferences :) > >> >> > >> >> Andrus > >> >> > >> >> On Mar 8, 2013, at 4:22 PM, Michael Gentry <[email protected]> > >> wrote: > >> >> > >> >>> I was just looking at Cayenne.java introduced in 3.1 and noticed > that > >> it > >> >> is > >> >>> declared to be a final class. Is there any reason for this? I can > >> quite > >> >>> easily see people wanting to subclass it to add their own utility > >> methods > >> >>> which would make it easier for all those utilities to be grouped > >> together > >> >>> in one bigger class rather than spread out over several classes > (from > >> an > >> >>> end-user's perspective of having to deal with different imports to > >> access > >> >>> the utilities -- obviously there would still be multiple classes, it > >> >> would > >> >>> just be better hidden). > >> >>> > >> >>> Thanks, > >> >>> > >> >>> mrg > >> >> > >> >> > >> > >> > > > > -- > http://www.grobmeier.de > https://www.timeandbill.de >
