There are warts in the standard library to be sure, but many of them have already been filled in by third parties like Apache Commons, Google Guava, and Joda-time. I'm sure there are others I'm not thinking of.
I'm glad you added that last line, because that's basically the whole story. Java is /very/ backwards compatible, and it's got round the...errr...quirks of the early versions by having a massive ecosystem of alternative implementations. Some of these (like Joda-Time) are good enough to get widely accepted as the 'correct' implementation.
I don't think anyone will argue when you say that that throws up some barriers to entry, but they're not massive barriers, the standard library does still work. Not having to rewrite your code every six months is much more important.
The Lombok stuff is pretty nasty, all kinds of hacks to hook into the compiler internals in unnatural ways. If you want those features just use a language which provides them, rather than awkwardly bolting them onto a language that doesn't.
Filing in the holes is nice, but without actually making it a design choice java embodies TMTOWTDI more than perl ever did.
For many common tasks there are 5 or 6 different standard library calls that seem to do the same thing, but 4 of them are to be avoided at all cost, but there's no depreciation tag and the official javadocs don't contain any pointers to the newer classes.
Yeah, and I've already come across most of those. Integrating lots of that stuff into the standard libraries that Java ships with would be exactly what I'm thinking of...and jettisoning all the broken GUI frameworks and such. And cleaning up the disaster pile that is I/O. I mean, I think there's still stuff sitting around in javax.* from when I last touched Java 14 years ago. I thought that was supposed to be the experimental branch where things might change without warning? Let's clean that up.
I know most IDEs just ship with all that stuff included, but I've found it makes packaging up things to give to somebody else a little more complicated than I'd like...which would be resolved in the standard libraries.
Because God knows, Java needs another logging framework. Seriously does ANYONE get any additional value out of the morass of crappy logging systems out there over and above System.out.println? Log4J is PARTICULARLY brain-damaged, with its refrain of "ooh, someone put a log4j.xml in their JAR (one of hundreds), that beats your log4j.properties.". Or SL4Js amazing performance of "1.6 doesn't work with Scala because of ambiguous varargs". Or who can forget the incredible log4j logfile appender with the global lock around the file I/O? Not to mention the interactions between SLF4J and org.whatever-it-is-this-week.Jetty's built-in crappy logging facade.
Really, NEVER has so much effort been spent for SO LITTLE REWARD.
Yeah and I don't get why the loggers default to noop when they're not configured correctly. Here's a typical scenario:
I'm deep in the zone, half way through fixing something and it's not working. I start up my app and realize log4whatever can't find its configuration so it defaults to no logging. Now I need to unpop my mental stack all the way to switch gears so I can fix this logging configuration issue because for all I know the key to my problem is in the log message that log4whatever hides when it's in noop mode. Why not default to as verbose as possible?
From what I can tell, the majority of these crappy Java logging frameworks are made by this one guy who keeps on screwing up. Eventually he abandons ship and starts over again. log4j, logback and slf4j are all by the same guy.
Never had a problem with slf4j on top of log4j. By the way, I use DEBUG in development and INFO in production. The ratio of logging messages between the two levels is about 1 for 50. Definitely an useful feature on top of System.out.println. I also change log levels for certain packages because some libraries are too verbose.
Agreed. I find it difficult to understand people griping so much about java logging. I know it's not perfect and I wish it were better, but it's really not that bad. Maybe if you come from Ruby or some other newer(ish) language, they only have one logging implementation (I don't really know the state of logging in other languages, so apologies) it's easy to point fingers. You learn your logging, use it, and be done with it.
I am currently in what you could consider log hell with a product based on OSGi. We have been using ops4j logging which has done a fantastic job of adapting the prevalent logging frameworks (log4j, slf4j, logback, and JUL) into the SLF4J API and we don't even have to think about it anymore.
Hmm. I've used that feature about once in 20 years of coding professionally.
My production systems don't generally log; they're busy serving (I once worked on a hard real-time embedded air traffic control system where production logging was literally a single bit of information - a logic level that went high when the processor was busy, and low on idle - so we could measure our timing safety margin with an oscilloscope)
Test systems log at debug except for low level packages that insist on ridiculous logging (Hibernate, http client - and both of those have ANOTHER level of hacks to do wire-level logging in addition to the standard stuff).
Logging is just so painful, and not just in Java. Debian switched to rsyslog some time ago and I am still seeing no benefit at all, yet have to learn yet another half-arsed buggy scripting language to achieve simple things like, oh, not having my DHCPD logs showing up in three different files. FFS people.
> Hmm. I've used that feature about once in 20 years of coding professionally.
Try debugging systems for which you can't access the system directly ... say in a product that you redistribute to customers. You will change your tune rather quickly.
For product development, having a good logging system is critical. And, honestly, other than rolling my own over the years (20+ years experience developing and distributing products), the Java logging systems are pretty decent. It can be a pain to get different logging systems to work together and properly configured, and I do wish it were better, but System.out.println() ain't the answer either. When I spend a little time getting them to work right, they do their job. And that is time well spent in my opinion for redistributed products.