Live data from Hacker News

What Future Java Might Look Like

blog.codefx.org

71–80 of 105 posts

Re: What Future Java Might Look Like

#71
post #20

Earlier quoted context omitted.

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.

This is going to happen anyway.

Re: What Future Java Might Look Like

#72
post #50

Earlier quoted context omitted.

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.

Who said anything about dropping the VM or infrastructure? JVM is awesome. Java isn't.

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.

Re: What Future Java Might Look Like

#73

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/obje…

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.

Re: What Future Java Might Look Like

#74
post #19
post #7

Earlier 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'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.

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.

Re: What Future Java Might Look Like

#75
post #50

Earlier quoted context omitted.

Who said anything about dropping the VM or infrastructure? JVM is awesome. Java isn't.

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 tha…

> Java is more optimized performance wise than Scala and Kotlin and performance is important not just cool syntax.

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.

Re: What Future Java Might Look Like

#76

Earlier quoted context omitted.

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…

> 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).

Re: What Future Java Might Look Like

#77
post #74
post #19

Earlier quoted context omitted.

Is anyone actually using Kotlin outside jetbrains? Seems like it doesn't have much mindshare or any high profile projects using it.

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…

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.

Re: What Future Java Might Look Like

#78
post #20
post #16

Earlier 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.

> 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.

Re: What Future Java Might Look Like

#79
post #75

Earlier quoted context omitted.

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 tha…

> Java is more optimized performance wise than Scala and Kotlin and performance is important not just cool syntax. 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.

> 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)?

Re: What Future Java Might Look Like

#80
post #46

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.

> 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.

Post reply on HN