Earlier quoted context omitted.
And Kotlin as well, with java interop considered a top priority.
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
what did you think of frege?
What Future Java Might Look Like
31–40 of 105 posts
Re: What Future Java Might Look Like
#32Earlier quoted context omitted.
FWIW, I did a presentation on Lombok at the local Java user group recently: https://docs.google.com/presentation/d/1XouaIJ5d3CaqEW87Fpup... It's a nice tool.
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?
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.
Re: What Future Java Might Look Like
#33Earlier quoted context omitted.
And Kotlin as well, with java interop considered a top priority.
Is anyone actually using Kotlin outside jetbrains? Seems like it doesn't have much mindshare or any high profile projects using it.
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)
Re: What Future Java Might Look Like
#34I 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 w…
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.
Re: What Future Java Might Look Like
#35Dead, finally? ..Ow, damn, false alarm! Just another vile article :(
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.
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)
Re: What Future Java Might Look Like
#36I 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 w…
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.
Welcome to Sacramento :-(
Re: What Future Java Might Look Like
#37Earlier quoted context omitted.
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…
>It is because you do not comment according to the guidelines, which encourage people to start conversation with reasoning
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."
Re: What Future Java Might Look Like
#38Earlier quoted context omitted.
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.
And another generation of programmers wastes time rewriting the same stuff in the language du jour.
Re: What Future Java Might Look Like
#39It'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.
Re: What Future Java Might Look Like
#40Earlier quoted context omitted.
FWIW, I did a presentation on Lombok at the local Java user group recently: https://docs.google.com/presentation/d/1XouaIJ5d3CaqEW87Fpup... It's a nice tool.
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?
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.