Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What Future Java Might Look Like

blog.codefx.org

Post reply on HN
Print view View original

91–100 of 105 posts

Re: What Future Java Might Look Like

#91

Post by nradov »

xaduha wrote: post #85
nradov wrote: post #81

Earlier quoted context omitted.

But in practice the language version is always specified in the build script which is bundled with the source code. In Java that's typically a Maven pom.xml file. So you only have to change it once per module rather than in every separate source code file. I see no particular advantage in specifying the language version in each and every file; those source code files aren't meant to stand on their own anyway.

The point is to remove obstacles that prevent you from introducing backward incompatible changes into the language, obstacles than prevent your language from evolving. Implementations can support several specifications of the language, you can keep those source code files as is or you can mix them. You can take advantage of new features in new files, but keep everything else working. Imagine you updated your pom file…

No I'm not stuck, but realistically when you make a change like that you're going to have to update the entire module. There's no way that having a mix of incompatible different language versions in individual source code files within a single module is ever going to be practical for real world large scale product development.

Re: What Future Java Might Look Like

#92

Post by paulddraper »

sixbrx wrote: post #90
paulddraper wrote: post #83

Earlier quoted context omitted.

class Rational(n: Int, d: Int) { require(d != 0) val (numer, denom) = { val g = gcd(n.abs, d.abs) (n / g, d / g) } // ... private def gcd(a: Int, b: Int) = if (b == 0) a else gcd(b, a % b) } Now `g` is a local variable.

As discussed in the thread, that doesn't work given that we're trying to avoid extra storage, it adds an extra tuple member to the class. It's still true as of the latest compiler just like it was in 2009: $ scalac -version Scala compiler version 2.12.1 -- Copyright 2002-2016, LAMP/EPFL and Lightbend, Inc. $ javap -private Rational Compiled from "Rational.scala" public class Rational { private final scala.Tuple2 x$1;…

Sure, okay. But the point remains that "you couldn't have local/temporary variables in your class constructors" isn't quite true.

FYI, you could avoid that but not without giving up `final`.

This isn't exactly unusual. Lots of source languages (e.g., C) don't expose all the abilities of the target language (ASM).

I'm surprised you mention this shortcoming compared to Java. I would have mentioned the lack of a Java enumeration equivalent.

Re: What Future Java Might Look Like

#93

Post by sixbrx »

paulddraper wrote: post #92
sixbrx wrote: post #90

Earlier quoted context omitted.

As discussed in the thread, that doesn't work given that we're trying to avoid extra storage, it adds an extra tuple member to the class. It's still true as of the latest compiler just like it was in 2009: $ scalac -version Scala compiler version 2.12.1 -- Copyright 2002-2016, LAMP/EPFL and Lightbend, Inc. $ javap -private Rational Compiled from "Rational.scala" public class Rational { private final scala.Tuple2 x$1;…

Sure, okay. But the point remains that "you couldn't have local/temporary variables in your class constructors" isn't quite true. FYI, you could avoid that but not without giving up `final`. This isn't exactly unusual. Lots of source languages (e.g., C) don't expose all the abilities of the target language (ASM). I'm surprised you mention this shortcoming compared to Java. I would have mentioned the lack of a Java en…

It was short for the explanation in the following paragraphs (OK I should have added "without unwanted storage side effects" which was the whole point though). WHich I still haven't seen resolved in a memorable/non-gross way (I do assume extempore's hack works). Even Martin's private[this] idea from that thread was apparently never implemented, I just tried it also.

I'm a Scala fan by the way, and this is a solvable problem (the private[this] solution would be fine I think). But it's currently a landmine IMO and an unfortunate because it's such an unforced error.

Re: What Future Java Might Look Like

#94

Post by xaduha »

nradov wrote: post #91
xaduha wrote: post #85

Earlier quoted context omitted.

The point is to remove obstacles that prevent you from introducing backward incompatible changes into the language, obstacles than prevent your language from evolving. Implementations can support several specifications of the language, you can keep those source code files as is or you can mix them. You can take advantage of new features in new files, but keep everything else working. Imagine you updated your pom file…

No I'm not stuck, but realistically when you make a change like that you're going to have to update the entire module. There's no way that having a mix of incompatible different language versions in individual source code files within a single module is ever going to be practical for real world large scale product development.

Don't try to make it a technical issue, because it totally isn't. Every single one of those files goes through a compiler of some kind. Source code gets transformed to a tree, AST, whatever. They only thing changing here is that somewhere near the root of that tree there's a version.

In many languages there is already a mechanism for specifying that kind of info, like pragmas or CDATA in SGML descended markup languages. And it's not hard to introduce either way. Javascript borrowed 'use strict' from Perl 5, for example.

In the end you write something in a language. What language you use to write that isn't defined in some external file, it's an inherent property of the text. You can't write a note in Ye Olde English and expect it to be understood by modern people without issues.

Re: What Future Java Might Look Like

#95

Post by douche »

jpitz wrote: post #86
overgard wrote: post #62

Earlier quoted context omitted.

Its weird how far java has fallen behind C# (especially given that C# was, to put it kindly, originally just basically "microsoft java".) It would seem like Oracle could just follow the blueprint, so I'm sort of surprised they haven't

The falling-behind happened early, and fast. MS took full advantage of second-mover status to change fast and add features. They also targeted fewer platforms initially. While the market niche was certainly aimed squarely at the same demographic as Java users, the language owes as least as much to Borland Object Pascal as it does to Java. Speaking of Object Pascal, MS also got Anders Hejlsburg to design it. Oracle/Su…

There was a huge gap of time where effectively there was no forward progress with Java. I learned Java 6 in high school - by the time I graduated college Java 7 still hadn't been released.

Re: What Future Java Might Look Like

#96

Post by cle »

shadowfacts wrote: post #24

The future of Java looks a lot like Kotlin. Aside from value classes, all of the mentioned features are present in Kotlin: - Data classes: https://kotlinlang.org/docs/reference/data-classes.html - Type inference: https://kotlinlang.org/docs/reference/basic-types.html - Switch as an expression: https://kotlinlang.org/docs/reference/control-flow.html#when... - Destructuring: https://kotlinlang.org/docs/reference/multi-…

These existed long before Kotlin.

Re: What Future Java Might Look Like

#97

Post by pjmlp »

xaduha wrote: post #82
pjmlp wrote: post #79

Earlier quoted context omitted.

> Oracle JVM isn't the only JVM implementation. Quite true, but from Azul, IBM, HP, Jamaica, Aonix, Excelsior, Gamato,CodenameOne, ... who is interested in replacing Java (the language)?

First, JVM vendors have to conform to specifications, that's all. And introduction of invokedynamic and other stuff that makes it easier for other JVM languages to exist obviously means that they aren't against the idea. All in all I'm for interoperation. "And", not "or". No one is forcing you to rewrite existing Java code.

My point is that Java is to the JVM, just like C is to UNIX, JavaScript to the browsers, VB/C#/F#/C++ to .NET, Swift/Objective-C to iOS, ...

Sure you can have other languages running there, but unless their is first tier support for those languages, most customers won't care and will only allow for first tier programming languages.

Re: What Future Java Might Look Like

#98

Post by chei0iaV »

cle wrote: post #96
shadowfacts wrote: post #24

The future of Java looks a lot like Kotlin. Aside from value classes, all of the mentioned features are present in Kotlin: - Data classes: https://kotlinlang.org/docs/reference/data-classes.html - Type inference: https://kotlinlang.org/docs/reference/basic-types.html - Switch as an expression: https://kotlinlang.org/docs/reference/control-flow.html#when... - Destructuring: https://kotlinlang.org/docs/reference/multi-…

These existed long before Kotlin.

But was there source-level compatibility with Java?

Re: What Future Java Might Look Like

#99

Post by Roboprog »

twic wrote: post #65
Yhippa wrote: post #27

Earlier quoted context omitted.

I've seen many different codebases but have never run into Lombok. I really want to use it. Any practical gotchas I need to worry about?

The gotcha is that Lombok thinks classes should be structs, and will try to persuade you of that too. A fundamental plank of good object-oriented design - which i admit that i rarely see or even practice - is information hiding. Lombok rips that up and burns it. And that may give you a warm feeling for a while, but at some point, you're going to fall through the floor.

Most java shops create a lot of "do nothing" scut work "beans". If that's what much of the work you are forced to do is, make short work of it.

Lombok of course doesn't help much for classes with "Actual Work" (TM) in them, but that's OK.

Was there something more subtle that I'm missing? (quite possible)

Re: What Future Java Might Look Like

#100

Post by Roboprog »

overgard wrote: post #68
Roboprog wrote: post #41

To me, most of the JVM languages have 2 similar problems with the "defaults": references are optional, rather than mandatory; objects are mutable, rather than immutable. It's past time for a language that makes it's references mandatory unless you explicitly indicate "optional" / "maybe" or whatever. Slapping "Optional " on stuff when "mandatory" isn't enforced seems to just make things worse. Similarly, classes/obje…

As much as I think immutable-by-default is a good idea for code correctness, it does have a really big performance penalty since it means a LOT of GC pressure (since you have to make a lot of allocations). Side effect free is great, but, at the moment anyway you can't really do it in real time systems where a GC pause is a huge problem

As always, there's a spectrum of problems that require increasingly lower level grunt work to be fast "enough" (or rather, "performant", as The Management likes to say these days)

However, to me at least, it makes sense to start at the top and work your way down when bottlenecks arise (systems level software aside):

Configuration -> DSL -> scripting -> "FP on VM" -> "(mutable) OOP on VM" -> "traditional 3GL (with bounds checking)" -> C -> assembler -> hardware.

Generational GC should take most of the pain out of immutable temp value churn. You can also use libraries and frameworks that "ask nicely" to mutate things, such as behind-the-scenes internal accumulators for filter/map/reduce type operations.

Post reply on HN