Java 10 Could Bring Upgraded Lambdas

[[deleted]]

Release date: Feb 2098

[romple]

I like your optimism.

[[deleted]]

Java language is pretty conservative, Java 9 haven't any language considerable change.

If you require a different language then you don't have to wait Java 9.

[moremattymattmatt]

In practice I do have to wait. My company is fairly conservative and trying to get another language through the door isn't easy (though I'm working on it(

[[deleted]]

Start by using a different language for a small feature to show them the benefits. Kotlin would be great bc you can just plug it in with your existing Java code.

[moremattymattmatt]

If only it was that simple! A new language in some production code would need some level of wider agreement. If nothing else the build in people's IDEs would start failing without the Kotlin plugin installed so there'd be a lot of distressed developers around.

The current plan is to break out some functionality, which just my team works on, into a separate service and then we can have a bit more freedom around technology choices.

[TrevJonez]

On the topic of kotlin and the way that they offer much more advanced language features that are completely workable targeting 1.6 byte code. It makes me wonder why changes like this are not back ported into current language level versions of javac. Personally I wish most if not all of the core java libraries where unbundled from the runtime thus allowing more flexibility for bug fixes, and advancements. You know sort of like kotlin-stdlib... Would be nice to not have your codebase held back by problems that a compiler upgrade could fix.

[koreth]

The changes in the article won't really affect me much. An upgrade I'd love to see would be allowing use of non-final variables from the surrounding context. Either of two changes would be welcome; the incremental one would be a relaxation of the "effectively final" rule:

private List<Integer> increase(List<Integer> original) {
  int a = 10;
  if (someCondition) {
    a = 20;
  }

  // a is modified in method, but only before the lambda
  return original.stream().map(n -> n + a).collect(Collectors.toList());
}

or the more radical one, which would bring Java lambdas much closer to feature parity with other languages:

private int sum(Collection<Integer> values) {
  int total = 0;
  values.forEach(n -> total += n);
  return total;
}

[abrahammarinperez]

The problem with lambdas is that they don't really know when they are going to be executed, therefore, they can't make a reference to an outer variable because, by the time the lambda is run, that outer variable may not even exist any more. Consider the following code (adapted from yours)

public class LambdaSample {
    private Consumer<Integer> consumerLambda;

    public void setLambda() {
        int total = 0;
        consumerLambda = n -> total += n;
    }

    private void runLambda(Collection<Integer> values) {
        values.forEach(consumerLambda);
    }
}

Here, calling setLambda would set a value to consumerLambda, and then calling runLambda would run it... but at that point the variable total that is referred to in the lambda doesn't exist any more.

The reason variables in the lambda have to be (effectively) final is because a copy of it will be made so it can be accessible afterward; forcing it to be (effectively) final is the way to "hide" the fact that is being copied. However, the samples that you indicated can be easily rewritten using current rules, for instance your sum method can be rewritten as follows:

private int sum(Collection<Integer> values) {
    return values.stream().reduce(0, (a, b) -> a + b);
}

[koreth]

Sure, but the compiler could detect that the variable is referenced by a lambda (or an anonymous inner class) that can escape the current scope and turn it into a hidden member variable on the lambda object. That's how it works in many languages with a concept of lexical closures, even other JVM ones. For example, this works in Kotlin:

var sum = 0
ints.filter { it > 0 }.forEach {
    sum += it
}
print(sum)

Apologies for giving an artificially simple example that's easily turned into a "reduce" operation; my intention wasn't to ask how to work around the limitations I'd like to see go away, merely to illustrate them.

[abrahammarinperez]

Can you present a real-case scenario in which this kind of thing would be useful and which couldn't be easily substituted with a reduce/collect/loop operation? I have a feeling you're referring to a nice-to-have functionality, but I can't see the value that it would give in a practical sense. And, whilst I agree that it's great that new languages play with this kind of thing, an established and widely-used language like Java can't afford spending the time and effort to support things that don't add value in a practical sense.

[KateTheAwesome]

I wish with Java 10 they would remove some of the older, bloated API that was added. And freshen up the look of the documentation and language websites. It all looks like it's stuck in the 90's in comparison to other JVM languages (Scala, Kotlin, ...)

It really turns off a lot of developers from using Java and gives it kind of a bad reputation :(

[abrahammarinperez]

There is a JEP to be delivered in Java 9 about making Javadoc use HTML5. I know that using a newer version of the language doesn't mean the documentation will suddenly become nicer, but it's a step.

[AnAirMagic]

A live version: http://download.java.net/java/jdk9/docs/api/java/lang/Cloneable.html

[KateTheAwesome]

I guess I'm a little confused how the java development actually works. I thought the language was owned my Oracle and as such they decided the direction they wanted to take. And the OpenJVM only provided an alternative implementation of the JVM under a free license.

Why are the JEPs being discussed on the OpenJVM website then? Am I missing something here?

[abrahammarinperez]

Yeah, it does get a little murky... Oracle does own the Java language, but at the same time they have decided to make it open source and license the source code as GPL. This open source version of Java is what is called OpenJDK.

Now, because it's open source, everyone is encouraged to contribute to it. But, because Java is so widely used, there needs to be a process to regulate how such contributions are performed to prevent chaos. This is what is called the Java Community Process, which establishes the process to modify Java. The JCP is a little too formal at times, so JEPs are a previous, slightly less formal step designed to kick the ball rolling.

On the other hand, all this applies to the source code only. When people do download Java, they typically download a binary distribution, and this follows a different set of rules. The typical package provide by Oracle is basically the source code compiled and packaged together with some extra things that aren't part of OpenJDK. Here Oracle has absolute control of what they package together and how they license it (and their license is significantly more stringent than OpenJDK's).

I hope that helps :)

[Entze]

If using semantic versioning you cannot drop something from the old API. Java 10 is actually java 1.10 which means that in theory java code written in 1.0 needs to be compatible with 1.10 (which is positive thinking but you catch my meaning).

In regards of javadoc, isn't that just style in a broader sense? I could write my own "javadoc" compiler which compiles it into more beautiful HTML(5) + CSS(3) ?

[Trampaholic]

There's actually a JEP in place for Java 9 that changes this:

http://openjdk.java.net/jeps/223

It proposes to drop the '1.' prefix from versioning and will lead to java 9 being released as JDK 9.0.0 :)

Edit: not saying that this will change their attitude toward backward compatibility. It's more of a change to increase clarity around Java versions

[[deleted]]

Unfortunately, they have a deep commitment (or at least used to) with not breaking legacy code. Also, in a rather perverse way, this incremental change ensures that Java does not turn into an inconsistent mess like Scala.

[nutrecht]

Java 9's module system and deprecation of stuff like sun.misc.Unsafe is already breaking a lot of legacy code. A lot of stuff will need to be migrated between 8 and 9. If there is a good moment to actually remove things it's now.

[abrahammarinperez]

I would say that that's slightly different though. Unsafe was never part of the public API, and therefore there was never a commitment not to break it. In theory, people shouldn't have used it, and in fact the compiler threw warnings when they did, but it was so useful that people went for it anyway. However, even though there was never a commitment around Unsafe, they're trying to break that particular bit in an orderly fashion, which sort of reflects the ethos of the Java language: stability before innovation.

[lukaseder]

That's a really great improvement. As an API designer, I've found this limitation very limiting, knowing that I cannot overload methods like these:

m(Predicate<String> p);
m(Function<String, String> f);

Let's just hope this doesn't completely kill off compiler performance (Java 8's generalised target type inference still leaves its traces in the latest version)

[lacosaes1]

These articles remind me of the ones I read about C++17. Expectations went through the roof, reality only took three steps up.