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

New language features since Java 8 to 17

advancedweb.hu

Post reply on HN
Print view View original

201–210 of 358 posts

Re: New language features since Java 8 to 17

#201

Post by seanmcdirmid »

mhh__ wrote: post #187
cyberbanjo wrote: post #159

Earlier quoted context omitted.

What would do notation add to Java?

Not specifically for Java but I have found myself wanting do-notation in non-functional languages so that I can basically write a very expressive library while also forcing users of that library to go down my road i.e. I hacked around it in the end as I didn't have a do-like abstraction but I had (in-effect, it wasn't quite a DSL) written a DSL that represented certain constructs just fine using operator overloading,…

Can you do something similar in Kotlin using this function scopes (that let you change the meaning of this in a lambda)? I’ve found those ok at defining EDSLs.

Re: New language features since Java 8 to 17

#202

Post by filoeleven »

JulianMorrison wrote: post #178
filoeleven wrote: post #111

Earlier quoted context omitted.

It’s not really copy-on-write though. That implies greater systemic performance losses than what Clojure provides, because it uses HAMTs (Hash Array Mapped Trie) internally. They enable much faster copies of immutable data than copy-on-write does. Your other points are good ones, I just don’t want people to be put off by copy-on-write performance assumptions. You take a ~50% performance hit from choosing Clojure over…

There was an issue I ran into with regular Java, JDOM 2 Documents, One thing saves a reference, the other thing snips a piece out to use in the response... oops, the first reference points to a snipped Document. Worse, that behaviour changed without interface changes between JDOM 1 and 2, and it mattered to the code I was editing. Easy enough to fix with a ".clone()" but still... it's not just parallelisation. Immuta…

Huh. I don’t know enough about JDOM to ask more than stupid questions, especially when we’re talking about two different languages on the same VM. So please bear with me or ignore at your leisure.

This all happened within Clojure? Their Java interop is reportedly good, but the docs also say you lose the immutability safeguards when you interact directly with Java classes. I dunno if “regular Java” means literally that, or while working with Java inside of Clojure. Which is it?

“One thing saves a reference” - if this was interop, did you convert that to a Clojure data structure as early as possible, and do no more interop after that until a final return?

I’ve avoided deep interop so far, so I don’t understand the mechanics of the interface, and I’m not clear if your response is about that.

Re: New language features since Java 8 to 17

#203

Post by karmakaze »

dunefox wrote: post #169
karmakaze wrote: post #161

Earlier quoted context omitted.

Great (unintended) straw-man comment. These are all minor reasons in the context of an introduction to developing software. Yes, there's some initial setup, but once that's done and you're learning how programs are constructed with classes, objects, methods and where static typing can help you, they're all the important things that will carry you well into a career.

Just because you can have a career in Java despite the disadvantages does not mean that they're not disadvantages that most other languages don't have.

Wasn't suggesting that one make a career of Java, but rather apply the knowledge learned in using a statically-typed, compiled language with OO and functional bits. Hopefully advancing to using languages with type-inference as one progresses.

Re: New language features since Java 8 to 17

#204

Post by xpressvideoz »

pron wrote: post #160
66fm472tjy7 wrote: post #59

Earlier quoted context omitted.

I don't think this is going to happen with Brian Goetz as language architect. He refuses to add many features that would address everyday pain points such as: * null safe navigation operator * properties * mutable records * a way to ignore checked exceptions (or at least having the stream API take functional interfaces that can throw exceptions) * adding functional methods like .filter()/.map() directly to collection…

Thank god for that, because those feature are either horrible on their own or superseded by better ones. You're getting a car and complaining for not getting faster horses. The features Java has adopted -- specifically, algebraic data types and pattern-matching -- will lead to better development practices, rather than making it easier to work with inferior ones.

I can understand the hate behind null-safe operators, but why properties? Why is bad to have an ability to "upgrade" a member variable into a property, without breaking any existing contracts? I really hate that I need to resort to using setters and getters in Java because those are bad for searchability.

Re: New language features since Java 8 to 17

#205

Post by armchairhacker »

cageface wrote: post #2

Unfortunately it looks like Java is going to evolve enough to take the wind out of the sails of Kotlin and Scala for most dev shops. I guess the positive take is that those improvements might not have happened without the efforts to develop better JVM languages.

Kotlin is still way ahead of Java with IMO essential features like:

- Explicit null

- Extension methods

- Getters/setters which use property syntax

- == instead of Object.equals confusion

Also Kotlin's this-scoping and delegated properties, while they take a while to get used to, can be incredibly useful. They make it possible for to write typesafe DSLs like kotlin-html.

Moreover, Kotlin is usually very easy to integrate with existing Java projects. Setting up Kotlin in Gradle is just adding a plugin, and Kotlin automatically imports and exports java code. And it runs on the JVM so it will support most platforms that also support Java. And one of the top Java IDEs and contributors (JetBrains) maintains and prioritizes Kotlin.

Re: New language features since Java 8 to 17

#206

Post by mhh__ »

seanmcdirmid wrote: post #201
mhh__ wrote: post #187

Earlier quoted context omitted.

Not specifically for Java but I have found myself wanting do-notation in non-functional languages so that I can basically write a very expressive library while also forcing users of that library to go down my road i.e. I hacked around it in the end as I didn't have a do-like abstraction but I had (in-effect, it wasn't quite a DSL) written a DSL that represented certain constructs just fine using operator overloading,…

Can you do something similar in Kotlin using this function scopes (that let you change the meaning of this in a lambda)? I’ve found those ok at defining EDSLs.

I've only ever done a hello world in Kotlin I'm afraid.

Re: New language features since Java 8 to 17

#207

Post by [deleted] »

JulianMorrison wrote: post #180
xxs wrote: post #48

Earlier quoted context omitted.

A friendly advice: dont be afraid to use public final immutable fields and omit the getters (and setters since you cant have them w/ finals).

I do. It bothers me this wasn't the Java Way from day one. What is with getters and setters - who subclasses and substitutes the implementation of their data carrier objects?

[deleted]

Re: New language features since Java 8 to 17

#208

Post by xxs »

JulianMorrison wrote: post #180
xxs wrote: post #48

Earlier quoted context omitted.

A friendly advice: dont be afraid to use public final immutable fields and omit the getters (and setters since you cant have them w/ finals).

I do. It bothers me this wasn't the Java Way from day one. What is with getters and setters - who subclasses and substitutes the implementation of their data carrier objects?

Initially java didn't favor getter and setters. They came with java 1.1 and the attempt bean model (and reflection) to catch visual language designers. The core java packages java.lang; java.util; java.io they dont feature getter/setters, either. If you look at the ancient AWT, there were not getter/setters - they were introduced with 1.1 and the bean stuff, most of the existing methods were deprecated.

So in essence it was the original design, some book authors/design concept promoted it... Personally I have not written 'bean alike classes' for years.

Re: New language features since Java 8 to 17

#209

Post by nikeee »

66fm472tjy7 wrote: post #59
cageface wrote: post #2

Unfortunately it looks like Java is going to evolve enough to take the wind out of the sails of Kotlin and Scala for most dev shops. I guess the positive take is that those improvements might not have happened without the efforts to develop better JVM languages.

I don't think this is going to happen with Brian Goetz as language architect. He refuses to add many features that would address everyday pain points such as: * null safe navigation operator * properties * mutable records * a way to ignore checked exceptions (or at least having the stream API take functional interfaces that can throw exceptions) * adding functional methods like .filter()/.map() directly to collection…

IMHO safe navigation only makes sense when the compiler is able to reason about nullability, meaning nullability is rooted in the type system. That's the case for Kotlin and not for Java.

Otherwise, you've got a high risk of developers inserting a ? to fix a bug, which only fixes the symptoms.

As of now, Optional#map seems to be the way to go.

Re: New language features since Java 8 to 17

#210

Post by hashmash »

rdpintqogeogsaa wrote: post #15

I've been bitten by bitwise operations on signed integers a few too many times. Are there any plans on having normal unsigned integer types yet?

I was griping about Java's lack of unsigned types for over 20 years until it dawned on me why mixing signed and unsigned types together in the same language is a bad idea. Consider when one method returns an unsigned type, but another one accepts a signed type. Signed and unsigned types cannot be safely casted to each other without loss of information, and that causes bigger issues.

The only times the lack of unsigned types causes issues is when doing low-level binary encoding, and most programmers steer clear of that anyhow. I think it's a good tradeoff to make things simpler for most, but a bit more difficult for few.

Post reply on HN