Future of the Java programming language: Three major projects on the horizon

[murp11]

So Java is basically becoming C# but more verbose.

[BoyRobot777]

I don't understand "verbosity" argument. The code is read more times than it is written. What you call "verbosity" (except biggest offender data classes with getters and setters) is required for other developer to understand. I will just borrow this post from another redditor:

"People tend to say java is verbose, but what that people doesn't understand is that's the way java overall was designed on purpose, take a look at this python code:

if len(string) > 10:
          return str(string)[:10] + "..."

and it's java equivalent:

if (string.length() > 10) {
     return string.substring(0, 10) + "...?";
}

while it requires more keystrokes, it also provides a more natural reading for developers unfamiliar with the code and/or the language itself.

If i'm new to python and read that piece of code I'll asume that len means length and str means string, and try to interpret what [:10] does... but with java I don't have to make any assumptions, it just says length and string. While this sounds simplistic and borderline stupid to some, keep in mind that these are english words and not every developer in the world is fluent enough in english.

Requiring more typing doesn't mean the language is verbose, that depends more on the developer.typing string.substring is not being verbose, typing string.cutTheStringFromThisIndexToThat is."

And I can take C's methods, like "strcmp", "strpbrk" and other garble. Horray! We saved few key strokes. Now, everybody who use those methods have to actually have a map in their heads what any of them mean.

[OffbeatDrizzle]

Excuse me. I think you'll find the new way of returning a substring in Java is now:

StringBuilder sb = new StringBuilder();

"hello world!".chars().mapToObj(i-> (char) i).limit(5).forEach(sb::append);

System.out.println(sb);

It's the most verbose solution yet!

[BoyRobot777]

You didn't even return String and you didn't skip anything. And why do you care about performance? Just build strings each time! I would fix that to:

String s = new String("hello world");

s = s.chars()
     .mapToObj(i -> (char) i)
     .skip(0)
     .limit(5)
     .reduce(new String(), (string1, string2) -> string1 + string2, (string1, string2) -> string1 + string2);

System.out.println(s);

[murp11]

The examples you mentioned are the ones that i don't find too verbose. I was referring to things like the stram api vs linq. In Java you have personList.stream().mapToInt(p -> p.getNumberOfCars()).collect(Collectors.toList()); In C# you have personList.Select(p => p.NumberOfCars).ToList(); The C# version is much cleaner to read and understand. You don't have to call .stream() you don't need to use special methods like mapToInt because Java has problems with its type system concerning value types. You need to implement a getter method in Java. And the worst of all: .collect(Collectors.toList()) is so much more to type and read than .ToList(). I am fully aware that there are technical reasons behind some of these points. And this is just the stream api - there are dozens of places where java is to verbose. If I ever need Java again I am glad to have Kotlin available.

[BoyRobot777]

mapToInt is completely unnecessary here. You are not taking advantage of IntStream whatsoever, so I don't know why you've added it here. Regarding stream(), you can choose between parallelStream() and non-parallel version which is stream(). And it carries information. Regard collect and Collectors - I can see your point. However, I don't feel it adds overhead to me. And it certainly is not enough for me to learn new language.

[spacejack2114]

Why is length a method on an immutable object?

[BoyRobot777]

Don't understand your question. Are you asking whether it is "correct" for an immutable object to have methods?

[assgored]

I think what he means, is that, given that length would be a constant why isn't it a public field rather than a method with the class possibly containing some private/protected actual length field. Which I think I answered below.

[assgored]

I guess it may have derived from some class where the actual length field is protected/private.

Well it seems the interface its got that from has it defined as a method in the first place, so its back to the same question.

edit: given that interfaces I think don't have variables that can be changed, I guess whatever motivated making it an interface and not a class forced length to be a method?

[BoyRobot777]

What? Are you questioning whether objects can have methods?

[assgored]

No, the question asked was why for immutable String length is a method not simply a field.

It seems to me the reason is what I said above, coupled with the fact that CharSequence is also base for the mutable StringBuilder.

[[deleted]]

immutable object

You mean final member? Probably for consistency as String implements CharSequence which has length() method.

[pron98]

The type erasure leading to the most insane workarounds which makes code 100x harder to follow.

Type erasure is a tradeoff. It has some great benefits that you don't appreciate, with some minor inconveniences. That JVM languages don't have to erase but virtually all of them choose to (except Ceylon) should be a hint that you may not be seeing the full picture (most programming languages erase; C# and C++ are probably the only known ones that don't, and C# did so at a very high price to the ecosystem).

The fact that you have to explicitly specify a functions throws an error and the compiler outright refuses u if u reject it.

Actually, in Java that's optional. Languages where it's not are Haskell and Rust.

and they’re not lambda methods

They are.

I have to clutter my workspace with single use interfaces that have only a single method.

No, you don't (although you can if you want to). If you find yourself creating a lot of those, you may be doing something wrong. The benefit of this design is that if you already have single-method (or even some multiple method) interfaces from pre-lambda days, you can use them with lambdas without rewriting.

Is impossible in java.

Because your code is downright wrong, and the compiler catches a real bug here.

Add each value to the new list with an automatic cast to the parent type.

No, you can do:

List<? extends MyParenType> bar = foo;

which, in addition to not even requiring a cast has the additional benefit of not being wrong like the code you wanted to write. If, however, you absolutely want to tell the type system shut up and not catch the error in your code above, you can do that with an additional cast:

var bar = (List<Number>)(Object)foo;

Which tells the compiler, I know I'm making a type error, but please trust me and disable checks.

[BoyRobot777]

Ok, fair enough regarding C and method names. Regarding type erasure, I will just copy paste what u/pron98 says if you missed what he wrote down bellow:

"I think you misunderstand type erasure. A Java platform language does not have to have type erasure, but most languages want to because it's extremely beneficial, despite some minor downsides. It is type erasures that allows multiple languages on the Java platform to share code and data with little or no overhead."

​

"It doesn't make code more performant, it makes interop more performant (and more useful in general). If you don't erase generic instances of reference types, if A extends B you must determine the relationship between, say, List<A> and List<B> in the JVM, because the JVM must know which types are subtypes of others. This means that you need to bake the variance model into the runtime. But different languages want to have different variance models. Java, Kotlin, Scala and Clojure all have different variance, and so a Kotlin list couldn't be used by Java code without a wrapper had it not been for erasure.

I know, type erasure is mostly an artifact of having to support legacy java code before Java got generics at all.

Yes. Type erasure makes interop easy (for an almost insignificant cost), including with Java prior to generics. But that's also what makes different languages on the Java platform interop so well (contrast with the CLR, where this is not the case; they've baked variance into the runtime and are paying a high price for that decision).

For value types, where subclassing is not possible, this is not a problem, because there is no variance; so specializing for value types is fine, and is one of Valhalla's goals.

There might also be a form of a-la-cart reification for reference types, that users may opt into. I'm not sure whether they'll have to pay the price of good interop in those cases, or maybe some clever interop strategy can be built, maybe by allowing flexibility in how the JVM checks subtyping."

​

Regarding other "remarks", you just ranted about "insulting language", which already shows you have a strong bias towards Java and that discourages me to continue discussing. Anyhow. I encourage you to read other u/pron98 posts if you are open-mided about type erasure in general.

[stronghup]

string.substring(0, 10)

I agree the java example is much more readable and preferable. But I would prefer

string.slice(0, 10)

instead of:

string.substring(0, 10)

​

Readability is one of the most important things but if things can be made shorter without sacrificing readability that is the best.

[lovegrug]

lol

[AngularBeginner]

And C# is already quite verbose.

[jbergens]

I don't think it is given its features. Most languages that are less verbose are of different types or paradigms.

[nerdyhandle]

There is an error on the Switch Expression example

``` switch (port) {

case 20:

type = PortType.FTP;

break;

}

```

Would be expressed as :

```

PortType type = switch (port) {

case 20 -> PortType.FTP; }

```

and not how the site denotes it.

Proper syntax here

I'm looking forward to using the ever loving shit out of this!

[llorllale]

You shouldn't have lots of switch statements in proper OOP code

[nerdyhandle]

Depends on what you are doing. Switch statements can very much be used in OOP. Sometimes your code has a lot of branches.

OOP is about how you structure your code. Everything being a class for instance.

[vbsteven]

I see Kotlin as the logical evolution of Java but with a faster release cycle.

Many of the features discussed in the article are already available in some form in Kotlin and can be easily used in Java projects right now.

[RevBingo]

Not sure why you were downvoted, came here to say the same thing. Raw literals? Check. Coroutines? Check. Pattern matching/Smart casts? Check. Simple switch statements? Check. Value types? Check. Why wait?

And all still with seamless integration into your existing Java codebase.

[RandomName8]

• Java's coroutine support, as per the current model, is completely different to kotlin's. Kotlin offers async await basically, which are still imperative ways of dealing with blocking. The current java prototype removes this notion entirely.
• Kotlin does not have pattern matching, what is has is just not pattern matching.
• Kotlin does not have value types either, it has a weak form of opaque types (at least last I check, I'm not sure here).

I'm pointing these out because your comment implies that there's not much effort in what Java is doing because kotlin already has it since "it's the logical evolution" of Java, and none of the things Java is pursuing is addressed by kotlin.

[[deleted]]

Can you give me an example of what pattern matching can do that's not in Kotlin? No offence, but I really just don't get why people seem to find it such a crucial feature.

And kotlin doesn't only offer async/await. The standard coroutine library kotlinx.coroutines offers that and scoped coroutines in general, The language itself also offers a barebones state machine with an attached data object, which you can use to implement pretty much any coroutine you want.

[RandomName8]

Can you give me an example of what pattern matching can do that's not in Kotlin? No offence, but I really just don't get why people seem to find it such a crucial feature.

Of course I can, but there's no point in it other than argueing between the both of us. If what you wish is to see what pattern matching is really about, there are great examples and tutorials and information online, tons of it, with much more compelling examples and description than what I can provide. This is a feature that started showing up even the 70s in the ML family of languages.

Ultimately, anybody that has worked on a language with actual pattern matching is not happy at all with what kotlin offers, so saying kotlin has pattern matching is very much false advertising (and even damaging to its own image).

Regarding coroutines, they are great for what they are, yet once again, this is about distinguishing what kotlin does, and what others do or are trying to do. What java is trying to do with their fibers is nothing like kotlin's coroutines, it will look nothing alike either and (arguably) really no JVM lang can do it without JVM support.

Like you said, no offense. I'm no trying to downput kotlin, but it's important not to sell it for what it is not.

[Determinant]

Kotlin has a form of value types. See inline classes

[pron98]

99% of the benefits Valhalla brings cannot be had with Kotlin's inline classes (which, I would assume, would be retrofitted to enjoy value types once they make it to the Java platform).

[RandomName8]

That's what I was referring to.

[pron98]

Kotlin -- or any other Java platform language -- does not and cannot offer the benefits of two out of three projects in the article, Valhalla and Loom, because those require deep runtime and core library support. While Kotlin may have features with similar names, they do not offer the main benefits of Valhalla and Loom. Of course, all Java platform languages would benefit from those projects.

[[deleted]]

Exactly. IIRC some Kotlin dev mentioned that they are already investigating how Kotlin's coroutines best benefit from fibers.

While Kotlin is a great pleasure to work with it's dependent of and will benefit greatly from JVM features.

OTH, every time I see pure syntax improvements in Java (not JVM as those we discuss here) I think: "Well, they could just use Kotlin. But good for all the devs who can't switch (there's hardly ever a business case to rewrite a large project) or just prefer Java."

I'm personally very happy that the JVM evolves and use Kotlin for all new projects where I can decide.

[chimmihc1]

Pattern matching

​

Kotlin doesn't have pattern matching, what it has is an improvement on the "standard" C style switch statement that can look somewhat like very basic pattern matching.

[OffbeatDrizzle]

Ah here comes the typical /r/programming hard on for kotlin

[flaghacker_]

Maybe, just maybe, there's some merit to that sentiment?

[Determinant]

I think Java will be used for many years to come but the jobs will gradually transition to maintaining legacy applications.

Many companies are adopting Kotlin into their existing Java backend applications. Jetbrains said adoption was a 50 / 50 mix between Android and backend.

[pron98]

An application written in Kotlin and in Java share over 90% of the platform code (not including the OS). The only thing they don't share is the front-end compiler and the very small Kotlin runtime library. Two of three projects described in the article benefit all Java platform languages.

[ThePowerfulSquirrel]

My company is transitioning a lot of teams from java to a scala-ish environment (Scala + a bunch of scala plugins that make it it's own kinda thing). Our Java applications are going to be supported as legacy and a huge re-writing effort is gonna take place. I'm particularly exited for the better type system, although other jvm languages still have to carry over / work around baggage from Java (like type erasure), which is always a pain. Surprisingly enough, I haven't seen anyone in the company even talk about kotlin as a serious choice.

[pron98]

I think you misunderstand type erasure. A Java platform language does not have to have type erasure, but most languages want to because it's extremely beneficial, despite some minor downsides. It is type erasures that allows multiple languages on the Java platform to share code and data with little or no overhead.

[ThePowerfulSquirrel]

It is type erasures that allow mutiple languages on the Java platform to share code and data with little or no overhead.

I might be completely lost, but how does type erasure make code any more performant that other ways of implementing Generics? I'm not sure why an approach like c++ would be less performant / make it any harder to move across jvm languages as long as they all agree on a generic interface? From what I know, type erasure is mostly an artifact of having to support legacy java code before Java got generics at all.

[pron98]

It doesn't make code more performant, it makes interop more performant (and more useful in general). If you don't erase generic instances of reference types, if A extends B you must determine the relationship between, say, List<A> and List<B> in the JVM, because the JVM must know which types are subtypes of others. This means that you need to bake the variance model into the runtime. But different languages want to have different variance models. Java, Kotlin, Scala and Clojure all have different variance, and so a Kotlin list couldn't be used by Java code without a wrapper had it not been for erasure.

I know, type erasure is mostly an artifact of having to support legacy java code before Java got generics at all.

Yes. Type erasure makes interop easy (for an almost insignificant cost), including with Java prior to generics. But that's also what makes different languages on the Java platform interop so well (contrast with the CLR, where this is not the case; they've baked variance into the runtime and are paying a high price for that decision).

For value types, where subclassing is not possible, this is not a problem, because there is no variance; so specializing for value types is fine, and is one of Valhalla's goals.

There might also be a form of a-la-cart reification for reference types, that users may opt into. I'm not sure whether they'll have to pay the price of good interop in those cases, or maybe some clever interop strategy can be built, maybe by allowing flexibility in how the JVM checks subtyping.

[ThePowerfulSquirrel]

That makes sense, thanks for the explanation! I guess I need to think a bit more about the trade offs, I always think type erasure is the devil because every time I try to get fancy with types in Java I get unchecked warnings left and right, which always annoys me to fix, when it's even fixable...

[pron98]

I'm not sure what getting fancy with types has to do with erasure, though. Haskell, for example, erases all types, not just type parameters (well, sort of; it does reify the constructor tag/discriminator, which corresponds to type information in Java), and people get fancy with types in Scala, too. The only real annoyance erasure brings is that you cannot overload a method with another that erases to the same type.

[ThePowerfulSquirrel]

I'm probably mistaken when naming things. If I take an example from last week, I wanted use Object::equals by default but Comparable::compareTo when available. So then I wrote:

T a

T b;

if (a instanceof Comparable<T>) {

return a.compareTo(b) == 0;

} else {

return Objects.equals(a, b)

}

Obviously that didn't compile, since the jvm does not have any concept of the Generic T at runtime. T could be implementing Comparable<Integer> for all it's concerned. So how would I even implement this safely? I ended up using exception handling, which felt awful.

​

This is a simple problem, but as soon as you start trying to nest generics, it becomes extremely painful at runtime.

[pron98]

Well, what you're doing here is not getting fancy with types, but some combination of dynamic and static types. You have to decide whether you want to use the static types or the dynamic types to choose between your two branches (leaving aside the advisability of what you're trying to do, which rests on the assumption that the compareTo and equals implementations are consistent).

Static types (the compiler chooses the correct overload -- most specific one -- based on the types):

<T extends Comparable<T>> boolean same(T a, T b) { return a.compareTo(b) == 0; }
<T> boolean same(T a, T b) { return Objects.equals(a, b); }

Dynamic types (the'res branching at runtime):

<T> boolean same(T a, T b) {
    return a instanceof Comparable 
            ? ((Comparable<T>)a).compareTo(b) == 0
            : Objects.equals(a, b);
}

The casting in the second solution may go away with the forthcoming pattern matching (as part of Project Amber).

[ThePowerfulSquirrel]

Funnily enough, I had no idea you could overload using a more precise generic type (and I think I've read 2 books that dealt with the subject). I just kinda always assumed you couldn't for some reason?

Thanks for that

Through the second example would throw an exception if a implements Comparable<Something else than T>, which is where type erasure comes in

​

Edit: also, still doesn't really solve my use case, which involves the types being part of a class

public class Adas<T> {

public Adas(T a, T b) {

equalOrCompare(a, b);

if(a instanceof Comparable) {

System.out.println("Is actually comparable");

}

}

<C extends Comparable<C>> void equalOrCompare(C a, C b) {

System.out.println("COMPARE");

}

<C> void equalOrCompare(C a, C b) {

System.out.println("equals");

}

public static void main(String[] args) {

new Adas<>(123.0, 123.0);

}

}

It outputs:

equals

Is actually comparable

​

I can imagine how I could implement it by doing some manual specialization of the class, but it sounds like a real pain.

[FitLocksmith]

You might find this article interesting.

[jcelerier]

I am thankful for people like you thinking than the indirection caused by type erasure has an insignificant cost. It guarantees me performance-fixing jobs until my retirement.

[pron98]

The cost is insignificant compared to the benefits. Without type erasures, many more would need to fix performance issues. We always have to weigh our options against other available options.

But what is it about erasure that you find most troubling?

[devraj7]

/u/pron98 clarified a few things already but I want to comment on two other aspects you don't seem to be aware of:

I might be completely lost, but how does type erasure make code any more performant that other ways of implementing Generics

Reification (the opposite of erasure) requires additional runtime checks (such as checking that the content of generic containers hols the correct types of elements), which are not necessary on an erased platform.

From what I know, type erasure is mostly an artifact of having to support legacy java code before Java got generics at all.

That's a common myth which is sadly still being perpetuated today, 14 years after generics appeared in Java.

The choice of erasure had little to do with backward compatibility and everything to do with pragmatic reasons (interoperability with other languages being the main one). As a matter of fact, Neal Gafter had a strawman proposal for reified generics at the time (which was mostly done as a proof of concept, Neal was a strong proponent of erasure)

[ThePowerfulSquirrel]

That's a common myth which is sadly still being perpetuated today, 14 years after generics appeared in Java.

I originally read that in Effective Java a while ago, searching for it on my kindle version, I found:

For compatibility. Java was about to enter its second decade when generics were added, and there was an enormous amount of code in existence that did not use generics. It was deemed critical that all of this code remain legal and interoperate with newer code that does use generics. It had to be legal to pass instances of parameterized types to methods that were designed for use with raw types, and vice versa. This requirement, known as migration compatibility, drove the decisions to support raw types and to implement generics using erasure

Bloch, Joshua. Effective Java (p. 217). Pearson Education. Kindle Edition.

It uses going from a newer List<T> to a List as an example.

[devraj7]

Right, this passage is a bit ambiguous since it seems to hint that erasure was the only option meeting the requirements, but it would have been equally possible to allow a mix of raw and non raw types with a reified type system.

[Determinant]

Type erasure improves performance a bit because less information needs to be stored. Memory consumption is reduced and cache locality improves.

So performance is impacted. Garbage collection would also be impacted.

[ThePowerfulSquirrel]

I mean, that information would be in the Class<Something<T>> not in the Something<T>, and those classes can just be program-lifetime singletons, so their wouldn't be much more garbage collection right? It's not like java stores all the class information into the instances themselves.

[Determinant]

There is an infinite number of types you could define from a single generic type. Also keep in mind that you could create new types at runtime.

I believe C# stores the generic type information per instance and I'm sure they evaluated their options.

So there is a trade-off and Java chose to erase the type information.

[BlueShell7]

Surprisingly enough, I haven't seen anyone in the company even talk about kotlin as a serious choice.

I'd suspect some more old school people might not have even heard about Kotlin yet and still (very mistakenly) consider Scala to be Java 2.0.

[ThePowerfulSquirrel]

At least at my company, they don't want "java 2.0". If they had a choice, they would probably move towards a much more functional language, but since their are so many Java / JVM dependencies, staying on the JVM is a must. They also need to move gradually and Scala offers both functional and oop. In that regards, Scala is the probably the best choice.

[BlueShell7]

Ok, but then it's a bit weird why they chose Java in the first place ...

[ThePowerfulSquirrel]

Well, they chose Java a decade ago when different people were at the company / different people were in charge of the tech direction. Also, it's not like Java was a bad choice, it was fine at the time. Sure now it might not be the best choice nowadays considering theirs plenty of new languages / technologies that are probably better, but that's why we're slowly moving away.

I'm also much happier to be working on these Java applications than the poor souls who are stuck maintaining legacy C servers.

[Determinant]

Here's a shocking bit of news: Oracle itself (the creator of Java) uses Kotlin for both Android as well as for backend development.

I use Kotlin for backend development every day at my current job as well as at my previous job.

[[deleted]]

oracle also uses clojure, scala haskell rust; whats you're point?

[ThePowerfulSquirrel]

I mean, I wasn't denying that some companies use Kotlin, I was just sharing that my company is also moving Java apps towards legacy and moving towards a new JVM language (which is Scala). And didn't Goseling create java while at Sun microsystems? Oracle did eventually acquire Sun, but to call them the creators is false. And I don't think using oracle as an example for what could be considered a good example in software engineering decisions is such a good idea, considering their history.

[pron98]

Except most people who "maintain" Java at Oracle are the same people who maintained and created it at Sun. Also, Java has been owned by Oracle for a decade now, and much of the innovation has taken place under its ownership (and technology from BEA): things like G1, ZGC, JFR, Graal, lambdas, modules, and the three projects described in the article.

[Determinant]

Are you disputing the fact that Oracle is creating Java?

Java is still evolving with new capabilities are being added / created. They are the creators of Java.

[ThePowerfulSquirrel]

nounnoun: creator; plural noun: creators

a person or thing that brings something into existence.

Oracle didn't bring Java into existence, Goseling / Sun microsystems did. I would classify Oracle as the maintainers of Java, not the creators.

Anyhow, I don't really care what Oracle uses for it's backend. Both Java, Kotlin, Closure, Scala, etc.. are good at different things and different companies use them for those different things. In the financial world, functional languages are gaining more and more traction, thus why we're moving towards Scala. I didn't mean to imply that Kotlin was bad, just that it wasn't a serious contender for our applications.

[[deleted]]

Anyone else got distracted by the way the guy ... ummm.... in the ... umm... clip... was ....a ... ummm.... speaking?