Live data from Hacker News

Love It or Hate It, Java Continues to Evolve

azul.com

81–90 of 156 posts

Re: Love It or Hate It, Java Continues to Evolve

#81

Earlier quoted context omitted.

That's a nice try, but the rest of the app would be[1]: import static spark.Spark.get; public class HelloWorld { public static void main(String[] args) { get("/hello", (req, res) -> "Hello World"); } } [1] http://sparkjava.com/

It is indeed a nice try, and the rest of the app would be: @SpringBootApplication @RestController class DemoApplication{ @GetMapping("/hello") fun hello() = "Hello, World!" } fun main(args: Array ) { runApplication (*args) } And this taught me that the best sinatra clone in java isn't really worth it in terms of lines of code saved (we save what? 3 lines of code? 6 with the imports?) when compared to a full-blown web…

In Kotlin, so you don't have to define multiple files, obviously skipping the imports. Let's do the same with Jooby, for instance:

    fun main(args: Array) = run(*args) {
      get { "Hello Kotlin" }
    }
It's always easy to make a framework lightweight. But there is no argument that Spring requires a lot of tedious boilerplate in Java (some of which can be avoided with Kotlin), and annotations which are hard to understand.

Lightweight frameworks don't really tell you "We do everything that Spring does in less lines", since at one point you'll ask them to make avocado toasts or something else that spring-bakery has a plugin for.

The real power of lightweight frameworks is their simplicity. This is not for everyone (that's why we've got Spring and Rails), but if everybody was fine with the tradeoffs that Spring makes, you'll see the same kind of frameworks ruling the Node.js and Go landscape.

Re: Love It or Hate It, Java Continues to Evolve

#82
post #17

In my experience most people don't like Java due to experiences they had before Java 8. This means they were used to the bloat, config as XML style world which made Java a pain to write and slow to run. Once I show them Java 11 with var keyword, lambda's and streams they start appreciating how modern the language has become. Then you throw in frameworks like javalin or sparkjava and suddenly they are not as hostile a…

Java 11 is obviously much better than Java 8, which is still leaps and bounds ahed of Java 6, itself an improvement over Java 4. You'd see the same in every language. Java's problem is that for many years it used to be the slowest car around. Maybe this was one of the things that helped Java become the undisputed ruler Enterprise Inc. but now it's got a lot to catch up with, and even though the pace has picked up sin…

Quick nitpick. Both of the C# examples are called LINQ. The first is called the "method syntax", the latter is called the "query syntax". The query syntax is transpiled into the method syntax before compilation.

Re: Love It or Hate It, Java Continues to Evolve

#83

Earlier quoted context omitted.

I write quite a lot of Java, and I have to admit I never “got” Spring. I’d much rather have explicit boilerplate code (preferably in library form as much as possible) than complex, invisible magic. The latter is “easy”, but the former is “simple”. In most cases, “simple” is more important.

I'd say there is no upside for the complex invisible magic. Half the time you have to run the application and pray that the configuration beans you've placed are working and if not, you are pretty much in trouble. Perhaps you missed a step in adding a configuration decorator in your application or configuration class, or used some deprecated method or used some incorrect class in the class hierarchy for the bean you…

it's not even magic, it's redundant over engineering at its peak

haskell has magic, but at least its concise..

Re: Love It or Hate It, Java Continues to Evolve

#84
post #17

In my experience most people don't like Java due to experiences they had before Java 8. This means they were used to the bloat, config as XML style world which made Java a pain to write and slow to run. Once I show them Java 11 with var keyword, lambda's and streams they start appreciating how modern the language has become. Then you throw in frameworks like javalin or sparkjava and suddenly they are not as hostile a…

That sounds a lot like what people are saying about PHP and its newer versions. But the thing is, now that we have great alternatives (Kotlin, C#, Scala, Go, Dart...), what does Java have that those don't?

Millions and millions of people using them. High quality (and in many cases user friendly and familiar, too) tools built around them, several options, even.

Re: Love It or Hate It, Java Continues to Evolve

#85
post #34

Earlier quoted context omitted.

Big fan of sparkjava for no-nonsense HTTP services. The days of tomcat-for-everything were not fun as someone who only occasionally dabbled in java back then. So I have to build this as a special type of jar and then set up this other, rather opaque, set of stuff and deal with all sorts of nonsense ... Now? get("/hello", (a,b) -> "Hello World"); And we're done...

That sure looks nice, but how often do you write services which return a single constant string? I like to judge languages/frameworks based on more representative snippets.

> That sure looks nice, but how often do you write services which return a single constant string?

The point was just to show that the http server aspect of it is trivial to set up.

You can hook in whatever you want from there.

Re: Love It or Hate It, Java Continues to Evolve

#86

Earlier quoted context omitted.

I may work with java soon, so I was reading about Spring and it was yet again a dive into insane amount of verbose over engineering that I ran away from years ago. It's true that post 8 Java becomes palatable. And someone on reddit just showed me this piece of stats: https://www.jetbrains.com/lp/devecosystem-2019/java/ 83% on java 8, java 11 nicely going up I pity those forced to work with old techniques

> I pity those forced to work with old techniques java modules broke a lot of software that were using sun classes or did classloading magic. I was on one of such application, it's not a lot of effort to migrate forward, but many of the issues are runtime only so unless you have a good test suite, a strong incentive and no closed source library that use some such classes you can't really move forward with it. anyway,…

I wonder how much salary increase it would take to make working with xml/spring worth someone's while.

ps: also how many shops are doing 'migration off of spring' ?

Re: Love It or Hate It, Java Continues to Evolve

#87
post #53

Earlier quoted context omitted.

But with Go you can iterate quickly compared to java as the compilation time is very small. This difference is massive in big projects. This is an important reason why I took up Go for many projects.

Can you give a few numbers what counts as "very small" here? Most of my big java projects take less than two minutes for a full compile and incremental compile of the whole project is usually in the range of 10 secs. If you run the whole test suite it can take longer depending on the tests, but that's not what I'd count as "compile time".

[deleted]

Re: Love It or Hate It, Java Continues to Evolve

#88

My only problem with Java is how it’s written. Enterprise java tends to be abstracted to absurd levels. I prefer a more direct approach.

A lot of modern Java libraries and frameworks got better, and the Java standard library itself is moving away from deep class hierarchies, but I think there's a long standing culture that dictates how Java is "ought to be written" and it's quite hard to dispel that.

A lot of this is the language's fault though. For the sake of "simplicity" Java decided to:

1. Have a bifurcated type system with boxing, so a lot of generic code had to be obtuse or use a lot of reflection (It took a long time before Java added a very flawed generics implementation and convenience functions like Strings.valueOf()). 2. Disallow standalone functions (everything has to be a method on a class). 3. Implement many standard library APIs as abstract classes (and worse - concrete non-final classes) instead of interfaces, encouraging developers to overuse inheritance where composition should suffice. 4. Not provide any mechanism for delegating to member objects. 5. Encourage the practice of getters and setters, but provide no mechanism for properties. 6. Provide neither powerful meta-programming mechanism nor a strong type system, but create a powerful reflection API instead. Any surprise it will be misused?

Re: Love It or Hate It, Java Continues to Evolve

#89
post #33
post #12

Earlier quoted context omitted.

Whilst I agree, it's language features are meant to reduce some of those issues. The rope you have to hang yourself with is a bit shorter than you have in other languages. At least in theory.

In practice, the language gives you enough rope if you don't think or care about design at all. This is a typical beginner's problem once they get past their first toy programs and try to write something useful.

I agree. Things like type saftey, interfaces, protected methods and properties and so on are what I was referring to. These kinds of features are borne out of necessity from big code bases and big teams, where you can't trust that every line of code will be written to the software architectures guidelines.

It shouldn't be possible for a new hire to feed a Customer to a Product repository for example, and in most mature languages we've made language level features to doo that, so we don't have to manually code checks in everywhere.

Eventually NewLanguage shows up without type saftey and everything is going great as it gets used in smaller projects. But then big teams start picking it up and suddenly these things are issues again.

Re: Love It or Hate It, Java Continues to Evolve

#90

Earlier quoted context omitted.

It is indeed a nice try, and the rest of the app would be: @SpringBootApplication @RestController class DemoApplication{ @GetMapping("/hello") fun hello() = "Hello, World!" } fun main(args: Array ) { runApplication (*args) } And this taught me that the best sinatra clone in java isn't really worth it in terms of lines of code saved (we save what? 3 lines of code? 6 with the imports?) when compared to a full-blown web…

In Kotlin, so you don't have to define multiple files, obviously skipping the imports. Let's do the same with Jooby, for instance: fun main(args: Array ) = run(*args) { get { "Hello Kotlin" } } It's always easy to make a framework lightweight. But there is no argument that Spring requires a lot of tedious boilerplate in Java (some of which can be avoided with Kotlin), and annotations which are hard to understand. Lig…

I understand, and I used to be in the sinatra camp a decade ago. What I really disliked with spring/tapestry and rails was the (at the time) huge stack trace and memory usage.

The annotations I used were "this is a spring boot application" on top of a class and another which says "this is a rest controller" to start your hello world application and we only saved a few lines and introduced additional hidden complexity with sparkjava because we still don't have a way to handle json whereas it comes free with spring boot.

You've got another one that says "this is an injectable service" and another which says "this is a db entity" and with the "this is a configuration" you've got 99% of spring boot applications covered. Not sure what is so hard about the annotations. Maybe it has to do with "knowing more than just java/kotlin syntax" that puts people off?

Post reply on HN