Is there any way to force an instance or a functional interface static method output to be inmutable in a fashion like Collections.immutable(x)?
I'd like for instance to create sort of Comparator functional interface and disallow chained operations like ".thenComparing()" for some of the static builder-like methods created instances.
You can force your return value to be immutable by returning an instance of an immutable class. There is no general purpose way to make instances of your class immutable without knowing what the class does.
The second paragraph of your question contains an incorrect assumption that .thenComparing(...) makes a comparator mutable. thenComparing leaves the original comparator intact and makes a new comparator.
Sadly, the Java collection types lack immutable collections, but google guava comes with lots of immutable collections (see https://code.google.com/p/guava-libraries/wiki/ImmutableCollectionsExplained), so you can use those as a return type.
Yet, I can't see how this correlates with the ability to compare something, since comparing doesn't change stuff.
Related
I see that several converter methods in Java Library classes are non-static. Example : toEpochMilli() of Instant, toArray() of ArrayList. We can instead have static methods like toEpochMilli(Instant instant) and toArray(ArrayList arrayList) to achieve the same purpose, right? Is there any specific reason why these methods are non-static?
In a comment, you wrote:
Yes, it is more like an utility method and utility methods are usually static
which seems to reflect the mindset of your question very well. There are two problems with it. For one, there is no clear definition of “utility method”, which makes this categorization very subjective.
Second, the fact that utility methods are (or were) often implemented as static methods does not indicate that this is an actual design pattern that should be copied, just because it has been done that way before.
This is rather a historic compromise. Before Java 8, there were no default methods, so every method added to an interface had to be implemented, even if only by delegating to another helper method.
As a practical example, if sort was added to the List interface right at the beginning, every List implementor had to deal with it. So it was rather added as a static method to the Collections class which does not imply that anyone considered
Collections.sort(list, comparator); // no import static by that time
better than
list.sort(comparator);
Or that having a one-size-fits-them all implementation. Not only did this miss optimization opportunities for implementations like ArrayList, it also implied that erroneously applying it to an immutable list would stay unnoticed when the list happened to be in the right order.
Now that we have default methods, List has such a sort method, so implementors are still not required to deal with that, but they can override the method when it is appropriate. So ArrayList has an optimized version, immutable lists throw unconditionally and the implementation returned Collections.synchronizedList can make the entire operation synchronized.
The categorization as a “utility method” never played any role here. Note that other languages deal with it differently, e.g. via Extension Methods, which have their pros and cons on their own, but also show that having to write an invocation of a utility method as a static method is not an actual goal. Actually, it’s the opposite.
Static does not work as well with inheritance:
List<String> list1 = new ArrayList<>();
List<String> list2 = new LinkedList<>();
list1.size()
list2.size()
ArrayList.staticSize((ArrayList) list1)
LinkedList.staticSize((LinkedList) list2)
List.staticSize(list1); // NOT POSSIBLE
One would want something like:
interface List {
static staticSize(List list) {
return list.size();
}
}
But then still a non-static size() is used.
There is no static dispatch, polymorphism. (The JVM has some support, for other languages.)
I know what an interface is and what is a collection. But to be honest, I could not find any solid reason as why not to implement two collection interfaces in one class.
Got this question asked a few days back in an interview.
In some cases they are or can be implemented by the same object.
A Queue and a List are both implemented by LinkedList, TreeMap is both NavigableMap and SortedMap. There are a few other examples like this.
Each describes a trait or feature of the collection (exposed as a way to use it).
It just doesn't make sense all that often. For a Java collection to implement two interfaces it must be a near perfect implementation of both (and perhaps that's your answer).
A linkedlist COULD technically implement the methods of an ArrayList, however it would be a really bad idea.
Another point that hasn't been made already is that you can't implement the same interface twice with different type parameters.
As a result, if you tried to make a class implement both List<String> and Collection<Integer>, you would get a compiler error. This is because List<String> extends Collection<String> so we're trying to implement Collection twice with different type parameters.
If you did manage to implement two collection interfaces at once, it would have to be like the LinkedList example (where the generic type is the same when you think of it as a List and when you think of it as a Deque).
For starters, incompatible method contracts: e.g. List.add must always return true, and Set.add must always return false if the element is already present.
I cannot fathom why Java wishes to hide immutable unmodifiable collections from being passed around.
It makes life harder on devs because you can't guarantee that a class is returning anything immutable unmodifiable, forcing you to smatter calls to Collections.unmodifiableWhatever throughout your code. This is both wasteful and annoying.
Is there a reason I'm missing behind why you would make these methods protected, or another library I'm missing that contains public versions of immutable and/or unmodifiable collections?
For the purposes of learning more about java, let's say Scala does not count as an answer to "a library that contains public versions of immutable collections" :)
I think it has to do with the design goals of the framework:
The main design goal was to produce an API that was small in size and, more importantly, in "conceptual weight."
(Source)
You should check out Guava's immutable collection types, if you are willing to learn more conceptual weight :)
The Collections interface permits one to wrap an exiting Collection so that calls to mutator methods result in failure.
unmodifiableCollection(Collection c): "Returns an unmodifiable view of the specified collection."
It makes life harder on devs because you can't guarantee that a class is returning anything immutable, ... This is both wasteful and annoying.
The JDK source of the Collections.unmodifiableList() method is:
public static <T> List<T> unmodifiableList(List<? extends T> list) {
return (list instanceof RandomAccess ?
new UnmodifiableRandomAccessList<>(list) :
new UnmodifiableList<>(list));
}
I see why this can be considered wasteful (these generics also make it ugly). Why doesn't that method check whether the passed instance is already an UnmodifiableRandomAccessList or UnmodifiableList?
I'd like to utilize a unique java collection that can accept a strategy for determining if member objects are "equal" on collection initialization.
The reason I need to do this is because the equals method of the class that I need to add to this collection is already implemented to satisfy other (more appropriate) functionality. In a specific case, the criteria for uniqueness in this collection instance needs to check only one variable of the class as opposed to a number of variables that are checked in the equals method. I would prefer to avoid decorating the objects as I am gathering them from disparate libraries and it would be costly to loop through for decoration (and it may muddy my code).
I realize this would not be a Set as it would break the Java contract for Set, but I just feel as though this problem must have been encountered previously. I figured Guava or Apache Collections would have provided something, but no luck it seems. Does anybody know of any available library that does provide this type of functionality? Should I be entertaining a different solution altogether?
Can you use a Custom Comparator and a TreeSet or TreeMap? Or use a Map where the Key has your criteria? A HashSet is just a wrapper for a HashMap so using a map instead should be much more expensive.
That is not really practical. Consider for instance two instances of a class C which you consider equivalent.
Now you do:
set.add(c1);
set.remove(c2);
Should the set be empty after that? What about .retainAll(), .removeAll()?
Your best bet here is to create your own class which wraps over class C, deletages whatever is needed to be delegated, and have this wrapper class implement .hashCode() and .equals() (and possibly Comparable of itself too). With such a class, you can just go on and use classical sets and maps.
Guava has an Equivalence, which lets you define whether two objects are equivalent.
It also has Equivalence.Wrapper which wraps arbitrary objects and delegates equals() and hashCode() to the implementations in the equivalence, rather than their own.
So you could do something like this:
public class MySet<T> implements Set<T> {
private final Equivalence<T> equivalence;
private final Set<Wrapper<T>> delegate = new HashSet<Wrapper<T>>();
public MySet(Equivalence<T> equivalence) {
this.equivalence = equivalence;
}
public boolean add(T t) {
return delegate.add(equivalence.wrap(t));
}
// other Set methods
}
Collections.unmodifiableList(...) returns a new instance of a static inner class UnmodifiableList. Other unmodifiable collections classes are constructed same way.
Were these classes public, one had two advantages:
ability to indicate a more specific return value (such as UnmodifiableList), so an API user wouldn't come to the idea of modifying that collection;
ability to check during runtime if a List is instanceof UnmodifiableList.
So, were there any advantages not to make those classes public?
EDIT: No definitely convincing arguments were presented, so I choose the most upvoted answer.
Personally I completely agree with you. At the core of the problem is that fact that Java's generics are not covariant, which, in turn, is because Java's collections are mutable.
It is not possible for Java's type system to codify a type that seems to have mutators is actually immutable. Imagine if we were to start designing some solution:
interface Immutable //marker for immutability
interface ImmutableMap<K, V> extends Map<K, V>, Immutable
But then ImmutableMap is a subclass of Map, and hence Map is assignable from ImmutableMap so any method which returns such an immutable Map:
public ImmutableMap<K, V> foo();
can be assigned to a Map and can therefore be mutated at compile time:
Map<K, V> m = foo();
m.put(k, v); //oh dear
So, you can see that the addition of this type has not actually prevented us from doing anything bad. I think for this reason a judgement was made that it did not have enough to offer.
A language like scala has declaration-site variance annotations. That is, you could specify a type as being covariant (and hence immutable) as Scala's Map is (actually it's covariant in its V parameter). Hence your API can declare whether its return type is mutable or immutable.
As another aside, Scala lets you declare intersection types so that you don't even need to create the ImmutableXYZ interface as a separate entity, you could specify a method to return:
def foo : XYZ with Immutable
But then scala has a proper type system, whereas Java does not
I think both advantages are there but are not that useful. The main problems remain the same: UnmodifiableList still is a List and thus all the setters are available and the underlying collections still are modifiable. Making the class UnmodifiableList public would add to the illusion of being unmodifiable.
The nicer way would be for the compiler to help, but for that the collection class hierarchies would have to changed a lot. E.g., the collection API of Scala is way more advanced in that respect.
A disadvantage would be the introduction of at least three additional classes / interfaces into the API. Because of them not being that useful, I think leaving them out of the API is a good choice.
If it important for you to check if the list was created with Collections.unmodifiableList then you can create an instance and ask for the class. Now you you can compare this class with the class of any list.
private static Class UNMODIFIABLE_LIST_CLASS =
Collections.unmodifiableList( new ArrayList() ).getClass();
...
if( UNMODIFIABLE_LIST_CLASS == listToTest.getClass() ){
...
}
The answer to the why is quite simple: at the time, in 1998, efficient design was a bit flanky. People thought about it it wasn't apparently a priority. But there was no true, deep thinking about it.
If you want to use such a mechanism, use Guava's ImmutableList/Set/Map/...
They are explicitly Immutable and a good practice when using that library is not to return a List for instance but an ImmutableList. So you will know that a List/Set/Map/... is immutable.
Example:
private final ImmutableList constants = ...;
public final ImmutableList<String> getConstants() {
return constants;
}
About the design itself of UnmodifiableXxx, one could have done the following:
public static final class UnmodifiableXxx implements Xxx { // don't allow extend
// static if inside Collections
UnmodifiableXxx (Xxx backend) { // don't allow direct instanciation
...
}
...
}
Suppose UnmodifiableList was a public class. I suspect that it would lull programmers into a false sense of security. Remember, UnmodifiableList is a view of a modifiable List. This means that the contents of an UnmodifiableList can still change via any changes made to its underlying List. A naive programmer may not understand this nuance and may expect instances of UnmodifiableList to be immutable.
ability to indicate a more specific return value (such as UnmodifiableList), so an API user wouldn't come to the idea of modifying that collection;
In a proper API, this should already be documented in the javadoc of the method returning the unmodifiable list.
ability to check during runtime if a List is instanceof UnmodifiableList.
Such a need indicates that the actual problem lies somewhere else. It's a flaw in the code design. Ask yourself, have you ever had the need to check if a List is an instance of ArrayList or LinkedList? Whether it's an ArrayList, LinkedList or UnmodifiableList is clearly a decision which is to be made during code write time, not during code run time. If you're encountering problems because you're attempting to modify an UnmodifiableList (for which the API developer may have very good reasions which should be already documented), then it's rather your own fault, not a runtime fault.
All with all, it makes no sense. The Collections#unmodifiableXXX(), synchronizedXXX() and checkedXXX() do in any way not represent concrete implementations. They are all just decorators which can be applied regardless of the underlying concrete implementation.
I think the answer is because the method form properly knows about the generics used and requires no extra programming to pass this information through, whilst the class form would require more messing about. The method form for unmodifiableMap has two floating generic arguments, which it maps to both the generic arguments of the return type and of the passed argument.
public static <K,V> Map<K,V> unmodifiableMap(Map<? extends K, ? extends V> m) {
return new UnmodifiableMap<K,V>(m);
}