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.
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).
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
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...)
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
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.
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.
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?
Yes let's just throw away 20 years of VM research and optimizations.
Dropping some backwards compatibility which impacts performance the most is sensible and I wish java would do some of that but this is a long way from killing java.
Java runs the world, you will have to work very hard and long to produce the same Ecosystem around something else.
That's not really true -- for instance, C++ 11 is a lot more pleasant than C++ 98 even though it's just a more complicated version of that. A lot of bad ideas tend to fall into disuse, even if they're not technically gone.
> 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.
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.
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.
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.
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.
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.
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.
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.
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.
[+] [-] shadowfacts|9 years ago|reply
- 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-declarations.htm...
[+] [-] cle|9 years ago|reply
[+] [-] dlandis|9 years ago|reply
[+] [-] pjmlp|9 years ago|reply
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.
[+] [-] mdellabitta|9 years ago|reply
https://medium.com/@octskyward/graal-truffle-134d8f28fb69#.h... https://en.wikipedia.org/wiki/Graal_(compiler)
[+] [-] twic|9 years ago|reply
[+] [-] matrix|9 years ago|reply
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|9 years ago|reply
[+] [-] overgard|9 years ago|reply
[+] [-] Roboprog|9 years ago|reply
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...)
[+] [-] overgard|9 years ago|reply
[+] [-] nradov|9 years ago|reply
[+] [-] tormeh|9 years ago|reply
[+] [-] nradov|9 years ago|reply
[+] [-] TheGuyWhoCodes|9 years ago|reply
Dropping some backwards compatibility which impacts performance the most is sensible and I wish java would do some of that but this is a long way from killing java.
Java runs the world, you will have to work very hard and long to produce the same Ecosystem around something else.
[+] [-] wtetzner|9 years ago|reply
[+] [-] dkersten|9 years ago|reply
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.
[+] [-] overgard|9 years ago|reply
[+] [-] user5994461|9 years ago|reply
That makes it easier to self select jobs and to recruit =)
A win win.
[+] [-] RyanHamilton|9 years ago|reply
- Data objects https://projectlombok.org/features/Data.html That generate toString, getters, setters etc as required
- Val for local variables 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/ a little program I made to make running java scripts/snippets extremely easy.
[+] [-] Roboprog|9 years ago|reply
https://docs.google.com/presentation/d/1XouaIJ5d3CaqEW87Fpup...
It's a nice tool.
[+] [-] ygra|9 years ago|reply
> 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.
[+] [-] michaelcampbell|9 years ago|reply
[+] [-] tomp|9 years ago|reply
[+] [-] cbdfghh|9 years ago|reply
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.
[+] [-] twic|9 years ago|reply
https://docs.oracle.com/javase/8/docs/technotes/guides/deplo...
[+] [-] fauigerzigerk|9 years ago|reply
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.
[+] [-] pjmlp|9 years ago|reply
The ones that died where the open source ones, most commercial JVMs do support AOT compilation since the early 2000's.
[+] [-] user5994461|9 years ago|reply
[+] [-] mikeevans|9 years ago|reply
[+] [-] hashhar|9 years ago|reply
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.
[+] [-] st3v3r|9 years ago|reply
[+] [-] pjmlp|9 years ago|reply
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.
[+] [-] geooooooooobox|9 years ago|reply
[+] [-] joncampbelldev|9 years ago|reply
[+] [-] unknown|9 years ago|reply
[deleted]
[+] [-] shadowfacts|9 years ago|reply
[deleted]
[+] [-] dschuetz|9 years ago|reply
[+] [-] mixedCase|9 years ago|reply
And right now the only one I can think of is j2objc. Java should absolutely die.