- A Concurrent Affair - https://www.concurrentaffair.org -

DrJava’s Most Annoying Bug is Sun’s JVM Bug

Posted By Mathias On In DrJava | 1 Comment

Corky just notified me that the very pesky ArrayIndexOutofBoundsException in DrJava that has been reported in numerous bug reports [1] (assigned to be duplicates of the first report, 2831821: Caret updating is broken [2]) is actually a JVM bug [3], not a bug in DrJava:

This is a documented bug in Java 6 which is supposed be fixed very soon in a new JVM release. (Update 16 build 2 is supposed to fix it but Update 16 build 1 is the current JDK release.)

See http://bugs.sun.com/view_bug.do?bug_id=6828938 [3] and http://bugs.sun.com/view_bug.do?bug_id=6857057 [4].

In my experience, it does not adversely affect the behavior of Drjava so I ignore it. It happens often on Linux with the Plastic look-and-feel.

The exception trace we have been seeing had no DrJava code in it:

Exception in thread "AWT-EventQueue-0" java.lang.ArrayIndexOutOfBoundsException: 8
	at sun.font.FontDesignMetrics.charsWidth(FontDesignMetrics.java:492)
	at javax.swing.text.Utilities.getTabbedTextOffset(Utilities.java:381)
	at javax.swing.text.Utilities.getTabbedTextOffset(Utilities.java:302)
	at javax.swing.text.Utilities.getTabbedTextOffset(Utilities.java:286)
	at javax.swing.text.PlainView.viewToModel(PlainView.java:403)
	at javax.swing.text.FieldView.viewToModel(FieldView.java:263)
	at javax.swing.plaf.basic.BasicTextUI$RootView.viewToModel(BasicTextUI.java:1540)
	at javax.swing.plaf.basic.BasicTextUI.viewToModel(BasicTextUI.java:1089)
	at javax.swing.text.DefaultCaret.moveCaret(DefaultCaret.java:311)
	at javax.swing.text.DefaultCaret.mouseDragged(DefaultCaret.java:565)
	at java.awt.AWTEventMulticaster.mouseDragged(AWTEventMulticaster.java:303)
	at java.awt.Component.processMouseMotionEvent(Component.java:6285)
	at javax.swing.JComponent.processMouseMotionEvent(JComponent.java:3285)
	at java.awt.Component.processEvent(Component.java:6006)
	at java.awt.Container.processEvent(Container.java:2041)
	at java.awt.Component.dispatchEventImpl(Component.java:4604)
	at java.awt.Container.dispatchEventImpl(Container.java:2099)
	at java.awt.Component.dispatchEvent(Component.java:4434)
	at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4574)
	at java.awt.LightweightDispatcher.processMouseEvent(Container.java:4255)
	at java.awt.LightweightDispatcher.dispatchEvent(Container.java:4168)
	at java.awt.Container.dispatchEventImpl(Container.java:2085)
	at java.awt.Window.dispatchEventImpl(Window.java:2475)
	at java.awt.Component.dispatchEvent(Component.java:4434)
	at java.awt.EventQueue.dispatchEvent(EventQueue.java:599)
	at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:269)
	at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:184)
	at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:174)
	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:169)
	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:161)
	at java.awt.EventDispatchThread.run(EventDispatchThread.java:122)

The bug description [4] says:

The test GlyphView2021 mis-uses the parameters `pos’ and `len’ to the GlyphView.getBreakWeight method. These parameters are expected to be in font-related units (pixels or whatever), but in the test they are passed as logical offsets into document (i.e., a number of characters). So in 2-nd run an interval passed to getBreakWeight is 12, and the width of two characters is 14. So they don’t fit and there’s no breakpoint in the region.

What a relief, I was starting to get frustrated with this. I hope the next JVM update is released soon.

[5] [6]Share [7]