Any ideas how to avoid this code checker error?
in [Java Programming]
|
From: Wojtek on 29 Jan 2010 16:13 John B. Matthews wrote : > In article <mn.e9df7da189db388f.70216(a)a.com>, Wojtek <nowhere(a)a.com> > wrote: > >> Lew wrote : >>> Roedy Green wrote: >>>> On Wed, 27 Jan 2010 19:12:07 -0500, Lew <noone(a)lewscanon.com> wrote, >>>> quoted or indirectly quoted someone who said : >>>> >>>>> - 'LOG' does not follow the Java coding conventions: >>>>> <http://java.sun.com/docs/codeconv/index.html> >>>> >>>> how can you tell without seeing his declaration for LOG? >>> >>> I explained my reasoning, and why it was wrong, upthread, but I'll >>> recap for your sake, since either you didn't read it, or didn't >>> understand it. or didn't read the links, or didn't understand them. >>> >>> The code convention document (not the JLS, though) suggests using all >>> upper-case names only for class constants. The OP's code >>> >>> LOG.error(e.getMessage(), e); >>> >>> shows that 'LOG' is not a class constant. QED. >> >> In which way? Because LOG has a method? >> >> Then what about a String? It has methods. > > I struggle with this, too. In _Effective Java_, item 56, Joshua Block > expands the notion of class constant to include static final fields > having a primitive type or an immutable reference type: > > static final Random RANDOM = new Random(); > static final Integer ANSWER = Integer.valueOf(42); > > I'm not sure how to apply this to java.util.logging.Logger. And then you have enum. Which can have a constructor with parameters. Which will then have methods to get at those parameters. And an enum value is all upper case. I am not confused at all. If it is static and final, then it is a class constant. The fact that it has attributes which can be modified (if exposed) is a moot point. The _reference_ cannot be changed, and so it is a constant. Where I use classes as constants, I also make sure that there are no setters, which preserves the original state of the object. -- Wojtek :-)
From: John B. Matthews on 29 Jan 2010 16:27 In article <mn.eb197da1e9e48642.70216(a)a.com>, Wojtek <nowhere(a)a.com> wrote: > John B. Matthews wrote : > > In article <mn.e9df7da189db388f.70216(a)a.com>, Wojtek <nowhere(a)a.com> > > wrote: [...] > >> Then what about a String? It has methods. > > > > I struggle with this, too. In _Effective Java_, item 56, Joshua Block > > expands the notion of class constant to include static final fields > > having a primitive type or an immutable reference type: > > > > static final Random RANDOM = new Random(); > > static final Integer ANSWER = Integer.valueOf(42); > > > > I'm not sure how to apply this to java.util.logging.Logger. > > And then you have enum. Which can have a constructor with parameters. > Which will then have methods to get at those parameters. > > And an enum value is all upper case. Bloch mentions this, also. I know I should should specify a more readable name in the enum constructor and overload toString(), but sometimes I am weak and rely on name(): <http://sites.google.com/site/drjohnbmatthews/composite/source-code> > I am not confused at all. If it is static and final, then it is a > class constant. The fact that it has attributes which can be modified > (if exposed) is a moot point. The _reference_ cannot be changed, and > so it is a constant. > > Where I use classes as constants, I also make sure that there are no > setters, which preserves the original state of the object. I'm more certain of this when the class is marked final. -- John B. Matthews trashgod at gmail dot com <http://sites.google.com/site/drjohnbmatthews>
From: Peter Duniho on 29 Jan 2010 16:29 John B. Matthews wrote: > [...] In _Effective Java_, item 56, Joshua Block > expands the notion of class constant to include static final fields > having a primitive type or an immutable reference type: > > static final Random RANDOM = new Random(); At the risk of making it look like I care about the naming convention aspect of this discussion when in fact I couldn't care less, I do just have to point out: The Random java.util.Random class (I'm assuming that's the type implied above) is neither a primitive type nor an immutable reference type. It's very much mutable. It mutates every time you call one of its declared members (i.e. any not inherited from Object). Pete
From: John B. Matthews on 29 Jan 2010 16:53 In article <xoKdnejh16ilzv7WnZ2dnUVZ_rmdnZ2d(a)posted.palinacquisition>, Peter Duniho <NpOeStPeAdM(a)NnOwSlPiAnMk.com> wrote: > John B. Matthews wrote: > > [...] In _Effective Java_, item 56, Joshua Block > > expands the notion of class constant to include static final fields > > having a primitive type or an immutable reference type: > > > > static final Random RANDOM = new Random(); > > At the risk of making it look like I care about the naming convention > aspect of this discussion when in fact I couldn't care less, I do > just have to point out: > > The Random java.util.Random class (I'm assuming that's the type > implied above) is neither a primitive type nor an immutable reference > type. Yes, thank you for clarifying. > It's very much mutable. It mutates every time you call one of > its declared members (i.e. any not inherited from Object). Good point, hence my struggle. The class java.util.Random is neither final or immutable, and yet it's behavior is entirely predictable once constructed. It becomes an immutable, cyclic sequence, governed by the seed and each call to the "next*" methods. If the goal of a naming convention is to lend clarity, I'd have to go with the context. -- John B. Matthews trashgod at gmail dot com <http://sites.google.com/site/drjohnbmatthews>
From: Peter Duniho on 29 Jan 2010 17:37
John B. Matthews wrote: > [...] >> It's very much mutable. It mutates every time you call one of >> its declared members (i.e. any not inherited from Object). > > Good point, hence my struggle. The class java.util.Random is neither > final or immutable, and yet it's behavior is entirely predictable once > constructed. It becomes an immutable, cyclic sequence, governed by the > seed and each call to the "next*" methods. The sequence is immutable. But the class is not. This is of particular concern is someone is trying to use the instance in a multi-threaded way. One commonly used advantage of immutable types is their inherent thread-safe behavior. The Random class doesn't have this. Personally, I would want to be careful using a class like this as a "constant". I can easily see the value of a _private_ static final Random variable, not used so much as a constant but rather just a class-wide implementation detail. As a public field, it would be much more problematic, specifically because it's not immutable. In any case, it seems to me that whatever one thinks about regarding the naming convention, Joshua Block's suggestion is specifically about classes that are NOT like the Random class. I agree with the concept he's putting forth, but find it inapplicable to a field of type Random even if it is static and final. There may be _other_ reasons to name such a field "RANDOM" or similar, but I don't think one can use that specific point of Block's to argue in favor of it. > If the goal of a naming convention is to lend clarity, I'd have to go > with the context. As mentioned, I'll stay out of the naming question. If someone wants a static final Random variable named "RANDOM", fine by me. :) Pete |