Live data from Hacker News

Moving Java Forward Faster

mreinhold.org

21–30 of 84 posts

Re: Moving Java Forward Faster

#21

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.

[deleted]

Re: Moving Java Forward Faster

#23
post #15

Earlier quoted context omitted.

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?

I'm guessing they work on a team, and other members of the team are using them.

Re: Moving Java Forward Faster

#24

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

It will mess up sorting. I agree with the suggestion. There really is no good reason why they wouldn't use yyyy.

Re: Moving Java Forward Faster

#25

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

You think that's funny but there is a good chance this will happen.

Re: Moving Java Forward Faster

#26
This is a major change:

"After JDK 9 we'll open-source the commercial features in order to make the OpenJDK builds more attractive to developers and to reduce the differences between those builds " http://mail.openjdk.java.net/pipermail/discuss/2017-Septembe...

Java Flight Recorder will be open source.

Re: Moving Java Forward Faster

#27
post #20

Earlier quoted context omitted.

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.

Not really; FP and OOP are dissimilar in their approach to mutable state and it's management, for instance. You can come up with a synthesis (or probably many different syntheses) of ideas from the two styles to make a style blending inspiration from each, but they aren't directly compatible, and most direct combinations mhave tension between the two styles, or directly subordinate one to the other, for that reason.

Re: Moving Java Forward Faster

#28

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.

Please explain how "I don't have to init an ArrayList and add to it manually" is such a heaven-forfend perversion of that traditional, solid language.

Re: Moving Java Forward Faster

#29
post #22

It'd be nice, but being an Android guy, I'd see zero benefit, as Google has no good way to push out updates to their VM.

Maybe Google should use openJDK instead of using their own proprietary version of Java.

No one benefits of fragmentation.

Re: Moving Java Forward Faster

#30
post #15

Earlier quoted context omitted.

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?

http://jimplush.com/talk/2015/12/19/moving-a-team-from-scala...
Post reply on HN