Results 1 to 10 of 10
Like Tree1Likes
  • 1 Post By jim829

Thread: Interesting Code in JFileChooser

  1. #1
    jim829 is offline Senior Member
    Join Date
    Jan 2013
    Location
    Northern Virginia, United States
    Posts
    6,226
    Rep Power
    13

    Default Interesting Code in JFileChooser

    Recent discussions led me to look at the JFileChooser source code. I found this:

    Java Code:
    public void setApproveButtonText(String approveButtonText) {
            if(this.approveButtonText == approveButtonText) {
                return;
            }
            String oldValue = this.approveButtonText;
            this.approveButtonText = approveButtonText;
            firePropertyChange(APPROVE_BUTTON_TEXT_CHANGED_PROPERTY, oldValue, approveButtonText);
    }
    What caught my eye was the way the strings are compared using ==. If there is a reason, I can't figure it out. Because the firePropertyChange method does a final "proper" comparison using equals(), no event is fired if the strings compare equally. However, if you create two separate String objects of the same string, it does make the exchange because the == will fail and the change is made immediately. I verified this using the System.identityHashCode() method.

    I also noticed that other methods involving a String argument are handled similarly. I am running java 1.8.

    Regards,
    Jim
    KevinWorkman likes this.
    The JavaTM Tutorials | SSCCE | Java Naming Conventions
    Poor planning on your part does not constitute an emergency on my part

  2. #2
    KevinWorkman's Avatar
    KevinWorkman is offline Crazy Cat Lady
    Join Date
    Oct 2010
    Location
    Washington, DC
    Posts
    4,143
    Rep Power
    14

    Default Re: Interesting Code in JFileChooser

    This is weird. I've been trying to peruse the source of older JDKs. I found this, but I'm not sure which version it is: Source for javax.swing.JFileChooser (GNU Classpath 0.95 Documentation)

    But the point is that it was slightly different:

    Java Code:
     949:   public void setApproveButtonText(String approveButtonText)
     950:   {
     951:     if (this.approveButtonText != approveButtonText)
     952:       {
     953:     String oldText = this.approveButtonText;
     954:     this.approveButtonText = approveButtonText;
     955:     firePropertyChange(APPROVE_BUTTON_TEXT_CHANGED_PROPERTY, oldText,
     956:                        this.approveButtonText);
     957:       }
     958:   }
    I'm not sure what this means or why they're using == though. I'd be curious to hear any explanations.
    How to Ask Questions the Smart Way
    Static Void Games - GameDev tutorials, free Java and JavaScript hosting!
    Static Void Games forum - Come say hello!

  3. #3
    jim829 is offline Senior Member
    Join Date
    Jan 2013
    Location
    Northern Virginia, United States
    Posts
    6,226
    Rep Power
    13

    Default Re: Interesting Code in JFileChooser

    Hmm. In my posted version, they use == and return if true. In yours, they only execute the code if !=. Same thing, so why the change? Seems to me that the most straightforward way would be to just make the change regardless and let the firing code determine if the change warrants an event notification.

    Regards,
    Jim
    The JavaTM Tutorials | SSCCE | Java Naming Conventions
    Poor planning on your part does not constitute an emergency on my part

  4. #4
    KevinWorkman's Avatar
    KevinWorkman is offline Crazy Cat Lady
    Join Date
    Oct 2010
    Location
    Washington, DC
    Posts
    4,143
    Rep Power
    14

    Default Re: Interesting Code in JFileChooser

    It seems even weirder, considering that the String.equals() method starts with a check against ==.
    How to Ask Questions the Smart Way
    Static Void Games - GameDev tutorials, free Java and JavaScript hosting!
    Static Void Games forum - Come say hello!

  5. #5
    gimbal2 is offline Just a guy
    Join Date
    Jun 2013
    Location
    Netherlands
    Posts
    5,114
    Rep Power
    12

    Default Re: Interesting Code in JFileChooser

    My gut is talking to me. I don't know if it is the pork sausage I had for lunch or a gut feeling.

    Possibly that code is there to work together with the runtime optimizer in some way?

    One thing is for certain and that is that it is significant, because otherwise that code would have been removed rather than altered. I assume people touching that code know what they are doing and people reviewing the changes know what they are doing too, so its not ignorance.
    Last edited by gimbal2; 02-04-2015 at 05:21 PM.
    "Syntactic sugar causes cancer of the semicolon." -- Alan Perlis

  6. #6
    DarrylBurke's Avatar
    DarrylBurke is offline Forum Police
    Join Date
    Sep 2008
    Location
    Madgaon, Goa, India
    Posts
    12,059
    Rep Power
    25

    Default Re: Interesting Code in JFileChooser

    Quote Originally Posted by gimbal2 View Post
    I assume people touching that code know what they are doing and people reviewing the changes know what they are doing too, so its not ignorance.
    Wanna bet? ;)

    <thread hijack>I recently bumped up against this:
    ListSelectionModel doesn't hold a reference to either the JList or its ListModel. As a result, you can set a selection range beyond the size of the list or its model. This blows up with AIOOBE if you call JList#getSelectedItemsList, added in Java 7. (OK, it also blows up if you call the now deprecated getSelectedValues.)
    </thread hijack>

    Back on topic, a LOT of older code relies on the String pool and uses == to compare Strings that are only ever assigned from literals. There's also a lot of reuse of mutable objects (Point, Dimension, Rectangle ...) dating from the days of slower computers and less efficient JVMs.
    db
    If you're forever cleaning cobwebs, it's time to get rid of the spiders.

  7. #7
    gimbal2 is offline Just a guy
    Join Date
    Jun 2013
    Location
    Netherlands
    Posts
    5,114
    Rep Power
    12

    Default Re: Interesting Code in JFileChooser

    Too bad, "old code from days of slower computers" sounds far more reasonable. And boring.

    Still funny that the code was changed. Someone did dare to touch it, but apparently not to go as far as clean it up.
    "Syntactic sugar causes cancer of the semicolon." -- Alan Perlis

  8. #8
    JosAH's Avatar
    JosAH is offline Moderator
    Join Date
    Sep 2008
    Location
    Voorschoten, the Netherlands
    Posts
    14,423
    Blog Entries
    7
    Rep Power
    27

    Default Re: Interesting Code in JFileChooser

    Quote Originally Posted by jim829 View Post
    Hmm. In my posted version, they use == and return if true. In yours, they only execute the code if !=. Same thing, so why the change? Seems to me that the most straightforward way would be to just make the change regardless and let the firing code determine if the change warrants an event notification.
    Those gnu folks wrote their version of the core classes without even look at Sun's reference implementation (or so they say); it would be likely that their source code differs from the original stuff. Both implementations could've been lazy and go through the entire hoopla, only to make the fireXXX( ... ) figure out that X was change to the same X; I guess (and that's just my guess) that that particular
    method is most often called with a literal String parameter and the cheap check at the start (== or !=) blocks all the rest of the code from executing ...

    kind regards,

    Jos
    Build a wall around Donald Trump; I'll pay for it.

  9. #9
    KevinWorkman's Avatar
    KevinWorkman is offline Crazy Cat Lady
    Join Date
    Oct 2010
    Location
    Washington, DC
    Posts
    4,143
    Rep Power
    14

    Default Re: Interesting Code in JFileChooser

    Ah whoops, I thought I was looking at an older version of the JDK's source (it's what turned up when I googled "java 1.4 jdk source")
    How to Ask Questions the Smart Way
    Static Void Games - GameDev tutorials, free Java and JavaScript hosting!
    Static Void Games forum - Come say hello!

  10. #10
    JosAH's Avatar
    JosAH is offline Moderator
    Join Date
    Sep 2008
    Location
    Voorschoten, the Netherlands
    Posts
    14,423
    Blog Entries
    7
    Rep Power
    27

    Default Re: Interesting Code in JFileChooser

    Quote Originally Posted by KevinWorkman View Post
    Ah whoops, I thought I was looking at an older version of the JDK's source (it's what turned up when I googled "java 1.4 jdk source")
    OpenJDK completely overtook gnu's Classpath (they only came as far as version 0.99) while the latter is only Java 1.5 compliant and still full of bugs; but gnu's Classpath is all there is on certain platforms ...

    kind regards,

    Jos
    Build a wall around Donald Trump; I'll pay for it.

Similar Threads

  1. Another interesting task
    By d3m3tri0 in forum New To Java
    Replies: 10
    Last Post: 11-01-2013, 03:31 PM
  2. Interesting JButton Query
    By ravjot28 in forum AWT / Swing
    Replies: 3
    Last Post: 01-14-2010, 04:54 PM
  3. Interesting CS problem. Need help.
    By xtrmi in forum New To Java
    Replies: 1
    Last Post: 05-02-2009, 03:51 AM
  4. Interesting Experiment
    By uncommon in forum Advanced Java
    Replies: 13
    Last Post: 12-20-2008, 11:30 PM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •