You can write a pretty trivial Java program to copy stdin to stdout but Java is still one of the enterprise languages and people writing enterprise applications don't tend to write this type of software (but they do tend to have log4j vulnerabilities). The strengths of Java are its mature dependency management system(s), its comprehensive standard library and the vast ecosystem of third-party libraries. A better test of the language is whether you can write a complicated application in relatively fewer lines of code.
I spent much of my career writing Java code but have moved to Go - it's almost a return to my roots as an embedded systems engineer (without the memory management hassles of C) and it's vastly more economical to run Go applications in containers. I do find myself writing code that I used to pull in from a library though.
No isNullOrEmptyString method, no Set operations, Java didn't have a good HTTP library until Java 11, no lazy file reading, unless you use InputStream which is a pain.
vast majority of mediocre libraries and one man libraries. We use Spring because it uses the best libraries, so the other ones are discarded.
Java being around for so long doesn't have a lot of convenience methods like others do languages do, like the ones I mentioned in the beginning.
So no, Java is a half assed programming language which C# and NET CORE should replace
Java didn't have all these things, because there were a lot of very good libraries already doing that. Adding them inside a project is trivial. I think this approached encouraged creating alternatives to the standard APIs as well as extensions which in the end made the language even more rich.
I use .NET 6 on Amazon ECS (Amazon Linux), and it's a pleasure to work with. The dotnet CLI makes running and building super easy. So, I just develop with VS Code and a terminal on macOS and deploy to AWS.
At last workplace we developed microservices running on Kubernetes using Redis and Postgres as databases. Integration with Elastic Search, Kibana, Datadog were a breeze.
I'm really not sure I would call Java's standard library comprehensive. I've only worked with it for a few months but needed many Apache commons libraries.
By the standards of the day, when Java was released it's standard library was pretty comprehensive: in addition to covering most of the c-ish stdlib, it had networking and web-aware apis.
It did set a new standard in a way that was very beneficial for the languages that came after it: you're not an ACTUAL language if you don't have a "good" standard library, and I can argue that "good" was defined by Java more than C++ or anything else at the time.
I also don't see any new languages, while more modernized, that have substantially pushed the envelope further to be the new gold standard of a minimum batteries included stdlib. All I could probably say is various threading/concurrency apis, but Java has added a lot of that too over the years.
Which falls under the heading of "mature dependency management system". Apache Commons (or Google Guava) is pretty much considered part of the standard library at this point, as they are so easy to include in projects.
The domain and the developers that inhabit that domain should be separated from the language. Below is the repo of the companion Java code to Sedgewick's "Algorithms" - make of it what you will.
On the right side of the page, you can find eleven (!) different wants to include this dependency (and) all of its transitive dependencies with just a few lines of configuration.
>People say this but where do you find libs for Java?
Everywhere, on the lib website, on GitHub, on Apache, etc. (including centralized places like Maven Central). You then put a ferences in your Maven or Gradle file like you would in your package.json.
In fact, because for 99% of the libraries you just need to have a jar (or more) in your classpath, you don't have to have all the ceremony that Python has, and all the installation mess, venvs, and other such shite.
Until you end up with dependencies transitively pulling in conflicting versions of Jackson or similar and you need to mess around with dependencyManagement or exclusions.
If this isn't a joke, I'd suggest learning the Maven or Gradle build systems. NPM has such horrible dependency management that these Java systems will seem like magic!
OK, so I'm trying out maven central as people in this thread are recommending. As an example, I'm searching for a command line argument parser.
The first thing I'm noticing is that there seems to be no way to judge the popularity of the libaries (an often-used proxy for quality, e.g. number of downloads, GitHub stars, etc).
I suppose the Java package ecosystem must be good if everyone says it is, but so far it looks to me like I'd find Maven Central very inefficient to discover high quality packages.
Maven Central is the place where the libraries are hosted, but not the place where they are found by users. Use Google/Stackoverflow/Reddit and simply search for what you want.
Searching for "command line argument parser java" immediately leads you to libraries and infact lists of libraries (see https://stackoverflow.com/a/7829772), of which most are going to be available on Maven Central.
Then you do your research that the library you are looking at looks valid and is trustable (!) by checking out the info available on it, maybe make another search to find opinions on it.
Then when you have decided to try it, look at its docs to find out where it s located on Maven Central and use it from there.
I think you're searching in the wrong place. The first search result for "argument parser maven" in google search yields this [1] - an ordered list of maven dependencies for "Command Line Parsers".
mvnrepository.com is good for what you are describing [1]. For example, searching for "command line" brings up the clear top favorite and tells you the number of usages:
IMO maven is much better than gradle these days. Indeed maven or go dependency management is refreshing after you run create-react-app or shit like that.
The Java ecosystem of libraries is huge, it used to be one of the largest ones. I don't know how it competes today with Python and JS, but Java certainly doesn't lack libraries for almost anything you can think of.
Err ... the npm authors (the CommonJS modules/packages spec writers for package.json) mention maven and CPAN in their design docs and discussions as reference. Many of the early Server-side JavaScript adopters (in the 2000's before Node.js but well after Netscape's server-side JavaScript) were, in fact, Java/J2EE dropouts longing for something simpler.
One of the nice things about Java and C# is that they tend to have "chunkier" dependencies, that aren't split out into an interlocking tree of dependencies deep and wide.
For the most part, anyway... Things are kind of gross if you are trying to use newer nuget packages on the old 4.8 .net framework...
In Java-land most people build and do dependency management with Maven or Gradle. In either case, these tools can pull from repositories based on the Maven format. The vast majority of popular libraries are in repo "Maven Central" and "just work" if added to your dependency list. A number of smaller, more specialized repos also exist, and it's trivial to add additional repos to your Maven/Gradle config as well.
You can search for libraries on mvnrepository.com, or your IDE can search the index. Also most libraries will include a section in the documentation that shows the details of the blob you have to put in your pom.xml / build.gradle file.
> Different languages have different failure modes. With Perl, the project might fail because you designed and implemented a pile of shit, but there is a clever workaround for any problem, so you might be able to keep it going long enough to hand it off to someone else, and then when it fails it will be their fault, not yours. With Haskell someone probably should have been fired in the first month for choosing to do it in Haskell.
So much unnecessary hate and stereotyping. And I bet they were thinking they're tongue-in-cheek-but-still-sounding-clever.
Also, interesting choice of programming languages, neither Python, PHP nor C got any flack, Javascript was spared but Java, Perl and Haskell are evil and using them makes you a "mediocre drone that cares only about cranking the lever and spouting code" (I'm paraphrasing the article here).
Choose your technology, learn your tools...
> I enjoyed programming in Java, and being relieved of the responsibility for producing a quality product.
Although, with that mindset, maybe forego programming altogether.
The author makes it really hard to judge his tone, but I don't think you're reading it right. For example, if you peruse his other articles, it's clear he really likes Haskell (he certainly doesn't consider it evil).
I can't say I understand every one of his assertions, and trying to be funny/sarcastic makes it hard to truly understand the point of his article, which I think is: Java lacks focus and is a verbose language, and therefore you should probably pick something else to solve interview challenges. I tend to agree.
I thought he summed up the tone pretty well earlier in the article:
> Java is neither a good nor a bad language. It is a mediocre language, and there is no struggle.
To be more explicit - I think the point he is trying to make is that Java is not very powerful (in sense of expression), which has benefits (making it hard to fuck up badly) but at the cost of pushing the programmer towards mediocre, verbose and inefficient solutions (again due to lack of expressiveness, trying to come up with elegant and efficient solutions is too tiresome).
Perhaps it's the difference between a scalpel and a blunt club. You're not going to cut off your own fingers with the club, but you're not going to be able to perform brain surgery or fix someone's heart either. Not the best analogy because technically Java and any other language is turing complete, but they are not equal in how easy it is to coerce the machine into performing a particular computation, and expressing that humanly.
How do you measure "mediocre"? And what do you mean by inefficient? In any language you can code 99% of the things needed by 99% of most of the systems.
Most of the "I love/hate this language" is usually subjective perception or strong preference for certain programming paradigms: people loving/hating OOP, people love/hating verbosity and so forth.
You don't, it's all opinion, but that doesn't mean it doesn't exist.
We can at least all agree there is difference in the efficiency of writing a program in binary opcodes for a specific architecture vs writing one in C... although quantifying it is impossible, and that's just one quality.
Leaving the low level languages aside, most of the top level one can achieve the same things with similar costs. It's still up to the individual/team skill how those apps/systems end up to be built. If some project fails, is rarely "picking the wrong language" reason...
The author is MJD. He is, among other things, the author of one of the best functional programming books[1].
> I was a professional Java programmer for three years (in a different organization), and I have meant for some time to write up my thoughts about it. I am often very bitter and sarcastic, and I willingly admit that I am relentlessly negative and disagreeable, so it can be hard to tell when I am in earnest about liking something. I once tried to write a complimentary article about Blosxom, which has generated my blog since 2006, and I completely failed; people thought I was being critical, and I had to write a followup article to clarify, and people still thought I was dissing Blosxom. Because this article about Java might be confused with sarcastic criticism, I must state clearly that everything in this article about Java is in earnest, and should be taken at face value. Including:
> I really like Java
> ...
> So yes, I enjoyed programming in Java, and being relieved of the responsibility for producing a quality product. It was pleasant to not have to worry about whether I was doing a good job, or whether I might be writing something hard to understand or to maintain. The code was ridiculously verbose, of course, but that was not my fault. It was all out of my hands.
Java: plentiful well paying jobs, good/great tools, good/great runtime. Personally, I like boring, predictable, "easy" (referring to low cognitive overhead of statically typed languages in general) for work, and save the fun stuff (lisp/scheme in my case) for personal projects.
This is how I feel about C# and .Net - they are relatively easy to hold in your head, the tools are excellent for the language, and there are plenty of decent paying jobs.
There is very little to trip you up in C#, for my first project in it I sat down and started churning out code and looking stuff up when I got stuck. Try doing that with C++ and you will end up with a hole lot of trouble.
Yeah, keep writing perl and spout cynicism about everything.
I feel like they are chasing a aesthetic of conciseness, their perfect little haskell program, not recognizing that regularity and good api design are much more important.
What is beautiful for a 100loc program becomes ugly and wrong for a 100kloc program. Other aspects become much more important.
I'm not a huge fan of go, but it proved there is a necessity for boringness in cooperation.
Boring syntax does not mean the upper limit is mediocrity, saying that is revealing shallowness.
The notion that languages focused on writing large-scale programs must be "boring" seems a bit silly. What these languages need is lots of ways to define sensible modularity boundaries, and the "boring" aesthetic (or lack thereof, rather) can really get in the way of that.
Boring Is Best! When you have junior programmers joining/leaving teams, consistent, boring code written in one Boring PL according to Boring Code Conventions is like driving on a freeway in one straight direction with auto-pilot on.
Clever code written in half-a-dozen Cool PL's is like driving for your life in sharply turning mountain roads with no guard-rails - something guaranteed to become cataclysmic as your number of issues/escalations rise and rise, your tech debt becomes an un-surmountable mountain and you watch your hair turn grey before you are middle-aged.
I would submit that any language that reaches the level of adoption that Java does will be considered boring. The human mind has a tendency to prefer new/fresh things, particularly for people high in trait openness (big 5 personality traits).
Well, the counterpoint is that you shouldn't have a team composed of rotating consultants. And if you have one, you can't expect it to deliver anything with any quality or productivity.
But yes, if that's your team, then all code should be written the same way, all on the most boring way possible.
> But yes, if that's your team, then all code should be written the same way, all on the most boring way possible.
I agree that code should be written to be "as boring as possible" but even then, it's not clear that a "boring" language helps. What you really want in your scenario is very extensive and up-to-date documentation, both of inter-module boundaries and within individual modules. Java and C# supposedly try to make this easy, but mostly fail. The real reason they're still so popular is that they're easy to "learn" up to some not-even-barely-tolerable standard for the average cheap consultant.
As I said, there's a reason Java and C# are so popular.
And it may not even be a bad thing, I don't know the overall impact. It does cut a lot of good developers that could be creating great software out of it, but it also opens space for a lot of people that wouldn't add value in a different environment. It also adds a great deal of costs due to the bad software, but it probably increases the amount of problems we can solve with software.
> What these languages need is lots of ways to define sensible modularity boundarie
One of the most important modularity boundaries is dependencies on libraries written by others. So a good, easy to use dependency manager and a straight forward mechanism for creating and sharing libraries is crucial.
TL/DR: it's about readability and clarity of unfamiliar code.
One problem of large codebases is that they tend to be team efforts. Given a a sufficiently large and flexible language, each team member will find their own style and idioms for their code. This creates the subtle problem that team members are unfamiliar with each other's styles and when they touch the same pieces of code, they each extend the subset of used language features by whatever is required for their favorite idioms. Eventually, the resulting code gets too elaborate for its own good and maintainability goes down. A boring, simplified language ideally constrains the team to use more or less the same patterns and idioms and this side-steps the problem.
Can I say one thing that is great about the JAR ecosystem -- at least in a safe "closed moat" enterprise setting? Monkey patching buggy JARs! In my experience (and many others!), it is pretty common to manage an enterprise Java project that is stuck on an ancient version of a JAR. (This can be true in any language.) If you find a bug, it might be too hard to upgrade to the latest version. But you can easily copy the source code into your project and monkey patch it. Yeah, it won't win any awards, but it keep the ball of mud rolling forward. Yes, I know this technique can be used in lots of other languages.
Also, you make it sound like Java -- in particular -- has a lot of poor open source libraries. I would say the same for Perl. I wrote it for many years, and I was constantly working around tiny bugs in open source libraries. This isn't a comment on Perl or people who contribute to open source Perl libraries. Rather, this is the reality of using a huge amount open source libraries. About 98 to 99% will be "good enough". Then, you need to hack around the last 1-2% buggy bits.
One thing I have noticed in general (JavaScript, Python, DotNet, Java, C++), in the last 10 years, there has been a dramatic rise in unit tests in open source libraries. Fifteen years ago, you were lucky to have any unit tests. Some of the best libraries now advertise their unit test code coverage on GitHub. It is great progress.
I’ve never used the jar monkey patching workflow (or gone much further with Java than some getting started guides in the 90s,) so I could be wrong, but it seems akin to opening up a new high-interest line of credit to pay down your current debt. Everyone has a plan to pay it down before the promo APR expires, but most end up making the minimum monthly payments and a year later have yesterdays debt with higher, retroactively-applied interest. Unless you know of an imminent replacement or resource boost, assuming there will be a better time to actually solve the root problem seems crazy.
I actually agree with all of what you say. I have done monkeypatching of that sort -- as a workaround for some bug in Apache Wicket, I forget the details -- and it wasn't elegant but it worked.
Also agreed, I'm sure other ecosystems share these problems. I know nothing of Perl, but I trust you on that.
I'm just happy if I can sort of read the code. My standards are pretty low for judging existing code bases. This is not to say I'm not going to mouth a long drawn out WTF several times a day or scream "dogshit!" at the screen sometimes.
Five years ago I might have said this was a "dis" or "flame" article. Now I too see the benefits of java while simultaneously feeling it's a bloated and verbose language.
We have a tendency to believe that everything we produce needs to be "high quality" but that is a subjective measure. Sometimes we just need to write a program that can be handed off and maintained by the next set of devlopers. For that, java is a useful tool.
Programming languages are just tools. You will have your favorite to use but that doesn't mean it's the one you should be using on most jobs.
Java has come a long ways since 2014. You can now code in functional style pretty naturally, checked exceptions are fading from use, and tools like lombok have stripped away the worst boilerplate excesses (getters, equals/hashcode impl).
This always riles people up, but I'll assert it again: An equivalent modern app that does something useful is shorter in Java than in Ruby or Python, largely because the type system enforces many of the things you would otherwise have to write explicit tests for.
I feel like people get what makes for the best programming language wrong in the same way they get the "fittest" wrong with darwinian selection of "survival of the fittest". It's not necessarily the prettiest (although that can help) or the fastest, or some subjective assessment of the best. It's what survives. Sometimes that's a stallion, other times it's a dung beetle but both are the best at what they do and if you put it in the wrong environment they die. Java's just doing what it does and it has survived where others have died.
> write a program that copies standard input to standard output
This is pretty trivial in Java, just as in other languages. But most people don't ever need to learn the low level `System` methods needed to do it.
To me, this highlights the difference between a comprehensive approach to learning a language and a more piecemeal one. I learned Java by reading the canonical books from cover to cover, like Effective Java. But I think this is pretty rare.
For example, I recall interviewing many experienced Java programmers who didn't know what things like `protected` or `volatile` mean.
"protected" should be obvious, if you've worked on any non-trivial Java codebase. However, I've been working with Java for over 20 years now, and don't think I have ever actually used "volatile" once. The only reason I know anything about it is because I read "Java Concurrency in Practice" once upon a time, and have a really good memory.
In my experience with concurrent code in the business world, it's more common to enforce immutability rather than try to manage state updates. On the RARE occasions to the contrary (e.g. a "tripwire" flag of some kind?), accuracy is more important that maximum performance, so you would use an atomic class or something synchronized.
Really, I think this example more than anything else just shows that technical interviewing is a speed-dating crapshoot. You just have to interview at enough places to find an opportunity you're excited about, and where you happened to not stumble across any interviewer's personal bugaboos that don't match up with you.
In my career, I have used volatile incorrectly many more times than I have used it correctly. :) For readers who are not deeply familiar with Java's volatile keyword, you can read more about it here: https://stackoverflow.com/questions/13688697/is-a-write-to-a...
I feel the same about robust, easy to maintain enterprise software: Just use a blocking queue (or disrupter circular buffer for speed freaks) and make all messages/requests immutable. It is a trivial concept to explain to new hires and all but guarantees "boring" thread-safe code can be written by junior devs.
I think I finally understood volatile (in a pratical setting) when I read the source code for class CopyOnWriteArrayList. To be honest, the first few times I read it... the pattern made no sense. I thought to myself: "Why use volatile?" After reading many times (and using volatile wrong many times), I finally understood the pattern.
Maybe thats the difference between "having mastered something" and "doing something a long time"? I cannot imagine an experienced Java programmer that doesn't know what "protected" means, its use is fundamental and pervasive. As for "volatile", idk - not knowing it hints at that person not having a concept of thread-safety. I'd expect someone who claims to be a senior to maybe not give me the memory model implications, but at least having a rough idea of what it is used for.
volatile has nothing to do with thread safety or the memory model in modern C. It's strictly for access to memory-mapped resources, where common assumptions relied-on by optimizers may fail. It should never be used for multithreading, use proper atomics and other provided facilities instead.
True, the guarantee of atomicity does come up in Java wrt. fields of type long or double, for which atomicity is not provided by the Java memory model in the absence of volatile. More to the point, volatile in Java provides linearizability which is a bit stronger than simple atomicity.
While somebody writing concurrent Java code should definitely know the atomic classes, locks, and possibly var handles if they are implementing their own algorithms, they absolutely should also know the semantics of volatile. It does not provide thread safety in C or Java, but it’s very important in choosing how to define your data structures.
Volatile is an interesting one because it highlights a facility of the JVM that some other runtimes don't provide, namely multi-threading AND multi-process. Someone coming from node or python for example may not appreciate what's going on behind the scenes unless they go looking or have been exposed to those ideas.
Your comment made me think of a very difficult programming interview question: Can you copy STDIN to STDOUT in a non-blocking fashion? My point: The most trivial solutions assume that STDIN will give you all the data very quickly, then STDOUT will accept 100% "instantly". Using only Java, I don't know the solution off the top of my head. I will need to do a little bit of research.
However, using POSIX calls with C (select() and friends), yes, I could imagine a way to do it.
Deeper: Can you write a function to launch an external process then (a) write to its STDIN, (b) read from its STDOUT, (c) read from its STDERR -- all independently and without blocking? It's a hard problem!
It is rather non-trivial to write a program to copy input to output if one requires proper handling of a termination signal when the code flushes the already read data without waiting for more and exits without loosing any buffered data. Knowing how to do that is a good sign that the person really knows the language and it’s libraries.
As another comment has written one needs Runtime.getRuntime().addShutdownHook(). The hook then, for example, closes the input stream to ensure that it’s reader is woken up from a blocking read and then waits until the already read data is written. In turn this requires to know how synchronization works.
I learned Java from the “Core Java” books 20 years ago. The language has changed so much since that I’m tempted to pick up another “Java from scratch” series and read it cover to cover to see how new developers are viewing the language now.
I’ve recently joined a company using Java. I’m open minded, and know that there are lots of good things about the JVM and the modern Java language. However one thing I hate is the complete disregard for command line UX. People writing Java command line tools seem to think it’s absolutely fine to spew 1000 lines of unformatted informational messages and non actionable warnings with bizarre indentation and not to provide any flag to turn this shit off. It’s like they just view the terminal as some sort of obscure log file that no-one’s likely to look at.
Java programs are usually daemons and internally use a logging library, per default stdout is set up as one output for logging. One can usually configure the logging with the log4j or logback config files and even suppress stdout.
Nobody wants to be blamed for something not being in the logs, probably in production. So everybody adds everything to the logs, you can always filter out the noise but not the reverse, right? And very soon the logs are completely unusable for your regular-dev cycle. Of course in java world, the IDE reigns, and checking logs is an "antipattern" anyways, you must use the fantastic debugging GUI that is provided by the behemoth. Everything is normal, you see.
Especially annoying when reams of nonsense also gets 'unexpectedly' sprayed into the web browser of some poor sod using an enterprise app, just because Java is having a bad day. This seems to happen less than it used to a few years ago, so there is some progress going in in software engineering, somewhere.
These sort of posts crack me up as it's another person jumping on a bandwagon they don't understand, but are also really sad, as it's taking a lot of otherwise talented people and ruining them.
> being relieved of the responsibility for producing a quality product
I've seen this sort of elitism in candidates and I've made the mistake of hiring them. It turns out they're just not very good at all, and they blame their failures on anything but themselves, stunting their self-growth professionally and interpersonally.
> I've seen this sort of elitism in candidates and I've made the mistake of hiring them. It turns out they're just not very good at all, and they blame their failures on anything but themselves, stunting their self-growth professionally and interpersonally.
If this is a trend for you, you're probably a bad hirer and in a toxic environment!
If the infamous HN Dropbox comment didn't exist, this post would serve well as the canonical "facile dismissal".
Reminded me of PG's essay about the "blub" programming language.
But, in this case, I'd like to reverse the use of the concept: it's not that Java is a blub programming language, but that the OP has only reached a blub-state of understanding it and its potential, and produced a blub (generic and derivative) argument against it.
I don't think Mark Dominus has a "blub level understanding". This is the author of the hilarious "monads are like burritos" and many others, and it's quite clear that he is very opinionated but also very knowledgeable about programming languages.
Having programmed in Java for... what, 15+ years? I do agree with him about his assessment. Trying to solve an interview challenge in Java is to handicap yourself, unless it's the only language you know.
Yeah, I'm not really talking about the OP per se, to be frank (didn't check who he was, and I don't know his story).
So, my assessement wasn't about the OP in general, but the OP as revealed by this particular post.
The post is based on the cliche early/mid-00s J2EE style of coding, that hasn't been in fashion for 15 years, and has been derided widely for at least 12.
There are amazing apps and libs written in Java, and Java as a language was not a problem for their development and design (even when it was far more restricting and ceremonious). Lucene for one. Vert.x. Jetty. XOM, ...
To quote Wiki (https://en.wikipedia.org/wiki/Paul_Graham_(programmer)):
<<
Graham considers a hypothetical Blub programmer. When the programmer looks down the "power continuum", they consider the lower languages to be less powerful because they miss some feature that a Blub programmer is used to. But when they look up, they fail to realise that they are looking up: they merely see "weird languages" with unnecessary features and assumes they are equivalent in power, but with "other hairy stuff thrown in as well". When Graham considers the point of view of a programmer using a language higher than Blub, he describes that programmer as looking down on Blub and noting its "missing" features from the point of view of the higher language.
>>
In my experience, it sounds like a very cool idea, until the first time you see someone programming DirectX using Excel/VBA. (Yes, it can be done.) My point: When you see someone using a "dumb" language (in your humble view), first ask if you are ignoring a Chesterson's Fence! For the avoidance of doubt, no, I am not seriously suggesting it is a good idea to program DirectX using Excel/VBA in 2022.
> If it takes ten times as much code as it would to program in Haskell, that is all right, because the IDE will generate half of it for you, and you are still being paid to write the other half.
Well that explains it. For me, I’m not going to touch Java unless I’m being paid to do it. IMO it’s a travesty that Java is the language of the AP test, because it really leaves the impression in young people that all of programming is Java. If that were the case, I’d be as far away from programming and computers as I could get.
Kotlin is surprisingly good if you cannot afford Scala. It's less divergent from the Java ecosystem and doesn't introduce anything conceptually new. But it's not that popular on the backend.
The only thing about it I personally find very unpleasant is its idiomatic approach to concurrency. In the world of Futures and go routines continuations are such an outlier.
I find it hard to remember more than one company I have interviewed with in the last ten years using Clojure. It was hyped together with Erlang in 2009 or so and nobody remembers either.
I feel like my Java skills improved greatly after switching to kotlin, because it made me realize how much more code I'd have to write for the code to be nice. The simplest example would be "val x = ..." vs "final String x = ...". Sometimes I just wouldn't bother with the "final" keyword, but now I cannot let mutability ruin my code.
I've had a bit of fun with Java some years ago when I was asked to write a converter from some proprietary music format to midi. Using Java was non negotiable requirement. While I succeeded and the project brought me gobbles of cash in very short time I was grinding my teeth on byte / bit level manipulations. Java was definitely not created with this kind of programming in mind.
Modern Java is actually pretty good. It's taken great features from other JVM languages like Kotlin and Scala and is much better for it. The JVM is a wicked fast run time and its nice to have a mature ecosystem of libraries to work from and large pool of developers available who know it inside and out. You could do far worse when picking a language for your team to use.
I actually really don't mind Java-the-language all that much, in fact I'd say I think it's pretty great. My problem with Java is that the ecosystem and culture of Java tend to leaning heavily on annotations for everything. It's not just Spring (though this is probably the worst offender) but everything from Configurations and Command-Line Parsing to DB access and connections, testing, serialization, it seems like overwhelmingly the community leans towards annotations for everything which to me makes working with the tools really difficult to discover and even more difficult to control or modify. There are some exceptions like Vertx.io for instance which are plain-code baed but I find working in a "Java shop" you are usually pushing against the grain if you're trying to avoid Spring/Hibernate/Jackson/etc.
The problem is that without annotations, injecting behavior or doing any sort of metaprogramming is nigh impossible. Higher-order functions aren't fun to deal with in Java, even in the post-Java-8 world.
I have written a good deal of Java as a professional Java developer for over 10 years. The core truth the article gets right is that Java is meant to be a language Enterprise developers can use and be reasonably sure other people can pick it up and work with it. Java is a defensible choice in that you can hire people that know Java, easily buy Java training, and have a lot of tools for Enterprise Java development that you can get (OSS or commercial) that will help your Java developers get Enterprise apps created.
Java, in many respects, is the COBOL replacement created in the 90s that will live on in the Enterprise for decades to come. Just as COBOL lives on.
Java has a high bar for the amount of prerequisite experience it takes to write good code. In other words, it has too many pitfalls for beginners. It is a phenomenally poor choice of language for teaching beginners to code.
On the other hand, a lack of beginner-friendliness could also be seen as a lack of effective static analysis. Of course, this is a very Java programmer point-of-view.
Others: "you shouldn't need to have that"
Java programmers: "but I do have that"
If you are in a position to pick tools for your organisation, think about how your choices would accommodate beginners. Not all of your tools can be or should be easy for beginners to use, but it is an important quality to consider.
> lack of beginner-friendliness could also be seen as a lack of effective static analysis
Slightly confusing comment to me ... Java has on the one hand a relatively simplistic static typing system but on the other hand some of the best static analysis support that you can find (I don't think it's a coincidence; the relatively simple type system and lack of ways to hack around it facilitates the strength of the analysis that can be done).
I'm talking about things like, add a parameter to a method in a library and eclipse automatically not only deterministically renames it everywhere that its called in the library but in every dependent project, all in milliseconds. And a dozen other similar types of operations.
In hindsight, I understand your confusion. I agree with your comment.
Without static analysis tools like error-prone, findbugs, nullaway, checker framework, sonar, PMD, IDE-provided analysers, et cetera, it is easy to write problematic Java.
On the other hand, the Java ecosystem has an abundance of such tools available and almost everybody is using them. (Hence, "but I do have that")
Java ain't no Scala to have any unusual prerequisites. It was designed as the golang of the day and that still shows in its lack of particularly sophisticated features.
Speaking of beginners, I'd venture to say that Java has the largest library by now. From Core Java to Java Concurrency in Practice, pretty much everything was well described years ago. The same is true about Design Patterns/Refactoring/DDD-related literature which was originally popularized mostly in the Java world.
I actually agree that JVM-like platforms should not be used for teaching beginners. Something like Python (or TypeScript?) is probably appropriate for high school usage. In my time it was Borland Pascal which was a nice first real language and a great IDE. All on a single floppy disk :))) I
I'm curious what these pitfalls are that you're referring to. Can you elaborate? It's been a long time since I was new to Java, and this sort of outside perspective is always a good thing.
Maybe GP is talking about type erasure, or considering the mention of teaching, it might be something more obvious like reference type vs value type distinction, strings cannot be compared using ==, etc..
A little tongue in cheek, but the strength of Java is that you don't have to actually use it to work in the Java ecosystem. Here is the entire program to copy stdin to stdout in Groovy:
I like the Apache Pulsar codebase. Well designed with a mix of code at different layers of abstractions depending on the module. Particularly good if you want to learn about writing network servers and distributed systems.
Nothing taught me as much about API design and testing as Google's Guava. I know there are lots of minor gripes with that library, but is it so incredibly consistent. It is also amazing that no one mentioned the Java Collections (ArrayList, LinkedList, HashSet, HashMap, TreeSet, TreeMap). They are some of the highest quality generic collections that exist anywhere. (For C++, I would say the same about an STL implementation by a high quality project like VCC/GCC/Clang.) For "Java high honors", try to understand how concurrent collections work, e.g., ConcurrentHashMap!
Want to pick up some modern Java(11+?) best practices in general since my knowledge is mostly stuck in Java 7/8. Would appreciate recs on codebases, books, talks, etc.
I'm not a professional Java developer, but I work at a company that uses Java, so it just came with the territory to understand things about it, even though I've already had at least a basic grasp of it. I feel blessed that most of the code is mostly straightforward Core Java code (as opposed to any framework-level fun). It is treated a bit like a systems programming language. However, I can agree with this article. It's safely boring to me (despite the fact that having an IDE to write your boilerplate is still necessary for the sake of your fingers.)
Since not being a pro at it and not planning to be, I'd rather toy with other things. The job market is diverse in its technical needs. :)
Anytime I learn a new language (I regularly write code in several) I start asking how is testing done, where are the libraries, where is this, and how do I do that? I already have all of that and more at my fingertips. Also, Groovy is vastly underrated. It’s the most economical and easiest to understand language I know meaning I can do more with less code and faster in general.
Groovy is definitely underrated when it's done properly (pretty much my favorite language when used as a "java substitute"). Unfortunately most people's exposure to it is in Jenkins or Gradle where it's a bit of a train wreck.
Cool. I didn't know about that one. I also learned about the new system logger since log4shell happened. I should make a project to see how much I can do with just the Java standard library in 17. Maybe I don't need any dependencies.
Yeah, reading it all I still think the author is just dissing Java, despite his, in big bold font "I really like Java". Nevertheless I had a really good laugh.
I spent much of my career writing Java code but have moved to Go - it's almost a return to my roots as an embedded systems engineer (without the memory management hassles of C) and it's vastly more economical to run Go applications in containers. I do find myself writing code that I used to pull in from a library though.