This is the mail archive of the
java-patches@sources.redhat.com
mailing list for the Java project.
Re: PATCH: PR 1411 Remove natTimeZone.cc (proposal)
- To: Warren Levy <warrenl at redhat dot com>
- Subject: Re: PATCH: PR 1411 Remove natTimeZone.cc (proposal)
- From: Tom Tromey <tromey at redhat dot com>
- Date: 31 Dec 2000 13:10:24 -0700
- Cc: Java Patch List <java-patches at sourceware dot cygnus dot com>, bryce at albatross dot co dot nz
- References: <Pine.LNX.4.10.10012272257490.11438-200000@fencer.cygnus.com>
- Reply-To: tromey at redhat dot com
>>>>> "Warren" == Warren Levy <warrenl@redhat.com> writes:
Warren> Specifically, take a look at the patch to
Warren> java/lang/natSystem.cc and let me know if you have any ideas
Warren> for improvement.
I haven't read up on the issues involved. My only comment is on
something in the patch that confused me.
Warren> +static char *
Warren> +getDefaultTimeZoneId (void)
Warren> [ ... ]
Warren> + return tzinfo[0];
Ok, here we return a char*.
Warren> + return (char *) JvGetStringChars (elts[i]);
elts is a `jstring*' and elts[i] is a jstring.
So here the code is casting a `jchar*' to a `char*' and returning it.
This is wrong, it suffers from encoding confusion.
Maybe using Jv_GetStringUTFRegion is the right thing to do.
Or, have getDefaultTimeZoneId return a jstring and then don't use the
SET macro to set user.timezone but instead use the put method
directly.
If synchronization of this code with Classpath is required, you might
want to find a way to write more of it in Java. JNI is really
horrible to write; the idea of rewriting getDefaultTimeZoneId using
JNI makes me shudder.
Tom