Comments on: When will Sun’s JDK start following code conventions? http://www.khanspot.com/2006/12/12/when-will-suns-jdk-start-following-code-conventions/ Computers are useless. They can only give you answers. Tue, 09 Mar 2010 20:48:13 +0000 http://wordpress.org/?v=2.6.3 By: Atif Khan http://www.khanspot.com/2006/12/12/when-will-suns-jdk-start-following-code-conventions/#comment-82 Atif Khan Fri, 15 Dec 2006 15:36:36 +0000 http://www.khanspot.com/2006/12/12/when-will-suns-jdk-start-following-code-conventions/#comment-82 Messi and Kevin, I have updated the post with your inputs. Thanks for the contribution. Messi and Kevin,
I have updated the post with your inputs. Thanks for the contribution.

]]> By: Kevin Riff http://www.khanspot.com/2006/12/12/when-will-suns-jdk-start-following-code-conventions/#comment-79 Kevin Riff Wed, 13 Dec 2006 21:45:34 +0000 http://www.khanspot.com/2006/12/12/when-will-suns-jdk-start-following-code-conventions/#comment-79 All compile-time constants (which includes strings and numerical values) are inlined by the compiler. All string constants, whether they are literals or not, are encoded with the ldc instruction by the compiler. The first time that ldc is encountered there may be a slight delay to resolve the constant pool entry at that location, but after that it's as fast (or faster) as an array lookup. So feel free to create a constant if you want to define the string's value in one place, but it makes no difference to the way it's referenced in the byte code. The 'final' modifier on local variables only has an effect at compile time. In fact, it isn't even possible to tell the JVM which local variables are final. That's not surprising really if you realize that even the type of local variables (not parameters) is not encoded in the class and must be inferred by the JVM based on the bytecodes used. Some coding standards require the use of 'final' to prevent accidental modifications, but it has absolutely no effect on the compiled code. All compile-time constants (which includes strings and numerical values) are inlined by the compiler. All string constants, whether they are literals or not, are encoded with the ldc instruction by the compiler. The first time that ldc is encountered there may be a slight delay to resolve the constant pool entry at that location, but after that it’s as fast (or faster) as an array lookup. So feel free to create a constant if you want to define the string’s value in one place, but it makes no difference to the way it’s referenced in the byte code.

The ‘final’ modifier on local variables only has an effect at compile time. In fact, it isn’t even possible to tell the JVM which local variables are final. That’s not surprising really if you realize that even the type of local variables (not parameters) is not encoded in the class and must be inferred by the JVM based on the bytecodes used. Some coding standards require the use of ‘final’ to prevent accidental modifications, but it has absolutely no effect on the compiled code.

]]> By: Atif Khan http://www.khanspot.com/2006/12/12/when-will-suns-jdk-start-following-code-conventions/#comment-78 Atif Khan Wed, 13 Dec 2006 21:11:52 +0000 http://www.khanspot.com/2006/12/12/when-will-suns-jdk-start-following-code-conventions/#comment-78 Messi, Thanks for the clarification. I do see the bytecode instruction for the string constant being pushed on the stack. Now this raises some questions: 1). Since the compiler generates a "ldc" for loading the reference to the string literal, is there any value in defining a constant even if the literal is used several times? The only cases I can think of is for programmatic accuracy and having a single point for future changes. Can anyone think of something else? 2). I understand "field != local variable". But as far as the memory allocation for two, wouldn't they both benefit from "final" declaration as they will be marked as immutable? 3). I do like the brackets and spaces instead of tabs. But, that's just my personal preference :) Messi,
Thanks for the clarification. I do see the bytecode instruction for the string constant being pushed on the stack. Now this raises some questions:

1). Since the compiler generates a “ldc” for loading the reference to the string literal, is there any value in defining a constant even if the literal is used several times? The only cases I can think of is for programmatic accuracy and having a single point for future changes. Can anyone think of something else?

2). I understand “field != local variable”. But as far as the memory allocation for two, wouldn’t they both benefit from “final” declaration as they will be marked as immutable?

3). I do like the brackets and spaces instead of tabs. But, that’s just my personal preference :)

]]> By: messi http://www.khanspot.com/2006/12/12/when-will-suns-jdk-start-following-code-conventions/#comment-73 messi Wed, 13 Dec 2006 19:45:17 +0000 http://www.khanspot.com/2006/12/12/when-will-suns-jdk-start-following-code-conventions/#comment-73 3) "ldc" is the instruction's mnemonic. 3) “ldc” is the instruction’s mnemonic.

]]> By: messi http://www.khanspot.com/2006/12/12/when-will-suns-jdk-start-following-code-conventions/#comment-72 messi Wed, 13 Dec 2006 19:33:09 +0000 http://www.khanspot.com/2006/12/12/when-will-suns-jdk-start-following-code-conventions/#comment-72 1) Just a guess. I checked java/lang/StringBuilder.java in src.zip from JDK5 and JDK6 and both methods contain tabs. 2) Sorry, you're right. I didn't scroll down to the //AVOID comment example. I'm glad Sun doesn't follow that convention. 3) String constants are loaded by a the const_n bytecode instruction which means directly pushing the reference onto the stack. No lookup required. 4) field != local variable 1) Just a guess. I checked java/lang/StringBuilder.java in src.zip from JDK5 and JDK6 and both methods contain tabs.

2) Sorry, you’re right. I didn’t scroll down to the //AVOID comment example. I’m glad Sun doesn’t follow that convention.

3) String constants are loaded by a the const_n bytecode instruction which means directly pushing the reference onto the stack. No lookup required.

4) field != local variable

]]>