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

Corky just notified me that the very pesky ArrayIndexOutofBoundsException in DrJava that has been reported in numerous bug reports (assigned to be duplicates of the first report, 2831821: Caret updating is broken) is actually a JVM bug, 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 and http://bugs.sun.com/view_bug.do?bug_id=6857057. 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 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.