42 ms·

Java’s Cultural Problem

226 points by madmax108 4y ago

Nimitz14 4y ago
I'm worried about python also going in this direction. I see so many repos with the @property decorator everywhere for not a single good reason!
dylzy 4y ago
quickthrower2 4y ago
No idea why I thought this was going to be about the Indonesian island. But I did!
ris58h 4y ago
Shouldn't the title be "Java EE's Cultural Problem"?
- kdtsh 4y ago
  Alternatively, ‘My Problems With Quarkus.’
  - mrkeen 4y ago
    There's nothing here that applies to Quarkus that doesn't also apply to Spring/Boot or Micronaut.
    - kdtsh 4y ago
      They’re not talking about Spring/Boot or Micronaut though. There isn’t even any evidence the author has any more experience with them than what little they have with Quarkus. It’s a rant.
- izacus 4y ago
  > Shouldn't the title be "Java EE's Cultural Problem"? A person understanding what Java EE is wouldn't write such a rant post in the first place ^^
thriftwy 4y ago
> Any FP developer should scream when seeing this It would be an interesting observation in 2007, but fifteen years later with no industrial success of Haskell-inspired pure FP approach, I don't see why we should listen to "any FP developer" criticisms. It's not that I have anything against FP - let's just admit that side-effect pure FP is a "futuretro" of today. A future that never was.
- marginalia_nu 4y ago
  I do think FP in Java is a bit of a mistake. Record types has done a lot more for the language than streams and lambdas. I initially liked the idea of adding functional paradigms to the language, when the dust has settled all it does is create a sort of nasty Cronenberg language with most the drawbacks of both paradigms and few of the benefits of either.
  - thriftwy 4y ago
    I absolutely disagree. Lambdas has in many ways revolutionized Java and put it back on its feet. Java 8 has seen faster adoption than any other major Java version because of this. Compare it with Java 11 or indeed with absolute non-adoption of Java 14. Streams are not very well designed IMHO. That's why their usage remains limited. Much more useful and robust libraries are possible on top of Java lambdas support. Since everyone is now on Java 11 (and many on Java 8 still), we will only really see the records used widely in five years or so. The modules stuff was a huge mistake in my opinion. Some people tend to like them in theory, but in practice they absolutely destroyed the adoption of newer Java versions and set Java 11 back by 10 years (literally).
    - bluejekyll 4y ago
      My issue with lambdas in Java is the complexity of types in defining interfaces that receive generic Functions as an argument. Really seems like a better definition could be used there, new language syntax possibly. On the topic of Streams, the big issue that always crops up is exceptions. Streams and Exceptions are nearly incompatible with tacked on constructs that are painful to use. Any IO oriented program will have to face the issue of what happens to the Stream if an Exception is thrown.
tannhaeuser 4y ago
https://github.com/Hello-World-EE/Java-Hello-World-Enterprise-Edition https://github.com/Hello-World-EE/Java-Hello-World-Enterpris...
- Tiddles-the2nd 4y ago
  Obligatory Fizz-Buzz EE. https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...
- Tiddles-the2nd 4y ago
  Also this is just weird, it tries to be EE but it just ends up being convoluted without applying the patterns correctly. E.g. all the logic is executed in the constructor of HelloWorld.java - I can't imagine that ever getting past code review.
  - tannhaeuser 4y ago
    Well it's on gh so why not fork and fake a PR with your code critiques (plus lots more, such as heretically not using a symbolic constant for zero) to make the satire perfect?
    - JanSt 4y ago
      "The instantiateHelloWorldMainClassAndRun() method should be private. This issue is blocking half of the team, please fix asap"
  - KptMarchewa 4y ago
    Also, hungarian notation I in front of interface name is something I've never seen in Java - it's a C#/windows pattern.
    - tannhaeuser 4y ago
      Sadly, it's a thing in Eclipse/SWT-derived or -inspired codebases.
nilsb 4y ago
Is it just me or is understanding those examples virtually impossible if you're not intimately familiar with that particular framework? Then again... I guess that's the author's point.
- ris58h 4y ago
  Yeah. It's the issue with the framework not the language.
- throw_m239339 4y ago
  The examples use CDI (dependency injection through annotations) and yes, these annotations become hardwired to the business objects... Java has some kind of traits now through interfaces so it's not much of a problem today.
  - mrkeen 4y ago
    > Java has some kind of traits now through interfaces so it's not much of a problem today. Well that's the article's premise, right? Opening sentence: Java is good by modern standards, from a technical perspective Later on: Java’s culture eschews common sense approaches > so it's not much of a problem today. Every Java codebase I've worked on in my career has had plenty of this crap in it. The culture has settled on doing it this way.
    - democracy 4y ago
      What non-java codebases you worked on (of similar magnitude) that didn't have plenty of crap in it?
    - HelloNurse 4y ago
      Java encourages doing things like they were done 15 years ago because rewriting reams of low-value boilerplate with delicate architectural impacts is neither fun nor (at first sight) valuable. Typical immature enterprise organizations tend to extend the system with low-risk new features instead of refactoring and remaking old stuff.
cruunchMuncher 4y ago
You need to educate yourself and learn Java better
- cruunchMuncher 4y ago
  Java is great
- tandr 4y ago
  Learning Java once is easy. Understanding it is fine too. But learning new framework every time you switch projects - not so much. Because every time it becomes a gargantuan task, with all the dependencies that it pulls. And the moment you wants to do a tiny step aside, you need to learn intricacies of internal working of said framework just to something oh-so-slightly different than original authors envisioned. And then add couple more libraries, and endless conflicts, and stubs, and injection debugging nightmare. The maintenance of the dependencies becomes a full time job... Yeah, Java is simple. Everything else around it makes it almost unbearable with mental load that you need to keep just to move forward with a simple change.
  - democracy 4y ago
    What language is different so by learning its syntax you don't need to invest into learning its frameworks?
    - foobarian 4y ago
      Maybe a language that few people use and hence don't have but one or two frameworks. Would explain a lot.
zcw100 4y ago
This is just an angry rant by someone describing themselves as a “functional programming enthusiast”. The post is only tangentially about Java and is really about a framework called Quarkus. If there’s a culture problem it’s the “Look at me. I learned something new and now I’m going to do my best to burn down everyone else”. If you want to program in Haskell or whatever have a great time. Think it’s so great? Prove it by writing great software with it.
- grumpyprole 4y ago
  The way I see it, is people searching for a better way, after years of trying to actually use Java. And what does Java's chief architect think? "It is my belief that the best direction for evolving Java is to encourage a more functional style of programming. ... We're not going to turn Java into Haskell, nor even into Scala. But the direction is clear." https://mail.openjdk.org/pipermail/lambda-dev/2011-August/003877.html https://mail.openjdk.org/pipermail/lambda-dev/2011-August/00...
  - fedeb95 4y ago
    What do you mean "trying" to use? Many corporations use it with profit. Is there a better way to make money? Probably. But this way is very much used and profitable enough. So trying is not the right verb...
    - grumpyprole 4y ago
      Yes they have succeeded in using Java to make profit, but argubly not in creating reliable, secure and easily maintainable software. Like I said, even Java's creators believe there is significant room for improvement.
      - kaba0 4y ago
        I would argue about that reliable, secure and easily maintainable software. Surely there are terrible examples for unmaintainable software monsters in every language, Java not being exempt. But based on the only relevant, existing evidence on the topic: empirical evidence, Java is probably one of the, if not the best at the software maintainability game. Clean FP in and of itself doesn’t solve the problem, so it’s not like there is a clear cut answer to the question. I do agree that incorporating more and more immutable elements to java is a worthwhile goal to pursue, but at the same time I also believe that on a local, single-threaded scope mutability can increase understanding, so neither imperative nor pure functional is an answer to every problem in themselves. We should strive to make both toolkits available and be ready to use the correct one for each case, the pragmatic approach.
fedeb95 4y ago
Java doesn't have a cultural problem. People need to understand that Java culture is almost entirely enterprise culture. Don't want a language influenced by that for your project? There are plenty out there, pick one
- grumpyprole 4y ago
  It has a culture of over-engineering, just look at Log4J or Spring with its AbstractSingletonProxyFactoryBean's. More complicated and far more adhoc than any abstraction should be.
  - democracy 4y ago
    Log4j is too simple to use and configure - what exactly is over-engineered and why we as users would even care if it's overengineers somewhere under the hood? It's hard to criticize Spring Core - it's too mature and popular to worry about some edge-cases where it didn't fit the developers view of the world. As with any other software - don't use it, or improve the existing one (and Spring Core is open-source), or write your own. But now it's de-facto the foundation of the Java programming landscape.
    - grumpyprole 4y ago
      > what exactly is over-engineered and why we as users would even care if it's overengineers somewhere under the hood? Log4J has been a major embarrassment for the Java community. I suggest you Google it, if you don't know why. > It's hard to criticize Spring Core Spring Core is at best a dynamic (reflection based) band-aid to work around Java's lack of expressiveness. It comes at a significant complexity cost and loss of static guarantees. You cannot both love Spring and Java. So which is it? :)
      - democracy 4y ago
        Oh, please, ok, there was a security flaw - how does it prove that it is over-engineers? If anything it is too flexible and gives developers too many features so that one of them was compromised.
deleted 4y ago
[deleted]
dmitriid 4y ago
Java is fine. Java frameworks are not. I'm still waiting for ASP.Net-like framework in Java where all configs are explicit and the framework doesn't require hundreds of confusing annotations just to display a hello world page.
- tandr 4y ago
  Yes, 100 times yes! Looks like we posted similar thoughts at about the same time. https://news.ycombinator.com/item?id=32896598 https://news.ycombinator.com/item?id=32896598
- mrkeen 4y ago
  I don't know what "ASP.Net-like" implies, but take a look at https://sparkjava.com/ https://sparkjava.com/ It was quite a pleasure to use.
  - KptMarchewa 4y ago
    Only if you're fine with using something that had latest release in 2020.
    - ihateolives 4y ago
      https://javalin.io/ https://javalin.io/ is a fork of Sparkjava, same simplicity, updated regularly. Used it in couple of glue projects.
- spockz 4y ago
  Spring is becoming more functional programming oriented: https://www.baeldung.com/spring-5-functional-web https://www.baeldung.com/spring-5-functional-web. Also functional bean definitions, etc. Perhaps mostly driven to be able to (more easily) use graalvm to generate native images.
  - kaba0 4y ago
    Not sure that is such a big step-up — I would rather prefer a much deeper support for records over POJOs.
tomerbd 4y ago
I'll take java any day for server side, I don't know why but when I use java things just tend to be much more stable and It does not take me more time to write code at all.
bluejekyll 4y ago
I agree so much with this article. Java EE practices bloat programs, waste memory, and make debugging harder. Let alone all the language constructs. > Java allows null objects… that ship has sailed Not necessarily, with project Valhalla, it should be possible to have generic Value Types in the language that would allow things like Optional to be defined on the stack where it would be non-null and then all it’s methods for checking if the Object it references would make sense, and actually work. This would be in contrast to today where the Optional type isn’t as useful as it seems since it can also be null. Anyone know the status of this? https://en.m.wikipedia.org/wiki/Project_Valhalla_(Java_language) https://en.m.wikipedia.org/wiki/Project_Valhalla_(Java_langu...
- democracy 4y ago
  Java EE is not really a thing in the wild for long long time...
  - bluejekyll 4y ago
    Spring and (and Quarkus apparently which I haven’t used) brought along a lot of the Java EE concepts. It lives on if not in name, in spirit. Thus the cultural problem this article discusses.
    - democracy 4y ago
      Well technically they are built on JEE APIs, but JEE is not a 10 page spec, so combining all of JEE into a pool of "horrible designs" would be somewhat naive.
  - pjmlp 4y ago
    Not only it is still around, Spring actually depends on many of the same standards.
    - StevePerkins 4y ago
      This take is so exhausting. It really is, "Tell me that you know little about Java beyond forum comments that you've read, without telling me that you know little about Java beyond forum comments that you've read". The most important Java EE specifications (now "Jakarta EE", as "Java EE" hasn't existed for years), are: CDI, EJB, JPA, JTA, JMS, JAX-WS, JAX-RS, JSTL, JSP, and JavaMail. Of that list, a typical Spring Boot application in the wild miiiiiiight use JPA. And that is totally optional, with a handful of newer ORM frameworks seriously eating into its market share. Even JPA itself didn't come out of the "Java EE" world. Hibernate won the ORM wars back in the day, and so the Hibernate folks were allowed to write the JPA spec, making it near-identical to the existing Hibernate API. Spring has extensions that allow it to interface with nearly anything in the Java ecosystem (and its DI container makes it easy to write an integration to anything new). However, while it CAN interact with all of those Java EE API's, it doesn't NOT "depend" on them! The story of Spring's relationship to Java EE is the classic "embrace, extend, extinguish". Reddit and HN are able to grasp that pattern just fine when they are slamming Microsoft. However, they can't grasp get it in this context. I honestly believe that the vast majority of people's Java knowledge on Reddit and HN comes from ignorant comments that have been in a self-reinforcing recursive loop for years.
ngalaiko 4y ago
LAC-Tech 4y ago
Halfway through reading - is this just another episode of "FP Programmers Don't Understand Other Paradigms?" Because honestly at this point I'm pretty much all caught up on that.
ncmncm 4y ago
"I enjoyed programming in Java, and being relieved of the responsibility for producing a quality product." — Mark Dominus https://blog.plover.com/prog/Java.html https://blog.plover.com/prog/Java.html
- tempodox 4y ago
  > In Java, you can forget about doing it in the cleanest or the best way, because that is impossible. Whatever you do, however hard you try, the code will come out mediocre, verbose, redundant, and bloated ... +1, I love this article. Do language developments since 2014 invalidate any of his characterizations?
  - kaba0 4y ago
    No, language developments since 1995 invalidate them.
    - ncmncm 4y ago
      This seems to be contradicted by agreements posted. Or is use of features introduced since 1995 especially limited? I doubt many still use Swing, anyway.
- the_gipsy 4y ago
  I've read this quote after working one year on a java project, and it just nails the sentiment. Both from devs like me that wouldn't pick java where you'd expect this kind of sentiment, but also from veteran java devs who also treat "quality" as something simply unobtainable.
democracy 4y ago
Sorry, it is not worth reading and analyzing. You can come up with a lot of criticism about Java (just as about any other technology) but the content is just too shallow.
unwind 4y ago
I was going to post a comment about the regex used to (coarsely) validate email addresses made no sense, but when I opened the article in a new tab to copy for quoting, it had changed. :) It's now "^[^@\\s]+@\\S+$" with a comment also stating that it could be better. That's at least sensible, the original one that I first saw was more or less "^[^@]@.*" which kind of makes no sense. Oh well, great that the author caught it, of course.
- bqmjjx0kac 4y ago
  I'm still not convinced that it's correct. Probably worth perusing RFC 3696. https://www.rfc-editor.org/rfc/rfc3696.html https://www.rfc-editor.org/rfc/rfc3696.html
tannhaeuser 4y ago
It must be said that this coding style may be the norm with Quarkus (and with Spring which it is trying to replace on graalvm/native-image), but isn't required by Java itself. As always, Spring-like Java buerocrats have chosen to chase and over-engineer trivialities because it's so much easier lol; well until using your framework becomes a study in psychology or software archeology. Update: what I don't get with Quarkus though is why did they set out in Spring factory style only to have to immediately limit this for native-image's "closed world assumption"
- absove 4y ago
  I'm pretty sure Quarkus tries to stick as close as possible to Java EE APIs with some limitations to accommodate the lack of runtime reflection, being Red Hat's answer to application containerization for which JBoss isn't a good fit, if it looks like Spring it's mostly because it's a popular style in Java.
kache_ 4y ago
Over abstraction is the devil :)
ilitirit 4y ago
Reading these comments, it's strange to see that the "Java" paradigm/context issue still exists after all these years. I have never had significant problems with Java-the-language. But, like with many other programming languages out there, you can't really dissociate the language from the environment and everything that goes with it. The paradigms, VMs, IDEs, patterns and practices etc etc. And for the record it's not just Java (it just seems to be more pronounced in the Java-development ecosystem). For every person who waxes lyrical about the joy of working with C# (for example), there are 3 more that will tell you anecdotes about "assembly hell". Or how Visual Studio is slow and a massive memory hog. Or that there is no proper Forms support on XYZ-os. Those are all fair points, but more often than not, they have little-to-nothing to do with current discussion. IMO, I think it's usually far more productive to try to understand the discussion in context than to veer off into irrelevant semantic issues or tangential anecdotes.
- dvfjsdhgfv 4y ago
  You conclude with: > Those are all fair points, but more often than not, they have little-to-nothing to do with current discussion. but earlier you noted that: > you can't really dissociate the language from the environment So it seems like a self-contradictory position.
  - ilitirit 4y ago
    Why would it seem that way? Why can't I say: "I like how C# implements XYZ" instead of "I don't like the C# development environment, but I like how C# implements XYZ"? What value is there in qualifying every aspect of a discussion given that you cannot fully dissociate <A> from <B>?
- jimbob45 4y ago
  You choose weird examples. I don’t know how VS can be considered slow when it only has one real competitor - JB Rider - and that competitor offers C# support. Also, I’d there a language that competes with C# that doesn’t also have some form of “assembly hell”?
StrLght 4y ago
What a stretch from a single badly designed (in author's opinion) framework to "cultural problem"
bullen 4y ago
It's not culture, it's the fact that Java enables huge structures to run that has become it's problem. Listen to James in the last chapters of this interview: https://www.youtube.com/watch?v=IT__Nrr3PNI https://www.youtube.com/watch?v=IT__Nrr3PNI Just because Java can run bloated is not a good reason to do so. I have written my own HTTP/DNS server with built in DB from scratch and it's 150KB (around 10.000 LoC) and that's how you use Java properly.
- philipwhiuk 4y ago
  > I have written my own HTTP/DNS server with built in DB from scratch and it's 150KB (around 10.000 LoC) and that's how you use Java properly. So you've probably got 90,000 bugs left to fix then. Seriously these "I built my tiny thing I claim implements X protocol" are very tedious. You think BIND is deliberately overcomplicated or do you think, maybe, just maybe your tiny server has lots of hidden problems.
  - bullen 4y ago
    I took responsability and over 10 years I fixed the bugs. It hosts a MMO with 350.000 customers at 10x perf./watt than all AAA studios.
  - CyberDildonics 4y ago
    This person also claimed that a rise in electricity prices will mean people won't be able to afford to play half life 2 and starcraft 2: https://news.ycombinator.com/item?id=32523818 https://news.ycombinator.com/item?id=32523818
Kostchei 4y ago
throwaway4good 4y ago
Can we maybe also talk about FP’s cultural problem: that lots of people with a functional programming background just don’t get object orientated programming and instead of trying to understand it, dismiss it as crap and enterprisey.
- tempodox 4y ago
  There will always be people who misunderstand things or are badly informed. Equating a whole culture with that subsection is not fair. Also, are you insinuating that those who “get” OOP can't find FP a superior approach for certain problems?
  - throwaway4good 4y ago
    No but I am implying that the author doesn't get OOP and makes no attempt to do so.
- vonwoodson 4y ago
  The very idea that FP programmers don’t understand OOP is absurd on its face. You point to an undergraduate CS program that is teaching FP before imperative and OOP paradigms; you find me an FP zealot who hasn’t written more OOP than FP code. This is a nonsense “reverse racism” argument rehashed to be about programming paradigms, and I won’t stand for it.
  - UncleMeat 4y ago
    When I was there, intro CS for the college of arts and sciences at UVA was taught in scheme. Lisp-y intro classes can be found at a large number of universities. MIT now teaches intro CS in python (multi-paradigm, not OOP) but famously taught it in Lisp for many many years.
    - cutler 4y ago
      Why stop there? Why not go the whole way and teach CS in Javascript? Python's tentacles of mediocrity know no bounds. It's as if the whole teaching profession is sleepwalking towards conformity.
tofflos 4y ago
I like SmallRye Config and I feel it's designed this way because of the problems it tries to solve. The following is an excerpt from the MicroProfile Config standard which SmallRye Config is an implementation of: > The majority of applications need to be configured based on a running environment. It must be possible to modify configuration data from outside an application so that the application itself does not need to be repackaged. > The configuration data can come from different locations and in different formats (e.g. system properties, system environment variables, .properties, .xml, datasource). We call these config locations ConfigSources. If the same property is defined in multiple ConfigSources, we apply a policy to specify which one of the values will effectively be used. > Under some circumstances, some data sources may change dynamically. The changed values should be fed into the client without the need for restarting the application. This requirement is particularly important for microservices running in a cloud environment. The MicroProfile Config approach allows to pick up configured values immediately after they got changed. One reason we don't know whether SmallRye Config is reading from a file or querying a database at development time is because that choice has been deferred to the system administrator at deployment time. Records are immutable. If we want to be able to reconfigure applications at runtime it might make sense to use a mutable data structure. You can load configuration programmatically if don't want to use dependency injection and/or want something that is easier to test. See https://download.eclipse.org/microprofile/microprofile-config-2.0/microprofile-config-spec-2.0.html#_simple_programmatic_example https://download.eclipse.org/microprofile/microprofile-confi....
- deleted 4y ago
  [deleted]
- le-mark 4y ago
  What are you suggesting? That one should read the documentation? And have a level of understanding why things are the way they are? Blasphemy! Zero ignorant screeds would be written! Productivity would increase 10 fold!
andor 4y ago
The equivalent Spring @ConfigurationProperties annotation supports records. Spring also requires fewer annotations overall and none of the CDI ones.
- jillesvangurp 4y ago
  There's even kofu, which largely get rid of annotations entirely in favor of declarative Kotlin DSLs. Very similar to how ktor works. I tend to use Spring this way as well. E.g. we use the router dsl rather than having annotated resource classes. Kotlin DSLs are superior to using annotations IMHO. More explicit/declarative, similarly easy to read. And it gets rid of all the builder boiler plate that you have in Java. Annotations are definitely overused in some frameworks. And debugging them is a bit tedious when the magic breaks; which tends to happen with the more complicated stuff. I've seen some spectacularly misguided things happen with e.g. the @Transactional annotation having some not quite intended side effects. I always preferred just using TransactionTemplate. That makes the transactional boundaries much more clear than junior engineers copy pasting annotations until stuff vaguel stops breaking. Which, btw. is literally what people seem to do with @Transactional. I've cleaned this up in several projects. Annotations with complicated side effects are a bad idea; especially when you need to understand what those effects are.
strictfp 4y ago
This is why I left Java. Everything "looks nice" on the surface with annotations, but you loose the flexibility of code and a lot of the available tooling. Plus you need to be a real expert to debug issues and solve problems; understand framework architecture and read reflection code. You can't just put a breakpoint in there and start debugging. It's optimizing for the wrong thing. The bad news is; this culture is permeating somewhat into Rust now that more Java devs are moving over. This whole attitude is IBMs fault. They tried to get into the Java market by applying their big iron terminal thinking to create Java EE. Java under Suns management was a lot more like golang today; pragmatism, fewer language features, and focus on writing code.
- democracy 4y ago
  Seriously, the speech is from the 2000?
- pjmlp 4y ago
  Java EE was created by Sun themselves, it was reborn from a Objective-C framework for OpenSTEP called Distributed Objects Everywhere, better get your history straight.
  - strictfp 4y ago
    Interesting. I can't find any sources for the IBM story, but I thought I read it here on HN. I found at least one similar comment; https://news.ycombinator.com/item?id=30538784 https://news.ycombinator.com/item?id=30538784 . So you're saying it was just Sun and not IBM?
    - pjmlp 4y ago
      Yes, unless you consider Wikipedia info possibly bogus. "By the time DOE, now known as NEO, was released in 1995,[1] Sun had already moved on to Java as their next big thing. Java was now the GUI of choice for client-side applications, and Sun's OpenStep plans were quietly dropped (see Lighthouse Design). NEO was re-positioned as a Java system with the introduction of the "Joe" framework,[2] but it saw little use. Components of NEO and Joe were eventually subsumed into Enterprise JavaBeans.[3]" https://en.m.wikipedia.org/wiki/Distributed_Objects_Everywhere https://en.m.wikipedia.org/wiki/Distributed_Objects_Everywhe...
eastbound 4y ago
Shall we definitively say that a problem of all languages is that they evolve to the maximum complexity that a single brain can understand, then they collapse because nobody understands them? All languages start with “Lightweight, lightening fast and hotreloadable!”, then become a gas plant as they need abstractions to handle industry concerns (hello Reflection API, javaagents, NIO, functional programming, now the Cloud, then AI), Are there intrinsic properties a language can have that prevents bloating to the maximum complexity a human can handle, and yet allows it to handle industry usecases?
- kaba0 4y ago
  Java is absolutely not victim of language-complexification by adding the n+1th fancy feature of the day, if anything it is one of the few exceptions — it is a quite old language and yet modern Java has very little differences to what it was back than — all the spring magic happens through its standard way of operation, everything is a class with methods, and these primitives are assembled in novel ways, that’s it, and that’s how it supposed to be. No async, coroutines (it gets solved on the JVM-level and exposed through method calls), no separate syntax for stream operations (those are just method calls with “builder pattern), etc. I greatly recommend Guy Steele’s Growing a Language talk about this exact topic.
- somewhereoutth 4y ago
  Indeed! The 'Complexity Horizon'. Any constructed system will tend to that horizon as it continues to be developed (particularly if by multiple people over significant timescales) - unless there is a concerted effort to pull it back.
  - eastbound 4y ago
    I love the ‘complexity horizon’ of algorithms: If something can be made simple, then we’ll build more complex things until we can’t understand it. All algorithm are always right above the maximum complexity that a single human can handle. Actually I believe it’s another surprising emergent effect of open-source: Linux’s or Postgres’ complexity horizon seem to have been managed, so that adding new stuff didn’t increase complexity, and it’s still possible to add new stuff THIRTY years later. As opposed to Excel.
javajosh 4y ago
The author shows good taste referencing Dropwizard. Then shows deep (even dangerous) inexperience with his email type. So while I encourage writing like this, and I especially like the exercise of considering all the different ways configuration can make it into an application, I don't think this piece would be worth referencing in, say, a work argument.
- HelloNurse 4y ago
  Reading between the lines, there seems to be a significant hope that an easy solution exists. Maybe a young programmer? The kind who could write the EmailAddress class because they didn't laugh adequately at the very idea?
- krzyk 4y ago
  Actually the email example is the best from the article, validation using external libraries is a hell and I really would like my codebase to get rid of it.
ACV001 4y ago
It shows lack of java knowledge and understanding of OOP. Rants about Java, but talks mostly about Quarkus.
- 411111111111111 4y ago
  > One of these days I’ll find out what the heck is a “bean”. It does indeed show a confusing lack of Java knowledge. It is quiet strange that this tidbit was in it, as I'm not sure how it's even possible to not know what a bean is if they've ever worked with the language for any amount of time. Unless it was meant as a sarcastic remark as the term is sometimes used to express what they enable (eg. singleton services) vs what they are
  - pwdisswordfish9 4y ago
    I have worked with Java for a year or so and I don’t know what a bean is.
    - kaba0 4y ago
      It’s a standard and it’s similar to a naming convention, but instead applied to class structures. Instead of extending/implementing some strange, third-party classes, you create a POJO (plain old java object) and you add getters and setters for the fields you want to make externally reachable. Now tools that don’t know anything about your code can use them through reflection based on these conventions, this is how dependency injection, JPA, every Java EE/Spring thing operate.
    - cutler 4y ago
      Then you ain't drinkin' the coffee.
  - krzyk 4y ago
    Everyone should forget about "bean" and don't reuse that word.
nerdponx 4y ago
I found this interesting because the ConfigMapping stuff reminds me a lot of Python. I knew that Python OO was inspired by Java OO to some extent, but I didn't expect so much similarity. I think Python could learn similar lessons here. But the flipside is that none of this stuff is a catastrophe in Python either, and the author's tone seems a bit out of proportion with what they're complaining about. The author complains about: 1) not knowing the underlying data model and implementation details that might affect their design 2) mutable attributes and non-final classes 3) lack of obvious composition root In the Python world, we often say that "we are all consenting adults here". Usually there is no need for private, immutable, or final things because people read docs know not to stray from the public interface. The trust also runs the other way, and it's very rare for the function to perform some kind of weird unexpected mutation. A function that mutates a user-provided object without the user's knowledge or consent is usually considered a bug. I actually found exactly this bug recently in a framework I was using, and several people were up in arms about it on the issue tracker. Yes, immutable data makes it harder/impossible to write such bugs. But the community generally has not devolved into a Satanic orgy of mutable state. Likewise, if a framework did something ridiculous like reloading a config file at every request, nobody would use it! I could only imagine how lively that GitHub issue thread would be. A framework that makes fundamentally bad design decisions tends not to be a lasting part of the community. The only one that really would suck, and that also doesn't seem to be a problem in Python, is the lack of an obvious composition root. I have never heard this term before, but it is a very very well-established pattern in Python application and library architecture. A framework that made it hard to design libraries in a conventional sensible way, would not be a very popular framework.
- UncleMeat 4y ago
  > Usually there is no need for private, immutable, or final things because people read docs know not to stray from the public interface. My experience is that this fails as soon as you've got a modest number of users. It only takes one user doing something foolish and now you've got a fight on your hands when you want to change an internal component of your system. And you'll often lose that fight.
  - 4y ago
axilmar 4y ago
I couldn't agree more. I currently work on a web application that uses Spring Boot and Vaadin and it sucks a million miles. Spring sucks separately from Vaadin, which sucks another million miles. The whole thing with beans and annotations is an abomination and whoever thought of it should be shot (not literally, for crying out loud!).
cletus 4y ago
> Java has null in it, all object references can be null, and it’s too late for that to change. At Facebook I used Hack, which is a fork of PHP. They've spent a ton of time on the type system to the point where I'd argue it's very good. One of the best things is that nullability is built into the type system so for: vec<?string> $a; // alows nulls vec<string> $b; // does not allow nulls function foo(string $s) {... } you get: $a = $b; // this is OK $b = $a; // error $b = Vec\filter_nulls($a); // OK foo($a[1]); // OK foo($b[1]); // error if ($b[1] is nonnull) { func($b[1]); // in this block the type is 'string' so this is OK } func($b[1] as string); // OK but throws a runtime error if it's null I was surprised just how useful these seantics are and how many errors could be avoided this way in annotated code (there are an ever-dwindling number of corners of the FB code base that aren't property typed). Like Java, this operates on type erasure at runtime so there are limits to the protection. I hope other languages with less advanced type systems (and I include Java when I say that) adopt nullability as a first class type concept. There's a lot of talk here about dependency injection. This was a big innovation in Java 20+ years ago. For some reason no other language seems to collectively wring its hand about DI quite like Java does. Java does suffer from a lack of duck typing, hence all these typically one use interfaces get created. It also has other issues (eg you can't make your own class that'll be a snap--in string replacement). Guice I consider to be a form of torture. Maybe it's time Java decides to stop rigidly solving a prroblem no one else seems to have. Maybe that part of a cultural problem. As for the "enterprise" problem, is that specific to J2EE? Is that still a thing? Or is just the consequences of the patterns J2EE promoted that still propagate (eg rigid DI)? It's generally better to have some structure rather than none, even if it's a bad structure. Maybe I just don't travel in the circles where you see a lot of bad Java enterprise code? Java has warts but the runtime maturity in particular is still world-class. I wish Google had bought Sun back in the day (I bet Google does too given the costs and consequences of the lawsuits) but Java continues to plod along and get better without getting massively complicated (I'm looking at you C++) so it all seems mostly fine.
- foobarian 4y ago
  Re: better null handling, languages like C#, Kotlin, and TypeScript all do similar things and IMO Kotlin in particular is a very nice experience while retaining Java interop.
exabrial 4y ago
I find the Java 17/Good IDE quite nice. Most of all the complaints have been resolved with the language, and it’s still faster than every other memory safe language (except Rust, which smokes everyone)
jeroenhd 4y ago
I strongly dislike working with most Java frameworks because I disagree with many of their design decisions (and type erasure keeps finding ways to bite me in the ass) but I accept that when I use Java, I need to comply with its expectations and work with the ecosystem. This reads like a functional developer who believes that functional programming is The Only Right Way to program anything trying to shoehorn functional programming into a framework that's decidedly not functional. Sorry, but that doesn't make sense. I agree with some parts of this; the lack of proper nullability in the type system is very annoying especially once you've worked with more modern languages. The conflict between recommending the use of `final` and major libraries being incompatible with such use is also quite jarring (though there are alternatives). However, statements like > This should be a pure data structure; go unexplained, assuming that "every FP developer" should know this for an absolute truth because... why, exactly? I can easily see these methods have side effects because they read configuration files, for example. Hard-coding IP and port in the Java files is a terrible idea. Sure, the record based abstraction is nicer, but records are not supported for a large part of the JVM ecosystem because upgrading Java versions is slow and painful for larger applications. I also don't understand this "annotations are bad" argument. Yes, some annotations should be built into the type system (and there are projects to accomplish this!) but what's wrong with @NotEmpty? Furthermore, the email address solution uses Objects.requireNonNull(value) without any annotations, making it difficult if not impossible for IDEs and static code analyzers to determine the nullability of this field. It also throws exceptions without any indication that the constructor can fail (I know many Java developers don't like the `throws` keyword but if you're going ham on code style and semantic programming, at least be clear what can and cannot fail). Java is not a functional programming language and the ecosystem even less so. It's an imperative language with functional aspects inserted to make your life easier. Projecting functional paradigms onto it is impractical at least, or maybe even just plain wrong; it's the wrong tool for the job. I personally find many of Kotlin's paradigms get much closer to the functional programming paradigm than Java, especially with the new libraries and frameworks that make use of Kotlin's language features. Kotlin is as imperative as Java but it's val/var system combined with (data) classes compiling to "normal" Java classes make it an excellent candidate for immutability constraints, stricter types, and other such annotation replacement language design. As an added bonus, the language works quite well together with most Java libraries.
moondowner 4y ago
"Java is good by modern standards, from a technical perspective, the platform having received a lot of improvements from Java 8 to 17. Unfortunately, it still stinks, and the problem is its "enterprise" culture." Then the author rants about a specific Java-based framework and does not mention anything about the use of Java in the enterprise or any supposed cultural problems it may have.
- krzyk 4y ago
  Issue is that Quarcus advertises as the new, hip framework but what it does it still reuses the old pre-17 constructs. It should use the latest and greatest from Java if it wants to be a game changer, not repeating what Spring did with their support for old, deprecated JDK releases.
yotamoron 4y ago
So you think there's some magical language, where things will never become complicated, syntax will always make simple sense and no developer can f** things up? Think again. No such thing. Java is a tool, and like every other tool - you have to know how to use it if you want to get the best results from it. When used by the right developer, Java can yield beautiful, concise and clear code. When used by the wrong developer... well...
HiIAmIlNano 4y ago
The author is using field injection and claiming that the field cannot be private. As far as I know he should be using constructor dependency injection and make the field private and final. That way is also easier to write unit tests and maybe make use of interfaces in case he wants to avoid using a mocking framework. Not only that but if I recall correctly quarkus resolves dependencies and config files at compile time and not at runtime using reflection as spring does.
- vips7L 4y ago
  The author sadly just doesn’t know what he’s doing.
  - mbo 4y ago
    Then this is clearly a library UX problem. Him not understanding what he's doing is the point!
jcon321 4y ago
You don't have to follow a framework explicitly to have success. You can use vanilla components of a framework and then treat the entire application more functional esque. The author's examples are just so overboard. Annotations on fields to represent validation is valid and I see it all over JavaEE, but I've never thought of as my "go to". (Or else you are then locked in to how to represent return values, relaying messages, entry points). Live by the framework, don't die by the framework.
ragnese 4y ago
I agree. Java has improved as a language quite a bit in recent years. And I don't even mean that in a "Java has followed the cargo cult of what's fashionable in programming languages"-sense. I mean that things like Records to define value types have "always" been desired in Java- at least in the 10 years that I've worked with people on Java code. If Java didn't automatically make everything equatable/hashable, it would be a different story. Anyway, Java still has baggage that I doubt will go away any time soon. My biggest two complaints with Java are that null exists outside of the type system and that they mix runtime type reflection and non-reified generics. The latter features being actually incompatible with each other makes working with Java libraries/frameworks a minefield. But, aside from those issues, the OP is totally right that so much of Java's bad reputation comes purely from library design and culture. Even when I preferred OOP architectures, I hated the fact that so many Java libraries and frameworks required a bunch of annotations for everything, even when it really wasn't necessary. I get that Java code can be verbose, but if you don't like it, use something else- don't just throw away compile time safety and information for a janky runtime-checked "DSL" where a bunch of the features don't even actually work together (I'm mostly looking at you, JacksonXML, but also Spring, et al). Everyone praises the Java ecosystem as some kind of selling point, but I find that while the ecosystem is indeed broad, the actual quality and productivity of many of the popular libraries and frameworks is fairly low. And by "quality", I don't necessarily mean number of open bug reports, I mostly mean that the APIs are really difficult to understand and use correctly. In some sense the devs are "off the hook" when my app doesn't work correctly because "this is documented behavior", but that makes me think I should just start writing documentation for my apps' bugs and seeing what my boss thinks... ;)
- titzer 4y ago
  Not sure what you mean by null being "outside the type system"--it's just the bottom type, assignable to all references. I loved Java circa 2002-2005 and was deeply interested in JVMs. However I wanted to develop the JVM itself, and it turns out that Java is bad systems language. So I really want a systems language because VMs are the itch I have. What's weird to me are the choices that Java has made in its evolution. In Java 5, the VM and library powers-that-be basically killed reified generics, forcing type erasure. That was a huge language design mistake precipitated by not wanting to upset the apple cart of libraries and the .class format. But in versions 6 and 7 they updated the class format anyway, to add stackmaps and invokedynamic! I never understood why such a key language feature didn't get the requisite VM support it needs to be done right, but completely marginal features did get VM support. Poor choices IMHO. Java is just a big ball of semi-typed mud at this point. There are no layers and hardly any separation between what features are in the VM and what features are in the class libraries that are wormholes into the VM.
vbezhenar 4y ago
I really don't like Quarkus approach. It's full of magic. It's everything I'd love to get rid of. I'm using Spring which is kind of full of magic but I spent 15 years learning to deal with this magic, so it's bearable to me. But it does not mean that I like it. I liked Helidon SE approach (not MP, MP is the same EE crap). It's 100% code, no magic. What I didn't like is reactive, I don't need reactive, so I don't use Helidon SE for my projects, I still endure Spring. But if someone enjoys reactive programming and wants zero-magic approach, I can recommend it. Helidon Nima might be a saviour to me. I didn't research it yet.
- rr888 4y ago
  I'm not sure the point of Quarkus. Its an easy way to get started with GraalVM development, but pre-compiled Java isn't any use for dev work. The autoreload classes is easy in most dev environments already too.
  - vbezhenar 4y ago
    It seems to me that the point of Quarkus is to allow old EE applications to be ported to Graal Native. For example they did that with KeyCloak, it was Java EE application running on top of JBoss Application Server, now it uses Quarkus.
- mwcampbell 4y ago
  I agree with you about both magic and reactivity (meaning, IIUC, asynchronous rather than blocking APIs). Helidon Nima looks interesting. But what I'd really like in Java is a non-magic, non-reactive server-side web framework that's designed to be used for full-stack, server-side web applications, including things like strongly-typed HTML templates, form validation and rendering, cookie-based authentication, and CSRF protection. Something we can use to develop a complete server-side web application, the kind that everyone used to write before the division into back-end API and front-end SPA became popular. Helidon Nima might be a good starting point for such a framework. Another starting point worth looking at is Javalin [1]. [1]: https://javalin.io/ https://javalin.io/
  - 4y ago
p2detar 4y ago
What does one do to land a Java job when neither Spring, nor Quarkus experience is present? Backstory: I have been using Java SE for more than a decade now. Currently building a Java 17 pure Vert.x project. I'm quite seasoned with the language, but not with large frameworks like Spring. I don't have any desire to learn Spring. Quarkus seems like a good choice on the first look, but I'm also looking for other options. Hints anyone?
sonicgear1 4y ago
Let's just agree that java is trash.
cies 4y ago
That's why there's Kotlin, by JetBrains, who also make a framework name KTor.
didip 4y ago
I agree with the general sentiment of the article. It is clearly possible to write a straight forward Java code. See: Sparkjava, Javalin, or Vert.x. Hell, even Minecraft Java code is pretty easy to read. Too bad Java culture is dominated by consultancy-like culture, which promotes as many obfuscation as possible. The world will not end if you don’t use annotations and DI frameworks.
exabrial 4y ago
This is a dumb rant about something the author doesn't know anything about and hasn't bothered to understand or research. Dependency Injection is not functional programming. Dependency Injection solves a lot of problems and entire classes of bugs around application state, but with far more approachable stepping stones than something like pure functional languages. Pure functional languages solve state problems as well but are far more complicated and difficult to grok because of the paradigm shift. Whatever one chooses for a team of developers, the most important thing is being able to use the tools at hand. It's pretty easy to explain to someone what Scope is and how CDI has some standard scopes. The author doesn't even seem to understand how Java annotations even work.
rippercushions 4y ago
sorokod 4y ago
"I don’t care from where the configuration is being read" This hints at a junior developer. Once you have configurations depending on environment or geography you'd care a lot.
m3047 4y ago
I haven't programmed in Java in many years, except for making DAGs for Storm and a authorization metalibrary that none of the "real" Java programmers liked. Paradoxically the most sccinct statement of dislike concerned my choice of arraylike class: "THAT'S WRONG!". The Java programmers had source control, just like the rest of us. But their Maven configs weren't under source control, and they wouldn't help the rest of us with ours. I've concluded that I'm indifferent to Java, but not so good with Java programmers. There's a big ball of puzzling contradictions in the above. Have you heard of Lacan or Zizek? Well. Poetically speaking, I'll paraphrase Tom Lehrer and opine that "Java programmers must feel like a Christian Scientist with appendicitis". In my opinion: remember that. They've build a lot of ritual around notions of control and deliberativeness (that array problem). They're Catholic or Orthodox, really. The JVM is supposed to be "safe", and I have to ask: does the communion wine really turn to the blood of Christ? My father was a psychiatrist. I am well aware that Dr. Tim Leary was a pioneer in personality diagnosis, having found "The Interpersonal Diagnosis of Personality" on my father's bookshelf. I analyzed precinct level voting patterns, and they exist; but the question "is it something in the water, or new car smell?" remains vexing and unsolved. There is something that happens when people program in different languages with different tools, especially in groups. It's not just languages: how does Docker culture compare to NanoVMs on the Leary radar chart? But what I have for you is a (hopefully) playful personality diagnosis of some of the major programming languages. Make some popcorn. This is for entertainment purposes, but maybe it'll give you something to think about. https://www.youtube.com/watch?v=mZyvIHYn2zk https://www.youtube.com/watch?v=mZyvIHYn2zk
- docmechanic 4y ago
  Thank you for the best guffaw of the day. 'Poetically speaking, I'll paraphrase Tom Lehrer and opine that "Java programmers must feel like a Christian Scientist with appendicitis".'
jononomo 4y ago
I quit software altogether after programming in Java for about 7 years and decided I never wanted to program again. Then, a few years later, I discovered Python and jumped back in with delight. Now I have discovered Elixir and I'm super happy. But to this day I can't even look at Java code without that dying-inside feeling.
winnie_ua 4y ago
I don't get, why author is bitching about validation. What's the point in referencing article about Haskell, if Java don't have such parsing libraries. I've also saw that article translated to Rust, but it ended being article, not library. And many questions of how to represent valid state remained unanswered. And example provided, with throwing exception in constructor: that approach would just throw single error, but javax.validation approach allows to return list with ALL failed validations, so client don't have to fix errors one at a time and retrying to see next error. Small complain from me: EmailAddress class is not zero cost(unless java would have value types), but actually java devs do not care about this.
flakiness 4y ago
This thread makes me smile as an Android programmer. Android doesn't have the cultural problem discussed here, but it has its own set of problems (mostly rooted to the poor platform API design). It's so contrastive. Which do you like?

226 points by madmax108 4y ago

I'm worried about python also going in this direction. I see so many repos with the @property decorator everywhere for not a single good reason!

dylzy 4y ago

quickthrower2 4y ago

No idea why I thought this was going to be about the Indonesian island. But I did!

ris58h 4y ago

Shouldn't the title be "Java EE's Cultural Problem"?

kdtsh 4y ago
Alternatively, ‘My Problems With Quarkus.’
- mrkeen 4y ago
  There's nothing here that applies to Quarkus that doesn't also apply to Spring/Boot or Micronaut.
  - kdtsh 4y ago
    They’re not talking about Spring/Boot or Micronaut though. There isn’t even any evidence the author has any more experience with them than what little they have with Quarkus. It’s a rant.
izacus 4y ago
> Shouldn't the title be "Java EE's Cultural Problem"? A person understanding what Java EE is wouldn't write such a rant post in the first place ^^

thriftwy 4y ago

> Any FP developer should scream when seeing this It would be an interesting observation in 2007, but fifteen years later with no industrial success of Haskell-inspired pure FP approach, I don't see why we should listen to "any FP developer" criticisms. It's not that I have anything against FP - let's just admit that side-effect pure FP is a "futuretro" of today. A future that never was.

marginalia_nu 4y ago
I do think FP in Java is a bit of a mistake. Record types has done a lot more for the language than streams and lambdas. I initially liked the idea of adding functional paradigms to the language, when the dust has settled all it does is create a sort of nasty Cronenberg language with most the drawbacks of both paradigms and few of the benefits of either.
- thriftwy 4y ago
  I absolutely disagree. Lambdas has in many ways revolutionized Java and put it back on its feet. Java 8 has seen faster adoption than any other major Java version because of this. Compare it with Java 11 or indeed with absolute non-adoption of Java 14. Streams are not very well designed IMHO. That's why their usage remains limited. Much more useful and robust libraries are possible on top of Java lambdas support. Since everyone is now on Java 11 (and many on Java 8 still), we will only really see the records used widely in five years or so. The modules stuff was a huge mistake in my opinion. Some people tend to like them in theory, but in practice they absolutely destroyed the adoption of newer Java versions and set Java 11 back by 10 years (literally).
  - bluejekyll 4y ago
    My issue with lambdas in Java is the complexity of types in defining interfaces that receive generic Functions as an argument. Really seems like a better definition could be used there, new language syntax possibly. On the topic of Streams, the big issue that always crops up is exceptions. Streams and Exceptions are nearly incompatible with tacked on constructs that are painful to use. Any IO oriented program will have to face the issue of what happens to the Stream if an Exception is thrown.

tannhaeuser 4y ago

https://github.com/Hello-World-EE/Java-Hello-World-Enterprise-Edition https://github.com/Hello-World-EE/Java-Hello-World-Enterpris...

Tiddles-the2nd 4y ago
Obligatory Fizz-Buzz EE. https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...
Tiddles-the2nd 4y ago
Also this is just weird, it tries to be EE but it just ends up being convoluted without applying the patterns correctly. E.g. all the logic is executed in the constructor of HelloWorld.java - I can't imagine that ever getting past code review.
- tannhaeuser 4y ago
  Well it's on gh so why not fork and fake a PR with your code critiques (plus lots more, such as heretically not using a symbolic constant for zero) to make the satire perfect?
  - JanSt 4y ago
    "The instantiateHelloWorldMainClassAndRun() method should be private. This issue is blocking half of the team, please fix asap"
- KptMarchewa 4y ago
  Also, hungarian notation I in front of interface name is something I've never seen in Java - it's a C#/windows pattern.
  - tannhaeuser 4y ago
    Sadly, it's a thing in Eclipse/SWT-derived or -inspired codebases.

nilsb 4y ago

Is it just me or is understanding those examples virtually impossible if you're not intimately familiar with that particular framework? Then again... I guess that's the author's point.

ris58h 4y ago
Yeah. It's the issue with the framework not the language.
throw_m239339 4y ago
The examples use CDI (dependency injection through annotations) and yes, these annotations become hardwired to the business objects... Java has some kind of traits now through interfaces so it's not much of a problem today.
- mrkeen 4y ago
  > Java has some kind of traits now through interfaces so it's not much of a problem today. Well that's the article's premise, right? Opening sentence: Java is good by modern standards, from a technical perspective Later on: Java’s culture eschews common sense approaches > so it's not much of a problem today. Every Java codebase I've worked on in my career has had plenty of this crap in it. The culture has settled on doing it this way.
  - democracy 4y ago
    What non-java codebases you worked on (of similar magnitude) that didn't have plenty of crap in it?
  - HelloNurse 4y ago
    Java encourages doing things like they were done 15 years ago because rewriting reams of low-value boilerplate with delicate architectural impacts is neither fun nor (at first sight) valuable. Typical immature enterprise organizations tend to extend the system with low-risk new features instead of refactoring and remaking old stuff.

cruunchMuncher 4y ago

You need to educate yourself and learn Java better

cruunchMuncher 4y ago
Java is great
tandr 4y ago
Learning Java once is easy. Understanding it is fine too. But learning new framework every time you switch projects - not so much. Because every time it becomes a gargantuan task, with all the dependencies that it pulls. And the moment you wants to do a tiny step aside, you need to learn intricacies of internal working of said framework just to something oh-so-slightly different than original authors envisioned. And then add couple more libraries, and endless conflicts, and stubs, and injection debugging nightmare. The maintenance of the dependencies becomes a full time job... Yeah, Java is simple. Everything else around it makes it almost unbearable with mental load that you need to keep just to move forward with a simple change.
- democracy 4y ago
  What language is different so by learning its syntax you don't need to invest into learning its frameworks?
  - foobarian 4y ago
    Maybe a language that few people use and hence don't have but one or two frameworks. Would explain a lot.

zcw100 4y ago

This is just an angry rant by someone describing themselves as a “functional programming enthusiast”. The post is only tangentially about Java and is really about a framework called Quarkus. If there’s a culture problem it’s the “Look at me. I learned something new and now I’m going to do my best to burn down everyone else”. If you want to program in Haskell or whatever have a great time. Think it’s so great? Prove it by writing great software with it.

grumpyprole 4y ago
The way I see it, is people searching for a better way, after years of trying to actually use Java. And what does Java's chief architect think? "It is my belief that the best direction for evolving Java is to encourage a more functional style of programming. ... We're not going to turn Java into Haskell, nor even into Scala. But the direction is clear." https://mail.openjdk.org/pipermail/lambda-dev/2011-August/003877.html https://mail.openjdk.org/pipermail/lambda-dev/2011-August/00...
- fedeb95 4y ago
  What do you mean "trying" to use? Many corporations use it with profit. Is there a better way to make money? Probably. But this way is very much used and profitable enough. So trying is not the right verb...
  - grumpyprole 4y ago
    Yes they have succeeded in using Java to make profit, but argubly not in creating reliable, secure and easily maintainable software. Like I said, even Java's creators believe there is significant room for improvement.
    - kaba0 4y ago
      I would argue about that reliable, secure and easily maintainable software. Surely there are terrible examples for unmaintainable software monsters in every language, Java not being exempt. But based on the only relevant, existing evidence on the topic: empirical evidence, Java is probably one of the, if not the best at the software maintainability game. Clean FP in and of itself doesn’t solve the problem, so it’s not like there is a clear cut answer to the question. I do agree that incorporating more and more immutable elements to java is a worthwhile goal to pursue, but at the same time I also believe that on a local, single-threaded scope mutability can increase understanding, so neither imperative nor pure functional is an answer to every problem in themselves. We should strive to make both toolkits available and be ready to use the correct one for each case, the pragmatic approach.

fedeb95 4y ago

Java doesn't have a cultural problem. People need to understand that Java culture is almost entirely enterprise culture. Don't want a language influenced by that for your project? There are plenty out there, pick one

grumpyprole 4y ago
It has a culture of over-engineering, just look at Log4J or Spring with its AbstractSingletonProxyFactoryBean's. More complicated and far more adhoc than any abstraction should be.
- democracy 4y ago
  Log4j is too simple to use and configure - what exactly is over-engineered and why we as users would even care if it's overengineers somewhere under the hood? It's hard to criticize Spring Core - it's too mature and popular to worry about some edge-cases where it didn't fit the developers view of the world. As with any other software - don't use it, or improve the existing one (and Spring Core is open-source), or write your own. But now it's de-facto the foundation of the Java programming landscape.
  - grumpyprole 4y ago
    > what exactly is over-engineered and why we as users would even care if it's overengineers somewhere under the hood? Log4J has been a major embarrassment for the Java community. I suggest you Google it, if you don't know why. > It's hard to criticize Spring Core Spring Core is at best a dynamic (reflection based) band-aid to work around Java's lack of expressiveness. It comes at a significant complexity cost and loss of static guarantees. You cannot both love Spring and Java. So which is it? :)
    - democracy 4y ago
      Oh, please, ok, there was a security flaw - how does it prove that it is over-engineers? If anything it is too flexible and gives developers too many features so that one of them was compromised.

deleted 4y ago

[deleted]

dmitriid 4y ago

Java is fine. Java frameworks are not. I'm still waiting for ASP.Net-like framework in Java where all configs are explicit and the framework doesn't require hundreds of confusing annotations just to display a hello world page.

tandr 4y ago
Yes, 100 times yes! Looks like we posted similar thoughts at about the same time. https://news.ycombinator.com/item?id=32896598 https://news.ycombinator.com/item?id=32896598
mrkeen 4y ago
I don't know what "ASP.Net-like" implies, but take a look at https://sparkjava.com/ https://sparkjava.com/ It was quite a pleasure to use.
- KptMarchewa 4y ago
  Only if you're fine with using something that had latest release in 2020.
  - ihateolives 4y ago
    https://javalin.io/ https://javalin.io/ is a fork of Sparkjava, same simplicity, updated regularly. Used it in couple of glue projects.
spockz 4y ago
Spring is becoming more functional programming oriented: https://www.baeldung.com/spring-5-functional-web https://www.baeldung.com/spring-5-functional-web. Also functional bean definitions, etc. Perhaps mostly driven to be able to (more easily) use graalvm to generate native images.
- kaba0 4y ago
  Not sure that is such a big step-up — I would rather prefer a much deeper support for records over POJOs.

tomerbd 4y ago

I'll take java any day for server side, I don't know why but when I use java things just tend to be much more stable and It does not take me more time to write code at all.

bluejekyll 4y ago

I agree so much with this article. Java EE practices bloat programs, waste memory, and make debugging harder. Let alone all the language constructs. > Java allows null objects… that ship has sailed Not necessarily, with project Valhalla, it should be possible to have generic Value Types in the language that would allow things like Optional to be defined on the stack where it would be non-null and then all it’s methods for checking if the Object it references would make sense, and actually work. This would be in contrast to today where the Optional type isn’t as useful as it seems since it can also be null. Anyone know the status of this? https://en.m.wikipedia.org/wiki/Project_Valhalla_(Java_language) https://en.m.wikipedia.org/wiki/Project_Valhalla_(Java_langu...

democracy 4y ago
Java EE is not really a thing in the wild for long long time...
- bluejekyll 4y ago
  Spring and (and Quarkus apparently which I haven’t used) brought along a lot of the Java EE concepts. It lives on if not in name, in spirit. Thus the cultural problem this article discusses.
  - democracy 4y ago
    Well technically they are built on JEE APIs, but JEE is not a 10 page spec, so combining all of JEE into a pool of "horrible designs" would be somewhat naive.
- pjmlp 4y ago
  Not only it is still around, Spring actually depends on many of the same standards.
  - StevePerkins 4y ago
    This take is so exhausting. It really is, "Tell me that you know little about Java beyond forum comments that you've read, without telling me that you know little about Java beyond forum comments that you've read". The most important Java EE specifications (now "Jakarta EE", as "Java EE" hasn't existed for years), are: CDI, EJB, JPA, JTA, JMS, JAX-WS, JAX-RS, JSTL, JSP, and JavaMail. Of that list, a typical Spring Boot application in the wild miiiiiiight use JPA. And that is totally optional, with a handful of newer ORM frameworks seriously eating into its market share. Even JPA itself didn't come out of the "Java EE" world. Hibernate won the ORM wars back in the day, and so the Hibernate folks were allowed to write the JPA spec, making it near-identical to the existing Hibernate API. Spring has extensions that allow it to interface with nearly anything in the Java ecosystem (and its DI container makes it easy to write an integration to anything new). However, while it CAN interact with all of those Java EE API's, it doesn't NOT "depend" on them! The story of Spring's relationship to Java EE is the classic "embrace, extend, extinguish". Reddit and HN are able to grasp that pattern just fine when they are slamming Microsoft. However, they can't grasp get it in this context. I honestly believe that the vast majority of people's Java knowledge on Reddit and HN comes from ignorant comments that have been in a self-reinforcing recursive loop for years.

ngalaiko 4y ago

LAC-Tech 4y ago

Halfway through reading - is this just another episode of "FP Programmers Don't Understand Other Paradigms?" Because honestly at this point I'm pretty much all caught up on that.

ncmncm 4y ago

"I enjoyed programming in Java, and being relieved of the responsibility for producing a quality product." — Mark Dominus https://blog.plover.com/prog/Java.html https://blog.plover.com/prog/Java.html

tempodox 4y ago
> In Java, you can forget about doing it in the cleanest or the best way, because that is impossible. Whatever you do, however hard you try, the code will come out mediocre, verbose, redundant, and bloated ... +1, I love this article. Do language developments since 2014 invalidate any of his characterizations?
- kaba0 4y ago
  No, language developments since 1995 invalidate them.
  - ncmncm 4y ago
    This seems to be contradicted by agreements posted. Or is use of features introduced since 1995 especially limited? I doubt many still use Swing, anyway.
the_gipsy 4y ago
I've read this quote after working one year on a java project, and it just nails the sentiment. Both from devs like me that wouldn't pick java where you'd expect this kind of sentiment, but also from veteran java devs who also treat "quality" as something simply unobtainable.

democracy 4y ago

Sorry, it is not worth reading and analyzing. You can come up with a lot of criticism about Java (just as about any other technology) but the content is just too shallow.

unwind 4y ago

I was going to post a comment about the regex used to (coarsely) validate email addresses made no sense, but when I opened the article in a new tab to copy for quoting, it had changed. :) It's now "^[^@\\s]+@\\S+$" with a comment also stating that it could be better. That's at least sensible, the original one that I first saw was more or less "^[^@]@.*" which kind of makes no sense. Oh well, great that the author caught it, of course.

bqmjjx0kac 4y ago
I'm still not convinced that it's correct. Probably worth perusing RFC 3696. https://www.rfc-editor.org/rfc/rfc3696.html https://www.rfc-editor.org/rfc/rfc3696.html

tannhaeuser 4y ago

It must be said that this coding style may be the norm with Quarkus (and with Spring which it is trying to replace on graalvm/native-image), but isn't required by Java itself. As always, Spring-like Java buerocrats have chosen to chase and over-engineer trivialities because it's so much easier lol; well until using your framework becomes a study in psychology or software archeology. Update: what I don't get with Quarkus though is why did they set out in Spring factory style only to have to immediately limit this for native-image's "closed world assumption"

absove 4y ago
I'm pretty sure Quarkus tries to stick as close as possible to Java EE APIs with some limitations to accommodate the lack of runtime reflection, being Red Hat's answer to application containerization for which JBoss isn't a good fit, if it looks like Spring it's mostly because it's a popular style in Java.

kache_ 4y ago

Over abstraction is the devil :)

ilitirit 4y ago

Reading these comments, it's strange to see that the "Java" paradigm/context issue still exists after all these years. I have never had significant problems with Java-the-language. But, like with many other programming languages out there, you can't really dissociate the language from the environment and everything that goes with it. The paradigms, VMs, IDEs, patterns and practices etc etc. And for the record it's not just Java (it just seems to be more pronounced in the Java-development ecosystem). For every person who waxes lyrical about the joy of working with C# (for example), there are 3 more that will tell you anecdotes about "assembly hell". Or how Visual Studio is slow and a massive memory hog. Or that there is no proper Forms support on XYZ-os. Those are all fair points, but more often than not, they have little-to-nothing to do with current discussion. IMO, I think it's usually far more productive to try to understand the discussion in context than to veer off into irrelevant semantic issues or tangential anecdotes.

dvfjsdhgfv 4y ago
You conclude with: > Those are all fair points, but more often than not, they have little-to-nothing to do with current discussion. but earlier you noted that: > you can't really dissociate the language from the environment So it seems like a self-contradictory position.
- ilitirit 4y ago
  Why would it seem that way? Why can't I say: "I like how C# implements XYZ" instead of "I don't like the C# development environment, but I like how C# implements XYZ"? What value is there in qualifying every aspect of a discussion given that you cannot fully dissociate <A> from <B>?
jimbob45 4y ago
You choose weird examples. I don’t know how VS can be considered slow when it only has one real competitor - JB Rider - and that competitor offers C# support. Also, I’d there a language that competes with C# that doesn’t also have some form of “assembly hell”?

StrLght 4y ago

What a stretch from a single badly designed (in author's opinion) framework to "cultural problem"

bullen 4y ago

It's not culture, it's the fact that Java enables huge structures to run that has become it's problem. Listen to James in the last chapters of this interview: https://www.youtube.com/watch?v=IT__Nrr3PNI https://www.youtube.com/watch?v=IT__Nrr3PNI Just because Java can run bloated is not a good reason to do so. I have written my own HTTP/DNS server with built in DB from scratch and it's 150KB (around 10.000 LoC) and that's how you use Java properly.

philipwhiuk 4y ago
> I have written my own HTTP/DNS server with built in DB from scratch and it's 150KB (around 10.000 LoC) and that's how you use Java properly. So you've probably got 90,000 bugs left to fix then. Seriously these "I built my tiny thing I claim implements X protocol" are very tedious. You think BIND is deliberately overcomplicated or do you think, maybe, just maybe your tiny server has lots of hidden problems.
- bullen 4y ago
  I took responsability and over 10 years I fixed the bugs. It hosts a MMO with 350.000 customers at 10x perf./watt than all AAA studios.
- CyberDildonics 4y ago
  This person also claimed that a rise in electricity prices will mean people won't be able to afford to play half life 2 and starcraft 2: https://news.ycombinator.com/item?id=32523818 https://news.ycombinator.com/item?id=32523818

Kostchei 4y ago

throwaway4good 4y ago

Can we maybe also talk about FP’s cultural problem: that lots of people with a functional programming background just don’t get object orientated programming and instead of trying to understand it, dismiss it as crap and enterprisey.

tempodox 4y ago
There will always be people who misunderstand things or are badly informed. Equating a whole culture with that subsection is not fair. Also, are you insinuating that those who “get” OOP can't find FP a superior approach for certain problems?
- throwaway4good 4y ago
  No but I am implying that the author doesn't get OOP and makes no attempt to do so.
vonwoodson 4y ago
The very idea that FP programmers don’t understand OOP is absurd on its face. You point to an undergraduate CS program that is teaching FP before imperative and OOP paradigms; you find me an FP zealot who hasn’t written more OOP than FP code. This is a nonsense “reverse racism” argument rehashed to be about programming paradigms, and I won’t stand for it.
- UncleMeat 4y ago
  When I was there, intro CS for the college of arts and sciences at UVA was taught in scheme. Lisp-y intro classes can be found at a large number of universities. MIT now teaches intro CS in python (multi-paradigm, not OOP) but famously taught it in Lisp for many many years.
  - cutler 4y ago
    Why stop there? Why not go the whole way and teach CS in Javascript? Python's tentacles of mediocrity know no bounds. It's as if the whole teaching profession is sleepwalking towards conformity.

tofflos 4y ago

I like SmallRye Config and I feel it's designed this way because of the problems it tries to solve. The following is an excerpt from the MicroProfile Config standard which SmallRye Config is an implementation of: > The majority of applications need to be configured based on a running environment. It must be possible to modify configuration data from outside an application so that the application itself does not need to be repackaged. > The configuration data can come from different locations and in different formats (e.g. system properties, system environment variables, .properties, .xml, datasource). We call these config locations ConfigSources. If the same property is defined in multiple ConfigSources, we apply a policy to specify which one of the values will effectively be used. > Under some circumstances, some data sources may change dynamically. The changed values should be fed into the client without the need for restarting the application. This requirement is particularly important for microservices running in a cloud environment. The MicroProfile Config approach allows to pick up configured values immediately after they got changed. One reason we don't know whether SmallRye Config is reading from a file or querying a database at development time is because that choice has been deferred to the system administrator at deployment time. Records are immutable. If we want to be able to reconfigure applications at runtime it might make sense to use a mutable data structure. You can load configuration programmatically if don't want to use dependency injection and/or want something that is easier to test. See https://download.eclipse.org/microprofile/microprofile-config-2.0/microprofile-config-spec-2.0.html#_simple_programmatic_example https://download.eclipse.org/microprofile/microprofile-confi....

deleted 4y ago
[deleted]
le-mark 4y ago
What are you suggesting? That one should read the documentation? And have a level of understanding why things are the way they are? Blasphemy! Zero ignorant screeds would be written! Productivity would increase 10 fold!

andor 4y ago

The equivalent Spring @ConfigurationProperties annotation supports records. Spring also requires fewer annotations overall and none of the CDI ones.

jillesvangurp 4y ago
There's even kofu, which largely get rid of annotations entirely in favor of declarative Kotlin DSLs. Very similar to how ktor works. I tend to use Spring this way as well. E.g. we use the router dsl rather than having annotated resource classes. Kotlin DSLs are superior to using annotations IMHO. More explicit/declarative, similarly easy to read. And it gets rid of all the builder boiler plate that you have in Java. Annotations are definitely overused in some frameworks. And debugging them is a bit tedious when the magic breaks; which tends to happen with the more complicated stuff. I've seen some spectacularly misguided things happen with e.g. the @Transactional annotation having some not quite intended side effects. I always preferred just using TransactionTemplate. That makes the transactional boundaries much more clear than junior engineers copy pasting annotations until stuff vaguel stops breaking. Which, btw. is literally what people seem to do with @Transactional. I've cleaned this up in several projects. Annotations with complicated side effects are a bad idea; especially when you need to understand what those effects are.

strictfp 4y ago

This is why I left Java. Everything "looks nice" on the surface with annotations, but you loose the flexibility of code and a lot of the available tooling. Plus you need to be a real expert to debug issues and solve problems; understand framework architecture and read reflection code. You can't just put a breakpoint in there and start debugging. It's optimizing for the wrong thing. The bad news is; this culture is permeating somewhat into Rust now that more Java devs are moving over. This whole attitude is IBMs fault. They tried to get into the Java market by applying their big iron terminal thinking to create Java EE. Java under Suns management was a lot more like golang today; pragmatism, fewer language features, and focus on writing code.

democracy 4y ago
Seriously, the speech is from the 2000?
pjmlp 4y ago
Java EE was created by Sun themselves, it was reborn from a Objective-C framework for OpenSTEP called Distributed Objects Everywhere, better get your history straight.
- strictfp 4y ago
  Interesting. I can't find any sources for the IBM story, but I thought I read it here on HN. I found at least one similar comment; https://news.ycombinator.com/item?id=30538784 https://news.ycombinator.com/item?id=30538784 . So you're saying it was just Sun and not IBM?
  - pjmlp 4y ago
    Yes, unless you consider Wikipedia info possibly bogus. "By the time DOE, now known as NEO, was released in 1995,[1] Sun had already moved on to Java as their next big thing. Java was now the GUI of choice for client-side applications, and Sun's OpenStep plans were quietly dropped (see Lighthouse Design). NEO was re-positioned as a Java system with the introduction of the "Joe" framework,[2] but it saw little use. Components of NEO and Joe were eventually subsumed into Enterprise JavaBeans.[3]" https://en.m.wikipedia.org/wiki/Distributed_Objects_Everywhere https://en.m.wikipedia.org/wiki/Distributed_Objects_Everywhe...

eastbound 4y ago

Shall we definitively say that a problem of all languages is that they evolve to the maximum complexity that a single brain can understand, then they collapse because nobody understands them? All languages start with “Lightweight, lightening fast and hotreloadable!”, then become a gas plant as they need abstractions to handle industry concerns (hello Reflection API, javaagents, NIO, functional programming, now the Cloud, then AI), Are there intrinsic properties a language can have that prevents bloating to the maximum complexity a human can handle, and yet allows it to handle industry usecases?

kaba0 4y ago
Java is absolutely not victim of language-complexification by adding the n+1th fancy feature of the day, if anything it is one of the few exceptions — it is a quite old language and yet modern Java has very little differences to what it was back than — all the spring magic happens through its standard way of operation, everything is a class with methods, and these primitives are assembled in novel ways, that’s it, and that’s how it supposed to be. No async, coroutines (it gets solved on the JVM-level and exposed through method calls), no separate syntax for stream operations (those are just method calls with “builder pattern), etc. I greatly recommend Guy Steele’s Growing a Language talk about this exact topic.
somewhereoutth 4y ago
Indeed! The 'Complexity Horizon'. Any constructed system will tend to that horizon as it continues to be developed (particularly if by multiple people over significant timescales) - unless there is a concerted effort to pull it back.
- eastbound 4y ago
  I love the ‘complexity horizon’ of algorithms: If something can be made simple, then we’ll build more complex things until we can’t understand it. All algorithm are always right above the maximum complexity that a single human can handle. Actually I believe it’s another surprising emergent effect of open-source: Linux’s or Postgres’ complexity horizon seem to have been managed, so that adding new stuff didn’t increase complexity, and it’s still possible to add new stuff THIRTY years later. As opposed to Excel.

javajosh 4y ago

The author shows good taste referencing Dropwizard. Then shows deep (even dangerous) inexperience with his email type. So while I encourage writing like this, and I especially like the exercise of considering all the different ways configuration can make it into an application, I don't think this piece would be worth referencing in, say, a work argument.

HelloNurse 4y ago
Reading between the lines, there seems to be a significant hope that an easy solution exists. Maybe a young programmer? The kind who could write the EmailAddress class because they didn't laugh adequately at the very idea?
krzyk 4y ago
Actually the email example is the best from the article, validation using external libraries is a hell and I really would like my codebase to get rid of it.

ACV001 4y ago

It shows lack of java knowledge and understanding of OOP. Rants about Java, but talks mostly about Quarkus.

411111111111111 4y ago
> One of these days I’ll find out what the heck is a “bean”. It does indeed show a confusing lack of Java knowledge. It is quiet strange that this tidbit was in it, as I'm not sure how it's even possible to not know what a bean is if they've ever worked with the language for any amount of time. Unless it was meant as a sarcastic remark as the term is sometimes used to express what they enable (eg. singleton services) vs what they are
- pwdisswordfish9 4y ago
  I have worked with Java for a year or so and I don’t know what a bean is.
  - kaba0 4y ago
    It’s a standard and it’s similar to a naming convention, but instead applied to class structures. Instead of extending/implementing some strange, third-party classes, you create a POJO (plain old java object) and you add getters and setters for the fields you want to make externally reachable. Now tools that don’t know anything about your code can use them through reflection based on these conventions, this is how dependency injection, JPA, every Java EE/Spring thing operate.
  - cutler 4y ago
    Then you ain't drinkin' the coffee.
- krzyk 4y ago
  Everyone should forget about "bean" and don't reuse that word.

nerdponx 4y ago

I found this interesting because the ConfigMapping stuff reminds me a lot of Python. I knew that Python OO was inspired by Java OO to some extent, but I didn't expect so much similarity. I think Python could learn similar lessons here. But the flipside is that none of this stuff is a catastrophe in Python either, and the author's tone seems a bit out of proportion with what they're complaining about. The author complains about: 1) not knowing the underlying data model and implementation details that might affect their design 2) mutable attributes and non-final classes 3) lack of obvious composition root In the Python world, we often say that "we are all consenting adults here". Usually there is no need for private, immutable, or final things because people read docs know not to stray from the public interface. The trust also runs the other way, and it's very rare for the function to perform some kind of weird unexpected mutation. A function that mutates a user-provided object without the user's knowledge or consent is usually considered a bug. I actually found exactly this bug recently in a framework I was using, and several people were up in arms about it on the issue tracker. Yes, immutable data makes it harder/impossible to write such bugs. But the community generally has not devolved into a Satanic orgy of mutable state. Likewise, if a framework did something ridiculous like reloading a config file at every request, nobody would use it! I could only imagine how lively that GitHub issue thread would be. A framework that makes fundamentally bad design decisions tends not to be a lasting part of the community. The only one that really would suck, and that also doesn't seem to be a problem in Python, is the lack of an obvious composition root. I have never heard this term before, but it is a very very well-established pattern in Python application and library architecture. A framework that made it hard to design libraries in a conventional sensible way, would not be a very popular framework.

UncleMeat 4y ago
> Usually there is no need for private, immutable, or final things because people read docs know not to stray from the public interface. My experience is that this fails as soon as you've got a modest number of users. It only takes one user doing something foolish and now you've got a fight on your hands when you want to change an internal component of your system. And you'll often lose that fight.
- 4y ago

axilmar 4y ago

I couldn't agree more. I currently work on a web application that uses Spring Boot and Vaadin and it sucks a million miles. Spring sucks separately from Vaadin, which sucks another million miles. The whole thing with beans and annotations is an abomination and whoever thought of it should be shot (not literally, for crying out loud!).

cletus 4y ago

> Java has null in it, all object references can be null, and it’s too late for that to change. At Facebook I used Hack, which is a fork of PHP. They've spent a ton of time on the type system to the point where I'd argue it's very good. One of the best things is that nullability is built into the type system so for: vec<?string> $a; // alows nulls vec<string> $b; // does not allow nulls function foo(string $s) {... } you get: $a = $b; // this is OK $b = $a; // error $b = Vec\filter_nulls($a); // OK foo($a[1]); // OK foo($b[1]); // error if ($b[1] is nonnull) { func($b[1]); // in this block the type is 'string' so this is OK } func($b[1] as string); // OK but throws a runtime error if it's null I was surprised just how useful these seantics are and how many errors could be avoided this way in annotated code (there are an ever-dwindling number of corners of the FB code base that aren't property typed). Like Java, this operates on type erasure at runtime so there are limits to the protection. I hope other languages with less advanced type systems (and I include Java when I say that) adopt nullability as a first class type concept. There's a lot of talk here about dependency injection. This was a big innovation in Java 20+ years ago. For some reason no other language seems to collectively wring its hand about DI quite like Java does. Java does suffer from a lack of duck typing, hence all these typically one use interfaces get created. It also has other issues (eg you can't make your own class that'll be a snap--in string replacement). Guice I consider to be a form of torture. Maybe it's time Java decides to stop rigidly solving a prroblem no one else seems to have. Maybe that part of a cultural problem. As for the "enterprise" problem, is that specific to J2EE? Is that still a thing? Or is just the consequences of the patterns J2EE promoted that still propagate (eg rigid DI)? It's generally better to have some structure rather than none, even if it's a bad structure. Maybe I just don't travel in the circles where you see a lot of bad Java enterprise code? Java has warts but the runtime maturity in particular is still world-class. I wish Google had bought Sun back in the day (I bet Google does too given the costs and consequences of the lawsuits) but Java continues to plod along and get better without getting massively complicated (I'm looking at you C++) so it all seems mostly fine.

foobarian 4y ago
Re: better null handling, languages like C#, Kotlin, and TypeScript all do similar things and IMO Kotlin in particular is a very nice experience while retaining Java interop.

exabrial 4y ago

I find the Java 17/Good IDE quite nice. Most of all the complaints have been resolved with the language, and it’s still faster than every other memory safe language (except Rust, which smokes everyone)

jeroenhd 4y ago

I strongly dislike working with most Java frameworks because I disagree with many of their design decisions (and type erasure keeps finding ways to bite me in the ass) but I accept that when I use Java, I need to comply with its expectations and work with the ecosystem. This reads like a functional developer who believes that functional programming is The Only Right Way to program anything trying to shoehorn functional programming into a framework that's decidedly not functional. Sorry, but that doesn't make sense. I agree with some parts of this; the lack of proper nullability in the type system is very annoying especially once you've worked with more modern languages. The conflict between recommending the use of `final` and major libraries being incompatible with such use is also quite jarring (though there are alternatives). However, statements like > This should be a pure data structure; go unexplained, assuming that "every FP developer" should know this for an absolute truth because... why, exactly? I can easily see these methods have side effects because they read configuration files, for example. Hard-coding IP and port in the Java files is a terrible idea. Sure, the record based abstraction is nicer, but records are not supported for a large part of the JVM ecosystem because upgrading Java versions is slow and painful for larger applications. I also don't understand this "annotations are bad" argument. Yes, some annotations should be built into the type system (and there are projects to accomplish this!) but what's wrong with @NotEmpty? Furthermore, the email address solution uses Objects.requireNonNull(value) without any annotations, making it difficult if not impossible for IDEs and static code analyzers to determine the nullability of this field. It also throws exceptions without any indication that the constructor can fail (I know many Java developers don't like the `throws` keyword but if you're going ham on code style and semantic programming, at least be clear what can and cannot fail). Java is not a functional programming language and the ecosystem even less so. It's an imperative language with functional aspects inserted to make your life easier. Projecting functional paradigms onto it is impractical at least, or maybe even just plain wrong; it's the wrong tool for the job. I personally find many of Kotlin's paradigms get much closer to the functional programming paradigm than Java, especially with the new libraries and frameworks that make use of Kotlin's language features. Kotlin is as imperative as Java but it's val/var system combined with (data) classes compiling to "normal" Java classes make it an excellent candidate for immutability constraints, stricter types, and other such annotation replacement language design. As an added bonus, the language works quite well together with most Java libraries.

moondowner 4y ago

"Java is good by modern standards, from a technical perspective, the platform having received a lot of improvements from Java 8 to 17. Unfortunately, it still stinks, and the problem is its "enterprise" culture." Then the author rants about a specific Java-based framework and does not mention anything about the use of Java in the enterprise or any supposed cultural problems it may have.

krzyk 4y ago
Issue is that Quarcus advertises as the new, hip framework but what it does it still reuses the old pre-17 constructs. It should use the latest and greatest from Java if it wants to be a game changer, not repeating what Spring did with their support for old, deprecated JDK releases.

yotamoron 4y ago

So you think there's some magical language, where things will never become complicated, syntax will always make simple sense and no developer can f** things up? Think again. No such thing. Java is a tool, and like every other tool - you have to know how to use it if you want to get the best results from it. When used by the right developer, Java can yield beautiful, concise and clear code. When used by the wrong developer... well...

HiIAmIlNano 4y ago

The author is using field injection and claiming that the field cannot be private. As far as I know he should be using constructor dependency injection and make the field private and final. That way is also easier to write unit tests and maybe make use of interfaces in case he wants to avoid using a mocking framework. Not only that but if I recall correctly quarkus resolves dependencies and config files at compile time and not at runtime using reflection as spring does.

vips7L 4y ago
The author sadly just doesn’t know what he’s doing.
- mbo 4y ago
  Then this is clearly a library UX problem. Him not understanding what he's doing is the point!

jcon321 4y ago

You don't have to follow a framework explicitly to have success. You can use vanilla components of a framework and then treat the entire application more functional esque. The author's examples are just so overboard. Annotations on fields to represent validation is valid and I see it all over JavaEE, but I've never thought of as my "go to". (Or else you are then locked in to how to represent return values, relaying messages, entry points). Live by the framework, don't die by the framework.

ragnese 4y ago

I agree. Java has improved as a language quite a bit in recent years. And I don't even mean that in a "Java has followed the cargo cult of what's fashionable in programming languages"-sense. I mean that things like Records to define value types have "always" been desired in Java- at least in the 10 years that I've worked with people on Java code. If Java didn't automatically make everything equatable/hashable, it would be a different story. Anyway, Java still has baggage that I doubt will go away any time soon. My biggest two complaints with Java are that null exists outside of the type system and that they mix runtime type reflection and non-reified generics. The latter features being actually incompatible with each other makes working with Java libraries/frameworks a minefield. But, aside from those issues, the OP is totally right that so much of Java's bad reputation comes purely from library design and culture. Even when I preferred OOP architectures, I hated the fact that so many Java libraries and frameworks required a bunch of annotations for everything, even when it really wasn't necessary. I get that Java code can be verbose, but if you don't like it, use something else- don't just throw away compile time safety and information for a janky runtime-checked "DSL" where a bunch of the features don't even actually work together (I'm mostly looking at you, JacksonXML, but also Spring, et al). Everyone praises the Java ecosystem as some kind of selling point, but I find that while the ecosystem is indeed broad, the actual quality and productivity of many of the popular libraries and frameworks is fairly low. And by "quality", I don't necessarily mean number of open bug reports, I mostly mean that the APIs are really difficult to understand and use correctly. In some sense the devs are "off the hook" when my app doesn't work correctly because "this is documented behavior", but that makes me think I should just start writing documentation for my apps' bugs and seeing what my boss thinks... ;)

titzer 4y ago
Not sure what you mean by null being "outside the type system"--it's just the bottom type, assignable to all references. I loved Java circa 2002-2005 and was deeply interested in JVMs. However I wanted to develop the JVM itself, and it turns out that Java is bad systems language. So I really want a systems language because VMs are the itch I have. What's weird to me are the choices that Java has made in its evolution. In Java 5, the VM and library powers-that-be basically killed reified generics, forcing type erasure. That was a huge language design mistake precipitated by not wanting to upset the apple cart of libraries and the .class format. But in versions 6 and 7 they updated the class format anyway, to add stackmaps and invokedynamic! I never understood why such a key language feature didn't get the requisite VM support it needs to be done right, but completely marginal features did get VM support. Poor choices IMHO. Java is just a big ball of semi-typed mud at this point. There are no layers and hardly any separation between what features are in the VM and what features are in the class libraries that are wormholes into the VM.

vbezhenar 4y ago

I really don't like Quarkus approach. It's full of magic. It's everything I'd love to get rid of. I'm using Spring which is kind of full of magic but I spent 15 years learning to deal with this magic, so it's bearable to me. But it does not mean that I like it. I liked Helidon SE approach (not MP, MP is the same EE crap). It's 100% code, no magic. What I didn't like is reactive, I don't need reactive, so I don't use Helidon SE for my projects, I still endure Spring. But if someone enjoys reactive programming and wants zero-magic approach, I can recommend it. Helidon Nima might be a saviour to me. I didn't research it yet.

rr888 4y ago
I'm not sure the point of Quarkus. Its an easy way to get started with GraalVM development, but pre-compiled Java isn't any use for dev work. The autoreload classes is easy in most dev environments already too.
- vbezhenar 4y ago
  It seems to me that the point of Quarkus is to allow old EE applications to be ported to Graal Native. For example they did that with KeyCloak, it was Java EE application running on top of JBoss Application Server, now it uses Quarkus.
mwcampbell 4y ago
I agree with you about both magic and reactivity (meaning, IIUC, asynchronous rather than blocking APIs). Helidon Nima looks interesting. But what I'd really like in Java is a non-magic, non-reactive server-side web framework that's designed to be used for full-stack, server-side web applications, including things like strongly-typed HTML templates, form validation and rendering, cookie-based authentication, and CSRF protection. Something we can use to develop a complete server-side web application, the kind that everyone used to write before the division into back-end API and front-end SPA became popular. Helidon Nima might be a good starting point for such a framework. Another starting point worth looking at is Javalin [1]. [1]: https://javalin.io/ https://javalin.io/
- 4y ago

p2detar 4y ago

What does one do to land a Java job when neither Spring, nor Quarkus experience is present? Backstory: I have been using Java SE for more than a decade now. Currently building a Java 17 pure Vert.x project. I'm quite seasoned with the language, but not with large frameworks like Spring. I don't have any desire to learn Spring. Quarkus seems like a good choice on the first look, but I'm also looking for other options. Hints anyone?

sonicgear1 4y ago

Let's just agree that java is trash.

cies 4y ago

That's why there's Kotlin, by JetBrains, who also make a framework name KTor.

didip 4y ago

I agree with the general sentiment of the article. It is clearly possible to write a straight forward Java code. See: Sparkjava, Javalin, or Vert.x. Hell, even Minecraft Java code is pretty easy to read. Too bad Java culture is dominated by consultancy-like culture, which promotes as many obfuscation as possible. The world will not end if you don’t use annotations and DI frameworks.

exabrial 4y ago

This is a dumb rant about something the author doesn't know anything about and hasn't bothered to understand or research. Dependency Injection is not functional programming. Dependency Injection solves a lot of problems and entire classes of bugs around application state, but with far more approachable stepping stones than something like pure functional languages. Pure functional languages solve state problems as well but are far more complicated and difficult to grok because of the paradigm shift. Whatever one chooses for a team of developers, the most important thing is being able to use the tools at hand. It's pretty easy to explain to someone what Scope is and how CDI has some standard scopes. The author doesn't even seem to understand how Java annotations even work.

rippercushions 4y ago

sorokod 4y ago

"I don’t care from where the configuration is being read" This hints at a junior developer. Once you have configurations depending on environment or geography you'd care a lot.

m3047 4y ago

I haven't programmed in Java in many years, except for making DAGs for Storm and a authorization metalibrary that none of the "real" Java programmers liked. Paradoxically the most sccinct statement of dislike concerned my choice of arraylike class: "THAT'S WRONG!". The Java programmers had source control, just like the rest of us. But their Maven configs weren't under source control, and they wouldn't help the rest of us with ours. I've concluded that I'm indifferent to Java, but not so good with Java programmers. There's a big ball of puzzling contradictions in the above. Have you heard of Lacan or Zizek? Well. Poetically speaking, I'll paraphrase Tom Lehrer and opine that "Java programmers must feel like a Christian Scientist with appendicitis". In my opinion: remember that. They've build a lot of ritual around notions of control and deliberativeness (that array problem). They're Catholic or Orthodox, really. The JVM is supposed to be "safe", and I have to ask: does the communion wine really turn to the blood of Christ? My father was a psychiatrist. I am well aware that Dr. Tim Leary was a pioneer in personality diagnosis, having found "The Interpersonal Diagnosis of Personality" on my father's bookshelf. I analyzed precinct level voting patterns, and they exist; but the question "is it something in the water, or new car smell?" remains vexing and unsolved. There is something that happens when people program in different languages with different tools, especially in groups. It's not just languages: how does Docker culture compare to NanoVMs on the Leary radar chart? But what I have for you is a (hopefully) playful personality diagnosis of some of the major programming languages. Make some popcorn. This is for entertainment purposes, but maybe it'll give you something to think about. https://www.youtube.com/watch?v=mZyvIHYn2zk https://www.youtube.com/watch?v=mZyvIHYn2zk

docmechanic 4y ago
Thank you for the best guffaw of the day. 'Poetically speaking, I'll paraphrase Tom Lehrer and opine that "Java programmers must feel like a Christian Scientist with appendicitis".'

jononomo 4y ago

I quit software altogether after programming in Java for about 7 years and decided I never wanted to program again. Then, a few years later, I discovered Python and jumped back in with delight. Now I have discovered Elixir and I'm super happy. But to this day I can't even look at Java code without that dying-inside feeling.

winnie_ua 4y ago

I don't get, why author is bitching about validation. What's the point in referencing article about Haskell, if Java don't have such parsing libraries. I've also saw that article translated to Rust, but it ended being article, not library. And many questions of how to represent valid state remained unanswered. And example provided, with throwing exception in constructor: that approach would just throw single error, but javax.validation approach allows to return list with ALL failed validations, so client don't have to fix errors one at a time and retrying to see next error. Small complain from me: EmailAddress class is not zero cost(unless java would have value types), but actually java devs do not care about this.

flakiness 4y ago

This thread makes me smile as an Android programmer. Android doesn't have the cultural problem discussed here, but it has its own set of problems (mostly rooted to the poor platform API design). It's so contrastive. Which do you like?