I agree so much with this article. Java EE practices bloat programs, waste memory, and make debugging harder. Let alone all the language constructs.<p>> Java allows null objects… that ship has sailed<p>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.<p>Anyone know the status of this? <a href="https://en.m.wikipedia.org/wiki/Project_Valhalla_(Java_language)" rel="nofollow">https://en.m.wikipedia.org/wiki/Project_Valhalla_(Java_langu...</a>
Reading these comments, it's strange to see that the "Java" paradigm/context issue still exists after all these years.<p>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.<p>And for the record it's not just Java (it just seems to be more <i>pronounced</i> 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.<p>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 <i>in context</i> than to veer off into irrelevant semantic issues or tangential anecdotes.
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.<p>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.<p>Helidon Nima might be a saviour to me. I didn't research it yet.
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:<p>> 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.<p>> 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.<p>> 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.<p>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.<p>Records are immutable. If we want to be able to reconfigure applications at runtime it might make sense to use a mutable data structure.<p>You can load configuration programmatically if don't want to use dependency injection and/or want something that is easier to test. See <a href="https://download.eclipse.org/microprofile/microprofile-config-2.0/microprofile-config-spec-2.0.html#_simple_programmatic_example" rel="nofollow">https://download.eclipse.org/microprofile/microprofile-confi...</a>.
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.<p>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.<p>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).<p>Everyone praises the Java ecosystem as some kind of selling point, but I find that while the ecosystem is indeed <i>broad</i>, 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... ;)
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.
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.<p>The bad news is; this culture is permeating somewhat into Rust now that more Java devs are moving over.<p>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.<p>Java under Suns management was a lot more like golang today; pragmatism, fewer language features, and focus on writing code.
"I enjoyed programming in Java, and being relieved of the responsibility for producing a quality product." — <i>Mark Dominus</i><p><a href="https://blog.plover.com/prog/Java.html" rel="nofollow">https://blog.plover.com/prog/Java.html</a>
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.
I agree with the general sentiment of the article.<p>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.<p>Too bad Java culture is dominated by consultancy-like culture, which promotes as many obfuscation as possible.<p>The world will not end if you don’t use annotations and DI frameworks.
> Any FP developer should scream when seeing this<p>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.<p>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.
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.<p>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.
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.<p>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"
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.
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.<p>There's a big ball of puzzling contradictions in the above.<p>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.<p>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?<p>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.<p>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?<p>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.<p><a href="https://www.youtube.com/watch?v=mZyvIHYn2zk" rel="nofollow">https://www.youtube.com/watch?v=mZyvIHYn2zk</a>
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
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.<p>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.
Java is fine. Java frameworks are not.<p>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.
This is a dumb rant about something the author doesn't know anything about and hasn't bothered to understand or research.<p>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.<p>Pure functional languages solve state problems as well but are far more complicated and difficult to grok because of the paradigm shift.<p>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.<p>The author doesn't even seem to understand how Java annotations even work.
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.<p>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.<p>The author complains about:<p>1) not knowing the underlying data model and implementation details that might affect their design<p>2) mutable attributes and non-final classes<p>3) lack of obvious composition root<p>In the Python world, we often say that "we are all consenting adults here".<p>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.<p>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.<p>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.
Halfway through reading - is this just another episode of "FP Programmers Don't Understand Other Paradigms?"<p>Because honestly at this point I'm pretty much all caught up on that.
What does one do to land a Java job when neither Spring, nor Quarkus experience is present?<p>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.<p>Hints anyone?
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.
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)
"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."<p>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.
I don't get, why author is bitching about validation.<p>What's the point in referencing article about Haskell, if Java don't have such parsing libraries.<p>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.<p>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.<p>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.
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?<p>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),<p>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?
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).<p>Live by the framework, don't die by the framework.
"I don’t care from where the configuration is being read"<p>This hints at a junior developer. Once you have configurations depending on environment or geography you'd care a lot.
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?<p>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.<p>When used by the right developer, Java can yield beautiful, concise and clear code. When used by the wrong developer... well...
This thread makes me smile as an Android programmer.<p>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?
I'm worried about python also going in this direction. I see so many repos with the @property decorator <i>everywhere</i> for not a single good reason!
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: <a href="https://www.youtube.com/watch?v=IT__Nrr3PNI" rel="nofollow">https://www.youtube.com/watch?v=IT__Nrr3PNI</a><p>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.
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. :)<p>It's now<p><pre><code> "^[^@\\s]+@\\S+$"
</code></pre>
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.
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.<p>The whole thing with beans and annotations is an abomination and whoever thought of it should be shot (not literally, for crying out loud!).
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.<p>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.<p>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<p>> This should be a pure data structure;<p>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.<p>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).<p>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.<p>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.
> Java has null in it, all object references can be null, and it’s too late for that to change.<p>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:<p><pre><code> vec<?string> $a; // alows nulls
vec<string> $b; // does not allow nulls
function foo(string $s) {... }
</code></pre>
you get:<p><pre><code> $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
</code></pre>
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).<p>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.<p>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.<p>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.<p>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.<p>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)?<p>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?<p>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.
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.
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.