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

Java is fast, code might not be

jvogel.me

Post reply on HN
Print view View original

251–259 of 259 posts

Re: Java is fast, code might not be

#251

Post by Tillerino »

drtse4 wrote: post #213
EricRiese wrote: post #150

This is a Spring specific gripe and I know this blog post doesn't assume Spring, but I hate seeing `new ObjectMapper()`. Spring Boot auto configures an ObjectMapper for you and you probably want the customization it gives you, including `java.time` handling and classpath scanning. I've wrestled with so many bugs caused by not using the `ObjectMapper` bean.

If you really want to write really performant java code, the word "spring" should not even be mentioned. Same thing for Jackson, write you own lazy json library if the data is bigger than a few 100k. The code will not look pretty but it will be very fast.

Speaking of Jackson and performance... I have been working on Jagger for a while now, which aims to replace all that reflection during databind with annotation processing.

I am trying to aim for something like Mapstruct for the developer experience, since everybody loves Mapstruct. With Jagger, you bring a parser (JSON/XML/whatever), define some databind methods, and it generates the implementation for you.

So far I've only had my own use cases, so I would love to have some wider feedback.

https://github.com/Tillerino/jagger

Re: Java is fast, code might not be

#252

Post by tripple6 »

abound wrote: post #30
tripple6 wrote: post #11

Do good, don't do bad. Okay.

I don't think that's a charitable take of the article. To many programmers, it wouldn't be obvious that some of these footguns (autoboxing, string concatenation, etc) are "bad", or what the "good" alternatives are (primitives, StringBuilder, etc). That said, the article does have the "LLM stank" on it, which is always offputting, but the content itself seems solid.

Of course it's not. I don't see any reason of posting an article that repeats the very same basics of Java or literally any programming language. Simple basics. Sure, if a particular programmer is not aware of these, the particular programmer would be very surprised that any of their operations are not imaginary O(0) (if they'd even care).

Re: Java is fast, code might not be

#253

Post by cryptos »

computerdork wrote: post #240
cryptos wrote: post #239

Earlier quoted context omitted.

It is not like auto-wiring would turn Java magically into a dynamically typed language!

For me at least, being statically typed is overall a strength. Yeah, it's not that much work to include types when declaring vars, but the benefits are you don't have the problems with types in expressions that you do with dynamically typed languages (Javascript for example, which is one the reasons why Typescript was created). ... although, Java have does support some dynamic typing, as you now don't need to have th…

`var` has nothing to do with dynamic typing. It is still statically (compile time) typed, so the type can not change at runtime. Compare that to JavaScript where you could easily switch the type of a variable from Number to String.

Re: Java is fast, code might not be

#254

Post by carlmr »

vbezhenar wrote: post #230
carlmr wrote: post #90

Earlier quoted context omitted.

The problem is rather that Java doesn't have generics and structs, so you're kind of forced to box things or can't use collections.

No, in the example they provided, programmer wrote obviously stupid code. It has nothing to do with necessity: Long sum = 0L; for (Long value : values) { sum += value; } I also want to highlight that there are plenty of collections utilizing primitive types. They're not generic but they do the job, so if you have a bottleneck, you can solve it. That said, TBH I think that adding autoboxing to the language was an erro…

>They're not generic but they do the job, so if you have a bottleneck, you can solve it.

But that's the thing, in other languages you don't need a workaround to work on primitives directly.

Re: Java is fast, code might not be

#255

Post by nightpool »

kerblang wrote: post #183
nightpool wrote: post #140

Earlier quoted context omitted.

How would you handle validating numeric input in a hot path then? All of the solutions proposed in #5 are incomplete or broken, and it stems from the fact that Java's language design over-uses exceptions for error handling in places where an optional value would be much safer and faster.

> Java's language design over-uses exceptions for error handling No, library authors' design over-uses exceptions. Also refer to people using exceptions to generate 404 http responses in web systems - hey, there's an easy DDOS... This can include some of Java's standard libraries, although nothing springs to mind. Exceptions are not meant for mainstream happy-path execution; they mean that something is broken. Countl…

I agree with you that the root problem is that the library author's design over-uses exception. But when the library in question is the standard library and the operation is as basic as Integer.parseInt, then I think it's fair to criticize that as a language issue, because the standard library sets the standard for what is idiomatic + performant for a language.

Re: Java is fast, code might not be

#256

Post by zadikian »

raw_anon_1111 wrote: post #208
zadikian wrote: post #143

Earlier quoted context omitted.

Well before LLMs, I already ditched ORMs. What sometimes holds back SQL is not having a convenient way to call it. Statically-typed languages require you to manually set result types unless you use a compile-time query builder, but that's a whole can of worms. Besides that, many client libs aren't so convenient out of the box, so you still need a few of your own helpers. Also, before jsonb existed, you'd often run in…

Let me introduce you to LINQ… https://learn.microsoft.com/en-us/dotnet/csharp/linq/ It solves all of your issues with “ORMs” (it’s really more than just an ORM)

That's part of the query builder "can of worms" I mentioned. Might be one of the better examples. But idk what limitations it has vs regular SQL, like it mentioned not having native support for count/max.

Re: Java is fast, code might not be

#257

Post by computerdork »

cryptos wrote: post #253
computerdork wrote: post #240

Earlier quoted context omitted.

For me at least, being statically typed is overall a strength. Yeah, it's not that much work to include types when declaring vars, but the benefits are you don't have the problems with types in expressions that you do with dynamically typed languages (Javascript for example, which is one the reasons why Typescript was created). ... although, Java have does support some dynamic typing, as you now don't need to have th…

`var` has nothing to do with dynamic typing. It is still statically (compile time) typed, so the type can not change at runtime. Compare that to JavaScript where you could easily switch the type of a variable from Number to String.

agreed, it's not (as mentioned, it's just syntactic sugar). Still, how often is changing the type of a var needed? (besides minor casting issues)

And not saying that dynamic typing doesn't have a place, I really like working in Python, it's just that for more complicated code, prefer statically typed as it leads to less problems with your expressions. To each their own.

Re: Java is fast, code might not be

#258

Post by kerblang »

nightpool wrote: post #255
kerblang wrote: post #183

Earlier quoted context omitted.

> Java's language design over-uses exceptions for error handling No, library authors' design over-uses exceptions. Also refer to people using exceptions to generate 404 http responses in web systems - hey, there's an easy DDOS... This can include some of Java's standard libraries, although nothing springs to mind. Exceptions are not meant for mainstream happy-path execution; they mean that something is broken. Countl…

I agree with you that the root problem is that the library author's design over-uses exception. But when the library in question is the standard library and the operation is as basic as Integer.parseInt, then I think it's fair to criticize that as a language issue, because the standard library sets the standard for what is idiomatic + performant for a language.

There is nothing wrong with Integer.parseInt(). It blows up if you give it invalid input. That's standard idiomatic behavior.

It might be helpful to have Integer.validateInt(String), but currently it's up to author to do that themselves.

Re: Java is fast, code might not be

#259

Post by larsnystrom »

lern_too_spel wrote: post #177
larsnystrom wrote: post #127

Earlier quoted context omitted.

I remember writing Java for our introductory programming course at university around 2010. I was already familiar with object oriented programming in PHP at the time, so I just wrote the Java code like I would write PHP. I was absolutely astounded at the poor performance of the Java app. I asked one of our tutors and I can still remember him looking at the code and saying something along the lines of ”oh, you’re inst…

Your tutor misdiagnosed the issue. These allocations in a tight loop would have used bump allocation on Java 6 in 2010, and the young generation would have used a copy collector, which would have freed those objects more cheaply than any unspecialized malloc/free. It would have beaten the pants off of PHP's reference counting GC.

I remember now what the problem was. I was instantiating a new ArrayList in a loop. The solution to the performance issue was to use a Vector instead. I was used to just writing PHP arrays when I wanted a list of something, and since they’re dynamically sized I thought the analogue in Java was ArrayList, which is also dynamically sized. But somehow that was extremely unperformant in Java.
Post reply on HN