redundant field initializers
Hi,
Do we have a coding style guideline about redundant field initializers?
I have a patch that removes a couple of these for static fields that
needlessly result in a static initializer method.
For example in javax.naming.spi.NamingManager:
- private static InitialContextFactoryBuilder icfb = null;
+ private static InitialContextFactoryBuilder icfb;
// Package private so DirectoryManager can access it.
- static ObjectFactoryBuilder ofb = null;
+ static ObjectFactoryBuilder ofb;
Making this change removes the need for the compiler to create a static
initializer.
Does everyone agree that this is a good idea? If so, how far should we
take this? How about this change:
Index: java/awt/EventDispatchThread.java
===
RCS file:
/cvsroot/classpath/classpath/java/awt/EventDispatchThread.java,v
retrieving revision 1.4
diff -u -r1.4 EventDispatchThread.java
--- java/awt/EventDispatchThread.java 31 May 2004 21:11:46 -
1.4
+++ java/awt/EventDispatchThread.java 19 Sep 2004 09:52:47 -
@@ -42,14 +42,14 @@
class EventDispatchThread extends Thread
{
- private static int dispatchThreadNum = 1;
+ private static int dispatchThreadNum;
private EventQueue queue;
EventDispatchThread(EventQueue queue)
{
super();
-setName(AWT-EventQueue- + dispatchThreadNum++);
+setName(AWT-EventQueue- + ++dispatchThreadNum);
this.queue = queue;
setPriority(NORM_PRIORITY + 1);
start();
Regards,
Jeroen
___
Classpath mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/classpath
Re: redundant field initializers
On Monday 20 September 2004 11:43, Jeroen Frijters wrote:
Hi,
Do we have a coding style guideline about redundant field
initializers? I have a patch that removes a couple of these for
static fields that needlessly result in a static initializer
method.
For example in javax.naming.spi.NamingManager:
- private static InitialContextFactoryBuilder icfb = null;
+ private static InitialContextFactoryBuilder icfb;
// Package private so DirectoryManager can access it.
- static ObjectFactoryBuilder ofb = null;
+ static ObjectFactoryBuilder ofb;
Making this change removes the need for the compiler to create a
static initializer.
Does everyone agree that this is a good idea? If so, how far should
we take this? How about this change:
I agree with you. We should remove redundant initializations . This
does not only cover static field initializations but also
initialization of instance variables with default values.
My personal checkstyle checks for this.
Index: java/awt/EventDispatchThread.java
===
RCS file:
/cvsroot/classpath/classpath/java/awt/EventDispatchThread.java,v
retrieving revision 1.4
diff -u -r1.4 EventDispatchThread.java
--- java/awt/EventDispatchThread.java 31 May 2004 21:11:46 -
1.4
+++ java/awt/EventDispatchThread.java 19 Sep 2004 09:52:47 -
@@ -42,14 +42,14 @@
class EventDispatchThread extends Thread
{
- private static int dispatchThreadNum = 1;
+ private static int dispatchThreadNum;
You should a comment that the dispatchThreads start with 1 and explain
it a bit.
private EventQueue queue;
EventDispatchThread(EventQueue queue)
{
super();
-setName(AWT-EventQueue- + dispatchThreadNum++);
+setName(AWT-EventQueue- + ++dispatchThreadNum);
this.queue = queue;
setPriority(NORM_PRIORITY + 1);
start();
OK, Thanks.
Michael
___
Classpath mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/classpath
Re: redundant field initializers
Jeroen Frijters wrote:
Hi Jeroen,
- private static InitialContextFactoryBuilder icfb = null;
+ private static InitialContextFactoryBuilder icfb;
Making this change removes the need for the compiler to create a static
initializer.
Does everyone agree that this is a good idea? If so, how far should we
take this? How about this change:
Looks good and useful to me.
Index: java/awt/EventDispatchThread.java
===
RCS file:
/cvsroot/classpath/classpath/java/awt/EventDispatchThread.java,v
retrieving revision 1.4
diff -u -r1.4 EventDispatchThread.java
--- java/awt/EventDispatchThread.java 31 May 2004 21:11:46 -
1.4
+++ java/awt/EventDispatchThread.java 19 Sep 2004 09:52:47 -
@@ -42,14 +42,14 @@
class EventDispatchThread extends Thread
{
- private static int dispatchThreadNum = 1;
+ private static int dispatchThreadNum;
private EventQueue queue;
EventDispatchThread(EventQueue queue)
{
super();
-setName(AWT-EventQueue- + dispatchThreadNum++);
+setName(AWT-EventQueue- + ++dispatchThreadNum);
this.queue = queue;
setPriority(NORM_PRIORITY + 1);
start();
I like the idea. I think that's OK for private fields, that are not used
in inner classes. But Tom's patch should make them explicitely
non-privat, so that's the only temporal caveat I can think of.
cheers,
dalibor topic
___
Classpath mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/classpath
Re: redundant field initializers
Hi,
On Mon, 2004-09-20 at 11:43, Jeroen Frijters wrote:
Do we have a coding style guideline about redundant field initializers?
I have a patch that removes a couple of these for static fields that
needlessly result in a static initializer method.
For example in javax.naming.spi.NamingManager:
- private static InitialContextFactoryBuilder icfb = null;
+ private static InitialContextFactoryBuilder icfb;
// Package private so DirectoryManager can access it.
- static ObjectFactoryBuilder ofb = null;
+ static ObjectFactoryBuilder ofb;
Making this change removes the need for the compiler to create a static
initializer.
Why would a compiler emit extra initialization code for default values
for fields? Not that I object to removing them, but it looks like the
compiler emits unnecessary code in this case.
Does everyone agree that this is a good idea? If so, how far should we
take this? How about this change:
- private static int dispatchThreadNum = 1;
+ private static int dispatchThreadNum;
private EventQueue queue;
EventDispatchThread(EventQueue queue)
{
super();
-setName(AWT-EventQueue- + dispatchThreadNum++);
+setName(AWT-EventQueue- + ++dispatchThreadNum);
this.queue = queue;
setPriority(NORM_PRIORITY + 1);
start();
This change seems more logical than the change above since you are
removing an initialization of a field with a non-default value (if not
initialized).
Cheers,
mark
signature.asc
Description: This is a digitally signed message part
___
Classpath mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/classpath
Re: redundant field initializers
Mark Wielaard wrote:
Why would a compiler emit extra initialization code for default values
for fields? Not that I object to removing them, but it looks like the
compiler emits unnecessary code in this case.
One can construct torture cases where the semantics are different, for
both static and instance fields, if some code change the field value
before the initialization is assigned.
For exmple:
class Z {
static int peek() { return j++; }
static int i = peek();
static int j = 0;
}
--
--Per Bothner
[EMAIL PROTECTED] http://per.bothner.com/
___
Classpath mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/classpath
Re: redundant field initializers
On Monday 20 September 2004 22:42, Per Bothner wrote: Mark Wielaard wrote: Why would a compiler emit extra initialization code for default values for fields? Not that I object to removing them, but it looks like the compiler emits unnecessary code in this case. One can construct torture cases where the semantics are different, for both static and instance fields, if some code change the field value before the initialization is assigned. For this reason, removing the initialiser is not necessarily harmless; the code _might_ not work without it. Of course, such code should not be allowed to exist ... -- Chris Gray /k/ Embedded Java Solutions Embedded Mobile Java, OSGihttp://www.kiffer.be/k/ [EMAIL PROTECTED] +32 3 216 0369 ___ Classpath mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/classpath
