United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
JDK-4492274 : JEditorPane.setPage(URL)-the URL treated as immutable object

Details
Type:
Enhancement
Submit Date:
2001-08-15
Status:
Resolved
Updated Date:
2003-07-26
Project Name:
JDK
Resolved Date:
2003-07-26
Component:
client-libs
OS:
generic,windows_98
Sub-Component:
javax.swing
CPU:
x86,generic
Priority:
P4
Resolution:
Fixed
Affected Versions:
1.3.1,1.4.0
Fixed Versions:
5.0 (tiger)

Related Reports

Sub Tasks

Description

Name: nt126004			Date: 08/15/2001


java -version
java version "1.3.0"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.0)
Java HotSpot(TM) Client VM (build 1.3.0, mixed mode)



Because of this line in JEditorPane.setPage(URL)

"if ((loaded == null) || (! loaded.sameFile(page))) {"

A user of the class is forced to use two lines of code to prevent the URL from
caching internally.

Since a URL object is a DYNAMICALLY CHANGING thing this is what I consider a
poor choice.  Maybe the contract should be changed from setPage(URL) to
considerPage(URL).  <grin>

Seriously I find the behavior very poor since the writer of the JEditorPane does
NOT mention ANYWHERE in the JavaDoc for setPage(URL) that he is caching.

So to put things in context if I have a file that I pull via URL from an
embedded network device and download it I CAN NO LONGER download it a second
time to ensure an up to date version of the file.  IF YOU DO CACHE PLEASE tell
me and allow me a way to turn it on and off.  URL's ARE NOT IMMUTABLE objects
and if they were we would only have to read www.java.sun.com once right?
<smile>

Ironically the fix is two lines of code and requires me to examine a Document
object when all I want is standard URLConnection.setUseCaches(false) behavior.

If I set the 'UseCaches(false)' and then pass the URL reference to JEditorPane
I'm misled to believe that the URL object behavior is controlled by my previous
contract.  JEditorPane makes decisions for me about an object I passed it
without telling me.  This is close to being a bug but since most developers
consider that word to have 4 letters I will nicely suggest an enhancement to the
JEditorPane object to turn off and on URL caching. :-)
(Review ID: 130063) 
======================================================================

Name: jk109818			Date: 10/17/2002


FULL PRODUCT VERSION :
java version "1.4.0_01"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0_01-b03)
Java HotSpot(TM) Client VM (build 1.4.0_01-b03, mixed mode)

FULL OPERATING SYSTEM VERSION :
Windows Millennium [Version 4.90.3000]

A DESCRIPTION OF THE PROBLEM :
JEditorPane.setPage(URL) doesn't update
Document.StreamDescriptionProperty when the URL is in the
same file as the current URL but has a different reference.

For example,

1. JEditorPane.getPage() is called and returns

   file:///C:\j2sdk1.4.0\docs\api\javax\swing   JEditorPane.html

2. Then JEditorPane.setPage(file:///C:\j2sdk1.4.0\docs\api   javax\swing\JEditorPane.html#getPage()) is called.

3. However, when JEditorPane.getPage() is called again,
   it returns the URL in step 1 instead of the one from
   step 2.

This doesn't cause problems on the setPage call in step 2,
but leads to problems when setPage is called again,
because getPage returns the URL it was set to before
instead of the one it's set to now.

I originally submitted this bug report on June 25, 2002
(Review ID: 148266).  Per Jeffrey Kim's request I checked
the JEditorPane.setPage code in 1.4.1-RC and found the
problem still exists.  Thus, I'm resubmitting it.

When you look at the code, you'll see the code on lines
404-406:

if (doc.getProperty(Document.StreamDescriptionProperty) ==
null) {
    doc.putProperty(Document.StreamDescriptionProperty,
page);
}

isn't executed because the code on line 389:

if ((loaded == null) || (! loaded.sameFile(page))) {

precludes it when the old URL (loaded) and new URL (page)
are in the same file.



STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
See the description above.

EXPECTED VERSUS ACTUAL BEHAVIOR :
See description above.

REPRODUCIBILITY :
This bug can be reproduced always.

CUSTOMER WORKAROUND :
After each call to setPage, make the following check:

editorPane.setPage(url);

if (!editorPane.getPage().equals(url))
{
    editorPane.getDocument().
    putProperty(Document.StreamDescriptionProperty, url);
}

Note that setPage is called in 10 core files in addition to
my application files.  I had to patch the ones in
FrameView.java.
(Review ID: 163933)
======================================================================

                                    

Comments
CONVERTED DATA

BugTraq+ Release Management Values

COMMIT TO FIX:
tiger

FIXED IN:
tiger

INTEGRATED IN:
tiger
tiger-b13


                                     
2004-06-14
WORK AROUND



Name: nt126004			Date: 08/15/2001


Customer's Workaround:
// clear the internal URL object in this control
         // TO PREVENT URL CACHING...
          Document doc = jEditorPane.getDocument();
          doc.putProperty(Document.StreamDescriptionProperty,null);
======================================================================
                                     
2004-06-11
EVALUATION

This bug describes a valid problem that should be addressed. Possible solutions include: always loading the URL unless it is the same one AND includes a reference; creating a property that says whether or not URLs should be cached. Since this has always been this way, I am moving this to an RFE and changing the priority to 4. This will be considered again post-merlin.
###@###.### 2001-08-17

Name: dsR10138			Date: 03/21/2003



There are two issues mensioned in the bug report.
First one is that JEditorPane.setPage(URL) doesn't
reload the document if the specified URL is the
same as the document being displayed has. This won't
be fixed since there is a simple workaround. The way
to reload a document will be described in documentation.

The second issue is that JEditorPane.getPage() doesn't
correctly return the URL if the page being displayed was 
scrolled to an anchor. This will be fixed.

###@###.### 2003-03-19


======================================================================
                                     
2003-03-19



Hardware and Software, Engineered to Work Together