This week's book giveaway is in the Server-Side JavaScript and NodeJS forum.
We're giving away four copies of Node.js Design Patterns: Design and implement production-grade Node.js applications using proven patterns and techniques and have Mario Casciaro & Luciano Mammino on-line!
See this thread for details.
Win a copy of Node.js Design Patterns: Design and implement production-grade Node.js applications using proven patterns and techniques this week in the Server-Side JavaScript and NodeJS forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Ron McLeod
  • Rob Spoor
  • Tim Cooke
  • Junilu Lacar
Sheriffs:
  • Henry Wong
  • Liutauras Vilda
  • Jeanne Boyarsky
Saloon Keepers:
  • Jesse Silverman
  • Tim Holloway
  • Stephan van Hulst
  • Tim Moores
  • Carey Brown
Bartenders:
  • Al Hobbs
  • Mikalai Zaikin
  • Piet Souris

.replace(oldChar, newChar) vs..replace(oldString, newString)

 
Ranch Hand
Posts: 110
2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Dear All,

Please can someone kindly explain why flag1 evaluates to true and flag2 evaluates to false? Many thanks for any help that you can give



The source of this question comes from the Online Udemy Course "Pass the Oracle Certified Associate(OCA): Java SE 8 Programmer I EXAM"
Instructor: Udayan Khattry
 
Saloon Keeper
Posts: 13283
292
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
It appears as if the replace(char, char) just returns the current string instance if the two characters are the same. Since the string instance you call replace() on comes from a string literal, it will be the same instance as the string literal you compare it to.

The replace(CharSequence, CharSequence) variant appears to return a new string instance, even if the method arguments are equal to each other. A new string instance will never be the same instance as a string literal.

Honestly, I really don't understand why exams include stupid questions like this. It tests absolutely nothing worth knowing.

The only real lesson here is that you must never use == when comparing strings. Always use equals().
 
Saloon Keeper
Posts: 24330
167
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Stephan van Hulst wrote:Honestly, I really don't understand why exams include stupid questions like this. It tests absolutely nothing worth knowing.


Stuff like that is precisely why I never bothered to sit for certification. Too much emphasis on things that would either cause me to be jailed for assault if someone inflicted them on me in the Real World and stuff that's so obscure that I'd have to look it up and find out what the latest rules were should I actually need it - And I'm thinking especially - but not only - of the Java assertion mechanisms.

The character versus character optimization is all well and good, but I wouldn't assume that it's universally true unless the Java specification explicitly says so.  It's one of those things that a language (in this case, class) provider has wide discretion on how they implement.

As to the second case, if memory serves, the first argument is a regex and therefore it would be much more overhead to A) ensure that the first argument was a true string literal and nothing more and B) to search for that specific case as opposed to simply running the internal regex machine.

Stephan van Hulst wrote:The only real lesson here is that you must never use == when comparing strings. Always use equals().



Chisel it in stone above your doorway!
 
Master Rancher
Posts: 4035
54
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The behavior of String#replace(char, char) is of course not specified in the Java language specification.  It is, however, specified by the String API.  Mostly because it was written as part of JDK 1.0 by someone who evidently didn't know any better, over-specifying the behavior of the method.  A few other methods put the same sort of behavior in their documentation - most do not.  In particular, String#replace(CharSequence, CharSequence) does not say anything about whether it creates a new String in all cases.  So, the behavior of this code is technically unspecified, and could change under a different JDK.

Even if it were specified, it would still make a very poor exam question.  That level of detail in API of each method is not useful to memorize or worry about.  The real exam did not have anything like this in its question when I took it many moons ago - I highly doubt they do now, either.  Unfortunately, this sort of thing does show up in various lower-quality practice exams, causing a lot of pointless worrying.

Tim Holloway wrote:As to the second case, if memory serves, the first argument is a regex and therefore it would be much more overhead to A) ensure that the first argument was a true string literal and nothing more and B) to search for that specific case as opposed to simply running the internal regex machine.


No, String#replace(CharSequence, CharSequence) actually treats its first argument as a literal, not a regex.  Which is quite unfortunate - that's not apparent at all from the name.  The only (weak) excuse is that they were matching the behavior of the pre-existing replace(char, char) method, which also treats its first argument as a literal.  So, all replace() methods treat the first arg as literal, and all replaceAll() or replaceFirst() methods treat the first arg as a regex.  
 
Tim Holloway
Saloon Keeper
Posts: 24330
167
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Ah. I see my error. String.replaceFirst and replaceAll do take regexes, though.

The truly treacherous thing about this is that String implements CharSequence, so it's only disambiguation measures that spare us.
 
Getting married means "We're in love, so let's tell the police!" - and invite this tiny ad to the wedding:
Thread Boost feature
https://coderanch.com/t/674455/Thread-Boost-feature
reply
    Bookmark Topic Watch Topic
  • New Topic