 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / General / March 2007About JTextPane, Why "Not equal" ?
See this code. <code> // JDK 1.5.0_11 void process() throws BadLocationException { String s = "\r\n12345\r\n6890"; JTextPane p0 = new JTextPane(); JTextPane p1 = new JTextPane(); /////////////////////////////////// // Irrelevant to this issue // p0.getDocument().putProperty(DefaultEditorKit.EndOfLineStringProperty, "\r\n"); // p1.getDocument().putProperty(DefaultEditorKit.EndOfLineStringProperty, "\r\n"); /////////////////////////////////// p0.setText(s); p1.getDocument().insertString(0, s, null); String r0 = p0.getText(); String r1 = p1.getText(); System.out.println(r0.equals(r1)); } </code> I expected that "true" is printed. But the code above prints "false". Why ? Is it proper behavior of JTextPane ? Thanks. > See this code. > [quoted text clipped - 27 lines] > > Thanks. It does print "true". ------------------------------------------------- import javax.swing.*; public class RedOrchid{ public static void main(String[] args) throws Exception{ String s = "\r\n12345\r\n6890"; JTextPane p0 = new JTextPane(); JTextPane p1 = new JTextPane(); p0.setText(s); p1.getDocument().insertString(0, s, null); String r0 = p0.getText(); String r1 = p1.getText(); System.out.println(r0 + " " + r1 + "\n" + r0.equals(r1)); } } ------------------------------------------------- > > See this code. I prefer SadRed's SSCCE (I had prepared one of my own, but SR beat me to the punch!). .. > > I expected that "true" is printed. But the code above prints "false". ... > It does print "true". Not here. Using your code (or mine), Java 1.6.0, on WinXP, I get 'false'. I suspect it has something to do with the 'null' character attribute set, but am not sure. What OS/Java are you running? Andrew T. > > > See this code. > [quoted text clipped - 15 lines] > > Andrew T. Linux + Java 1.6.0 Were your two string different on print out? .. > Were your two string different on print out? Here is the output, copy/pasted from the DOS prompt.. _____________________ 12345 6890 12345 6890 false Press any key to continue . . . _____________________ ..note that first, entirely blank line, I had not noticed that till now. OTOH, I think Tom has identified the root cause. Andrew T. > .. >>> I expected that "true" is printed. But the code above prints "false". [quoted text clipped - 3 lines] > Not here. Using your code (or mine), > Java 1.6.0, on WinXP, I get 'false'. I get 'true' on Ubuntu with Java 1.6.0 and 1.4.2_13. > I suspect it has something to do with the 'null' > character attribute set, but am not sure. The code compares the raw text, so the attributes should come into it. The difference between JEditorPane.setText and Document.insertString (other than that one replaces, etc) is that setText goes through the EditorKit (which then calls insertString). So you can setText an entire HTML document, if the JEditorPane is so configured. For plain text, the PlainEditorKit attempts to cope with different new line standard. It may not pass through the text unchanged. Mixing new line standards, makes it go false for me. String s = "\r\n123\n45\r\n6890"; ^^ Tom Hawtin ... > The code compares the raw text, so the attributes should come into it. (snip explanation) Thanks for filling in those details. Andrew T. Given I quoted *nothing* I wrote. I should have trimmed the 'Andrew Thompson wrote:' bit.. Ooops! I blame it on the JD ( three, doubles so far.. ;) Andrew t. > > .. > >>> I expected that "true" is printed. But the code above prints "false". [quoted text clipped - 23 lines] > ^^ > Tom Hawtin > PlainEditorKit It's DefaultEditorKit. I saw the source code of its read() method. And I just saw it is playing with various line-end markers, '\n', '\r' and '\r\n'. But nothing was clear to me. ;-) Tom Hawtin <usenet@tackline.plus.com> wrote or quoted in Message-ID <460e25ea$0$8726$ed2619ec@ptn-nntp-reader02.plus.net>: > The code compares the raw text, so the attributes should come into it. For comparing strings, what role do the above "attributes" play ? Event if "p1.getDocument().insertString(0, s, p1.getInputAttributes())", the result is "false" on JDK1.5.0_11 (WinXP). > The difference between JEditorPane.setText and Document.insertString > (other than that one replaces, etc) is that setText goes through the [quoted text clipped - 7 lines] > String s = "\r\n123\n45\r\n6890"; > ^^ Let's suppose that String s = "\r\n12345\r\n6890" is received from a remote server. With the same code, 1) SadRed and you said "true". 2) Andrew Thompson and I said "false". I think, it means that platform-independent code is not guaranteed with "JTextPane". And also, it means that an app has bugs if both "..setText" and "..insertString" are used in the app. See this code. <code> import javax.swing.JTextPane; import javax.swing.text.BadLocationException; import javax.swing.text.DefaultEditorKit; import javax.swing.text.Document; public class Test_Swing { public static void main(String[] args) throws BadLocationException { String s = "\r\n0\r\n1"; JTextPane pane = new JTextPane(); pane.getDocument().insertString(0, s, pane.getInputAttributes()); String r = pane.getText(); for (int i = 0; i < r.length(); i++) { System.out.println((int) r.charAt(i)); } } } </code> The above code prints this: -- 13 13 10 48 13 13 10 49 -- Note that 13(\r) was doubled. Was "JTextPane" and "Document" designed properly ? > I think, it means that platform-independent code is not guaranteed > with "JTextPane". And also, it means that an app has bugs if both > "..setText" and "..insertString" are used in the app. That would be like saying that an app has bugs in if it using String. Some of String's method pick up the default locale. As ever, static variables suck big time. > The above code prints this: > -- [quoted text clipped - 7 lines] > 49 > -- Not it doesn't, it prints: 10 48 13 10 49 Which is a little eccentric. If I switch from 1.4.2_13 to 1.6.0 I get: 13 10 48 13 10 49 > Note that 13(\r) was doubled. > Was "JTextPane" and "Document" designed properly ? In terms of duplicating the CR, that's a pure implementation bug. Tom Hawtin > ..As ever, static variables suck big time. 'For those of us that are a little slower than the rest' (OK.. me) could you expand a little on that? Andrew T. Tom Hawtin <use...@tackline.plus.com> wrote: >> ..As ever, static variables suck big time. > 'For those of us that are a little slower than the rest' > (OK.. me) could you expand a little on that? Whilst awaiting Tom's answer I shall venture a guess, which if Tom's answer differs I shall almost certainly abandon in favor of his explanation. Static variables are the global variables of Java. They have implicit effects ignorance of which can lead one to create bugs. Locale in a String is such a thing - global to all instances of String within a particular run of the JVM unless explicitly specified. This causes portability issues in such code. Likewise, I guess the AttributeSets in a JTextPane are implicit and can lead to surprising portability issues. I do not know what parts of the JTextPane issue are literally static or global, but I can see the point about implicit characteristics. Am I close? -- Lew > Tom Hawtin <use...@tackline.plus.com> wrote: >>> ..As ever, static variables suck big time. [quoted text clipped - 5 lines] > answer differs I shall almost certainly abandon in favor of his > explanation. That's a bad attitude. If you disagree, call me an asshat or something. > Static variables are the global variables of Java. They have implicit > effects ignorance of which can lead one to create bugs. [quoted text clipped - 7 lines] > I do not know what parts of the JTextPane issue are literally static or > global, but I can see the point about implicit characteristics. I didn't actually see where the problem is in JTextPane (is it actually a in getText, perhaps picking the default document line separator). It's a piece of configuration and even when I'm looking for it, it's not at all obvious. I spend all day (when I'm not posting to usenet) looking through code for bugs. These sort of things annoy me. So, general problems with (mutable, and immutable with context dependent initialisation) statics: * The class (and any clients of the class) now depends upon the entire application. This is Bad. You might think you only want to ever use one object per application. But that means that code defines what the application is. * If that code is ever turned used an applet (or similar), it will break. The idea of what an application is is broken. * Testing is made much more troublesome, due to the first point. You could try some classloading shenanigans with a bit of reflection, but I'd really rather not. * Initialisation sequence is not explicit. * If the initialisation legitimately throws an exception (a security exception, say), then you can never initialise that class again. For instance, you can almost adapt JUnit (3.8.1) GUI runner to run under WebStart, except for one flipping read of a system property. * Statics are implicitly multithreaded. You just know this is not going to be done right. So use "Parameterisation from Above"/"Dependency Injection". Or to put it in simpler terms, don't use statics. Tom Hawtin > ...If you disagree, call me an asshat or something. 'You're an asshat'. Naaah! Just kidding! But I couldn't resist trying to use that phrase in a sentence. ;-) (I promise that when I'm less drunk, I will read the full text of the posts pertaining to this matter) Andrew T. Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.