Earlier quoted context omitted.
Licensing. Oracle requires a commercial license
That's a reason not to use Oracle--GP's asking for a reason to use Oracle.
OpenJDK:Ubuntu::OracleJDK:RedHat
Java 18 / JDK 18: General Availability
251–260 of 304 posts
Re: Java 18 / JDK 18: General Availability
#252Earlier quoted context omitted.
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.
It doesn't mean to me either, I was only making a point for the typical Oracle bashers that still haven't got the memo that OpenJDK is anyway mostly done by Oracle employees, while using the same style from the parent post.
Re: Java 18 / JDK 18: General Availability
#253Earlier quoted context omitted.
I think it's a combination of four things: 1. GC is an enormous productivity improvement for applications whose performance characteristics can afford it. Seriously, I can't think of a single programming language feature/concept/technology that makes a bigger difference in developer velocity than memory safety and GC. 2. Static types are also a large productivity improvement for developers comfortable using them and…
> I also think it's a pretty decent language. The things people don't criticize about Java are mostly complaints about a certain style of programming in the 90s and less the language itself. (assuming that's a typo there, the things people don't like/the things people criticize?) I disagree on that point, I think the language itself was a problem. Java 6 and prior were very very verbose and very very slow. I think th…
> exact code to open a file, read each of the lines, and then close everything
var lines = Files.lines(Paths.get("file.txt"));
try (var lines = Files.lines(Paths.get("file.txt"))) {
}
Re: Java 18 / JDK 18: General Availability
#254The simple HTTP server is a nice addition. I end up using python's SimpleHTTPServer for all sorts of things so it will be nice to have an alternative right in the JDK.
Ever since Java 11 enabled running single Java files directly without compiling them I've been using my own trivial single file web server for this purpose: https://github.com/ianopolous/simple-http-server
Re: Java 18 / JDK 18: General Availability
#255Earlier quoted context omitted.
People don't like to see their favorite languages bashed. It's completely understandable. I suppose there are many Java enthusiasts on here.
I mean, Java is not a liked language by any metrics, so I guess fans (myself included) are more than used to bashing. That’s why I don’t think that marketing helped the language become as great as it is. Sure, it had a part, but if something would have been substantially better it could have taken over a long time since java is not hypes at all anymore.
> but if something would have been substantially better it could have taken over a long time
I don't think that is true. Windows is still around.
Re: Java 18 / JDK 18: General Availability
#256Earlier quoted context omitted.
That wasn't the only reason why I left one job but their Oracle buy-in was a big factor. Things like paying 7 figures a year for support, and then having the Oracle support manager ask if they could redistribute the hot-patch I made to other customers.
Big enterprise vendors are always like that. My first boss wrote the TCP stack for a long defunct mainframe, which was distributed via a “shared source” program that his employer paid for and eventually was licensed to his employer at significant expense.
Indeed. The primary reason I was so annoyed by that is that this was when (IIRC) IE8 was released, and day one we noticed that their sloppy JavaScript caused an exception which broke the entire UI. That happens but when I contacted enterprise support, I got a surprisingly snotty “we don't beta test Microsoft's software for them” message closing the ticket. They re-opened it when I pointed out that it was the release version and rolling out enterprise-wide to our Windows desktops for security reasons but I was not expecting a fix for a while based on the blow-off (this proved accurate), much less the call from a support manager a couple days later who'd seen in the case notes that I'd mentioned having patched it on our cluster (this was literally one line of code — trivial for any decent web developer).
Re: Java 18 / JDK 18: General Availability
#257Earlier quoted context omitted.
I think it's a combination of four things: 1. GC is an enormous productivity improvement for applications whose performance characteristics can afford it. Seriously, I can't think of a single programming language feature/concept/technology that makes a bigger difference in developer velocity than memory safety and GC. 2. Static types are also a large productivity improvement for developers comfortable using them and…
> I also think it's a pretty decent language. The things people don't criticize about Java are mostly complaints about a certain style of programming in the 90s and less the language itself. (assuming that's a typo there, the things people don't like/the things people criticize?) I disagree on that point, I think the language itself was a problem. Java 6 and prior were very very verbose and very very slow. I think th…
> (assuming that's a typo there, the things people don't like/the things people criticize?)
Oops, yes, sorry.
> Java 6 and prior were very very verbose and very very slow.
It's kind of verbose, when looking at it from today's perspective, but at the time I didn't think it was that bad. I think they deliberately tried to be less cryptic and more wordy than C/C++ (which can often be impenatrable). I think they overcorrected for that, but I don't think the language is interolerably verbose.
Performance was definitely bad until Lars Bak and company showed up and wrote HotSpot. But almost every managed language at the time had poor performance. It was certainly painfully slow compared to C and C++ but... what wasn't?
> I couldn't tell you off the top of my head the exact code to open a file, read each of the lines, and then close everything, or the right way to open a JNP connection to RabbitMQ or something.
I mean, I couldn't tell you how to do that off the top of my head in just about any language. Except C. But, of course, the code I would write for C off the top of my head is simple and wrong because it doesn't handle all of the various ways IO can fail.
Networking and file systems are honestly just kind of grungy. You can paper over it with simple APIs but what you end up with is code that looks pretty but can fail in obscure ways.
> try/catch, and mother. fucking. IOException. thrown everywhere.
Yeah, checked exceptions were simply a mistake. I don't fault them for trying to fit exceptions into the static type system. It was a cool, ambitious idea. At the time, no one really had a sense of how the ecosystem would settle around using exceptions. In practice, it ended up being more trouble than it's worth.
> The other quiet boost that people don't talk about is Android.
Android is definitely keeping it popular these days, but Java was huge because of server development before Android came along.
Re: Java 18 / JDK 18: General Availability
#258Earlier quoted context omitted.
To echo others: relatively good performance, incredible tooling/deployment infra (really best-in-class), intercompatibility with tons of other languages built on top of the JVM such that it can be functional/do actors/whatever your other weird approach is, relatively high productivity due to a large library base (not just the standard library but also a huge amount of stuff written to support android apps), and ease…
> relatively good performance, That's kind of downplaying it right? Outside of "native" languages like C, C++, Rust, fortran, Java blows everything else out of the water.
Javascript in V8 is more performant than Java on a lot of tasks, and almost always 'sooner'. V8 is focused on 'getting going quickly' and it does, very fast. Java takes some time to optimize for most tasks.
Also, 'performance' isn't really an issue once you are past 'good enough'.
I don't think most devs are worried about Java/Node/Python/Golang performance on the backend for most apps. Obviously not always the case, but in most instances, it's not a primary concern.
Frankly, these days, when I think about 'performance' I think about 'developer performance!'. Java downsides in that its bureaucratic by convention, but at least it's super solid and reliable. I really, really wish it were a bight lighter however.
Re: Java 18 / JDK 18: General Availability
#259Earlier quoted context omitted.
Still, coming from other languages, it is all too easy to write this and this silently fails without any warning. This is consistent with the rest of the language, but I'd bet one rarely wants referential equality when comparing strings. People commenting "yeah but that's because you are a newbie / you are comparing references and you should know better" miss the point I think. I can easily see myself making this mis…
I learned this 25 years ago when I got started with the language. It tripped me up once, I learned about how references work in Java, and that was that. We are expected to learn about our tools.
> We are expected to learn about our tools.
I hope making mistakes is ok though?
I learnt C years before Java, it's also the first language I properly learnt. And a little bit of C++ too, so I've known the concepts of pointers and references way before learning Java. In C, you also either do pointer equality or explicit value equality (with strcmp) for string equality tests. I never had any issue understanding how things work in Java. It's not about learning anything. It's about doing mistakes. And I won't take "you should know better" as a counter argument to a mention of some rough edge in an API or a programming language. It's like Javascript: you might know the differences between == and === in Javascript full well, but still happen to write == by mistake because you just wrote some C/Java/Python code just before. I'll probably not forget about .equals(...) in Java most of the time but the fact that == would be silently accepted and not do what is wanted is still a bit concerning (and .equals(...) is ugly, too).
A linter will do indeed and that's a fair point. I'd argue that linters are there to work around rough edges of programming languages, but that's fair enough too, every programming language has its gotchas and I'll accept considering a programming language + its linter(s) instead of a programming language alone. However, that's still not ideal because you might have to work on non linted code and deal with these gotchas without any safety net.
I hadn't thought about number comparisons (mentioned in other comments) but that's even worse indeed.
It's no wonder Kotlin and Groovy both chose value comparison for ==.
Re: Java 18 / JDK 18: General Availability
#260This is tangential and possibly too open ended to be productive but worth a shot anyway. Why is Java so popular? I know of a major Silicon Valley company that's migrating their backend to it. Why Java over other languages? Or maybe there's not really other viable options? I'm speaking as someone who spent the last 6 years focused on frontend web technology.
Java is popular because of marketing. https://www.theregister.com/2003/06/09/sun_preps_500m_java_b...