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
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
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: implementing "historical" character encoding names
Hi, On Mon, 2004-09-20 at 19:25, Noa Resare wrote: > Hello friends > > OutputStreamWriter.getEncoding() is documented in Sun's 1.4.2 apidocs to > return the "historical" name of the used encoding. In the > java.nio.charset.Charset docs "historical name" is defined as > "Some charsets have an historical name that is defined for compatibility > with previous versions of the Java platform." I couldn't find any more > information about the historical encoding names (such as a list) in the > api specification. Ah, just answered this on the mauve list. The Java Class libries Second Edition Volume 1 lists them under the String constructor description. An online copy can be found at: http://java.sun.com/j2se/1.4.2/docs/guide/intl/encoding.doc.html in the column "Canonical Name for java.io and java.lang API" > Is running a program like the one attached below in Sun's java an ok way > of gathering the information needed to implement the "historical > charset" functionality? If there is no public documentation and there are no (free) programs depending on a feature/implementation detail then you don't have to go out of the way to support such things. > If nothing unforeseen happens I might be contributing code to classpath > in the future. Where can I find the copyright assignment document > discussed in the Hackers Guide? You write to me or the list and then I'll email you the forms. Expect email soon :) 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: implementing "historical" character encoding names
On mÃn, 2004-09-20 at 19:25 +0200, Noa Resare wrote:
> Is running a program like the one attached below in Sun's java an ok way
> of gathering the information needed to implement the "historical
> charset" functionality?
MEEP. Forgot to attach. Here goes.
/noa
--
And the lions ate the christians and the christians burned the witches,
and even I am out of explanations -- Ola Salo
gpg fingerprint: F3C4 AC90 B885 FE15 344B 4D05 220B 7662 A190 6F09
import java.util.*;
import java.io.*;
import java.nio.charset.Charset;
public class HistoricalCharsetChecker
{
public static void main(String[] args)
throws Exception
{
Map charsetMap = Charset.availableCharsets();
Iterator charsets = charsetMap.keySet().iterator();
while (charsets.hasNext())
{
String charsetName = (String)charsets.next();
String historicalName = getHistoricalName(charsetName);
if (!historicalName.equals(charsetName))
System.out.println(charsetName + ": " + historicalName);
}
}
private static OutputStream os = new ByteArrayOutputStream();
private static String getHistoricalName(String charsetName)
throws Exception
{
OutputStreamWriter osw = new OutputStreamWriter(os, charsetName);
return osw.getEncoding();
}
}
___
Classpath mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/classpath
implementing "historical" character encoding names
Hello friends OutputStreamWriter.getEncoding() is documented in Sun's 1.4.2 apidocs to return the "historical" name of the used encoding. In the java.nio.charset.Charset docs "historical name" is defined as "Some charsets have an historical name that is defined for compatibility with previous versions of the Java platform." I couldn't find any more information about the historical encoding names (such as a list) in the api specification. Is running a program like the one attached below in Sun's java an ok way of gathering the information needed to implement the "historical charset" functionality? If nothing unforeseen happens I might be contributing code to classpath in the future. Where can I find the copyright assignment document discussed in the Hackers Guide? cheers/noa -- And the lions ate the christians and the christians burned the witches, and even I am out of explanations -- Ola Salo gpg fingerprint: F3C4 AC90 B885 FE15 344B 4D05 220B 7662 A190 6F09 ___ Classpath mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/classpath
Re: Error handling in RMI server code
On Monday 20 September 2004 14:07, Jeroen Frijters wrote: > Hi, > > Thanks. I've applied your fix. The contribution is on the border of a little contribution to contributions which need a copyright assigment. AFAIK Ilya has not done the paperwork yet. Each following contributions can only get commited when the legal status is clear. Ilya: If you are interested please contact Mark Wielaard <[EMAIL PROTECTED]>. Greetings, Michael ___ Classpath mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/classpath
RE: Error handling in RMI server code
Hi, Thanks. I've applied your fix. Regards, Jeroen > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On > Behalf Of Ilya Perminov > Sent: Monday, September 13, 2004 20:46 > To: [EMAIL PROTECTED] > Subject: Error handling in RMI server code > > Hi, > > The RMI server code does not propagate Errors to RMI clients. > I found why. There are two bugs: > 1. UnicastServerRef.incomingMessageCall casts >InvocationTargetException.getTargetException () to Exception. >It fails when getTargetException () returns an Error. > 2. UnicastServer.incomingMessageCall does not have a handler > for Errors. >According to RMI spec. Errors in a remote method should be caught, >wrapped in ServerError and send to the client. > I fixed these bugs. A patch is attached. Can somebody apply it? > Also, please close my bug report > http://savannah.gnu.org/bugs/?func=detailitem&item_id=10315 > > Regards, > Ilya > ___ 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
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
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
