Win a copy of Fixing your Scrum this week in the Agile 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
  • Paul Clapham
  • Rob Spoor
  • Liutauras Vilda
Sheriffs:
  • Jeanne Boyarsky
  • Junilu Lacar
  • Tim Cooke
Saloon Keepers:
  • Tim Holloway
  • Piet Souris
  • Stephan van Hulst
  • Tim Moores
  • Carey Brown
Bartenders:
  • Frits Walraven
  • Himai Minh

Set

 
Greenhorn
Posts: 1
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello,

during the java 25th anniversary when we all had access to oracle university i found an interesting question in the preparation test they provide.
Frankly i think, that it should be multiple choice question, but they expect only one.

Here is the code :



the question was : What is the output ?

And there are 7 options :

A, TCNJC
B, TCNJ
C, TJNC
D, CTJN
E, TCAJ
F, UnsupportedOperationException
G, TCAJC

The correct answer was D (only this one).

According to my knowledge set (some impl of set ...) is unordered and the method toSet() does not guarantee to return any specific implementation of Set interface.

So my question is : is there anything behind so it is obvious that the oracle is right ? Or there are multiple correct answers (TCNJ, NJTC etc ...) ?

Thanks
 
Master Rancher
Posts: 4000
52
  • Likes 2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
You are correct - there are multiple correct answers possible.  As long as you have the four letters C, J, N, T (no A), they can occur in any order.  Theoretically.

Now in practice, they do in fact occur in the order CTJN, at least under the current JDK implementation.  But that is based on specific implementation details of HashMap that are, as far as I know, now documented, and could change.  Plus details of String's hashCode() that are documented but, really, no programmer should reasonably be expected to have those details memorized.

Basically, this is a poor question to ask people, but your answer is better than theirs, even if theirs may in fact be true.
 
Master Rancher
Posts: 1011
28
Eclipse IDE Postgres Database C++ Java
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
So the guys writing the Javadocs are working hard to get people to never depend on "no guarantees" so that they don't paint the implementation team into a corner by having production code depending on implementation details that could change, and the guys writing the test questions here are undermining that!

I saw a presentation by Stuart Marks (actually a few, he is great) where he intentionally randomized the results of new API methods that returned Set or Map, even tho it was some extra work, so that nobody would get "stuck to the couch" depending on those results.  Of course, they wish they had done that everywhere, because dumb programmers reason from results they happen to see in one run of something with specific data, instead of what is guaranteed.  They didn't, and there are things that they would love to improve, but there is code out there expecting certain results.

Perl added some randomizations somewhere (I think maps) for security reasons, so that hackers had a harder time hacking.  That wasn't the reason given for the randomization in some Map or Set related results.  Nobody could possibly be depending on non-guaranteed ordering in API calls that didn't exist previously, so they got unpredictable results from the first call.  That means they can improve the implementation later without anyone screaming at them.

In the Old Days, good Java books would warn you against making assumptions based upon your platform of Java, there were other JVM's out there and as long as everything followed the JLS and the JVM specs, they were legitimate.  Writing code that depended on non-guaranteed behavior was a great way to force your Java to be non-portable.

Now pretty much everyone uses OpenJDK, but if you rely on stuff that "just happens to happen" on the version of Java you are using (8, 9, 10, 11, ... 16) you can still write code that will break and cause Maintenance Programmers in the future to curse your name...

I like to think there aren't a lot of Cert Exam questions that would actually reinforce such behaviors, they wind up holding us all back when the Java Team can't give us something better because it will break some bone-headed Assumptions that made their way into commonly used Open or Closed-source projects.

I think this is an example where at least the training materials did that.  Boo!!  What do our Best Friends, the JavaDocs say about this?

Returns a Collector that accumulates the input elements into a new Set. There are no guarantees on the type, mutability, serializability, or thread-safety of the Set returned; if more control over the returned Set is required, use toCollection(Supplier).
This is an unordered Collector.



Correct me if I am wrong, but the highlighted words mean "If you assume you are always going to get the same ordering you happen to see when you run this once, you are likely wrong, right?"

Or does being an "unordered Collector" mean something different?  I know that "unordered streams" are way less work to .parallelStream(), and actually this is what I was studying right when I saw this.
If a Stream is ordered it means that the encounter order matters, and that means more work when re-integrating parallel results, what exactly does being an "Unordered Collector" mean?
 
Jesse Silverman
Master Rancher
Posts: 1011
28
Eclipse IDE Postgres Database C++ Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I answered my own question but won't EDIT to look smarter at the risk of getting the TVA on my case.

Our friends the JavaDocs say:

public static final Collector.Characteristics UNORDERED
Indicates that the collection operation does not commit to preserving the encounter order of input elements. (This might be true if the result container has no intrinsic order, such as a Set.)



Literally, there is no guarantee before we get to the Iterator of whatever kind of Set it decides to give us back.

If it happens to be a HashSet (not guaranteed), then we go read some more JavaDocs and see:
public Iterator<E> iterator()
Returns an iterator over the elements in this set. The elements are returned in no particular order.

Presuming that the results of iterating over a HashSet are always going to come out in the same order you see on this particular run on this particular Java version is Bone-Headed Bad Assumption-Making.

LinkedHashSet is a different story?  No, because then we fall back to the fact that the Collector toSet() is UNORDERED, so even there you are painting yourself into a corner pretending you know what order they will come out in!
 
Jesse Silverman
Master Rancher
Posts: 1011
28
Eclipse IDE Postgres Database C++ Java
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Note, since this is the Programmer Certification (OCPJP) forum, normally when you see answer choices that depend on not-guaranteed assumptions, those choices are to be considered WRONG and not selected, of course.
 
Pay attention! Tiny ad!
the value of filler advertising in 2021
https://coderanch.com/t/730886/filler-advertising
reply
    Bookmark Topic Watch Topic
  • New Topic