When everything looks like a hammer ...
-
Where are the nails?
private static Level retrieveDebugMessageLevel(String moduleName, Properties props, Level level) { String tmpString; Level debugMessageLevel;WTFs I see immediately:tmpString = properties.getProperty(moduleName + ".Debug.Message.Level");
if (tmpString == null) {
if (level.intValue() <= Level.WARNING.intValue()) {
logger.log(Level.WARNING, "Property " +
moduleName +
".Debug.Message.Level" +
" not found in the configuration file. " +
Constants.CarriageReturn +
"Using the default of WARNING.");
}
debugMessageLevel = Level.WARNING;
} else if (tmpString.compareTo("SEVERE") == 0) {
debugMessageLevel = Level.SEVERE;
} else if (tmpString.compareTo("WARNING") == 0) {
debugMessageLevel = Level.WARNING;
} else if (tmpString.compareTo("INFO") == 0) {
if (level.intValue() <= Level.INFO.intValue()) {
logger.log(Level.INFO, "The debug message level is set to INFO");
}
debugMessageLevel = Level.INFO;
} else if (tmpString.compareTo("FINE") == 0) {
if (level.intValue() <= Level.INFO.intValue()) {
logger.log(Level.INFO, "The debug message level is set to FINE");
}
debugMessageLevel = Level.FINE;
} else if (tmpString.compareTo("OFF") == 0) {
debugMessageLevel = Level.OFF;
} else {
if (level.intValue() != Level.SEVERE.intValue() &&
level.intValue() != Level.WARNING.intValue() &&
level.intValue() != Level.INFO.intValue() &&
level.intValue() != Level.FINE.intValue() &&
level.intValue() != Level.OFF.intValue() ) {
logger.log(Level.WARNING, "Property " +
moduleName +
".Debug.Message.Level" +
" is not a valid value: " +
tmpString +
Contants.CarriageReturn +
"Using the default of WARNING.");
}
debugMessageLevel = Level.WARNING;
}
return debugMessageLevel;
}- Constants.CarriageReturn ... really? Typing "\n" is harder? Expecting it to change soon? As far as I know, Java makes \n portable under-the-covers ...
- Ladies and gentlemen, I give you Level.parse(String) ... [use the bleedin' methods that come with the classes you're using]
- Ladies and gentlemen, I give you String.equals() ... [readability]
- I guess the default really needs to be set three times (perhaps a premature optimization?)
- By default, there are several other legal values of Level that aren't taken into account.
-
Not being a Java programmer myself, I'm not sure what Java stuffs into Constants.CarriageReturn. If it is an actual carriage return, as in character 13, the programmer is Doing It Wrong(TM) (I realize that I'm stating the obvious here, but still). The only recent platform that will give you a new line from a lone \r -- that I know of, anyway -- is Classic Mac OS.
\n is designed to be transformed into the operating system's new line character/sequence of choice so that it would be a valid escape sequence in any environment. \n isn't just more convenient in this case, it's the correct way of doing it.
-
@Spectere said:
Not being a Java programmer myself, I'm not sure what Java stuffs into Constants.CarriageReturn. If it is an actual carriage return, as in character 13, the programmer is Doing It Wrong(TM) (I realize that I'm stating the obvious here, but still). The only recent platform that will give you a new line from a lone \r -- that I know of, anyway -- is Classic Mac OS.
\n is designed to be transformed into the operating system's new line character/sequence of choice so that it would be a valid escape sequence in any environment. \n isn't just more convenient in this case, it's the correct way of doing it.My guess is that it's a poor mans System.getProperty("line.separator");, seeing as it doesn't seem to be a built-in constant.
-
@zelmak said:
WTFs I see immediately:
- Constants.CarriageReturn ... really? Typing "\n" is harder? Expecting it to change soon? As far as I know, Java makes \n portable under-the-covers ...
- Ladies and gentlemen, I give you Level.parse(String) ... [use the bleedin' methods that come with the classes you're using]
- Ladies and gentlemen, I give you String.equals() ... [readability]
- I guess the default really needs to be set three times (perhaps a premature optimization?)
- By default, there are several other legal values of Level that aren't taken into account.
Also,
- If anyone ever deletes the Debug.Message.Level property for the logger module itself, KABOOM!
(Probably)
-
@Spectere said:
Not being a Java programmer myself, I'm not sure what Java stuffs into Constants.CarriageReturn.
Java doesn't stuff anything in there — that is not a built-in class. It's something specific to this application (or whatever it is).
@Spectere said:
\n is designed to be transformed into the operating system's new line character/sequence of choice so that it would be a valid escape sequence in any environment. \n isn't just more convenient in this case, it's the correct way of doing it.
That's how C does it. Not Java, though. The Java Language Specification defines the \n escape sequence to always be exactly U+000A, and \r to always be exactly U+000D.
The proper way to do this in Java is to call System.getProperty("line.separator"), which will return a String containing the entire newline sequence for the current platform.
-
@Someone You Know said:
@Spectere said:
\n is designed to be transformed into the operating system's new line character/sequence of choice so that it would be a valid escape sequence in any environment. \n isn't just more convenient in this case, it's the correct way of doing it.
That's how C does it. Not Java, though. The Java Language Specification defines the \n escape sequence to always be exactly U+000A, and \r to always be exactly U+000D.
That's not how C does it, either (the standard library transforms '\n' into whatever sequence the system uses for newlines on I/O - and so does the Java library).
-
Elsewhere in the code --
public class Constants { public static final String CarriageReturn = System.getProperty("line.separator"); // rest of class omitted for clarity/sanity }So the process is relatively sane; it just boggles me that the same codebase uses all three methods (and perhaps ones I've not seen yet)
- System.getProperty("line.separator") is used directly and concatenated with output strings
- "\n" is inserted into output strings liberally
- Constants.CarriageReturn is concatenated with output strings
@Spectere said:
\n is designed to be transformed into the operating system's new line character/sequence of choice so that it would be a valid escape sequence in any environment. \n isn't just more convenient in this case, it's the correct way of doing it.
I haven't sat down to research this, but I'm reasonably sure that this is the case ... output is parsed and depending on environment (essentially *NIX or Windows) the Right Thing(tm) is done.
-
@zelmak said:
@Spectere said:
\n is designed to be transformed into the operating system's new line character/sequence of choice so that it would be a valid escape sequence in any environment. \n isn't just more convenient in this case, it's the correct way of doing it.
I haven't sat down to research this, but I'm reasonably sure that this is the case ... output is parsed and depending on environment (essentially *NIX or Windows) the Right Thing(tm) is done.
You forget that this is Java. I've had this exact problem a while ago and I can assure you that it's not.
If you're bored, try the following (in Windows):
1.: Consider: static void main() {System.out.println("foo"); System.out.print("bar\n"); System.out.print("baz");}
2.: Execute that on the console and pipe the output into some file.
3.: Open file with notepad.
4.: Rejoice
-
@Spectre said:
@Someone You Know said:
@Spectere said:
\n is designed to be transformed into the operating system's new line character/sequence of choice so that it would be a valid escape sequence in any environment. \n isn't just more convenient in this case, it's the correct way of doing it.
That's how C does it. Not Java, though. The Java Language Specification defines the \n escape sequence to always be exactly U+000A, and \r to always be exactly U+000D.
That's not how C does it, either (the standard library transforms '\n' into whatever sequence the system uses for newlines on I/O - and so does the Java library).
I don't understand the difference between how I said C does it and how you're saying C does it.
The Java library does not transform '\n' into anything other than U+000A, regardless of environment. There are places in Java where this type of thing is done — for instance, the OutputStream.println() method always uses the OS-appropriate newline sequence to end the line — but the escape sequence '\n' is always translated into U+000A. Try it.
-
@Someone You Know said:
Your method implies it was done on the string handling routine, SpecLad explained that it was done in the standard library, which Java probably has to go through anyways.@Spectre said:
@Someone You Know said:
@Spectere said:
\n is designed to be transformed into the operating system's new line character/sequence of choice so that it would be a valid escape sequence in any environment. \n isn't just more convenient in this case, it's the correct way of doing it.
That's how C does it. Not Java, though. The Java Language Specification defines the \n escape sequence to always be exactly U+000A, and \r to always be exactly U+000D.
That's not how C does it, either (the standard library transforms '\n' into whatever sequence the system uses for newlines on I/O - and so does the Java library).
I don't understand the difference between how I said C does it and how you're saying C does it.
The Java library does not transform '\n' into anything other than U+000A, regardless of environment. There are places in Java where this type of thing is done — for instance, the OutputStream.println() method always uses the OS-appropriate newline sequence to end the line — but the escape sequence '\n' is always translated into U+000A. Try it.
-
@Lingerance said:
@Someone You Know said:
Your method implies it was done on the string handling routine, SpecLad explained that it was done in the standard library, which Java probably has to go through anyways.@Spectre said:
@Someone You Know said:
@Spectere said:
\n is designed to be transformed into the operating system's new line character/sequence of choice so that it would be a valid escape sequence in any environment. \n isn't just more convenient in this case, it's the correct way of doing it.
That's how C does it. Not Java, though. The Java Language Specification defines the \n escape sequence to always be exactly U+000A, and \r to always be exactly U+000D.
That's not how C does it, either (the standard library transforms '\n' into whatever sequence the system uses for newlines on I/O - and so does the Java library).
I don't understand the difference between how I said C does it and how you're saying C does it.
The Java library does not transform '\n' into anything other than U+000A, regardless of environment. There are places in Java where this type of thing is done — for instance, the OutputStream.println() method always uses the OS-appropriate newline sequence to end the line — but the escape sequence '\n' is always translated into U+000A. Try it.
I was wrong about Java — as [b]PSWorx[/b] shows above, the Java library doesn't actually do that.
-
@Spectre said:
I was wrong about Java
SpecLad was... wrong? head explodes
-
@MiffTheFox said:
My guess is that it's a poor mans System.getProperty("line.separator");, seeing as it doesn't seem to be a built-in constant.
It actually IMO is better (assuming it always gives the same as System.getProperty("line.separator") ) because a) it's fewer characters, b) it's a lot quicker to autocomplete, and c) getProperty obviously can't have any compile-time checking for typos in its parameter.
