File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Features new in Java 8 and the fly likes Interface as a Type in Java 8. Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


JavaRanch » Java Forums » Java » Features new in Java 8
Bookmark "Interface as a Type in Java 8." Watch "Interface as a Type in Java 8." New topic
Author

Interface as a Type in Java 8.

Derik Davenport
Ranch Hand

Joined: May 30, 2011
Posts: 57
Since Java 1.2, I have seen the following naming convention used in the libraries.

An interface defines a type. Remember, a "type" is just a set of method signatures that can be called on a class. A class can implement more than one type.
Example: Executor
An abstract class defines a skeletal version of a concrete class. It usually named Abstract<InterfaceName>:
Example: AbstractExecutor
An uninstantiable class filled with static factory methods provides commonly useful concrete instances of the type. It usually named <InterfaceName>s (ends with an "s").
Example: Executors
This frequently used naming pattern is consistent with the advice found in books like Joshua Bloch's "Effective Java": Prefer Interfaces to Abstract Classes to define a type.

However the Comparator group in Java 8 does not follow this pattern. There is no Comparators class, and all the static methods are instead placed into the Comparator interface? Are the days of using a pure interface to define a type over? If so, why didn't the designers of Java 8 continue new pattern with the Collector and Collectors? Are the static factories in the new Comparator different than those found in Collectors? Are they special in some way that makes it more appropriate to bundle them with the type definition?





Jesper de Jong
Java Cowboy
Saloon Keeper

Joined: Aug 16, 2005
Posts: 14194
    
  20

Java's standard library contains thousands of classes and interfaces, and has grown bit by bit over the years. Many different engineers have worked on it, and there are many inconsistencies, and also a number of very badly designed APIs in there.

There was probably not a conscious decision made to follow a specific style in the Comparator interface that is different from other classes in the JDK.


Java Beginners FAQ - JavaRanch SCJP FAQ - The Java Tutorial - Java SE 8 API documentation
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 39084
    
  23
If you go back to versions of Java before 8 you find the Comparator interface had two methods: compare and equals. And most people didn't bother implementing equals.
Derik Davenport
Ranch Hand

Joined: May 30, 2011
Posts: 57
With the most sincere possible respect to both Campbell and Jesper, after some serious reflection on their responses, I don't feel like my question is resolved. This might mean I didn't ask my question clearly, which I will try to rectify with this posting.

Jesper says
"Many different engineers have worked on it, and there are many inconsistencies, and also a number of very badly designed APIs in there."
Sure sure. That is certainly true. No one is perfect. One of the reasons they added default functions to interfaces was for the very purpose of being able to update a broken interface and still maintain binary compatibility with older code that might be compiled against the new library.

Campbell said,
"If you go back to versions of Java before 8 you find the Comparator interface had two methods: compare and equals. And most people didn't bother implementing equals."
Is your point that Comparator was largely undeveloped, and that in order to expand it we had to also include defaults for the new parts of the interface? I would certainly agree with that. But in my original post I was mostly concerned about the placement of the static factory functions into the interface. Rather I expected them to be in Comparators. Maybe the only reason that the <InterfaceName>s pattern developed was because programmers couldn't put them in the interfaces. But now the pattern seems well established. I would have expected a code review to have caught this, so I am expecting that there was a conscious decision to avoid the convention here.

So I will restate my question. Was there a good reason why the static factories in the Comparator interface should not have been placed in a separate class called Comparators? Is this a pattern I should follow or avoid in my own API's?


Joanne Neal
Rancher

Joined: Aug 05, 2005
Posts: 3606
    
  15
Derik Davenport wrote:Was there a good reason why the static factories in the Comparator interface should not have been placed in a separate class called Comparators? Is this a pattern I should follow or avoid in my own API's?

As with all questions concerning the design of the standard Java API, the answer is that unless an Oracle engineer happens to be browsing these forums you are not going to get a definite answer to your question. Everyone else here can only offer possible reasons for any design decisions that were made, but at the end of the day they will be guesses and your guess will be just as good as anyone elses.
Unless you are working in a company with a style guide that specifies this sort of thing, you should choose whatever suits you best and stick with it. You at least can be consistent even if the Java developers weren't.


Joanne
 
It is sorta covered in the JavaRanch Style Guide.
 
subject: Interface as a Type in Java 8.