Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Moving Java Forward Faster

mreinhold.org

Post reply on HN
Print view View original

11–20 of 84 posts

Re: Moving Java Forward Faster

#11

Post by fauigerzigerk »

doodpants wrote: post #3

> To make it clear that these are time-based releases, and to make it easy to figure out the release date of any particular release, the version strings of feature releases will be of the form $YEAR.$MONTH. Thus next year’s March release will be 18.3, and the September long-term support release will be 18.9. Shouldn't those version numbers be 2018.3 and 2018.9? Have we learned nothing from the Y2K bug?

Imagine the shock when our descendents wake up on Jan 1 2118 and all their systems are accidentially running on a 100 year old JVM :)

Re: Moving Java Forward Faster

#12

Post by tetha »

As I keep saying, more and smaller releases cause a constant, low amount of pain. That's good, because you avoid the teeth-yanking bullshit of deploying 6 month of care-free development to prod. And even though I hope the OpenJDK community develops more responsibly than my devs, but the point still stands given scaled time frames.

Re: Moving Java Forward Faster

#13

Post by organsnyder »

doodpants wrote: post #3

> To make it clear that these are time-based releases, and to make it easy to figure out the release date of any particular release, the version strings of feature releases will be of the form $YEAR.$MONTH. Thus next year’s March release will be 18.3, and the September long-term support release will be 18.9. Shouldn't those version numbers be 2018.3 and 2018.9? Have we learned nothing from the Y2K bug?

Only if the first number is constrained to two digits. The release from March of 2100 would be 100.3, which would work just fine.

Re: Moving Java Forward Faster

#14

Post by newforice »

callinyouin wrote: post #8
newforice wrote: post #6

As long as they stay away from the lambdas and FP trainwrecks that was 8.

I can't tell if you're being sarcastic, but I'm guessing you aren't. Anyway, from a full time Java developer's perspective, lambdas and the FP stuff added to Java 8 have sort of been a holy grail. Filtering with streams have single-handedly made my life as a developer measurably easier, but then again I'm a back-end web dev so it comes up a lot. If you're a Java developer, I'd strongly recommend going back and trying…

You seem to have jumped to the conclusion that I haven't tried the FP features. If I hadn't tried them, I wouldn't be criticizing them. If I wanted to work in FP style, I would choose an FP language; not encourage a traditional, solid language to be perverted to do something that is completely against the nature and design of that language.

Re: Moving Java Forward Faster

#15

Post by shock »

newforice wrote: post #14
callinyouin wrote: post #8

Earlier quoted context omitted.

I can't tell if you're being sarcastic, but I'm guessing you aren't. Anyway, from a full time Java developer's perspective, lambdas and the FP stuff added to Java 8 have sort of been a holy grail. Filtering with streams have single-handedly made my life as a developer measurably easier, but then again I'm a back-end web dev so it comes up a lot. If you're a Java developer, I'd strongly recommend going back and trying…

You seem to have jumped to the conclusion that I haven't tried the FP features. If I hadn't tried them, I wouldn't be criticizing them. If I wanted to work in FP style, I would choose an FP language; not encourage a traditional, solid language to be perverted to do something that is completely against the nature and design of that language.

Since lambdas and streams are optional, what is your critique of them?

Re: Moving Java Forward Faster

#16

Post by mreinhold »

virtualwhys wrote: post #10
EddieRingle wrote: post #5

I'm fully in support of defined, rolling release trains. 6 months is a good start considering where they're coming from. I feel like that's still slightly too long though, and is one of the things I wish the Go team would change. The Go team's argument is that it takes time to fully test features before being able to release them, which I understand, but that's the whole point behind a multiple release train model. B…

> Faster Java & JVM updates More likely faster updates will be to Java itself, while JVM enhancements will be limited to LTS. Pattern matching and data classes, for example, will arrive far sooner in Java than value types in the JVM.

No, JVM enhancements will not be limited to LTS. If anything it's best to merge them long before an LTS, so that they're well-baked in the LTS itself.

Re: Moving Java Forward Faster

#17

Post by virtualwhys »

mreinhold wrote: post #16
virtualwhys wrote: post #10

Earlier quoted context omitted.

> Faster Java & JVM updates More likely faster updates will be to Java itself, while JVM enhancements will be limited to LTS. Pattern matching and data classes, for example, will arrive far sooner in Java than value types in the JVM.

No, JVM enhancements will not be limited to LTS. If anything it's best to merge them long before an LTS, so that they're well-baked in the LTS itself.

My point is that "smaller" features like pattern matching and data classes will land in Java well before big ticket items like value types; not that JVM enhancements will be strictly limited to LTS.

Of course, you have the inside word: when are value types coming to the JVM? Hopefully by Java 10.

Re: Moving Java Forward Faster

#18

Post by aardvark179 »

virtualwhys wrote: post #17
mreinhold wrote: post #16

Earlier quoted context omitted.

No, JVM enhancements will not be limited to LTS. If anything it's best to merge them long before an LTS, so that they're well-baked in the LTS itself.

My point is that "smaller" features like pattern matching and data classes will land in Java well before big ticket items like value types; not that JVM enhancements will be strictly limited to LTS. Of course, you have the inside word: when are value types coming to the JVM? Hopefully by Java 10.

Minimal value types will arrive as an experimental feature at the VM level real soon now, language and library support will take a lot more work.

Re: Moving Java Forward Faster

#20

Post by jswizzy »

newforice wrote: post #14
callinyouin wrote: post #8

Earlier quoted context omitted.

I can't tell if you're being sarcastic, but I'm guessing you aren't. Anyway, from a full time Java developer's perspective, lambdas and the FP stuff added to Java 8 have sort of been a holy grail. Filtering with streams have single-handedly made my life as a developer measurably easier, but then again I'm a back-end web dev so it comes up a lot. If you're a Java developer, I'd strongly recommend going back and trying…

You seem to have jumped to the conclusion that I haven't tried the FP features. If I hadn't tried them, I wouldn't be criticizing them. If I wanted to work in FP style, I would choose an FP language; not encourage a traditional, solid language to be perverted to do something that is completely against the nature and design of that language.

FP and OOP are compatible styles. In fact, I would argue that FP is more object orientated than procedural code such as loops.
Post reply on HN