Live data from Hacker News

Don’t call it a comeback: Java is still champ

github.com

411–420 of 557 posts

Re: Don’t call it a comeback: Java is still champ

#411

Earlier quoted context omitted.

Modern Java has first-class functions, pattern matching with structural binding, records/pure immutable data classes, the whole 9 yards: static void main() { BiFunction add = (Integer x, Integer y) -> x + y + 5; Integer result = addTo(10, add); Integer result2 = addTo(10, (x, y) -> x + y + 5); } static Integer addTo(Integer acc, BiFunction addFn) { return addFn.apply(acc, 5); } Integer eval(Expression e) { return swi…

> records/pure immutable data classes Example? As far as I know, Java has final, which means that particular reference can't be re-assigned, but the object referred to remains mutable. You have to resort to e.g. having separate immutable and mutable interfaces or whatever to restrict a someone from mutating your object. If you want an immutable data class more than one level deep, I don't know if there's a convenient…

You are right, though I seldom find it a problem in practice. Also, OOP sort of makes immutability hard to define (e.g. is a getter with an internal counter of accesses immutable? In a way, it is. Also, Rust’s internal mutability pattern is similar).

Nonetheless, recently more and more standard classes are made deliberately immutable, and there was a proposal for frozen arrays as well (not sure on their status).

Re: Don’t call it a comeback: Java is still champ

#412

Earlier quoted context omitted.

Modern Java has first-class functions, pattern matching with structural binding, records/pure immutable data classes, the whole 9 yards: static void main() { BiFunction add = (Integer x, Integer y) -> x + y + 5; Integer result = addTo(10, add); Integer result2 = addTo(10, (x, y) -> x + y + 5); } static Integer addTo(Integer acc, BiFunction addFn) { return addFn.apply(acc, 5); } Integer eval(Expression e) { return swi…

I haven't programmed in Java since 2005, so forgive me. But isn't a lambda automatically converted to an object of the necessary single-method type? That feels a little magical and suggests that there really isn't such a thing as a genuine first-class function in Java, as there is no way to define a function, and no universal type to assign to such a thing.

Well, the standard library does have some function types, like Function, Supplier, etc. You can just initialize a variable of these types and pass them around. I don’t see how are these not genuine first-class entities. The lambda syntax is also quite pleasant.

(Also, behind the scenes they often compile to static functions and called through the invokedynamic instruction)

Re: Don’t call it a comeback: Java is still champ

#413

Java was actually not bad for me in class when learning software design and data structures, but soul-crushing to work with in the real world. Mindless, unnecessary use of getters/setters, interfaces, and AbstractFactoryImpls. Hiding almost every piece of functionality behind 10+ layers of indirection. Dependency Injection with Spring. They all make it feel like Java draws folks who actually __enjoy__ writing bloated…

I'm not really a fan of Java but isn't a comparison with Elixir and Python a bit apples to oranges?

Re: Don’t call it a comeback: Java is still champ

#414

Earlier quoted context omitted.

I have been learning Elixir for past couple of months. After a long time, I am in love with programming+design again. It has honestly given my brain a much needed refresh. Of course, it can definitely be attributed, at least partly, to just moving to functional programming. Every day I look forward to 6'o clock, so I can stop working and continue on my own projects.

You will also find Clojure just as refreshing / enlightening. My company uses Elixir but I’ve also done a lot of Clojure, give it a shot if you haven’t.

Seconded. Clojure was a real turning point for me but be warned - once you have the veil lifted re OOP you'll not want to work with Java/C# ever again.

Re: Don’t call it a comeback: Java is still champ

#415

Anybody have experience with the JNI interop with native libs? Is it better to implement something natively in a compiled library and link it in from Java or better to rewrite it in Java? What about lifetimes of objects - who "owns" an object - the runtime or the lib?

Unless absolutely necessary, I would say avoid using it - the JVM ecosystem is almost completely pure in terms of being written almost entirely in itself. If it is a must, then I recommend looking into the new Panama APIs that help a lot with scope, can autogenerate code from C headers, etc.

Re: Don’t call it a comeback: Java is still champ

#416

Earlier quoted context omitted.

I don't think this is an issue with Java, it's an issue with Spring. I'm baffled by the popularity of Spring.

Old school xml based Spring is horrible and if that was your only exposure, I understand your aversion. But spring-boot has an almost zen like quality once you get that it favor convention over configuration. When I was a Java developer, I'd usually use spring-boot with the following dependencies to make the experience better: - lombok: to generate the boilerplate: constructors, getters, setters, equals, hashcode...…

Spring Boot is still Spring with its annotation madness. Take parameter validation, for example. Crazy, full-screen-width multiple annotations stuffed inside the method parameter list. What on earth is wrong with doing validation as other frameworks do, ie. in the method body?

Re: Don’t call it a comeback: Java is still champ

#417
post #106

The JVM is pretty great. I could certainly nitpick things, but it's pretty great. Java is pretty decent. However, I would say that Java lost a lot of time and even now there are some decently rough edges. Java didn't evolve as a language for a while and that left the door open to other languages and other non-JVM ecosystems a lot. As the article notes, Java 8 was a breath of fresh air, but it was minimal in some ways…

C# interfaces with methods, properties, and events is just so nice from a readability standpoint. I know we like to pretend that Java now has first-class functions since Java 8, but without easier to use functional signatures they're just too much of a chore. Who the heck wants to write a new interface in a separate file to do this. I'm grateful for the JVM and think it's probably better than the CLR for targeting a…

You have Function, Supplier, and many other predefined functional interface in the standard library.

Re: Don’t call it a comeback: Java is still champ

#418
post #312

Java was actually not bad for me in class when learning software design and data structures, but soul-crushing to work with in the real world. Mindless, unnecessary use of getters/setters, interfaces, and AbstractFactoryImpls. Hiding almost every piece of functionality behind 10+ layers of indirection. Dependency Injection with Spring. They all make it feel like Java draws folks who actually __enjoy__ writing bloated…

Java is the perfect example of software "bureaucracy" for the sake of bureaucracy

That also goes for Java's imitators - C# and PHP5+.

Re: Don’t call it a comeback: Java is still champ

#419

Earlier quoted context omitted.

What's your take on Kotlin? Neatly solves a ton of these issues.

I’ve looked at Kotlin but haven’t used it. It seems like it was designed carefully, and conceptually, I think Jetpack Compose is pretty cool. Is there a (non-Spring-like) Kotlin server-side framework you would recommend taking a look at?

The main Kotlin framework is Ktor.

Re: Don’t call it a comeback: Java is still champ

#420

Earlier quoted context omitted.

Enhanced hot swap using GraalVM has mostly caught up with capabilities https://www.graalvm.org/22.1/reference-manual/java-on-truffl...

I’ve tried that and it didn’t work reliably for me. The jet brains runtime release works but it’s a bear to figure out which download to use. Regardless, it’s ridiculous that at this point Java doesn’t have full hotswap. All the hooks are there (as is apparent from the error messages when a hotswap fails) and the dcevm is being maintained by jetbrains employees. It needs an internal champion at oracle/sun.

What should happen when you remove an existing field, remove a method already used, change its initial value, etc? You will quickly get some incorrect state by blind hot swapping, and it is not trivial to do in a mutable object graph.

Clojure (and other lisps) can do it well because their scope of changes can be really small. Nonetheless, method hot-swap is well-defined and is implemented by OpenJDK.

Post reply on HN