Name: asR10013 Date: 04/23/2002


Filed By : J2SE-SQA [###@###.###
JDK : jdk1.4.1-b09, plugin
JCK : jck1.4-b17
Platform[s] : Windows 2000, Windows 95
switch/Mode : plugin with IE 6.0
JCK test owner : http://javaweb.eng/jck/usr/owners.jto
Falling test[s]: api/java_sql/serialization/description.html#Date, api/java_sql/serialization/description.html#Time

These tests fail when running in the plugin VM on Windows platforms, GMT+6 timezone. I discovered these failures because this is our usual timezone.
The reason is that the read values differ from the expected values by the DST offset for dates where DST is used.

The following observations about the bug's reproducibility were made:
1) Tests fail only when running in the plugin vm and the system timezone has its "use daylight saving" property on.
2) This is independent of the timezone used.
3) The bug is reproducible only in jdk1.4.1-b08, jdk1.4.1-b09 and is not reproducible under older builds or releases (tested also with jdk1.4.1-b08, jdk1.4.0-b92).
4) The bug appears in the following browsers: Netscape 4.76, IE5.0, IE6.0.
5) Further exploration discovered that the bug is reproducible only when running tests under the JavaTest agent.
I wrote my own test applet that loaded and executed the tests but the bug was not reproduced in such environment.

6) There is another satellite bug or rather a symptom of the bug:
The getOffset of the timezone returned by TimeZone.getDefault() suddenly starts to return 5.5 instead of 6.0.
This is not correct, and, according to my observations, this happens every time the tests fail and does not happen when tests do not fail.
7) When the system "use daylight saving" flag is on the TimeZone object returned by TimeZone.getDefault() has the following properties:
ID: Asia/Dhaka
Display Name: Bangladesh Time
   and when the flag is off, the properties are the following:
ID: GMT+06:00
Display Name: GMT+06:00


The following researches have been made on the Windows 95 platform using IE5.0. I hope this information will be usefull for developers to fix the bug.
I recompiled the Javatest agent with some debug output and used it to localize the place where the satellite bug described above appeared for the first time.

=====
I noticed that this always happened when
    the Task innerclass of com.sun.javatest.agent.Agent was created for the first time in sun.javatest.agent.Agent.handleRequestsUntilClosed().
=====

Then I inserted the some code that utilizes PluginClassLoader into com.sun.javatest.agent.Agent.handleRequestsUntilClosed() before "new Task"

This test showed that the satellite bug occured when Agent.Task is loaded by PluginClassLoader.
I used also URLClassLoader and other classes including another innerclass of Agent.
Changes in the default timezone happened only when Agent.Task was loaded using PluginClassLoader.
In other cases changes in the default timezone appeared only after task = new Task(..)

The same results were for Netscape Communicator 4.76.


Test source location:
=====================
/net/jdk/export/disk8/local.java/jck1.4/JCK-runtime-14/tests/api/java_sql/serialization/DateTests.java
/net/jdk/export/disk8/local.java/jck1.4/JCK-runtime-14/tests/api/java_sql/serialization/TimeTests.java
 
jtr file location:
==================
/net/jtgb4u4c.eng/export/sail15/results/hopper/b09/jck14/win32/win2000_plugin_ie6.0_linux-2/workDir/api/java_sql/serialization/descriptions_Date.jtr
/net/jtgb4u4c.eng/export/sail15/results/hopper/b09/jck14/win32/win2000_plugin_ie6.0_linux-2/workDir/api/java_sql/serialization/descriptions_Time.jtr

How to reproduce:
=================
1) Install JDK1.4.1-b09 if it is not already installed. The plugin of JDK1.4.1-b09 must be the default plugin for the browser where you want to reproduce the bug.
This can be checked while installing JCK (selected by default) or in the control panel applet for Java plugin 1.4.1.

2) Start Javatest as you usually start it

3) adjust Javatest to run the following tests:

api/java_sql/serialization/descriptions.html#Date
api/java_sql/serialization/descriptions.html#Time

The tests must be run in the java plugin-vm (using SlaveCommand)

4) In the Agent Monitor page of Javatest enter the appropriate port (written in your classes/slave.html file) and check the Listen checkbox.

5) Open classes/slave.html from your JCK installation in the browser you want to test. Make sure that the agent is connected to Javatest and
the corresponded item appeared in the list in the Agent Monitor page.

6) Run tests from the Javatest


Test output:
============

Executing command via localhost.nbsp.nsk.su,port=1770,localport=1907
testRead: Failed. Equals test, expected: Sun May 24 05:30:00 BDT 1970, received: 1970-05-24
testWrite: Passed. OKAY

Specific Machine Info:
======================
Hostname: linux-2
OS: Windows 2000

======================================================================