Skip to main content

Concerns about Java 8

1 reply [Last post]
Joined: 2013-04-25
Points: 0

Hey there !

I've checked the planed features for Java 8 today and had a few concerns I'd like to discuss here, in case someone worries about the same thing.


First thing I'd like to talk about is the default keyword. This keyword will sure remove many design limitations but I'm concerned about using it in an "interface" block (maybe I'm just rigid-minded or something). Correct me if I'm wrong, but if you add any line of code in an interface, then it's no longer an interface...right?
I'm just a student so I maybe I don't yet have the experience to discuss the semantics, but here's how I understand it: a class consists of two parts, being the interface and the implementation, and the "interface" keywords allows the programmers to define the interface separately from the implementation, to be able to use it in several polymorphic classes. Did I get it right?
Because then this concept of "default" method is in contradiction with the concept of interface. An interface that contains a default method (thus a default implementation, which has nothing to do with an interface) is no longer an interface.

What about giving a different to the entire structure then? We could, for example, have "interfaces" which would have the same role as they have right now, and a different type of structure that would allow definition of default methods (like "module").

public interface Edible {
    public void cook();
    public void eat();
    public void drink();

public module Edible {

    public default void cook() {



    public void eat();
    public void drink();



I've noticed the Optional, OptionalInt, ... classes, but I don't know if there are more features like this one.
I'm afraid it gives programmers too much rope to hang themselves with...
I doubt a skilled programmer would use those, because his/her design wouldn't require optional parameters. If a beginner gets his/her hands on these, it might get real messy.
I know a C++ programmer who's currently trying to learn Java. C++ programmers seem to LOVE using every kind of constructs in weird ways and design their software in a strange fashion. This guy often asks me about the possibilities of Java and then rants about it not having the necessary constructs for him to implement his design.... And to be honest I'm GLAD that Java doesn't have these because I wouldn't want to have to deal with his code afterwards.
I don't know if I made my point here, but what I mean is that Java got a very unique strong point: it doesn't allow for bad designs. It just doesn't have the necessary constructs to let you do crazy things (optional parameters, using primitives on generics, ...).
It would be a good thing to keep that idea in the language: providing the user with a minimalist and efficient set of tools which can't be used wrong. The Optional class....hurrr


Again, maybe I'm worrying for bad reasons, but was it really necessary to add a new operator ( -> )? Another good thing with Java is that it doesn't use too many different symbols, unlike C++ which seems to use every printable characters in every possible way, which results in ugly code. Some languages lets you define lambda function without having a specific operator.

Isn't this possible?
lambda = (int i, int j) { return i * j; }

Ok that's all :p
Thanks for reading

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Joined: 2004-10-07
Points: 0

About interfaces, the keyword you want not module but 'trait'[1],
What you're asking was discussed by the lambda Expert Group and rejected for several reasons.
The main one was that even with default methods, an interface is still an interface that behave like an interface. So introducing a new concept for something that was too similar to existing interface was seen as more disturbing that helping.

Optional is a controversy by itself. You are free to not using it if you don't like it.
Some very vocal people really want to have it, so it's in the API.

You need -> because otherwise there is no way for the compiler to see the difference between a lambda and a cast:
lambda = (foo) foo; // a cast
lambda = (foo) -> foo; // a lambda