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.
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)
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-convert.... There are several companies listed on the Kotlin website as well.
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.
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.
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.
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.
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.
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.
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). 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.
Which post # in the discussion did you have in mind? There's some misdirections in that thread with ideas that didn't survive the javap test (which I think rather makes my point). I may do Scala again in the future and would like to know how to avoid this (without factory methods as I mentioned).
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.
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;
private final int numer;
private final int denom;
public int numer();
public int denom();
private int gcd(int, int);
public Rational(int, int);
}
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.
> 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.
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.
...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!
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...
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.
We are going OT here, but one last comment in this thread to clarify what I meant.
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.. :) )
>Putting a comment saying just "Just another vile article", without any thoughts about why it is vile
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) :)
The guidelines aren't there to help you get upvotes. Moreover, it says nothing about how / why to downvote, much less encourage people to do so. The fact that it's ok to downvote when disagreeing is something that pg once wrote in a comment (don't have the link).
A pg dictum is a de facto "guideline" here. That's pretty well understood. Not sure why you think it's valuable to try parsing a distinction.
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.
> A pg dictum is a de facto "guideline" here. That's pretty well understood. Not sure why you think it's valuable to try parsing a distinction.
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).
>it's safe to say only what's written in the guidelines is supposed to be common knowledge
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.
Sounds great, really, but it didn't work once when I tried to put up well-reasoned arguments. Why would I follow guidelines any further when everyone seems to interpret them as they well damn please? So, basically 'upvote' is for the popular opinion, and it doesn't matter if it's well reasoned or not. And the 'downvote' is for preventing flame wars by suppressing the unpopular opinion, no matter if well reasoned or not? I'm very confused.
> I'm getting downvoted for having issued an opinion which opposes that of the others? This sounds so horribly wrong to me...
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".
I think Kotlin makes a newer version of the same mistakes Java made. Let's see how it looks in 5 years' time. (I'd say Ceylon is the actually good JVM language)
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.
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?
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.
I'd say about 5 years after their replacement becomes production-ready. (Having started switching to Scala 6 years ago I'd say that's about now for Java).
It's plenty better. You're saying on the source code level that it's not designed to be run by anything but an implementation of that specification version.
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 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.
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.
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.
Well that's just your opinion, I think java is pretty nice with Java8.
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.
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.
If we take Scala for example that's only true if you write Java-like Scala code and what's the point of that?
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.
Kotlin solves what Scala didn't. Great Java interop, first class IDE support, easier to get into. Whichever way you look at it Kotlin code is nicer than Java, even if written Java-like.
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.
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.
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.
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
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.
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.
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...)
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.
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
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.
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.
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.
104 comments
[ 5.5 ms ] story [ 187 ms ] threadhttp://www.dcs.ed.ac.uk/home/mlj/index.html
(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.
- 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)
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.
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.
> 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.
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".
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.
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.
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)
- 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.
- Data classes: https://kotlinlang.org/docs/reference/data-classes.html - Type inference: 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... - Destructuring: https://kotlinlang.org/docs/reference/multi-declarations.htm...
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.
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.