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 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.
Love It or Hate It, Java Continues to Evolve
101–110 of 156 posts
Re: Love It or Hate It, Java Continues to Evolve
#102Which lib/framework to use today for a webapp backend development in Java ? (I am senior dev, some past java7/8 core server experience, FE will probably be React and then mobile)
Re: Love It or Hate It, Java Continues to Evolve
#103I really liked Java back then because C++ had always been a struggle, not because of pointers or anything like that... but because I always found project management, figuring out how to link libraries, and build my projects, to be overly complicated. With Java, I only had to import a library, and that was it. I didn't need to link external libraries because Java's standard library was large enough that it had most of what I needed at the time, and adding external libraries wasn't nearly as difficult as C++.
However, over the years, I feel like I've kind of grown apart from it and have started to want to migrate back towards C++ and Python. I still use Java because it's the language I know best and it's the language I'm writing my game in, but after I finish my game, I think I'll be using it significantly less. The bulkiness of the code, the complications from the JVM, and the lack of good options for deploying executable code is just getting more and more frustrating.
Also, as I was working on my Bachelor's Degree, filling in the gaps of knowledge left by a "meh" education at my previous school, I could see that Java is just not good for writing good, fast code.
That said, Java 8 did make me like Java a lot more when it came out, but they're starting to deploy new versions so frequently now I feel like 8 is the last version I will bother learning.
Re: Love It or Hate It, Java Continues to Evolve
#104In 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…
Re: Love It or Hate It, Java Continues to Evolve
#105Earlier quoted context omitted.
> "Enterprise Software" CRUD-churn I did some Java in the late 90s at university, and a tiny bit in about 2001, pre-dating a lot of the enterprise stuff. I've come back to it in the last three or four years and it's currently my main language. I think I manage to miss the enterprisey stuff. I remember J2EE happening to other people, and then for a while everything was Spring. Somehwere in there were 'Beans' Now ... I…
If you have a strong background in both C and Java, I’d encourage you to give Go a fair shot. I also had long runs with C and Java, but ever since I’ve tried Go, it has become my favorite Swiss Army knife. Basically, it’s my default language until I have a reason not to use it.
Go and Rust are definitely on the list of things I want to learn though.
Re: Love It or Hate It, Java Continues to Evolve
#106Earlier quoted context omitted.
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…
I don't want to have to learn a brand new syntax to get things done. Your Spring example immediately turns me off because it uses a bunch of annotations that could do pretty much anything (and I'd have to learn). Further, it uses kotlin which is not java - it's a valid choice but it's a more terse language in general (so not necessarily valid to compare against java examples). Spark is straightforward and easy to rea…
Re: Love It or Hate It, Java Continues to Evolve
#107In 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?
Re: Love It or Hate It, Java Continues to Evolve
#108Earlier quoted context omitted.
Loom is rather nice, but frankly I don't find the lack of co-routines something I miss. You can spawn hundreds of real threads a second so it is possible to write Go style code in Java if you really want. I may change my mind when I actually use it though. I don't mind what type of data classes they come up with. I just want to not have to write stupidly long constructors, multiple sets or chain-able objects when I w…
Except that the memory overhead for each thread is MUCH higher: the default would be 1Mb for most JVM implementation. Yes, you can change the thread stack size, but that's a global fixed size for all threads, so you can't make it to small, or you'll risk stack overflows. Meanwhile, Go is using dynamically growing stacks, starting at 2k.
Re: Love It or Hate It, Java Continues to Evolve
#109In 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…
The additions and improvements are great but I think we're developing a kind of shared 'Modern X' fallacy. Modern Perl, Modern C++, Modern PHP, Modern Java, etc. The 'modern' facilities and the styles and efficiencies they enable are invariably terrific but you can't comfortably and effectively make use of them without having to know the bulk all the non-modern stuff. Which ends up limiting the appeal to the sorts of…
I started learning Perl in 2007; after it was no longer popular, but also around the time that the principles/practices that became 'Modern Perl' were becoming popular in the community.
I think there is a difference between the two though. Java was always a language which required a lot of ceremony and typing to get anything done at all. Perl was always focused on expressivity. Modern Perl was a case of learning from past mistakes and consciously avoiding some of the more egregious code the language easily afforded. Modern Java is more a case of Java playing catch-up to the more expressive languages out there.
One is applying constraints on your coding style, the other is trying to lift constraints. Both are trying to reach some middle point.
But! I agree that no company writes purely 'Modern Perl' - you will have to deal with some terrifying code at some point.
So. I agree with the concept of the 'Modern X' fallacy, but I would say that dealing with non-modern code is pretty normal, and people who are OK putting up with the pre-modern code may be some of your best employees. I suffer from rewrite-it-all syndrome myself sometimes, but it's something I try to avoid. Code that frustrates me, isn't necessarily bad.
(If it helps contextually, I'm - at heart - a Clojure programmer.)
Re: Love It or Hate It, Java Continues to Evolve
#110Earlier quoted context omitted.
I don't want to have to learn a brand new syntax to get things done. Your Spring example immediately turns me off because it uses a bunch of annotations that could do pretty much anything (and I'd have to learn). Further, it uses kotlin which is not java - it's a valid choice but it's a more terse language in general (so not necessarily valid to compare against java examples). Spark is straightforward and easy to rea…
Just now I embedded an amqp client into my app. To do that, I had to create a configuration class that instantiates necessary queues, exchanges and binds them to eachother using builder syntax and beans. The spring boot app lazily handles rmq client initialization and I didn't have to think of object lifetimes. That kinda sorta simplified my job. However, your point still stands, I had to learn new syntax (I learned…
I have no need for one of those, I'm good building some fairly simple microservices against spark without 'lazy client initialization' or any framework features.
That's kinda the point, it's a simpler toolset for a single purpose. You may have requirements that are made simpler for you by knowing the arcane ins and outs of a feature-rich framework.
Not everyone does, and bringing in said framework to achieve something simple in the name of "Maybe, in future, I may need this" is a prime route to an overcomplex, heavyweight mess. IMHO.
Maybe you've avoided Spring-related hell, but all the java devs I know who survived that era tend to groan whenever it's mentioned.