About JTextPane, Why "Not equal" ?

[Red Orchid]

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.

 

[SadRed]

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.

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));
}
}
-------------------------------------------------

 

[Andrew Thompson]

I prefer SadRed's SSCCE (I had prepared one
of my own, but SR beat me to the punch!).
...

....
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.

 

[SadRed]

I prefer SadRed's SSCCE (I had prepared one
of my own, but SR beat me to the punch!).
..


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.

Linux + Java 1.6.0
Were your two string different on print out?

 

[Tom Hawtin]

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

 

[Andrew Thompson]

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.

 

[Andrew Thompson]

Andrew Thompson wrote: ....
The code compares the raw text, so the attributes should come into it.

(snip explanation)

Thanks for filling in those details.

Andrew T.

 

[SadRed]

I get 'true' on Ubuntu with Java 1.6.0 and 1.4.2_13.


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

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. ;-)

 

[Andrew Thompson]

On Mar 31, 7:13 pm, Tom Hawtin <[email protected]> wrote:> Andrew Thompson wrote:

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.

 

[Red Orchid]

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
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";
^^

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

 

[Tom Hawtin]

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:
--
13
13
10
48
13
13
10
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

 

[Andrew Thompson]

..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.

 

[Lew]

'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]

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.

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.

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.

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

 

[Andrew Thompson]

...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.