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

Java 18 / JDK 18: General Availability

mail.openjdk.java.net

Post reply on HN
Print view View original

231–240 of 304 posts

Re: Java 18 / JDK 18: General Availability

#231

Post by datavirtue »

kaba0 wrote: post #137
pfortuny wrote: post #37

Earlier quoted context omitted.

I do not know but apart from just vendor lock in, oracle might provide guarantees (maintenance?) that the other providers cannot.

There is no vendor lock-in, other than perhaps the logo, OpenJDK is the same as OracleJDK, since Oracle develops the former 90+%.

The Oracle JDK ships with capabilities not found in OpenJDK. Oracle ships webkit for instance--to parse/render HTML. OpenJDK does not. There also used to be a JavaScript engine, which I believe was deprecated unfortunately, and does not ship with OpenJDK.

Re: Java 18 / JDK 18: General Availability

#232

Post by gunnarmorling »

pjmlp wrote: post #164
mdaniel wrote: post #112

Earlier quoted context omitted.

That's actually why I prefer Azul's openjdk builds over adoptopenjdk or other distros: it's sane but not in contact with the Oracle swamp https://www.azul.com/downloads/?package=jdk#download-openjdk https://hub.docker.com/r/azul/zulu-openjdk

Majority of OpenJDK code is tainted with Oracle's paycheck swap.

I don't get that sentiment, at all. Why would you be complaining about Oracle sponsoring JDK development (the resources they put into it are tremendous), which you can benefit from absolutely for free, 100%, no strings attached whatsoever? Can you help me to understand the reasoning here, because it just doesn't make sense to me.

Re: Java 18 / JDK 18: General Availability

#233

Post by krzyk »

hu3 wrote: post #20
ajoberstar wrote: post #15

Earlier quoted context omitted.

Oracle's builds of Java are open source as well. The OpenJDK codebase is shared across all of the vendors that provide builds.

Thanks! So why would I pick Oracle's implementation?

Question is why would you pick any vendors implementation?

OpenJDK is reference one build from the source which is then taken by vendors and tweaked and built.

Re: Java 18 / JDK 18: General Availability

#234

Post by dfee »

matsemann wrote: post #85
dfee wrote: post #47

Earlier quoted context omitted.

Definitely an issue in 8. My hack is to call everything an `int`, write the statement, and go back and let IntelliJ handle the proper name, adding the import, etc. I understand though, that in more recent versions of Java this is taken care of for you.

Why not just write the statement and write `.var`? Like if you write myService.getSomething().var and press tab, it will autocomplete it to Something something = myService.getSomething()

wow. you just blew my mind. thank you.

Re: Java 18 / JDK 18: General Availability

#235

Post by dfee »

pritambarhate wrote: post #59
dfee wrote: post #40

Earlier quoted context omitted.

Great error handling? What does that mean? Checked exceptions seem cool at first, but are really just nonsense… as your only real way of dealing with this is: 1. Catch, log and rethrow, or 2. Wrap as a runtime exception (so you don’t have to change every method signature up to main()) Sure, there’s option 3: catch and handle… but this is used 1/50 times, and the ergonomics of (2) overwhelm the utility of this. BTW, v…

>> 1. Catch, log This is not as useless as it sounds. You can analyse the logs and find out why these exceptions are occurring. A lot of times these lead you to subtle bugs which you might not have noticed otherwise.

sure. or if using something like Vavr... catch a bunch of 'em all at once.

``` Try.success(foo. .map(...) .mapTry(...) .map(...) .mapTry(...) .onFailure(e -> LOGGER.warn("Failed %s", e) .get() ```

Re: Java 18 / JDK 18: General Availability

#236

Post by krzyk »

toyg wrote: post #97
th3iedkid wrote: post #17

IntelliJ is yet to catchup it seems https://www.jetbrains.com/help/idea/supported-java-versions....

I don't think they ever supported a JDK on the day of release, they don't seem to have any sort of inside-track that would allow them to fix bugs before then.

They don't need inside track, EA releases are available quite soon (and some JetBrains developers are also commiting to OpenJDK).

Re: Java 18 / JDK 18: General Availability

#237

Post by wiseowise »

manuelabeledo wrote: post #33
l5ymep wrote: post #18

Earlier quoted context omitted.

Java developers are cheap and easy to find. There are libraries for everything that you would need - AWS SDK, Redis, etc. Performance is tolerable and can be improved with things like Micronaut and native ahead of time compilation (GraalVM).

> Java developers are cheap and easy to find. I wish.

Nobody said they’re good quality though.

Re: Java 18 / JDK 18: General Availability

#238

Post by dfee »

Slartie wrote: post #96
dfee wrote: post #40

Earlier quoted context omitted.

Great error handling? What does that mean? Checked exceptions seem cool at first, but are really just nonsense… as your only real way of dealing with this is: 1. Catch, log and rethrow, or 2. Wrap as a runtime exception (so you don’t have to change every method signature up to main()) Sure, there’s option 3: catch and handle… but this is used 1/50 times, and the ergonomics of (2) overwhelm the utility of this. BTW, v…

Anyone not seriously considering option 3 as the default, with options 1 and 2 being the exception that one must have good reason to take, automatically disqualifies himself as ignorant of proper error handling. Of course you catch and handle errors. Or at the very least you must think about whether it makes sense to handle an error on the current abstraction level that you are on, which means you must always conside…

sure. consider me ignorant of proper error handling.

looks like the "true scotsman problem", though. i'm using state of the art packages like jgrapht which throw runtime exceptions, and i'm manually catching those runtime exceptions, pattern matching on the exception messages, and trying to handle.

when the community doesn't use the API, it's a tragedy of the commons problem. there's a lot of grey area between what constitutes a runtime exception vs. a checked exception. it's all very subjective!

Re: Java 18 / JDK 18: General Availability

#239

Post by Tomte »

stevoski wrote: post #138
ok123456 wrote: post #104

Earlier quoted context omitted.

> Java values backwards compatibility very highly, so if something runs today, it's likely to keep running without modification on future JVMs. Then why do I have to have multiple JVMs installed, which I need to go through via trial-and-error, if I'm given some random java application?

> Then why do I have to have multiple JVMs installed, which I need to go through via trial-and-error, if I'm given some random java application? You don't. Almost any Java program written ever will run on Java 18.

Unfortunately, FreePlane demands Java 8, I think.

Re: Java 18 / JDK 18: General Availability

#240

Post by dfee »

ahtihn wrote: post #197
dfee wrote: post #40

Earlier quoted context omitted.

Great error handling? What does that mean? Checked exceptions seem cool at first, but are really just nonsense… as your only real way of dealing with this is: 1. Catch, log and rethrow, or 2. Wrap as a runtime exception (so you don’t have to change every method signature up to main()) Sure, there’s option 3: catch and handle… but this is used 1/50 times, and the ergonomics of (2) overwhelm the utility of this. BTW, v…

Okay,so what's a better way to do error handling? Returning an Either is pretty much the same thing conceptually. Either you propagate the error or you handle it.

I'm just suggesting that Checked Exceptions aren't well enough adopted and there's grey area between what constitutes a checked / unchecked exception.

I have no problem with Either though.

Post reply on HN