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

Java 27

mail.openjdk.org

Post reply on HN
Print view View original

341–350 of 424 posts

Re: Java 27

#341

Post by tpoacher »

liampulles wrote: post #285
liampulles wrote: post #283

Earlier quoted context omitted.

I have a strong belief (mostly borne out by my years as Java dev) that the larger the possibility space of a language (and its ecosystem) the more room there is for inappropriate use and unclear code. Add time and an assortment of rolling devs of mixed ability level, and crap mounts faster then a "simpler" language. Let me be clear: Do I think it is possible to write good, clear, performant code in Java? Of course -…

Also - and this is very subjective - I find developers who have similarly low view of software development and high view of simple languages, to be very good team mates. We can laugh at the realities and move on pragmatically.

I see. I tend to agree in principle. I felt this with julia for example and it put me off a bit even though I was very keen on it at first

In the specific case of java however I don't think this applies much; the vast majority of improvements are aimed at under the hood optimisations rather than syntax. And I feel that any changes in syntax have been quite incremental, intuitive, and reasonable.

AND they stay around as preview features forever, so this may inflate the perception of features entering the language, when in fact it's the same one feature being mildly iterated on.

E.g. the main syntactical change in this version seems to be the use of primitives in switch statements, which was already discussed for a while, and is itself a meaningful change brought about by the introduction of switch expressions.

Re: Java 27

#342

Post by okeuro49 »

jonenst wrote: post #248
pron wrote: post #86

Earlier quoted context omitted.

The Java language and runtime have been co-designed as a unified platform for many years now. Virtually every significant feature has language, library, and VM people working on it, and we often don't even know when we start how much of the feature would be in the language, library, or VM. Consequently, there is no "language version" or a "runtime version". There's only a platform version, which is defined in a singl…

I wish there was a canonical write up on the governance of "java" and its history, it has changed a lot over the years (not just once I guess) and has a lot of fine prints. I find it hard to understand the hidden reasons and behind-the-scenes conflicts/compromises. There could probably be a whole book about this I guess.

Read the small book by O'Reilly "Java the legend".

Re: Java 27

#343

Post by samus »

ivan_gammel wrote: post #128
gentlewater wrote: post #64

Earlier quoted context omitted.

It’s still missing null safety, right? Which means it’s still a hard no for me.

It is really not a big deal nowadays, the problem of the same scale as having index out of bounds error (no language has good defence against this, yet it is not a catastrophe).

The problem with array out of bounds is that you'd need to reason about arithmetic expressions over natural numbers. However, in general that's a very thorny problem since one runs squarely into [Gödel's incompleteness theorems](https://en.wikipedia.org/wiki/G%C3%B6del%27s_incompleteness_...). Working around it requires painful restrictions or cause uncertainty over whether the compiler will apply certain optimizations.

Re: Java 27

#344

Post by gf000 »

unscaled wrote: post #308
dorkypunk wrote: post #123

Earlier quoted context omitted.

Most organizations that use Java tend to be pretty conservative with their technology picks and nowadays with newer Java versions the only real gap with Kotlin is null-safety which is supposed to also come to Java at some point. There is also an organization culture component most of the time, one our engineers actually proposed to use Kotlin for one of the new projects but it got rejected because "We are a Java shop…

> Most organizations that use Java tend to be pretty conservative with their technology picks That part i s true. > with newer Java versions the only real gap with Kotlin is null-safety But that part isn't. Kotlin has: - Structured Concurrency: Coming to Java sometime in the future, but it's been in preview for very long now. - Standalone functions that don't have to live in classes - Properties - Property delegation…

> Structured Concurrency

I think the two languages mean slightly different things here. In any case, Java's model is so much more simpler that I don't think they are honestly comparable. In kotlin's case you have to be very on top of your game to have a chance of correctly using it - there is concurrency, parallelism, exception handling all combined into a single abstraction in a non-native way - so your stack traces will be useless/swallowed etc on incorrect usage. Of course the usual caveat applies, just use java's abstraction if you need that.

> Standalone function

Don't really see the benefit, if anything it creates place for style disagreements. A SomethingUtil class was just fine (and findable).

> Properties

Difficult topic with both cons and pros.

> Data classes

Exactly because they are "more powerful" they are strictly worse. A design element is just as much about what it is as it isn't. Copy is good though.

> Delegation

Used a couple of times, but it's not the full blown thing (see manifold)

> Extension method

I will be honest, I really dislike these. They can occasionally help a bit with some DSL, but for the most part they just make code very hard to read. I much prefer a normal static method instead.

> Context parameters

One of the few useful syntactic sugar.

> Operator overloading

Argued to death already :)

> Inline function

Feels more like a hack to support some of these extra features than something you would want to use yourself

> Block syntax

For the rare DSL usecase it's useful. Everywhere else I really dislike it and the accompanying coding style. These .also and similar implicit receiver thingies are just straight up evil.

All in all, there are a few things that are very elegant in kotlin, but I feel they went the c++ c# way of over abstracting just to have a long feature list.

Re: Java 27

#345

Post by samus »

PaulHoule wrote: post #84
voidfunc wrote: post #62

Earlier quoted context omitted.

Checked exceptions are controversial mostly because a lot of the core APIs use them in places where it's pointless to check, like IOException. Using them correctly can be great tho.

Mostly I think they are a mistake, like in ordinary application code instead of catching close to the throw you want to do a lot of try { ... } finally() { ... } to make sure things get torn down that have to be torn down and let the exception go to the top of the unit of work and probably to whatever drives the work unit. You can probably do better than logging the raw exception and moving on to the next work unit b…

> avoid other kinds of "sloppy" coding encouraged by checked exception such as catching exceptions locally without doing the right thing globally.

That's a code style and code review issue; each project has so set standards regarding how errors are dealt with and enforce them throughput the codebase.

Re: Java 27

#346

Post by gf000 »

eklavya wrote: post #41
ndriscoll wrote: post #30

Earlier quoted context omitted.

Golang gives you none of nice features of a modern language while being about the same performance tier as Scala or Java, so there's basically no reason not to use Scala.

I ported a moderate sized java project to golang. Test suite runs order of magnitude faster now. There isn't much change in terms of the architecture. Pretty much the same algos and data structures. The whole dev tooling runs on a 16 gb mac without swapping now. I used vs code for both

So you compare the build tool of A and B on a short-lived job type where java is knowingly not its strongest? How is that a meaningful comparison?

Re: Java 27

#347

Post by samus »

cavoirom wrote: post #110
BoppreH wrote: post #44

Earlier quoted context omitted.

> there is nearly no magic I agree with the rest, but there's definitely a lot of magic in Java. This is from both what features the languages makes available (many) and how the community uses them (often). I've had so many hard-to-debug issues in Java over the years due to reflection, annotations, and bytecode manipulation shenanigans. And another positive point for Java: checked exceptions. It's verbose, but knowin…

I agree, to name a few: - Annotation processing: if you know Lombok, MapStruct. - Class loader. - Reflection. - Garbage collection.

Annotation processors were actually carefully designed to prohibit what Lombok does. Lombok hacks into javac and manipulates the AST. Unsurprisingly, there is breakage with every Java release and with other tools that work similarly, like Google Error Prone, which gets a pass since it's read-only and the build will still work if you turn it off.

Class loader and reflection shenanigans can be shut down with the module system.

Garbage collection matters when you stress the JVM to its limits. Don't do that.

Re: Java 27

#348

Post by samus »

speed_spread wrote: post #253
cavoirom wrote: post #110

Earlier quoted context omitted.

I agree, to name a few: - Annotation processing: if you know Lombok, MapStruct. - Class loader. - Reflection. - Garbage collection.

You forgot runtime agents! IMO compile-time annotation processors such as Lombok and MapStruct are far from the most magic part of Java. They're straightforward code generators. Their impacts is localized to where they get applied and you can actually see the code that's generated. They're very good for diminishing boilerplate. They're no worse than Rust's very standard #[derive(xyz)] proc macros. Having the code bei…

Dynamic runtime agents are deprecated functionality. In a few releases agents have to be specified at JVM startup. Mockito (I bet it's the most common user of that feature) and current JVMs already warn about it.

Another issue with Lombok is that it requires IDEs and other tools to be aware of it. Missing integration with other annotation processors only causes "definition of external element not found"-style errors.

Re: Java 27

#349

Post by gf000 »

liampulles wrote: post #283
tpoacher wrote: post #188

Earlier quoted context omitted.

In the absence of a sarcasm tag, would you care to explain your reasoning?

I have a strong belief (mostly borne out by my years as Java dev) that the larger the possibility space of a language (and its ecosystem) the more room there is for inappropriate use and unclear code. Add time and an assortment of rolling devs of mixed ability level, and crap mounts faster then a "simpler" language. Let me be clear: Do I think it is possible to write good, clear, performant code in Java? Of course -…

Java is a very small language, all things considered. Compare to kotlin, c#, rust it's absolutely tiny

Re: Java 27

#350

Post by samus »

cavoirom wrote: post #122
ulimn wrote: post #76

Earlier quoted context omitted.

Not just the time, but the environment, the OS as well. Where you can run JVM, there's a pretty good chance you can run your app.

If your app requires a specific JDK version and your OS wont support, you can run that JDK version in a modern JVM: https://www.graalvm.org/latest/reference-manual/espresso/

That's important since this capability has been removed from OpenJDK a long time ago.
Post reply on HN