From HP:

----------------------
Hang is observed while running the jck test javasoft.sqe.tests.api.javax.swing.Timer.Ctor2Tests with JDK 7.0 on NonStop system which does not have Kernel level thread. This is not seen with JDK 6.0
 
 
On analysis of the issue, it was found that the run() method of the thread that posts the timer event in javax/swing/TimerQueue.java was in a continuous loop, thus not allowing the running of other threads.
This resulted in a hang on NonStop, since it does not have Kernel Level Thread.
 
On comparing javax/swing/TimerQueue.java of 7.0 with 6.0, it was observed that the file has changed significantly.
However it was observed that when the run() method is executed, the postExpiredTimers() method in it makes a call to wait with the following comment in 6.0 . Adding this in 7.0 solves the issue.
 
                // Allow other threads to call addTimer() and removeTimer()
                // even when we are posting Timers like mad. Since the wait()
                // releases the lock, be sure not to maintain any state
                // between iterations of the loop.
 
                try {
                    wait(1);
                }
                catch (InterruptedException e) {
                }
 

When we put the following change in 7.0 after the timer.isRepeats(), we observed that the testcase is passing.
Thus the below code changes are required on platform not supporting Kernel Level Threads.
                       
 
173: try {
174: DelayedTimer delayedTimer = timer.delayedTimer;
175: if (delayedTimer != null) {
176: /*
177: * Timer is not removed after we get it from
178: * the queue and before the lock on the timer is
179: * acquired
180: */
181: timer.post(); // have timer post an event
182: timer.delayedTimer = null;
183: if (timer.isRepeats()) {
184: delayedTimer.setTime(now()
185: + TimeUnit.MILLISECONDS.toNanos(
186: timer.getDelay()));
187: addTimer(delayedTimer);
188: }
189: try {
190: wait(1);
191: } catch ( InterruptedException e ) {
192: }
189: }
190: } catch (SecurityException ignore) {
191: } finally {
192: timer.getLock().unlock();
193: }
194: } catch (InterruptedException ie) {
195: // Shouldn't ignore InterruptedExceptions here, so AppContext
196: // is disposed gracefully, see 6799345 for details
197: if (AppContext.getAppContext().isDisposed()) {
198: break;
199: }
200: }
 
 
As the above code breaks with system that does not have Kernel Threads , we would like Oracle to address this issue. Also , as TimerQueue.java has changed a lot we would like Oracle to review the suggested fix and provide your feedback.
 
----------------------