Java Lambdas Finalised!

General Discussions
#81

Well due to the single-inheritance rule putting a default implementation in an abstract base class is a lot less confusing. Could someone tell me what would happen in the case of conflicting default methods?


interface InterfaceA
{
  void draw() default { System.out.println("drawA"); }
}

interface InterfaceB
{
  void draw() default { System.out.println("drawB"); }
}

class Confused implements InterfaceA, InterfaceB {}

I’m hoping to be told my understanding is wrong, because this looks flat out broken.

#82

I never claimed otherwise. If you have cross-cuts in types, then using an abstract class is not an option and is the whole point of interfaces in java. Not having default methods in the first place was a mistake. But there are a fair number of people that will never need to write a default method and can pretty much ignore this feature (and likewise for lambda expressions) WRT: Needed to read other people’s code, protector method defs aren’t brain surgery…there are alot of possible java 1.0 expressions which would be infinitely harder to read…so what? My guess is there are a fair number of people that don’t really understand generics, but are living just fine.

#83

So, like this:

class Confused implements InterfaceA, InterfaceB {
    void draw() default { InterfaceA.super.draw(); }
}

Not overriding draw() should result in a compilation error.

#84

Ah I see, ta. Unambiguous, but still horrifically ugly IMHO.

#85

Interfaces with implementations … i think it’s safe to say java now has multiple inheritance. Looks to me like there is no linearization order at all though, as opposed to scala traits where it’s rightmost depth-first. Frankly it looks a lot like Python 1.x’s mistake that required hardwiring superclass names in, which was rectified with super() in 2.2, and made syntactically nicer in 3.0.

So I can’t say I’m entirely pleased with Java’s approach there, but I’m pretty happy with the lambda syntax at least.

#86

It won’t help anybody because it is useless, it only adds confusions into the language. I read a lot of source code and I don’t want to see this. In some case, it might cause compilation errors. I’m against multiple inheritance and I fear this feature can be used to do it in Java. If someone wants to put several “default” implementations of methods into an interface, he should create an abstract class, he should not use this keyword to put some code into this interface in my humble opinion. I can vaguely tolerate other new features but I find this one particularily confusing and crappy.

#87

I prefer to focus on the positives. The current state of lambdas has an elegance that’s compatible with how we’re used to write code in Java. Unlike generics, the most recent major language change, which still feel like an awkward mess. A bunch of tough decisions have been made in order to add lambdas to Java and I find the justifications behind those decisions satisfying. On default methods for example:

[quote][…]interfaces are essentially set in stone once they are published. The purpose of default methods (sometimes referred to as virtual extension methods or defender methods) is to enable interfaces to be evolved in a compatible manner after their initial publication.
[/quote]
They’re not about multiple inheritance and I don’t expert we’ll be seeing a lot of default methods outside of library code. Every other feature is equally well justified and the corresponding code looks as straightforward and simple as it could be.

#88

Actually it’s advocated by people that have a firm understanding of language design, and (as I stated) should have existed earlier. It addresses existing real world design problems.

You’re very unlikely to see it outside of library code.

Not in any existing code, so who cares. For new code…that’s the point.

As I stated before, creating an abstract class is impossible in the case where an interface is being properly used. Interfaces are, by design, for dealing with cross-cuts of the inheritance hierarchy. So what you are suggesting is doesn’t work.

#89

It is possible to create an abstract class implementing some methods of an interface, what is wrong with that? If you really need multiple inheritance, maybe it means that something is wrong in the design of your whole source code, Java doesn’t need this feature as it should not handle any crappy choice with crappy solutions. An interface should not contain any implementation of method.

#90

Ah, the joy of arguing with Julien. His opinions are set in stone, just like all the APIs he uses. I admire his ability to write the perfect API at first attempt. For us mere mortals, I find this a positive and sensible move!

#91

Sorry but on this one I’m with Julien. I agree that interface should not contain any code. Usually when a class implements an interface you expect the implemented methods to behave in a certain way based on the definition of the interface. If you have 2 conflicting interface like OrangyTang said you have no idea what the implemented methods are doing.

Seriously what is too difficult in doing the following to get similar behavior to multiple inheritance if that is what you want :


public class A{
    public void methodA(){...}
}
public class B{
    public void methodB(){...}
}
public class newA extends A{
...
}
public class newB extends B{
...
}
public class C{
    public final newA;
    public final newB;
}

Or you have the alternative to create two interface for class A and B, make C implements those interface and just redirect the method to newA and newB variable.

#92

Really? That’s not my reading of the spec. Indeed, OrangyTang later states it’s not ambiguous (though to be fair he does call it ugly)

Extending interfaces is not about multiple inheritance. If I never, ever, ever see the MyInterface, MyInterface2, MyInterface3 pattern again it will be too soon! :slight_smile:

Roquen is right. I have no problem with interfaces containing (default) code. The key thing, and why this is still Java, these aren’t abstract classes and this isn’t multiple inheritance is that interfaces still do not contain state.

#93

Whow, hold yer horsis. What gives you the impression developers of today actually want to write code?
Majical one-liners FTW!

#94

I think it’s probably important to distinguish between strictly-unambiguous (in the sense that it’s well defined in the spec that my example code throws a compiler error), and apparently-ambiguous (in the sense that a human reader can’t immediately and easily see exactly what will be called without trawling through lots of code).

Obviously what’s “apparently ambiguous” will vary from person to person, but I think default implementations are probably too far for most people’s definition. My personal gripe with it is that it breaks the locality of the code - if you see ‘implements FooInterface’ then you know that it conforms to an external interface, but the implementation is entirely within this single code file. Default implementations break that so now you’ve potentially got to be switching between multiple files all the time to see what’s actually going on.

#95

I thought that yer typical default implementation was supposed to do something totally benign like output a debug message or throw an exception or something - isn’t the idea that it’s there just so you can extend interfaces in libraries with new stuff, that existing code doesn’t know about and therefore will never call? So really your default implementations should more or less all just return null / 0 / throw new RuntimeException(“Not implemented”) etc.

Cas :slight_smile:

#96

You prefer caricaturating my comments especially when I disagree with you.

My opinions are not set in stone. For example, my first attempt of writing a first person shooter was written in C++ until I discovered Java could do the same job more easily. In 2006, I didn’t want to use any scenegraph whereas I have used 2 of them these last 3 years. I didn’t want to use OpenAL to avoid adding another native dependency to my project whereas I now use JOAL. You’re completely wrong.

The APIs I use are not set in stone neither. JOGL 1.1.1a and JOGL 2.0 are noticeably different, porting several renderers was not completely trivial. JMonkeyEngine and Ardor3D have evolved last years.

Have you often worked with students? I’m sure they are mortals like me and this use of the “default” keyword in interfaces won’t ease the task of explaining to them what a Java interface is and what it is for. I still think that the syntax of Java should be frozen even though it is not perfect because some attempts of improving it might be lethal for it by driving it too much complicated and that is what happened to C++. Maybe lambdas are helpful but this possibility of putting a default implementation of some methods in interfaces is not the way to go in my humble opinion.

I find your argument particularily weak, you laught about me because I refuse a change. Something shown as “modern” is sometimes neither fair nor good, it does not mean that I refuse any change, I just refuse accepting them blindly. This is the same in politics: If homophobia and the death penalty were “modern”, I would still fight against them whatever people think about them.

#97

I’m on the fence with the whole interface thing myself. The more I look at it the more it basically seems like what Java needed was just plain old multiple inheritance and ditching interfaces completely, which appear to be basically a degenerate form of multiple inheritance.

Cas :slight_smile:

#98

Here’s the deal. “IF” an abstract base class can perform the same job, then it is the superior choice IMHO. But the point here is that it isn’t always a option. Examples include cross-cuts, as I’ve already mentioned, backward compatibility and avoiding special casing of other library code. Unfortunately (again IMHO) Java culture encourages overuse of interfaces when it is unnecessary. (As an example see section “12. Unintended consequences for the language” of the spec).

@Gudradain: Like Julien’s abstract base class suggestion, this does not address the issue at hand. And like abstract base classes, if a composite class can do the job, great, but it still doesn’t address the issues at hand.

Cringe!!! This is completely different from MI, like nsigma said: “that interfaces still do not contain state”. As stated in the spec, this is more like adding lightweight taits/mixins to the language.

It could be used in this manner, but I think that it would be pretty uncommon.

Yes backward compatibility is one the the big reasons. Although “new” code most likely will be called, but in a transparent way the the user doesn’t care about. I’d image that one of the big internal (JDK group) pushes for this is to allow using of lambdas in classpath classes.

BUT another reason is to get rid of some pointless boilerplate in code (something that has not been discusses at all in this thread). Oh yeah, java programmers seem to love their pointless boilerplate code…sigh. Exactly the kinds of things that can be done is still unclear since the spec isn’t finalized.

#99

complexity VS boiler plate code :cranky:

#100

I don’t believe the solution is to allow interfaces to include behaviour code, that defeats the point of an interface, and we have abstract classes for that. Multiple inheritance is also not the solution.

Personally I believe you need mixins, or something similar, to solve this issue.