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.
What Future Java Might Look Like
71–80 of 105 posts
Re: What Future Java Might Look Like
#72Earlier 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.
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
#73To 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
Re: What Future Java Might Look Like
#74Earlier 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.
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
#75Earlier 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…
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
#76Earlier 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…
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
#77Earlier 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…
Re: What Future Java Might Look Like
#78Earlier 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.
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
#79Earlier 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.
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
#80What 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.
The ones that died where the open source ones, most commercial JVMs do support AOT compilation since the early 2000's.