What Future Java Might Look Like • Hacker News Board

Re: What Future Java Might Look Like

#61

Post by unclebucknasty » Wed, Dec 07, 2016, 7:14 PM UTC

rootlocus wrote: post #53

unclebucknasty wrote: post #37

Earlier quoted context omitted.

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

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.

Re: What Future Java Might Look Like

#62

Post by overgard » Wed, Dec 07, 2016, 7:25 PM UTC

matrix wrote: post #26

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…

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

Re: What Future Java Might Look Like

#63

Post by nradov » Wed, Dec 07, 2016, 7:30 PM UTC

Roboprog wrote: post #41

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…

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.

Re: What Future Java Might Look Like

#64

Post by twic » Wed, Dec 07, 2016, 7:32 PM UTC

dlandis wrote: post #23

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

What features or changes would make the JVM more amenable to other, non-Java languages?

Re: What Future Java Might Look Like

#65

Post by twic » Wed, Dec 07, 2016, 7:36 PM UTC

Yhippa wrote: post #27

Roboprog wrote: post #21

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

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.

Re: What Future Java Might Look Like

#66

Post by twic » Wed, Dec 07, 2016, 7:43 PM UTC

cbdfghh wrote: 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.

That's been around since 2014:

https://docs.oracle.com/javase/8/docs/technotes/guides/deplo...

Re: What Future Java Might Look Like

#67

Post by xaduha » Wed, Dec 07, 2016, 7:43 PM UTC

nradov wrote: post #60

xaduha wrote: post #49

Earlier quoted context omitted.

Some languages have official versions than you need to declare right at the start. As in specification version, not implementation versions.

I'm not convinced that's any better than specifying the language version as a compiler command line argument.

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.

Re: What Future Java Might Look Like

#68

Post by overgard » Wed, Dec 07, 2016, 7:46 PM UTC

Roboprog wrote: post #41

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

Re: What Future Java Might Look Like

#69

Post by twic » Wed, Dec 07, 2016, 7:46 PM UTC

estefan wrote: post #19

bdavisx wrote: 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 asked my hipster Android developer friend (who doesn't work for JetBrains) and he said:

"two apps in the Play Store and one of them [also] has an API gateway written in Kotlin"

Re: What Future Java Might Look Like

#70

Post by overgard » Wed, Dec 07, 2016, 7:48 PM UTC

tormeh wrote: post #12

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.

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.