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.
Moving Java Forward Faster
21–30 of 84 posts
Re: Moving Java Forward Faster
#22Re: Moving Java Forward Faster
#23Earlier 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?
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.
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 :)
Re: Moving Java Forward Faster
#26"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
#27Earlier 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.
Re: Moving Java Forward Faster
#28Earlier 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.
Re: Moving Java Forward Faster
#29It'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.
No one benefits of fragmentation.
Re: Moving Java Forward Faster
#30Earlier 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?