I've a problem with GregorianCalendar, which returns different weeks (in year)
on FreeBSD 6.1, java version is
# java -version
Java HotSpot(TM) Server VM (build 1.5.0-p2-heiko_03_jan_2006_23_51, mixed
mode)
Test program (A.java):
import java.util.Calendar;
import java.util.GregorianCalendar;
public class A {
public static int weeksInYear(int year) {
Calendar cal = GregorianCalendar.getInstance();
cal.set(year, 11, 31);
return cal.get(Calendar.WEEK_OF_YEAR) == 53 ? 53 : 52;
}
public static void main(String args[]) {
for (int i = 1990; i <= 2006; i++)
System.out.println("Weeks in Year " + i + " = " +
weeksInYear(i));
}
}
Output on a Linux or Windows JRE is:
Weeks in Year 1990 = 52
Weeks in Year 1991 = 52
Weeks in Year 1992 = 53
Weeks in Year 1993 = 52
Weeks in Year 1994 = 52
Weeks in Year 1995 = 52
Weeks in Year 1996 = 52
Weeks in Year 1997 = 52
Weeks in Year 1998 = 53
Weeks in Year 1999 = 52
Weeks in Year 2000 = 52
Weeks in Year 2001 = 52
Weeks in Year 2002 = 52
Weeks in Year 2003 = 52
Weeks in Year 2004 = 53
Weeks in Year 2005 = 52
Weeks in Year 2006 = 52
Output on FreeBSD is:
Weeks in Year 1990 = 52
Weeks in Year 1991 = 52
Weeks in Year 1992 = 52
Weeks in Year 1993 = 52
Weeks in Year 1994 = 53
Weeks in Year 1995 = 52
Weeks in Year 1996 = 52
Weeks in Year 1997 = 52
Weeks in Year 1998 = 52
Weeks in Year 1999 = 52
Weeks in Year 2000 = 52
Weeks in Year 2001 = 52
Weeks in Year 2002 = 52
Weeks in Year 2003 = 52
Weeks in Year 2004 = 52
Weeks in Year 2005 = 53
Weeks in Year 2006 = 52
Is this my fault or would it help to update the FreeBSD JRE ? Or is the
java-Calendar-System build up on some local (changeable) settings ?
Thanks for any help or hint.
Heiko
_______________________________________________
freebs...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-java
To unsubscribe, send any mail to "freebsd-java...@freebsd.org"
I can't replicate this here on either diablo-jdk15 or jdk15 patchset 2
(as yours). Is your systems time/timezone/etc. correct?
Cheers,
Panagiotis
Hm, /etc/localtime has been installed last year in september - from
installation of FreeBSD 6.0. If I remember correct I used sysinstall and
answered "cmos time == local time".
# date
Tue May 30 09:48:36 CEST 2006
Is this ok for germany ?
At the moment I compile jdk with patchset 3 on an other FreeBSD system to
verify ... there I can play with the timezone settings after installation.
Thanks for the hint.
Heiko
I think yes, it means Central European Time (CET) with saylight savings
(S).
Applying
--- A.java.old Tue May 30 12:57:28 2006
+++ A.java Tue May 30 12:57:37 2006
@@ -11,6 +11,7 @@
}
public static void main(String args[]) {
+ java.util.TimeZone.setDefault(null);
for (int i = 1990; i <= 2006; i++)
System.out.println("Weeks in Year " + i + " = "
+ weeksInYear(i));
}
Should give you a hint of whether the problem is TZ related.
P.S.
Also with 1.4.2 I get the first result set.
>
> At the moment I compile jdk with patchset 3 on an other FreeBSD system to
> verify ... there I can play with the timezone settings after installation.
>
> Thanks for the hint.
>
> Heiko
> _______________________________________________
> freebs...@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-java
> To unsubscribe, send any mail to "freebsd-java...@freebsd.org"
>
--
-Achilleus
> At the moment I compile jdk with patchset 3 on an other FreeBSD system to
> verify ... there I can play with the timezone settings after installation.
>
Only for your information:
/usr/ports/jdk15 fails to compile. I'll give diablo-jdk15 a try ... last
output of "make" follows ...
Heiko
...
gmake[3]: Leaving directory
`/usr/ports/java/jdk15/work/control/build/bsd-i586/hotspot-i586/tmp/bsd_i486_compiler2/product'
gmake[3]: Entering directory
`/usr/ports/java/jdk15/work/control/build/bsd-i586/hotspot-i586/tmp/bsd_i486_compiler2/product'
/usr/local/linux-sun-jdk1.4.2/bin/javac -g
-d ../generated/jvmtifiles /usr/ports/java/jdk15/work/hotspot/src/share/vm/prims/jvmtiGen.java
Java HotSpot(TM) Client VM warning: Can't detect initial thread stack location
Generating ../generated/jvmtifiles/jvmdiEnter.cpp
/usr/local/linux-sun-jdk1.4.2/bin/java -classpath ../generated/jvmtifiles
jvmtiGen -IN /usr/ports/java/jdk15/work/hotspot/src/share/vm/prims/jvmti.xml
-XSL /usr/ports/java/jdk15/work/hotspot/src/share/vm/prims/jvmdiEnter.xsl
-OUT ../generated/jvmtifiles/jvmdiEnter.cpp -PARAM interface jvmdi
Java HotSpot(TM) Client VM warning: Can't detect initial thread stack location
Info: jvmtiGen using javax.xml.transform.TransformerFactory =
org.apache.xalan.processor.TransformerFactoryImpl
Generating ../generated/jvmtifiles/jvmdiEnterTrace.cpp
/usr/local/linux-sun-jdk1.4.2/bin/java -classpath ../generated/jvmtifiles
jvmtiGen -IN /usr/ports/java/jdk15/work/hotspot/src/share/vm/prims/jvmti.xml
-XSL /usr/ports/java/jdk15/work/hotspot/src/share/vm/prims/jvmdiEnter.xsl
-OUT ../generated/jvmtifiles/jvmdiEnterTrace.cpp -PARAM interface jvmdi
-PARAM trace Trace
Java HotSpot(TM) Client VM warning: Can't detect initial thread stack location
Info: jvmtiGen using javax.xml.transform.TransformerFactory =
org.apache.xalan.processor.TransformerFactoryImpl
Warning: popContextNodeList when stack is empty!
** Transformation error
java.lang.ArrayIndexOutOfBoundsException: -1
java.lang.ArrayIndexOutOfBoundsException: -1
at org.apache.xml.utils.ObjectStack.pop(ObjectStack.java:137)
at
org.apache.xalan.transformer.TransformerImpl.popElemTemplateElement(TransformerImpl.java:2521)
at
org.apache.xalan.transformer.TransformerImpl.applyTemplateToNode(TransformerImpl.java:2178)
at
org.apache.xalan.transformer.TransformerImpl.transformNode(TransformerImpl.java:1213)
at
org.apache.xalan.transformer.TransformerImpl.transform(TransformerImpl.java:668)
at
org.apache.xalan.transformer.TransformerImpl.transform(TransformerImpl.java:1129)
at
org.apache.xalan.transformer.TransformerImpl.transform(TransformerImpl.java:1107)
at jvmtiGen.main(jvmtiGen.java:143)
Generating ../generated/jvmtifiles/jvmtiEnv.hpp
/usr/local/linux-sun-jdk1.4.2/bin/java -classpath ../generated/jvmtifiles
jvmtiGen -IN /usr/ports/java/jdk15/work/hotspot/src/share/vm/prims/jvmti.xml
-XSL /usr/ports/java/jdk15/work/hotspot/src/share/vm/prims/jvmtiHpp.xsl
-OUT ../generated/jvmtifiles/jvmtiEnv.hpp
Java HotSpot(TM) Client VM warning: Can't detect initial thread stack location
Info: jvmtiGen using javax.xml.transform.TransformerFactory =
org.apache.xalan.processor.TransformerFactoryImpl
** Transformation error
java.lang.NullPointerException
java.lang.NullPointerException
at
org.xml.sax.helpers.NamespaceSupport.<init>(NamespaceSupport.java:101)
Exception in thread "main" java.lang.ArrayStoreException
at java.lang.System.arraycopy(Native Method)
at java.lang.String.getChars(String.java:489)
at java.lang.StringBuffer.append(StringBuffer.java:402)
at java.lang.StackTraceElement.toString(StackTraceElement.java:130)
at java.lang.String.valueOf(String.java:2131)
at java.lang.StringBuffer.append(StringBuffer.java:370)
at java.lang.Throwable.printStackTrace(Throwable.java:464)
at java.lang.Throwable.printStackTrace(Throwable.java:451)
at jvmtiGen.main(jvmtiGen.java:165)
gmake[3]: *** [../generated/jvmtifiles/jvmtiEnv.hpp] Error 1
gmake[3]: Leaving directory
`/usr/ports/java/jdk15/work/control/build/bsd-i586/hotspot-i586/tmp/bsd_i486_compiler2/product'
gmake[2]: *** [jvmti_stuff] Error 2
gmake[2]: Leaving directory
`/usr/ports/java/jdk15/work/control/build/bsd-i586/hotspot-i586/tmp/bsd_i486_compiler2/product'
gmake[1]: *** [product] Error 2
gmake[1]: Leaving directory
`/usr/ports/java/jdk15/work/control/build/bsd-i586/hotspot-i586/tmp'
gmake: *** [product] Error 2
*** Error code 2
Stop in /usr/ports/java/jdk15.
--
Heiko Weber : he...@wecos.de
Tel. +49 (4169) 91000 : Fax +49 (4169) 919033
webm...@terminmarktwelt.de
Hi Achilleus,
the above "patch" makes no difference on my system.
I compared /etc/localtime with the files in /usr/share/zoneinfo, it=20
is /usr/shared/zoneinfo/Europe/Berlin.
Heiko
Did you have linprocfs mounted?
Cheers,
Panagiotis
Compared to jdk15 the installation off diablo-jdk15 is much easier - below a
minute. But the result is still the same. Later then I used sysinstall to
change /etc/localtime to CDT, rebooted but no effect.
# date
Tue May 30 06:40:58 CDT 2006
# java -version
java version "1.5.0"
Java(TM) 2 Runtime Environment, Standard Edition (build diablo-1.5.0-b00)
Java HotSpot(TM) Server VM (build diablo-1.5.0_06-b00, mixed mode)
What could make this difference? Is there any other way to implement a
weekOfTheYear(int year) funtion ?
Anyone an idea what to try next ?
Heiiko
Could you print out the value of cal.get(Calendar.WEEK_OF_YEAR) for
those years? It's obviously not 53, but what exactly is it?
Cheers,
Panagiotis
oh sh*t - you're right ! I saw this someone this morning during make, but
forgot to mount it.
Big thanks
Heiko
Sure, 31.12.XXXX print:
Weeks in Year 1990 = 1
Weeks in Year 1991 = 1
Weeks in Year 1992 = 1
Weeks in Year 1993 = 1
Weeks in Year 1994 = 53
Weeks in Year 1995 = 1
Weeks in Year 1996 = 1
Weeks in Year 1997 = 1
Weeks in Year 1998 = 1
Weeks in Year 1999 = 1
Weeks in Year 2000 = 1
Weeks in Year 2001 = 1
Weeks in Year 2002 = 1
Weeks in Year 2003 = 1
Weeks in Year 2004 = 1
Weeks in Year 2005 = 53
Weeks in Year 2006 = 1
Ah, got some light:
if I change
Calendar cal = GregorianCalendar.getInstance();
to
Calendar cal = new GregorianCalendar(
TimeZone.getTimeZone("CEST"), new Locale("DE"));
I get better results:
31.12.1990 is week #1 / year 1990 has 52 weeks
31.12.1991 is week #1 / year 1991 has 52 weeks
31.12.1992 is week #53 / year 1992 has 53 weeks
31.12.1993 is week #52 / year 1993 has 52 weeks
31.12.1994 is week #52 / year 1994 has 52 weeks
31.12.1995 is week #52 / year 1995 has 52 weeks
31.12.1996 is week #1 / year 1996 has 52 weeks
31.12.1997 is week #1 / year 1997 has 52 weeks
31.12.1998 is week #53 / year 1998 has 53 weeks
31.12.1999 is week #52 / year 1999 has 52 weeks
31.12.2000 is week #52 / year 2000 has 52 weeks
31.12.2001 is week #1 / year 2001 has 52 weeks
31.12.2002 is week #1 / year 2002 has 52 weeks
31.12.2003 is week #1 / year 2003 has 52 weeks
31.12.2004 is week #53 / year 2004 has 53 weeks
31.12.2005 is week #52 / year 2005 has 52 weeks
31.12.2006 is week #52 / year 2006 has 52 weeks
Maybe there is a problem getting the "default" Locale and/or Timezone.
I changed the line to
Calendar cal = new GregorianCalendar(TimeZone.getDefault(), new Locale("DE"));
looks good - results are ok. And
Calendar cal = new GregorianCalendar(
TimeZone.getTimeZone("CEST"), Locale.getDefault());
Looks bad, problem is the default Locale. But how to fix this in FreeBSD, is
there a file in /etc/ which contains a default ? "locale" reports:
# locale
LANG=
LC_CTYPE="C"
LC_COLLATE="C"
LC_TIME="C"
LC_NUMERIC="C"
LC_MONETARY="C"
LC_MESSAGES="C"
LC_ALL=
with
# setenv LANG de_DE.ISO8859-1
this could be fixed - and my test program works ! Now looking for a good place
where to set "LANG" system wide ...
> # setenv LANG de_DE.ISO8859-1
/etc/login.conf
man login.conf
migh probably do what you want.
Regards,
Holger Kipp
Right, using the same locale settings on Linux gives the same results as
FreeBSD. The best place to set LANG would be /etc/login.conf, unless you
have other requirements.
Cheers,
Panagiotis