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

381–390 of 427 posts

Re: Java 27

#381

Post by gf000 »

someone_19 wrote: post #363
gf000 wrote: post #317

Earlier quoted context omitted.

> The stack is definitely faster than anything else I have seen it mentioned everywhere, but is this actually true? I mean, of course it is faster than random cold memory, but is it actually faster than a hot, in-cache part of the heap? It is not special in any other way, AFAIK. And for what it's worth, what pron mentioned, Java uses a pretty similar structure for initial allocation, a thread local buffer where you j…

> I have seen it mentioned everywhere, but is this actually true? Yes, it just adding or subtraction int to stack pointer register. I’m not certain, but the only thing that might be faster is accessing data at a fixed address - that is, global variables.

That's the way of getting the address itself, that's unrelated to how fast the actual memory read/write is.

Stack is fast because it is frequently "touched" staying in cache. If you were to continuously read write a small segment of the heap, I don't think it would fair any worse than "the stack". This was my point

Re: Java 27

#382

Post by wink »

MaxBarraclough wrote: post #274
theandrewbailey wrote: post #16

Earlier quoted context omitted.

I never thought of Java being the 'move fast ~and break things~' alternative over .NET, but Java has a faster release schedule to get features out sooner.

Move fast and break things does not describe Java well at all. Their process is still very deliberate, they go to some lengths to avoid getting it wrong when they add new features to the standard. New features have to get through their preview phase successfully before becoming final. [0] They're also pretty committed to not breaking existing source code or bytecode. [0] https://openjdk.org/jeps/12 JEP 12: Preview Fe…

One of the releases was that, though - either 9 or 11, with the package reorgs that broke everything. OK... it wasn't fast.

But Java 8 was stable (as in APIs, not judging its quality here) and since then it's gotten good again.

Re: Java 27

#383

Post by retrodaredevil »

rendaw wrote: post #190
retrodaredevil wrote: post #176

Earlier quoted context omitted.

NullAway with JSpecify annotations are a really good way to add null safety to Java applications. Even enforces nullability at the generic level.

The elephant in the room is the standard library (collections). It isn't even type safe yet, because some methods were around before generics were added. And collections are too core for anyone to be able to agree on a 3rd party standard.

I mean, I guess you could say stuff like get(Object) and contains(Object) aren't type safe, but I've never seen that as an issue in practice. Plus there are some ErrorProne checks that'll tell you if you're doing something wrong in regards to calling contains(Object) with the wrong type.

Re: Java 27

#384

Post by cute_boi »

pron wrote: post #195
rohan_ wrote: post #172

Earlier quoted context omitted.

This is quite the take - i doubt most startups building in these spaces are using Java.

First, they do. Second, most software is not only not produced by software startups, it's not even produced by software companies. Do you know how much software a bank, or a credit card company, or a telecom provider, or a car manufacturer (like BMW), or a shipping company (like FedEx), or a defence company (like Boeing), or a large retailer (like Walmart) write in house?

I used to work on bank, and their java code was very bad, although it works as they have been using same code for 30 years lol.

Re: Java 27

#385

Post by samus »

troupo wrote: post #360
samus wrote: post #330

Earlier quoted context omitted.

> Some of those ways come from just plain object initialisers. Which are amazing and sorely needed in Java. They really aren't, and they are IMHO an antipattern since they break encapsulation. One might argue that encapsulation doesn't matter with mere data classes, but Java will cater to that use case by introducing withers.

> They really aren't, and they are IMHO an antipattern since they break encapsulation. They don't. Java had to come up with the extremely verbose builder pattern for the exact same thing. And withers are basically the same tedious manual builder pattern, just with a different name. For withers C# just has the with keyword: https://learn.microsoft.com/en-us/dotnet/csharp/language-ref...

With withers they will become less verbose. In the best case you'll only need to define a value type and a constructor taking an instance of that.

Re: Java 27

#386

Post by pron »

unscaled wrote: post #310
pron wrote: post #293

Earlier quoted context omitted.

> Rust is just as ergonomic as any other popular language today if you're using an agent Have you worked on large (>500KLOC) codebases with an agent? Not only do you have to be an expert at the language, but even if you're lucky and everything is fine, Java code is likely to be particularly fast by comparison, because the agents aren't very good at manual optimisation, especially as the code grows (they're even worse…

Have you worked on large (>500KLOC) codebases with an agent? Yes. But keep in mind KLOCs are not easily comparable across languages. Java is notoriously verbose. A 500KLOC codebase in Java would usually be half that size in Rust. If your argument is that large codebases makes life harder for agents, you should go with a less verbose language. I'm not sure what "manual optimization" means (isn't it a bit of an oxymoro…

> A 500KLOC codebase in Java would usually be half that size in Rust

Ok, so you barely know either Java or Rust.

> If your argument is that large codebases makes life harder for agents, you should go with a less verbose language.

You mean, like Rust??? But no, that's not my argument. Agents have a hard time keeping up the architecture in large software (and the differences between verbose languages like Java, Go, Rust, and C++ vs less verbose ones like Python and JS don't make much of a difference). So they either make a mess or they do the simple thing, and the simple thing in low-level languages is often slow.

> But it wouldn't be worse on the slop that humans created on every moderately-sized Java project I've worked on.

Yeah, I don't think you've actually tried it.

> I've never seen an agent optimizing for Java where necessary (e.g. using object pools to avoid GC churn). Java is not magic.

Object pools are far less efficient than Java's GCs, but while state-of-the-art compiler and memory management technology is certainly not magic, I suggest you learn more about these things if you want to make informed decisions.

Re: Java 27

#387

Post by pron »

steveklabnik wrote: post #372
pron wrote: post #292

Earlier quoted context omitted.

Oh, sorry, missed a few words. Their CPU time.

I’m curious where you have seen this.

It's quite common in concurrent services that non-experts write. But the more interesting cases are things like Moka. In a simple evaluation (and, of course, not much can be extrapolated from any benchmark) Java's old Caffeine library had lower latencies in all percentiles at twice the throughput as Moka (at 90% cache hit rate), as the latter spent 41% of CPU (on top of the cost of malloc/free) on epoch based reclamation.

Re: Java 27

#388

Post by samus »

troupo wrote: post #361
samus wrote: post #320

Earlier quoted context omitted.

> - object initialisers Probably not a good idea since they break encapsulation by exposing internals of the class. There is work on withers, which should make defining builders far simpler. > - extension methods. They make code harder to understand. If they ever come they would have to be declared at the top of each source file. > - null coalescing operator Maybe we'll get it, maybe not, but they want to first intro…

> Probably not a good idea since they break encapsulation by exposing internals of the class. And thousands of manual get/set functions don't? Thousands of lines of builders don't? Object initializers are that plus much better handling of fields/properties that doesn't require hundreds of lines of tedious manual code: https://learn.microsoft.com/en-us/dotnet/csharp/programming-... > for the simple reason that there i…

> And thousands of manual get/set functions don't?

My statement doesn't apply to mere data carrier classes. Anyway, getters and setters are an antipattern as well since one can just as well make all the fields public.

> Thousands of lines of builders don't?

With withers most of these will go away. And a class will be able to choose which things can be set, which is not the case for initializers.

> But it's not synchronous code, is it? It's easily dozens of lines wrangling Futures, and Thread initialisers, and Executors, and..

That code won't look that much different with async/await.

Re: Java 27

#389

Post by [deleted] »

pjmlp wrote: post #354
samus wrote: post #352

Earlier quoted context omitted.

IMHO, Dex is a historical artifact. In the past it was thought that the format provides benefits for JIT compilation because it's register based, which turned out to not be case.

Lots of "improvements" on Dalvik over J2ME was Google's marketing to sidestep Sun, speaking as ex-Nokia, coupled with the experience of Java on Symbian devices and Sony Ericson. All these years afterwards it quite clear that there is just similar fragmentation, and implementation differences between all OEMs selling every kind of devices, and as you say the format doesn't really provide that much benefits. What ART h…

[deleted]

Re: Java 27

#390

Post by jayd16 »

za3faran wrote: post #221
troupo wrote: post #162

Earlier quoted context omitted.

> Java has a faster release schedule to get features out sooner While still being behind on most features?

Which features exactly? Java got exhaustive pattern matching before C# (through sealed interfaces), it has switch expressions, multi-line strings, green threads and structured concurrency, is getting value types, and even type classes in the work.

Even in the small list of features in your retort you had to switch to future tense.
Post reply on HN