What Future Java Might Look Like
blog.codefx.org
blog.codefx.org
- 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...
But the fact that those features might have existed in Haskell or Algol68 or whatever is largely irrelevant since we're taking about Java.
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.
https://medium.com/@octskyward/graal-truffle-134d8f28fb69#.h... https://en.wikipedia.org/wiki/Graal_(compiler)
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).
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.
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...)
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.
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.
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.
Yes, I get to use mature libraries for everything without having to spend development time redoing them, and can focus on business code instead.
Imagine you updated your pom file and bunch of stuff stopped working. If it's easy enough to fix you do it, if not you might just revert pom changes and stay with older version of the language, module or whatever. That wouldn't happen with versioned specification languages.
> I see no particular advantage in specifying the language version in each and every file
You obviously stuck with this mindset and not thinking about it hard enough.
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.
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.
When you see someone say let's kill Java what does that mean for the JVM? Because Oracle will not say ya cool let's just focus on other languages running on the JVM like kotlin and Scala and drop java all together.
Java is more optimized performance wise than Scala and Kotlin and performance is important not just cool syntax.
I think it's good that we have other implementations that allows the JVM to be pushed further and make Java compete with them, it's a win-win for the languages that run on the JVM and Java itself.
Not true. You're running bytecode, not Java. Compiled JVM languages benefit from JVM optimizations all the same.
No one will actually 'kill' Java, it's about mindset of the users and companies. Kill Java = Give another JVM language a try.
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)?
All in all I'm for interoperation. "And", not "or". No one is forcing you to rewrite existing Java code.
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.
Once you go deep with Scala magic it goes downhill, but prob. 80% as fast.
I think Java and other JVM languages can co-exist nicely, depending on the task at hand, there is no "need" to kill anything, I wish you could mix and match code from different JVM languages easily.
That makes it easier to self select jobs and to recruit =)
A win win.
- 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.
https://docs.google.com/presentation/d/1XouaIJ5d3CaqEW87Fpup...
It's a nice tool.
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.
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.
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)
> 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.
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). 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.
The discussion you linked to shows you how.
If you mean Paul P/extempore's self described "if you can handle a little perversion" method then - "no thanks", that's pretty bad, I'd rather just do factories.
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)
}
$ 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;
private final int numer;
private final int denom;
public int numer();
public int denom();
private int gcd(int, int);
public Rational(int, int);
}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.
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.
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.
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.
https://docs.oracle.com/javase/8/docs/technotes/guides/deplo...
The ones that died where the open source ones, most commercial JVMs do support AOT compilation since the early 2000's.
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.
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.
(since the newer Android SDK is based on Intellij, I guess that's not too surprising, but still useful)
"two apps in the Play Store and one of them [also] has an API gateway written in Kotlin"
edit: The list of companies from the Kotlin website: 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.
And right now the only one I can think of is j2objc. Java should absolutely die.
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!
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.
Not strictly. The guidelines encourage people to start conversation with reasoning, but also encourage people to downvote for disagreeing.
So, there's some dissonance in there as it says, effectively: "make well-reasoned arguments with which everyone can agree."
Putting a comment saying just "Just another vile article", without any thoughts about why it is vile, is just completely against the guidelines (from the points mentioned in my previous comment). Even if you agree with its content or not.
Also, I do not believe the guidelines encourage people to down-vote for disagreeing (or at-least from my understanding). It is just in our nature and the consequence of the fact, that there is a down-vote button. (I have never tried it, still under 500 karma.. :) )
I agree that it doesn't add to the discussion, which might be a good reason for downvoting (i.e. as a form of "quality control"). OTOH, if you happen to agree with the statement, then the ethos is that it's cool to upvote it on that basis alone. Yet, it still adds no more to the discussion.
My overall point is that agreement/disagreement as a basis for surfacing (or submerging) people's comments/ideas is a poor choice in either direction, if it's stimulating, challenging discussion we want.
>I have never tried it, still under 500 karma..
Meh. It's overrated. Can't even remember the last time I downvoted a comment (as you might've guessed) :)
I don't think anyone is suggesting that guidelines are designed to help people get upvotes. In fact, my comment wasn't about upvotes at all, but how encouragement to downvote for disagreement undermines constructive discussion and contradicts the GP's guideline-citing assertion that well-constructed arguments are valued most.
Perhaps. However, since not everyone has read every comment pg ever made, it's safe to say only what's written in the guidelines is supposed to be common knowledge and easily available for reference.
> effectively: "make well-reasoned arguments with which everyone can agree."
They don't say "make arguments with which everyone can agree". Not effectively or otherwise, that would stupid. They say (in your opinion) that you are encouraged to downvote what you don't agree with (I would substitute encouraged with allowed, but I can't make a reference to an authoritative source because it's not actually in the guidelines). It was your own deduction that you should make comments everyone agrees with (in order to avoid being downvoted / get more upvotes).
And, yet, you immediately trotted out the dictum on this thread, as have so many before you. I mean, c'mon. Stop it. It's common knowledge around here.
>They don't say "make arguments with which everyone can agree"
Greenlighting the use of downvotes to express disagreement does exactly this. Not even sure why you think there's an argument to be made otherwise. If you want your comment to be read, instead of literally faded into oblivion as the result of downvotes, then you'd better be sure it's somewhat in agreement with the community.
>It was your own deduction...
Sure was, and it didn't take much effort to deduce it. In fact, I would say no effort. It was just lying there to trip over. OTOH, the entirety of your argument seems to rest on the willful denial of the obvious.
I went through your comment list out of curiosity, and I have to say, your arguments weren't well-reasoned at all.
> Why would I follow guidelines any further when everyone seems to interpret them as they well damn please?
Why do you care about your karma?
You haven't issued an opinion. Moreover, what people mean with their downvotes is subjective. You're not on trial, and your karma doesn't affect your life in any way, so I don't see how this is "so horribly wrong".