I have two different editors using JTextPane with strange bugs in Java 7 that did not occur with the previous JVM versions. It happens with long lines containing styled text or components.
Here is an example demonstrating this bug. In this example, the default style is applied for all the text each time a character is inserted. I tested it with the JDK 1.7.0_04.
import java.awt.BorderLayout;
import javax.swing.*;
import javax.swing.event.*;
import javax.swing.text.*;
public class BugWrapJava7 extends JFrame {
JTextPane jtp;
StyledDocument doc;
public BugWrapJava7() {
setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
setLayout(new BorderLayout());
jtp = new JTextPane();
add(jtp, BorderLayout.CENTER);
jtp.setText("\ntype some text in the above empty line and check the wrapping behavior");
doc = jtp.getStyledDocument();
doc.addDocumentListener(new DocumentListener() {
public void insertUpdate(DocumentEvent e) {
insert();
}
public void removeUpdate(DocumentEvent e) {
}
public void changedUpdate(DocumentEvent e) {
}
});
setSize(200, 200);
setVisible(true);
}
public void insert() {
SwingUtilities.invokeLater(new Runnable() {
public void run() {
Style defaultStyle = jtp.getStyle(StyleContext.DEFAULT_STYLE);
doc.setCharacterAttributes(0, doc.getLength(), defaultStyle, false);
}
});
}
public static void main(String[] args) {
new BugWrapJava7();
}
}
My question is : is there something wrong in my code, or is it indeed a new bug introduced in Java 7 ? And if it is a new JVM bug, is there a workaround ?
It might be related to question 8666727, but the problem here lies in the wrong wrapping rather than the appearance of a scrollbar.
for futures readers, bug is still present in JDK 1.7.0_04.,
comparing Java7 and with stable Java6,
<------ Java7 v.s. Java6 --->
<------ Java7 v.s. Java6 --->
<------ Java7 v.s. Java6 --->
<------ Java7 v.s. Java6 --->
from code
My HTMLDocument was wrapping-by-letter. I installed StanislavL's above solution. No joy, still wrapping-by-letter inside <td> elements. So I fixed a bug in StanislavL's code. Joy; wrapping-by-word everywhere. Then I discovered that my program wasn't using the StanislavL code! It seems that my tinkering fixed the same bug in my own code.
The problem is that there are two different kinds of Element (in javax.swing.text and javax.swing.text.html.parser) and both have a tag type name with the string value "content". Method Element.getName confuses this by returning a String instead of an Object.
So where the code says ".equals()"
it should say "=="
Investigated this. The reason is breakSpots caching. Looks like
LabelView
stores them and don't recalculate offsets on previos text edit. If I reset them manually the bug does not happen.A workaround (very dirty because of private breakSpots fields) is following
Less hack without the reflection. Based on usual reset of breakSpots on model change.
UPDATE: This one fixes TextSamplerDemo as well. I reset all spots for all labels views.