Java Magazine, Jan/Feb 2017

ORACLE COM JAVAMAGAZINE JANUARY FEBRUARY 2017 65 fix this documentation suggests that this rule varies based on accessibility so options B and D are incorrect too That leaves only options C and E as the two correct answers I should explain why these two are correct not simply accept the elimination of all the others even if doing that would have been suficient for Sherlock Holmes Considering option C if you make the declaration final you actually have achieved a constant variable Recall that the definition of a constant variable required a primitive or String that the variable be final and that it be initialized with a constant expression I should justify the assertion that you have a constant expression Section 1528 of the specification Constant Expressions describes the criteria for this and one of the first items in a fairly long list is the String literal So option C is correct Option E actually describes the case where the field is reverted to an instance field rather than a static one There are no restrictions on a regular instance field in an inner class so option E is also correct Theres just one thing left to consider and that is why this rule exists It probably seems a little arbitrary I dont have insight into the minds of those who put this together but I do have an explanation that makes reasonable sense and might serve to make the rule seem sensible and therefore easier to remember even if its not actually the logic that led to the rule With an inner class that is a nonstatic inner class its as if the class itself is a member of the enclosing instance That would require that every new outer instance create a new inner class just like a new instance creates a new copy of every field In this case the inner class is based on the same source code as all the other inner classes Each inner class would have its own version of any static members but how would you refer to those static members Youd need to distinguish which class youre referring to when you want to use one of these fields That could be complex ugly error prone and as history has shown unnecessary Java has survived with this restriction since the inception of inner classes in Java 11 Ill reiterate that this perspective might not be what Caution should be exercised when using a comparator capable of imposing an ordering inconsistent with equals the designers had in mind but they did call these things inner classes and not inner objects Either way I hope the mental model serves to help you remember that statics are not permitted in inner classes Nested classes however have no such restriction Question 2 The correct answer is option C This question investigates the behavior of sets in the Java APIs The most fundamental behavior of a set is that it does not permit duplicate entries In the API documentation for the Set interface this requirement is expressed in terms of the equals method specifically that no two non null entries may return true when one is tested against the other using the equals method and also that at most one null item is permitted To do this before actually adding a new item the set must test to see if the ofered item is already in the set A simple check of every item in turn would be very time consuming particularly as the number of items in the set grows Therefore the concrete implementations provided by Java seek to improve the speed of this check In TreeSet the items are added to the set in order and this means that the set can use a binary search to locate an item or determine that its not present A binary search is much more eficient particularly as the number of items in the set grows However in the example in the question the ordering is determined solely by the int field called order and this means that the two objects with order equal to 9 are at the same point in the ordering even though they have clearly