12 ms·

What Future Java Might Look Like

45 points by reactor 10y ago

geooooooooobox 10y ago
still doesn't look bright imo
- joncampbelldev 10y ago
  yes I feel that scala or clojure already offer all these advantages (depending on your preference of static vs dynamic typing) and have great java interop.
  - bdavisx 10y ago
    And Kotlin as well, with java interop considered a top priority.
    - marktangotango 10y ago
      So long as we're citing favorites, sad SML on the JVM never took off: http://www.dcs.ed.ac.uk/home/mlj/index.html http://www.dcs.ed.ac.uk/home/mlj/index.html
      - geooooooooobox 10y ago
        what did you think of frege?
    - estefan 10y ago
      Is anyone actually using Kotlin outside jetbrains? Seems like it doesn't have much mindshare or any high profile projects using it.
      - Roboprog 10y ago
        I only know one person at a local meetup who is a fan of the language. He makes a good point that it does generate binaries that work on Android, though. (since the newer Android SDK is based on Intellij, I guess that's not too surprising, but still useful)
      - twic 10y ago
        I asked my hipster Android developer friend (who doesn't work for JetBrains) and he said: "two apps in the Play Store and one of them [also] has an API gateway written in Kotlin"
      - bdavisx 10y ago
        I'm not sure, but I know the Gradle people worked with Jetbrains to integrate it into Gradle, so you can use it instead of Groovy. SpringBoot initializer will allow you to choose Kotlin as a language (along with Java and Groovy). Corda (an open source distributed ledger was built with it) - not sure how many are using Corda since it's so new. Quasar (an JVM actor library) supports it. Here's an article about KeepSafe converting their Android app: https://medium.com/keepsafe-engineering/lessons-from-converting-an-app-to-100-kotlin-68984a05dcb6#.c6dnkag4h https://medium.com/keepsafe-engineering/lessons-from-convert.... There are several companies listed on the Kotlin website as well. edit: The list of companies from the Kotlin website: https://github.com/JetBrains/kotlin-web-site/blob/master/data/companies-using-kotlin.yml https://github.com/JetBrains/kotlin-web-site/blob/master/dat... I guess my point is you can find people using it. I just wonder why anyone who is currently using Java doesn't at least consider it and try it out -- it's much more concise and nicer to develop in. But then again, I guess a much larger percentage of Java developers don't ever learn anything new and probably have never even heard of the name.
        vorg 10y ago
        Kotlin's backed by Jetbrains which makes IntelliJ which many Java developers have heard of, whereas Apache Groovy was dropped by Pivotal which also still backs Spring. I imagine more and more software which enables Groovy for scripting will follow in the footsteps of Gradle and SpringBoot by allowing Kotlin to be used as well, such as Jenkins and maybe even Grails one day.
      - voddan 10y ago
        Netflix, for example. 3/4 of all Kotlin presentations are done by people outside of JetBrains who use Kotlin at work. And there are a lot of them.
hashhar 10y ago
I really started hating Java when I had to write a government office's Licence Management web application using Java. The tooling is brain dead, except JetBrains IntelliJ. The dependency management system is braindead too (if not for IntelliJ's maven integration). The MVC architecture implementation using Struts and Spring annotations reminds me of PHP. The resulting applications are painful to step through, I don't know why since Visual Studio can easily step through .aspx or .cshtml files. I then picked up ASP.NET MVC and haven't look back but unfortunately most of the jobs in my country (India) still use Java for legacy web applications.
RyanHamilton 10y ago
Lombok already gives you some of this: - Data objects https://projectlombok.org/features/Data.html https://projectlombok.org/features/Data.html That generate toString, getters, setters etc as required - Val for local variables https://projectlombok.org/features/val.html https://projectlombok.org/features/val.html I don't start a new project without it. And if you really want stripe down java checkout http://jpad.io/ http://jpad.io/ a little program I made to make running java scripts/snippets extremely easy.
- Roboprog 10y ago
  FWIW, I did a presentation on Lombok at the local Java user group recently: https://docs.google.com/presentation/d/1XouaIJ5d3CaqEW87Fpup7YTcEQc4ZW3UF3hyrnDgx0M/edit#slide=id.p https://docs.google.com/presentation/d/1XouaIJ5d3CaqEW87Fpup... It's a nice tool.
  - Yhippa 10y ago
    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?
    - lmm 10y ago
      All your tools need to understand it - not just your IDE but if you're using anything like FindBugs, code coverage reporting, profilers.... I used it for a while but that kind of thing really needs to be a first-class language feature, so I switched to Scala (which has case classes) and haven't looked back.
    - scalesolved 10y ago
      Almost none, well the only thing that is annoying is that type inference currently won't work within lambdas but otherwise it's great. We use Lombok on all our Java services and have never had an issue (we do about 33million requests a day across these services so they are real battle tested and used code bases). Type inference, automatic builders, removal of getters and setters (@Data will automatically add getters and setters to the fields of a class) and (@Value will make the immutable version). I would never work in Java these days without being able to use Java 8/Lombok/Javaslang/Guava.
michaelcampbell 10y ago
So... scala with some boilerplate?
- tomp 10y ago
  Exactly. That's the primary reason I use Scala these days - all that's good in Java (libraries, JVM) but with a much nicer surface language! The only thing that's missing, really, is fast for loops (either Java-like, or automatic optimisation when looping over things like arrays or ranges). Conversely, a major thing missing in the post above is some sort of implicits, or at least C#-like extension methods.
  - sixbrx 10y ago
    Is the excessive virtual dispatch still really slowing down simple for loops in Scala? I thought Paul Phillips did a special-case fix for that. That's very disappointing if that's still a problem. When I programmed in Scala, I felt like this sort of thing showed that priorities weren't quite right in the leadership somehow. For-loops are pretty basic and their performance is important - simple ones shouldn't have ever been slower than the equivalent Java ones IMO. Another instance of misplaced priorities (again IMO), was the problem that you couldn't have local/temporary variables in your class constructors (see for example http://www.scala-lang.org/old/node/1198.html http://www.scala-lang.org/old/node/1198.html). Any values that you created inline in your class body (which is your primary constructor) could be used but would implicitly become fields in your class instances even if they were never used in any methods. Sure you can make factory methods in a companion object etc but should have to do that always? That's worse than Java and for no good reason! The "simplified" syntax of not having an explicit block representing scope for the actual constructor code, separate from member declarations, really bites in this case. An example of this was the gcd value in Oderski's rational number class which is one of the first examples in his book. The gcd value is needed to initialize the numerator and denominator values, and you want to save it after it's first computed temporarily so you don't have to compute it twice. But naming it at all made it an actual instance field, not just a temporary in the constructor. So every Rational would be carrying around this significant extra storage unbeknownst even to a programmer who would have reviewed the source code, unless they are in the habit of examining javap output for everything or already knew to watch for this issue. I don't know if that's been fixed or not. The very fact that this could stand for so long, and how implicit the whole thing was about something so fundamental (object construction!), really bothered me about Scala though.
deleted 10y ago
[deleted]
ygra 10y ago
> Brian went to great lengths to stress how very, > very speculative all of the following is and how > much things might evolve or simply get dropped. He > went so far to let everyone in the audience sign an > acknowledgment thereof (just mentally but still) and > explicitly forbade any sensationalist tweets. > Well… first of all, this is no tweet and second of all, > I wasn’t in that audience. Oh well. So they agree it's sensationalist and I won't hold my breath for those things to appear in the near future. For a recent new release of our library at work we dropped compatibility for Java < 8. I actually tried finding out how far the value types proposal had progressed (since we convert the code from C# we actually have value types that were turned into classes in Java again) to see whether we can do things now that would integrate cleanly into a new Java language version later without drastic API changes on our part. Alas, nothing was to be found except for the original 2014 proposal. Another point is the upgraded switch statement with pattern matching. The next version of C# is currently trying to add this and the current form looks a lot different from the initial proposal. I expect reality to change a fair bit of how those features will end up in Java eventually.
dschuetz 10y ago
Dead, finally? ..Ow, damn, false alarm! Just another vile article :(
- mixedCase 10y ago
  You're being downvoted, but really, the only saving grace in Java is the occasionally useful tooling that can't be used in the other two actually good JVM languages: Kotlin and Scala. And right now the only one I can think of is j2objc. Java should absolutely die.
  - dkersten 10y ago
    ...in the other two actually good JVM languages: Kotlin and Scala As a Clojure programmer, I take exception to this statement. There's more than just two "actually good" JVM languages. (I personally don't like the two you mentioned that much, but its because I have a distaste for OO these days, not because they're bad languages) The JVM is a solid piece of tech and the Java ecosystem is strong, but Java the language is not something I want to have to use again, if I can help it. There are many better languages out there nowadays!
  - dschuetz 10y ago
    Isn't this upvote-downvote thing somehow linked to confirmation bias? I'm getting downvoted for having issued an opinion which opposes that of the others? This sounds so horribly wrong to me...
    - odabaxok 10y ago
      It is because you do not comment according to the guidelines, which encourage people to start conversation with reasoning etc. Points done bad in your comments: Avoid gratuitous negativity. When disagreeing, please reply to the argument instead of calling names. E.g. "That is idiotic; 1 + 1 is 2, not 3" can be shortened to "1 + 1 is 2, not 3." Please avoid introducing classic flamewar topics unless you have something genuinely new to say about them. Please resist commenting about being downvoted. It never does any good, and it makes boring reading.
st3v3r 10y ago
It'll look like this, except on Android. There, despite constantly being asked when newer improvements to Java would come, they still had to ask if people wanted them to update to Java 8, and why they'd want that.
- pjmlp 10y ago
  It is because of this attitude that I side with Oracle. Google just forked Java 6, and we only get cherry picked updates from newer versions, which will only get worse every time a new Java version gets released. Looking at the current Java 8 half-backed support in Android 7, try to imagine writing Java 10 library with all these goodies that also needs an Android version.
tormeh 10y ago
Languages cannot get better, only bigger, without dropping backwards compatibility. This is why Java needs to die. Not because it's particularly horrible, but because we can do better now.
- dkersten 10y ago
  Languages cannot get better, only bigger, without dropping backwards compatibility. Completely agree. Dropping backwards compatibility, if you have serious users, really isn't an option either. Just look at Python 2/3. You can deprecate stuff and very very very very slowly remove it, but it really is a slow process if you want to keep your existing users happy.
- nradov 10y ago
  By that standard every language needs to die. Or to put it another way, how long should languages be permitted to survive as we figure out better ways of doing things?
  - tormeh 10y ago
    Very interesting question. The benefits of a new language has to be weighed against the learning that has to be done to use it and the load of maintaining things in different languages. It's not every 3 years or anything like that, but Java is 20 years old now, and it shows.
    - afandian 10y ago
      And another generation of programmers wastes time rewriting the same stuff in the language du jour.
      - greydius 10y ago
        This is going to happen anyway.
    - pjmlp 10y ago
      > It's not every 3 years or anything like that, but Java is 20 years old now, and it shows. Yes, I get to use mature libraries for everything without having to spend development time redoing them, and can focus on business code instead.
mikeevans 10y ago
So just like Kotlin then?
dlandis 10y ago
I wish they would focus on making the underlying platform and bytecode more amenable to all the other, non-Java languages like Scala that compile to JVM bytecode. The real value is in the highly optimized, stable, and performant underlying JVM platform. If it was easier to create languages like Scala that were "compatible" with Java codebases and had the primitives they require in the underlying platform, then that would lead to an incredible amount of innovation I think. Nobody really cares that Java (on the language syntax level) is going to add some features in 5-10 years that other langs already had 10 years ago, that is ridiculous.
- pjmlp 10y ago
  When looking at the common Java shops scattered all around the world, not the SV darlings, Java (the language) is the only option. Why do you think Lightbend now offers Java services in addition to Scala ones? Most of us only get to use Java, customers don't allow for anything else on JVM related projects.
  - Roboprog 10y ago
    Welcome to Sacramento :-(
- mdellabitta 10y ago
  Have you looked at Truffle & Graal, which are going to be introduced in Java 9 to some extent? https://medium.com/@octskyward/graal-truffle-134d8f28fb69#.hgyprrd1j https://medium.com/@octskyward/graal-truffle-134d8f28fb69#.h... https://en.wikipedia.org/wiki/Graal_(compiler) https://en.wikipedia.org/wiki/Graal_(compiler)
- twic 10y ago
  What features or changes would make the JVM more amenable to other, non-Java languages?
shadowfacts 10y ago
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 https://kotlinlang.org/docs/reference/data-classes.html - Type inference: https://kotlinlang.org/docs/reference/basic-types.html https://kotlinlang.org/docs/reference/basic-types.html - Switch as an expression: https://kotlinlang.org/docs/reference/control-flow.html#when-expression https://kotlinlang.org/docs/reference/control-flow.html#when... - Destructuring: https://kotlinlang.org/docs/reference/multi-declarations.html https://kotlinlang.org/docs/reference/multi-declarations.htm...
- cle 10y ago
  These existed long before Kotlin.
  - chei0iaV 10y ago
    But was there source-level compatibility with Java?
    - cle 10y ago
      What does that have to do with anything? My comment was mainly a protest of what appeared to be Kotlin fanboyism, which I see a lot lately on HN. There is nothing special about these features in Kotlin, they are common features in many popular languages preceding Kotlin, and have been on Java developers' radars long before Kotlin.
      - chei0iaV 10y ago
        My point is that you can take an existing Java codebase, stick in a Kotlin file, and use those "future Java" features right now, in your Java project. But the fact that those features might have existed in Haskell or Algol68 or whatever is largely irrelevant since we're taking about Java.
shadowfacts 10y ago
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 https://kotlinlang.org/docs/reference/data-classes.html - Type inference: https://kotlinlang.org/docs/reference/basic-types.html https://kotlinlang.org/docs/reference/basic-types.html > Absence of implicit conversions is rarely noticeable because the type is inferred from the context - Switch as an expression: https://kotlinlang.org/docs/reference/control-flow.html#when-expression https://kotlinlang.org/docs/reference/control-flow.html#when... - Destructuring: https://kotlinlang.org/docs/reference/multi-declarations.html https://kotlinlang.org/docs/reference/multi-declarations.htm...
matrix 10y ago
While these would be welcome improvements to Java, the future of Java is not about these sorts of tweaks. What Java really needs to revitalize their ecosystem is a sustained focus on improving developer experience with modern applications. That means elevating languages like Kotlin and Clojure, and producing modern libraries for basic web development so that there's a foundation of high quality components that people can build with, similar to .NET. Today, Java developers have to pick through a confusing mess of implementations for basic things with highly variable levels of quality and interopability (the biggest gap probably being security).
- fauigerzigerk 10y ago
  Value types are not a tweak. They are foundational for all JVM languages and the entire ecosystem. Their importance can hardly be overstated.
- overgard 10y ago
  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
  - jpitz 10y ago
    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/Sun, stuck with a huge, conservative enterprise user base, was shackled by backwards compatibility. In hindsight, I don't think it weird that Java fell behind the way it did.
    - douche 10y ago
      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.
Roboprog 10y ago
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/objects, methods, modules, packages should be side-effect free, unless there is a flag for mutation or other side effects. We don't need Java 1.9, we need 2.0, with "breaking" (fixing) changes :-) Scala shows some good ideas, but it doesn't go far enough. That, and I kind of liked Groovy, too, as I would like to be able to turn on and off strong/static type checking. (default on, but if you ask nicely...)
- nradov 10y ago
  You can enforce most of those rules through static analysis and annotations. Of course it won't be as solid as having it in the core language specification but you can achieve most of the same benefits.
  - Roboprog 10y ago
    Oh, I know. @Nullable, @NonNull (@Pure/@Function - something like that ???), etc. I'd like to see a bit less clutter in Java, though. I mean, thanks for mentioning it, but Java 1.x has really gotten out of hand in terms of unreadable logorrhea filling the screen for trivial things.
- overgard 10y ago
  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
  - tormeh 10y ago
    A lot of those deallocations should be easy to figure out by a compiler, though. Maybe the JVM can accommodate a delete instruction? If I say list(1,2,3).par.map(x=>x*x) there's a couple of intermediate objects that can immediately be deallocated. The GC shouldn't be bothered with cases that are so obvious.
cbdfghh 10y ago
What I would personally like (and I'm kind of surprised all projects which tried to implement it died) is a Java -> static exe/elf compiler (sort of like Go) or at least java -> exe/elf +libjava.so . I hate that deploying Java requires that everything has to be configured _exactly_ right, and write once run anywhere turns into write once debug everywhere.
- fauigerzigerk 10y ago
  IntelliJ or maven can at least create a fat runnable jar that includes all dependencies. So once you have a JVM on the target machine that jar is all you need to deploy. But I agree with you that an entirely static compilation target that includes the JVM and excludes everything that isn't necessary would be very desirable.
- user5994461 10y ago
  Other languages don't do much better once you start to have a few dependencies.
- twic 10y ago
  That's been around since 2014: https://docs.oracle.com/javase/8/docs/technotes/guides/deploy/self-contained-packaging.html https://docs.oracle.com/javase/8/docs/technotes/guides/deplo...
- pjmlp 10y ago
  > Java -> static exe/elf compiler (sort of like Go) The ones that died where the open source ones, most commercial JVMs do support AOT compilation since the early 2000's.

45 points by reactor 10y ago

geooooooooobox 10y ago

still doesn't look bright imo

joncampbelldev 10y ago
yes I feel that scala or clojure already offer all these advantages (depending on your preference of static vs dynamic typing) and have great java interop.
- bdavisx 10y ago
  And Kotlin as well, with java interop considered a top priority.
  - marktangotango 10y ago
    So long as we're citing favorites, sad SML on the JVM never took off: http://www.dcs.ed.ac.uk/home/mlj/index.html http://www.dcs.ed.ac.uk/home/mlj/index.html
    - geooooooooobox 10y ago
      what did you think of frege?
  - estefan 10y ago
    Is anyone actually using Kotlin outside jetbrains? Seems like it doesn't have much mindshare or any high profile projects using it.
    - Roboprog 10y ago
      I only know one person at a local meetup who is a fan of the language. He makes a good point that it does generate binaries that work on Android, though. (since the newer Android SDK is based on Intellij, I guess that's not too surprising, but still useful)
    - twic 10y ago
      I asked my hipster Android developer friend (who doesn't work for JetBrains) and he said: "two apps in the Play Store and one of them [also] has an API gateway written in Kotlin"
    - bdavisx 10y ago
      I'm not sure, but I know the Gradle people worked with Jetbrains to integrate it into Gradle, so you can use it instead of Groovy. SpringBoot initializer will allow you to choose Kotlin as a language (along with Java and Groovy). Corda (an open source distributed ledger was built with it) - not sure how many are using Corda since it's so new. Quasar (an JVM actor library) supports it. Here's an article about KeepSafe converting their Android app: https://medium.com/keepsafe-engineering/lessons-from-converting-an-app-to-100-kotlin-68984a05dcb6#.c6dnkag4h https://medium.com/keepsafe-engineering/lessons-from-convert.... There are several companies listed on the Kotlin website as well. edit: The list of companies from the Kotlin website: https://github.com/JetBrains/kotlin-web-site/blob/master/data/companies-using-kotlin.yml https://github.com/JetBrains/kotlin-web-site/blob/master/dat... I guess my point is you can find people using it. I just wonder why anyone who is currently using Java doesn't at least consider it and try it out -- it's much more concise and nicer to develop in. But then again, I guess a much larger percentage of Java developers don't ever learn anything new and probably have never even heard of the name.
      - vorg 10y ago
        Kotlin's backed by Jetbrains which makes IntelliJ which many Java developers have heard of, whereas Apache Groovy was dropped by Pivotal which also still backs Spring. I imagine more and more software which enables Groovy for scripting will follow in the footsteps of Gradle and SpringBoot by allowing Kotlin to be used as well, such as Jenkins and maybe even Grails one day.
    - voddan 10y ago
      Netflix, for example. 3/4 of all Kotlin presentations are done by people outside of JetBrains who use Kotlin at work. And there are a lot of them.

hashhar 10y ago

I really started hating Java when I had to write a government office's Licence Management web application using Java. The tooling is brain dead, except JetBrains IntelliJ. The dependency management system is braindead too (if not for IntelliJ's maven integration). The MVC architecture implementation using Struts and Spring annotations reminds me of PHP. The resulting applications are painful to step through, I don't know why since Visual Studio can easily step through .aspx or .cshtml files. I then picked up ASP.NET MVC and haven't look back but unfortunately most of the jobs in my country (India) still use Java for legacy web applications.

RyanHamilton 10y ago

Lombok already gives you some of this: - Data objects https://projectlombok.org/features/Data.html https://projectlombok.org/features/Data.html That generate toString, getters, setters etc as required - Val for local variables https://projectlombok.org/features/val.html https://projectlombok.org/features/val.html I don't start a new project without it. And if you really want stripe down java checkout http://jpad.io/ http://jpad.io/ a little program I made to make running java scripts/snippets extremely easy.

Roboprog 10y ago
FWIW, I did a presentation on Lombok at the local Java user group recently: https://docs.google.com/presentation/d/1XouaIJ5d3CaqEW87Fpup7YTcEQc4ZW3UF3hyrnDgx0M/edit#slide=id.p https://docs.google.com/presentation/d/1XouaIJ5d3CaqEW87Fpup... It's a nice tool.
- Yhippa 10y ago
  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?
  - lmm 10y ago
    All your tools need to understand it - not just your IDE but if you're using anything like FindBugs, code coverage reporting, profilers.... I used it for a while but that kind of thing really needs to be a first-class language feature, so I switched to Scala (which has case classes) and haven't looked back.
  - scalesolved 10y ago
    Almost none, well the only thing that is annoying is that type inference currently won't work within lambdas but otherwise it's great. We use Lombok on all our Java services and have never had an issue (we do about 33million requests a day across these services so they are real battle tested and used code bases). Type inference, automatic builders, removal of getters and setters (@Data will automatically add getters and setters to the fields of a class) and (@Value will make the immutable version). I would never work in Java these days without being able to use Java 8/Lombok/Javaslang/Guava.

michaelcampbell 10y ago

So... scala with some boilerplate?

tomp 10y ago
Exactly. That's the primary reason I use Scala these days - all that's good in Java (libraries, JVM) but with a much nicer surface language! The only thing that's missing, really, is fast for loops (either Java-like, or automatic optimisation when looping over things like arrays or ranges). Conversely, a major thing missing in the post above is some sort of implicits, or at least C#-like extension methods.
- sixbrx 10y ago
  Is the excessive virtual dispatch still really slowing down simple for loops in Scala? I thought Paul Phillips did a special-case fix for that. That's very disappointing if that's still a problem. When I programmed in Scala, I felt like this sort of thing showed that priorities weren't quite right in the leadership somehow. For-loops are pretty basic and their performance is important - simple ones shouldn't have ever been slower than the equivalent Java ones IMO. Another instance of misplaced priorities (again IMO), was the problem that you couldn't have local/temporary variables in your class constructors (see for example http://www.scala-lang.org/old/node/1198.html http://www.scala-lang.org/old/node/1198.html). Any values that you created inline in your class body (which is your primary constructor) could be used but would implicitly become fields in your class instances even if they were never used in any methods. Sure you can make factory methods in a companion object etc but should have to do that always? That's worse than Java and for no good reason! The "simplified" syntax of not having an explicit block representing scope for the actual constructor code, separate from member declarations, really bites in this case. An example of this was the gcd value in Oderski's rational number class which is one of the first examples in his book. The gcd value is needed to initialize the numerator and denominator values, and you want to save it after it's first computed temporarily so you don't have to compute it twice. But naming it at all made it an actual instance field, not just a temporary in the constructor. So every Rational would be carrying around this significant extra storage unbeknownst even to a programmer who would have reviewed the source code, unless they are in the habit of examining javap output for everything or already knew to watch for this issue. I don't know if that's been fixed or not. The very fact that this could stand for so long, and how implicit the whole thing was about something so fundamental (object construction!), really bothered me about Scala though.

deleted 10y ago

[deleted]

ygra 10y ago

> Brian went to great lengths to stress how very, > very speculative all of the following is and how > much things might evolve or simply get dropped. He > went so far to let everyone in the audience sign an > acknowledgment thereof (just mentally but still) and > explicitly forbade any sensationalist tweets. > Well… first of all, this is no tweet and second of all, > I wasn’t in that audience. Oh well. So they agree it's sensationalist and I won't hold my breath for those things to appear in the near future. For a recent new release of our library at work we dropped compatibility for Java < 8. I actually tried finding out how far the value types proposal had progressed (since we convert the code from C# we actually have value types that were turned into classes in Java again) to see whether we can do things now that would integrate cleanly into a new Java language version later without drastic API changes on our part. Alas, nothing was to be found except for the original 2014 proposal. Another point is the upgraded switch statement with pattern matching. The next version of C# is currently trying to add this and the current form looks a lot different from the initial proposal. I expect reality to change a fair bit of how those features will end up in Java eventually.

dschuetz 10y ago

Dead, finally? ..Ow, damn, false alarm! Just another vile article :(

mixedCase 10y ago
You're being downvoted, but really, the only saving grace in Java is the occasionally useful tooling that can't be used in the other two actually good JVM languages: Kotlin and Scala. And right now the only one I can think of is j2objc. Java should absolutely die.
- dkersten 10y ago
  ...in the other two actually good JVM languages: Kotlin and Scala As a Clojure programmer, I take exception to this statement. There's more than just two "actually good" JVM languages. (I personally don't like the two you mentioned that much, but its because I have a distaste for OO these days, not because they're bad languages) The JVM is a solid piece of tech and the Java ecosystem is strong, but Java the language is not something I want to have to use again, if I can help it. There are many better languages out there nowadays!
- dschuetz 10y ago
  Isn't this upvote-downvote thing somehow linked to confirmation bias? I'm getting downvoted for having issued an opinion which opposes that of the others? This sounds so horribly wrong to me...
  - odabaxok 10y ago
    It is because you do not comment according to the guidelines, which encourage people to start conversation with reasoning etc. Points done bad in your comments: Avoid gratuitous negativity. When disagreeing, please reply to the argument instead of calling names. E.g. "That is idiotic; 1 + 1 is 2, not 3" can be shortened to "1 + 1 is 2, not 3." Please avoid introducing classic flamewar topics unless you have something genuinely new to say about them. Please resist commenting about being downvoted. It never does any good, and it makes boring reading.

st3v3r 10y ago

It'll look like this, except on Android. There, despite constantly being asked when newer improvements to Java would come, they still had to ask if people wanted them to update to Java 8, and why they'd want that.

pjmlp 10y ago
It is because of this attitude that I side with Oracle. Google just forked Java 6, and we only get cherry picked updates from newer versions, which will only get worse every time a new Java version gets released. Looking at the current Java 8 half-backed support in Android 7, try to imagine writing Java 10 library with all these goodies that also needs an Android version.

tormeh 10y ago

Languages cannot get better, only bigger, without dropping backwards compatibility. This is why Java needs to die. Not because it's particularly horrible, but because we can do better now.

dkersten 10y ago
Languages cannot get better, only bigger, without dropping backwards compatibility. Completely agree. Dropping backwards compatibility, if you have serious users, really isn't an option either. Just look at Python 2/3. You can deprecate stuff and very very very very slowly remove it, but it really is a slow process if you want to keep your existing users happy.
nradov 10y ago
By that standard every language needs to die. Or to put it another way, how long should languages be permitted to survive as we figure out better ways of doing things?
- tormeh 10y ago
  Very interesting question. The benefits of a new language has to be weighed against the learning that has to be done to use it and the load of maintaining things in different languages. It's not every 3 years or anything like that, but Java is 20 years old now, and it shows.
  - afandian 10y ago
    And another generation of programmers wastes time rewriting the same stuff in the language du jour.
    - greydius 10y ago
      This is going to happen anyway.
  - pjmlp 10y ago
    > It's not every 3 years or anything like that, but Java is 20 years old now, and it shows. Yes, I get to use mature libraries for everything without having to spend development time redoing them, and can focus on business code instead.

mikeevans 10y ago

So just like Kotlin then?

dlandis 10y ago

I wish they would focus on making the underlying platform and bytecode more amenable to all the other, non-Java languages like Scala that compile to JVM bytecode. The real value is in the highly optimized, stable, and performant underlying JVM platform. If it was easier to create languages like Scala that were "compatible" with Java codebases and had the primitives they require in the underlying platform, then that would lead to an incredible amount of innovation I think. Nobody really cares that Java (on the language syntax level) is going to add some features in 5-10 years that other langs already had 10 years ago, that is ridiculous.

pjmlp 10y ago
When looking at the common Java shops scattered all around the world, not the SV darlings, Java (the language) is the only option. Why do you think Lightbend now offers Java services in addition to Scala ones? Most of us only get to use Java, customers don't allow for anything else on JVM related projects.
- Roboprog 10y ago
  Welcome to Sacramento :-(
mdellabitta 10y ago
Have you looked at Truffle & Graal, which are going to be introduced in Java 9 to some extent? https://medium.com/@octskyward/graal-truffle-134d8f28fb69#.hgyprrd1j https://medium.com/@octskyward/graal-truffle-134d8f28fb69#.h... https://en.wikipedia.org/wiki/Graal_(compiler) https://en.wikipedia.org/wiki/Graal_(compiler)
twic 10y ago
What features or changes would make the JVM more amenable to other, non-Java languages?

shadowfacts 10y ago

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 https://kotlinlang.org/docs/reference/data-classes.html - Type inference: https://kotlinlang.org/docs/reference/basic-types.html https://kotlinlang.org/docs/reference/basic-types.html - Switch as an expression: https://kotlinlang.org/docs/reference/control-flow.html#when-expression https://kotlinlang.org/docs/reference/control-flow.html#when... - Destructuring: https://kotlinlang.org/docs/reference/multi-declarations.html https://kotlinlang.org/docs/reference/multi-declarations.htm...

cle 10y ago
These existed long before Kotlin.
- chei0iaV 10y ago
  But was there source-level compatibility with Java?
  - cle 10y ago
    What does that have to do with anything? My comment was mainly a protest of what appeared to be Kotlin fanboyism, which I see a lot lately on HN. There is nothing special about these features in Kotlin, they are common features in many popular languages preceding Kotlin, and have been on Java developers' radars long before Kotlin.
    - chei0iaV 10y ago
      My point is that you can take an existing Java codebase, stick in a Kotlin file, and use those "future Java" features right now, in your Java project. But the fact that those features might have existed in Haskell or Algol68 or whatever is largely irrelevant since we're taking about Java.

shadowfacts 10y ago

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 https://kotlinlang.org/docs/reference/data-classes.html - Type inference: https://kotlinlang.org/docs/reference/basic-types.html https://kotlinlang.org/docs/reference/basic-types.html > Absence of implicit conversions is rarely noticeable because the type is inferred from the context - Switch as an expression: https://kotlinlang.org/docs/reference/control-flow.html#when-expression https://kotlinlang.org/docs/reference/control-flow.html#when... - Destructuring: https://kotlinlang.org/docs/reference/multi-declarations.html https://kotlinlang.org/docs/reference/multi-declarations.htm...

matrix 10y ago

While these would be welcome improvements to Java, the future of Java is not about these sorts of tweaks. What Java really needs to revitalize their ecosystem is a sustained focus on improving developer experience with modern applications. That means elevating languages like Kotlin and Clojure, and producing modern libraries for basic web development so that there's a foundation of high quality components that people can build with, similar to .NET. Today, Java developers have to pick through a confusing mess of implementations for basic things with highly variable levels of quality and interopability (the biggest gap probably being security).

fauigerzigerk 10y ago
Value types are not a tweak. They are foundational for all JVM languages and the entire ecosystem. Their importance can hardly be overstated.
overgard 10y ago
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
- jpitz 10y ago
  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/Sun, stuck with a huge, conservative enterprise user base, was shackled by backwards compatibility. In hindsight, I don't think it weird that Java fell behind the way it did.
  - douche 10y ago
    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.

Roboprog 10y ago

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/objects, methods, modules, packages should be side-effect free, unless there is a flag for mutation or other side effects. We don't need Java 1.9, we need 2.0, with "breaking" (fixing) changes :-) Scala shows some good ideas, but it doesn't go far enough. That, and I kind of liked Groovy, too, as I would like to be able to turn on and off strong/static type checking. (default on, but if you ask nicely...)

nradov 10y ago
You can enforce most of those rules through static analysis and annotations. Of course it won't be as solid as having it in the core language specification but you can achieve most of the same benefits.
- Roboprog 10y ago
  Oh, I know. @Nullable, @NonNull (@Pure/@Function - something like that ???), etc. I'd like to see a bit less clutter in Java, though. I mean, thanks for mentioning it, but Java 1.x has really gotten out of hand in terms of unreadable logorrhea filling the screen for trivial things.
overgard 10y ago
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
- tormeh 10y ago
  A lot of those deallocations should be easy to figure out by a compiler, though. Maybe the JVM can accommodate a delete instruction? If I say list(1,2,3).par.map(x=>x*x) there's a couple of intermediate objects that can immediately be deallocated. The GC shouldn't be bothered with cases that are so obvious.

cbdfghh 10y ago

What I would personally like (and I'm kind of surprised all projects which tried to implement it died) is a Java -> static exe/elf compiler (sort of like Go) or at least java -> exe/elf +libjava.so . I hate that deploying Java requires that everything has to be configured _exactly_ right, and write once run anywhere turns into write once debug everywhere.

fauigerzigerk 10y ago
IntelliJ or maven can at least create a fat runnable jar that includes all dependencies. So once you have a JVM on the target machine that jar is all you need to deploy. But I agree with you that an entirely static compilation target that includes the JVM and excludes everything that isn't necessary would be very desirable.
user5994461 10y ago
Other languages don't do much better once you start to have a few dependencies.
twic 10y ago
That's been around since 2014: https://docs.oracle.com/javase/8/docs/technotes/guides/deploy/self-contained-packaging.html https://docs.oracle.com/javase/8/docs/technotes/guides/deplo...
pjmlp 10y ago
> Java -> static exe/elf compiler (sort of like Go) The ones that died where the open source ones, most commercial JVMs do support AOT compilation since the early 2000's.