Hacker News Reader

The only way to think about Java and not go insane is to forget about pretty much the entire built-in standard library and instead go use the extremely solid 3rd party libraries. If I don't have JodaTime, Apache Commons and Google Guava on my classpath, I feel like my hands are tied.

That's one of the main reasons I enjoy programming in C#/.NET. The fact that there are, as far as I'm concerned, a solid set of de facto libraries without having to hunt around for third-party ones somehow makes me feel warm and fuzzy.

Thanks for the recommendations. I've been pretty happy with the little bit of Commons that I've been touching. Haven't tried Guava out yet...on the list.

Guava is decent enough (though not complete enough for my tastes), and should be much much better when lambdas are available.

I think that's a bit strong. There are bits of the standard library that are fine - collections, concurrency, and anything else designed by Doug Lea. I even get on fine with IO and most of networking. Sure, Guava adds a lot of really nice stuff to collections, but it adds rather than replaces.

Then there are bits which should be avoided at all costs. Date and time is one. All the GUI libraries are another. HTTP via URLConnection isn't terrible, but people mostly use Apache HttpClient instead. NIO is a mixed bag, with some really good bits, and some complexity whose necessity escapes me (particularly since it can be hidden by XNIO without losing anything).

It is a real shame that there is this patchiness. I would love to claim that all the rough code is from the pre-1.2 era, but i would be lying. Particularly if you look beyond the JDK and into the enterprise libraries, there have been some real shitshows given official imprimatur (i remember Java Advanced Imaging being particularly horrifying).

JAI was real bad.. JMF (Java Media Framework) was another one, which for a while had the unfortunate distinction of being the only reliable way of playing video on top of being poorly documented and turning into abandonware.

With the exception of JodaTime, which is quite well designed, most of the third party libraries you mention or absolute shit. Apache Commons in particular is worse than ammateur hour work.

And while the quality of the standard SDK varies, most of it is very good, and there are stuff that's solid gold in there, like Nio and Concurrency libs.

I've had good luck with Apache Commons. What specifically do you find objectionable about it?

Also, you really shouldn't just drop "x sucks" into a conversation without backing it up with something reasonable. Or was this a well-crafted troll comment?

Well, regarding the "x sucks", I was responding to someone who advised people to "forget about pretty much the entire built-in standard library" lest you want to go insane.

As for the Apache Commons, well where to start? It's been several years since I last dealed with them, on my Java days, but there were lots of issues.

From the general overboard AbstractFactoryProxyFactorytis and overall OO fails (real example: DoubleListIteratorListIterator), to useless utility classes that replicate already existing SDK capabilities, to the lack of generics support for the collections (for a looooong time, don't know if they fixed this now) -- oh, and them not being compatible with Java collection interfaces either --, to lack of thread safety, to string output libraries blisfully unaware of the existance of encodings, and a whole lot more besides.

Funny how in languages like python or clojure, the bazaar library eco system can be a fuzzy moving target daunting to control, while Java stdlib is on the other side of things, but too far, Guava, Apache Commons, Joda could have been made standard but it's not.

Well the new Date and Time API is a reworking of Joda by the very author of Joda, so that one's there.

you're right, I'm .. outdated.

>After banging my head for a couple hours trying to figure out the magical combination of classes I needed to assemble to get a date formatter to work, I just ended up rolling my own in half an hour.

It's really not that difficult to assemble the combination of classes to get a formatter. There are problems with the API, but that's not one of them.

Plus, your hand rolled case probably misses hundrends of edge cases (I'm not exagerrating, date and time is one of the most difficult things to get right).

It turns out certain subsets of things you need to do with Dates are pretty easy. In my case all I needed was to convert a date format to another. All I wanted was something like

   Date thing = new Date(someStringWithaDate,"MMM dd, yyyy");
   String newDateThing = thing.convertDateFormat("yyyy-mm-dd");

and be done with it. Or at worst

   Date thing = new Date(someStringWithaDate,"MMM dd, yyyy");
   Date newDateThing = thing.convertDateFormat("yyyy-mm-dd");
   String someStringWithaDateButFormattedLikeIWant = newDateThing.toString();

But the overwrought standard library just completely got in the way and I don't even remember how many lines of code and objects I ended up with just to do this before I said "fuck it" and did the equivalent of (with a some utilities to convert abreviated dates to numbers.

   String.replaceAll("([A-Z]{3}) (\d{2}), (\d{4})","$3-$2-$1");

Of course now I'm not getting whatever date validation the Date class might offer (if it does), and I ended up using a 50 cent solution when I really needed a $1.50 solution, but the standard library only offered an overpriced $20 way that I didn't need.

The end result is that we're all poorer for it.

A quick google would have found: new SimpleDateFormat("HH MM YYYY").format(new Date()); new SimpleDateFormat("HH MM YYYY").parse("17 02 2014");

Well geez, there you go. My google fu obviously failed me, I definitely did not come across this yet another Date Formatting library in the Java Standard Library.

Why isn't all this garbage just bundled into the Date class? It seems to me that among the many things somebody might want to do on a date, converting the String representation might be one of them.

okay here's what I'm talking about. From the API docs on Date

   toGMTString() - *Deprecated.* As of JDK version 1.1, replaced by DateFormat.format(Date date), using a GMT TimeZone.

   toLocaleString() - *Deprecated.* As of JDK version 1.1, replaced by DateFormat.format(Date date).

   toString() - Converts this Date object to a String of the form: dow mon dd hh:mm:ss zzz yyyy

All either deprecated or useless (dow mon dd hh:mm:ss zzz yyyy? really?). And the documentation doesn't point to the better classes to do what I want.

Okay, so what's a DateFormat?

   DateFormat is an abstract class for date/time formatting subclasses which formats and parses dates or time in a language-independent manner.

Okay that sounds promising, of course they're admitting they don't have the concept of a "Date Format" object type since it's all just static stuff, so shouldn't all this just be in the Date class? That feels weird.

Wait there's a DateFormatter, that sounds promising, it's all verby sounding.

   DateFormatter is an InternationalFormatter that does its formatting by way of an instance of java.text.DateFormat.

Well what the hell is an InternationalFormatter? And down the rabbit hole I went.

I did eventually figure it out. But it was so inelegant and stupid I felt ashamed to have it in my code. If I had read one more line in the DateFormatter doc I suppose I could have found SimpleDateFormat, but the bizarre complexity about converting formats was already so mind bendingly dumb.

This is stupid and obtuse design, overly parsing the problem and unnecessarily separating what should be connected pieces of the puzzle.

Solution (needs revision, but this would be a useful point to start a discussion):

Classes

Date - a representation of a specific date and time down to millionths of a second resolution

methods:

   add, sub Dates - returns Duration

   add,sub Duration, returns Dates

   one of the constructors takes a String that ostensibly contains a Date of some sort, and a format String to parse it, throws exception if the date isn't valid

   setOutPutFormat - takes a Format string and the next call toString() emits on that format.

   all the get, set hour minute day year methods so you can pick it apart change pieces as you want

   setOutPutCalendar - changes the Date to whatever recognized calendar system (Chinese, Arabic, Hebrew, etc.), setOutPutFormat is context aware of this

   all the timezone stuff

   after and before

   get/set 2 digit year

   Date comparison methods like isBefore(Date) to see if another Date object is before or after this one

Done. All of Date, DateFormat and SimpleDateFormat is there, problems solved

Duration - an representation of a time Duration (6 days, 7 minutes, 14 second), and since all time intervals are durations, that's it.

Methods:

   Constructor can be an ISO 8601 String for Duration or two Date objects representing the beginning and end of a duration. Since Date objects should have their own timezone and locals, the magic black box of this class should figure out the duration for me. It's not my problem to sort this out. If the begin and end dates produce a negative duration that's cool because now I have a countdown.

   Duration comparison methods, like isWithin(Duration) to check if another duration object is within this one or isWithin(Date) to see if a Date is within the duration or isLongerthan(Duration)

  Duration math like add/subtract other durations from the begin and end of the Duration

Done.

Most of what you want sounds like DateTime and TimeSpan from .net.

However Joda does a lot more, like taking into account the various historical, political changes in time zone, and the distinction between a duration between two human-understandable semantic times, versus a duration as a fixed span of time.

I'm probably looking at the issue too simply, but shouldn't all that be abstracted away into the library, with maybe some notes on particularly weird cases?

I'm also not sure I understand the distinction between the two durations, if I set a startDate object up on the Islamic Tabular Fatimid calendar and say it's year 14 and endDate is some pre-reformation Julian calendar and say it's year 231, shouldn't the Duration class be able to figure out a fixed span of time from that? I really could care less how it does it, just that the right number of years, months and days fall out of it. Or if I just want to create the object with some defined span, they're the same thing.

Given a date, how do you obtain a new date equal to the same month and day of month in the following year?

You can't do that consistently with a duration measured in milliseconds or nanoseconds. Instead, you need a more abstract representation of time, something akin to "increment only the year field of a date".

That's what Periods are for.

I think you are overlooking the fact that perhaps there was an easier and/or more idiomatic way to convert from one format to another, but that you missed out on how to do it with the (admittingly poor) standard date/time libraries since you haven't had to solve this particular problem in Java before. You probably just want something like:

    DateFormat format1 = new SimpleDateFormat("MMM dd, yyyy");
    DateFormat format2 = new SimpleDateFormat("yyy-mm-dd");
    String originalDateString = ...;
    String newDateString = format2.format(format1.parse(originalDateString));

Even in something like Python, the basic pattern is the same: a call to strptime to convert from string => date object in the original format, and a call to strftime to convert from date object => string in desired format.

True, it's been so long since I Java'd at all, that I simply don't remember the idiomatic ways to do things. And those ways have probably changed quite a bit in the intervening years.

Still it seems conceptually weird that the idea of a DateFormat object can be a thing, when it's just a String with the magic Format language.

Parsing or formatting (the verbs) seem more like actions to be taken on a Date itself. It seems much tidyier to me to just keep all that contextually in the Date class.

From a theoretical perspective, date formatting is a behavior that can be accomplished in a number of different ways. While the pre-Java 8 API only provides SimpleDateFormat, JodaTime provides a similar class and a slew of formatters based upon ISO8601 that don't use patterns at all.

From a practical standpoint, SimpleDateFormat and its analogues don't operate directly on the format string you supply, but instead compile it into a form that is easier to process. If Date.format was the only way to format a date, then the format pattern would have to be recompiled on every call (or else cached, which would affect thread safety).

Now, String.split exists, despite having to recompile the regular expression every time it is called (except for certain optimized cases), so presumably Date.format could also exist, but DateFormat would still be preferable for many cases.

Regarding date and time stuff, everyone appears to use Joda-Time: http://www.joda.org/joda-time/

If you want inconsistent, .Net framework's collections and HTTP stuff was the worst for years. They added to the former and wrapped the latter but you still fall over crimes. Java collections and Servlet API are pretty good really in comparison.

It's not terrible really. Anything on that scale is inconsistent: python, ruby, .Net, C++.

The hard bit is learning where stuff is hidden. I'm currently doing that with Objective-C.

> Anything on that scale is inconsistent: python, ruby, .Net, C++.

Well, I wonder if this is necessarily inevitable. The Oxford English Dictionary is probably as large and complex as any of the above, but is remarkably consistent in style and tone. I'm a firm believer that good design extends to code (and coders are sadly not very good designers in general).

Agreed. It definitely shouldn't be inevitable.

I left Go off that list precisely for that reason.

The difference between a dictionary and a standard library is you can change entries in a new dictionary as much as you like and no-one will complain that their book no longer compiles :)

It would be nice if a programming language came along that designed all features right from the start, so no features ever needed to be deprecated or redesigned. Unfortunately I have yet to find a language that is all things to all people, even after several versions; designing a language perfectly from scratch might not even be possible.

Yeah I agree. But perhaps a tick-tock version release schedule could work well for this. Odd number versions fix bugs, and even ones introduce new things, deprecate old things, fix bad syntax etc. I know it's sort of being tried with Python right now, but it's sort of this monumental this or that (with that not being clearly better) that doesn't seem to be working. The way the Perl community is back porting perl 6 bits into 5 does.

Keeping the even releases well scoped would ease the pain of transitioning. Maybe ensure some guaranteed level of support for 12-24 months a la Ubuntu and we might have a good model for language development.

Well, deprecating the language every 12 months would sure be good for developers on support contracts. If we could make it so most new software needs you to have the latest version of the language/vm/runtime, and our software needs an older version with deprecated features, customers would have to keep paying for upgrades whether we were adding new features or not.

For the end users, people who don't get paid to do maintenance etc it might not be so good.

There's not really any reason why software couldn't still be maintained/written in an older version of the language, and have older VM/runtimes sitting around to deal with that. It's not like I can run Java 7 code on a Java 6 VM.

Hell, isn't that de rigueur anyways these days? We're already dealing with this problem, except the language itself is getting worse.

Java is actually very good at backwards compatibility - sometimes IMHO going annoyingly far, like type erasure on collections. Java 6 bytecode will run on the Java 7 JVM, and Java 6 source will compile with the Java 7 JDK, modulo one or two incompatibilities [1]. Oracle 'highly recommend' you uninstall old versions [2].

On the other hand, when I install the Google App Engine Python SDK on Ubuntu it causes my hex editor to stop working. And I use some Ruby software where getting it working meant a nasty fight with xcode and rvm, which left me fearful that if I ever upgrade, reinstall or switch computers I'll never get it working again :) admittedly my knowledge of ruby is pretty weak.

[1] http://www.oracle.com/technetwork/java/javase/compatibility-... [2] http://www.java.com/en/download/faq/remove_olderversions.xml

So, are you using python3?

I agree with you. yeah, there are some new APIs in nio Files that you weren't aware of. But now you have to know go to Files for the "Good API" instead of the old "File" API. Bow to the Gods of backwards compatibility!

The JDBC API is still beyond horrible (is there a decent 3rd party SQL API?). Checked Exceptions still survive. String still lacks many basic features.... and sadly as others have pointed out to get usable APIs you need Apache Commons.

I agree, Oracle needs to do some house cleaning. Some times it's ok to break things. Don't do it too often, but once every 10 years seems ok to me!

The Java standard API has a lot of inconsistencies, but it would break too much code to remove old stuff. A simpler first step would be much more aggressive use of @Deprecated. There are entire packages in the standard API that should be deprecated. Most Java IDE strongly discourage using deprecated code. More use of @Deprecated would encourage future Java code to use more modern APIs.

As for the reading file into a string, there is almost somethig like that: http://docs.oracle.com/javase/7/docs/api/java/nio/file/Files...

There is a method for reading a file into a list of lines (it is strange that they didn't include a method to read the lines into a single string).

In Java 7 you can use Files.readAllLines to read file to string, also there is a built-in CSV parsing library, it's called String.split() :)

> Files.readAllLines

Geez, I think I've already reimplemented that half a dozen times. Of course it would be buried in the Files class and not one of the 30 dozen buffer reader whatever classes I have to piece together.

> String.split()

Yeah yeah, that's what all the Java books say ;)

String.split will work fine until you have data like this: Sarah Jones,Paul Williams,"Smith, John",Fred Johnson

It's best to use a library for this like SuperCSV: http://supercsv.sourceforge.net

This. This is such a common problem, I added it to our formal code test. We supply an interface, a unit test and a rather broken CSV file and they have to make the test pass by adding the implementation.

22 people failed the test entirely, complaining about quotes and line ending inconsistency.

2 people wrote a proper state machine driven parser that didn't work.

1 person wrote a proper state machine driven parser that worked.

1 person imported commons-csv and wrapped stuff.

The last person got the job.

2 people wrote a proper state machine driven parser that didn't work. 1 person wrote a proper state machine driven parser that worked.

You probably missed three really good candidates here.

Sure, but if you've only got one position, you might as well go for the one with enough experience/wisdom to get it right.

I thought for coding tests implementations are supposed to be done from scratch on. Or at least the guy who wrote the working parser should be on top of the list.

Not really. We want people to solve the problem, not invent something that needs maintenance. In some cases, from scratch is important, but for most it's not.

Sounds like you don't want competent people to challenge the rest.

No we don't want competent people showboating and pissing cash up the wall reinventing wheels that have a high maintenance cost because it's fun.

We hire engineers.

An analogy: would you hire the electrical engineer who knocks up an ASIC for every task or the one who designs in a COTS part for a predictable unit cost and manufacturing lead time?

>>1 person wrote a proper state machine driven parser that worked.

Look, the fact is, based on the replies below, this guy is probably better off working somewhere else.

Not to go off on this particular person, the preoccupation with "Library Knowledge(tm)" in the enterprise (so, Java) world has become an epidemic. I have seen libraries used for all the wrong reasons, pulling in great gobs of someone elses code to do a bloody string copy!

Damn, you are hiring coders. Let them fricken code, for God's sake.

Please, I know all of the counter arguments (I've been harangued by them for years), but I really think that there is a middle ground here. Some things are truly worth bringing into a project via library. Big things, things that are really hard things that you may not have the staff to handle. But if we are afraid to let coders code some stuff, even trivial stuff, then we have killed the one true joy that we had in the first place: coding!

One thing to remember about libraries is that they have bugs too! Just because someones got an apache page, doesn't mean that there are no bugs in there lurking. You WILL most probably need to understand the problem/solution well enough to use the library in the first place.

Gosh, rant off.

In my mind the bigger issue is that something like CSV parsing is so common, and so old that it just should be part of every higher level language's standard library these days, as common as split() is. That way people learning the language learn that you just do it with the library and get on with it.

(I agree with the rest, anybody can more or less learn their way around a library with a little time, but learning to actually code well is a much more valuable skill and much more rare).

We pay people for robust solutions, not to write code. It's a whole lot more complicated than "just programming". In fact we'd rather they wrote less code and did more thinking.

Experienced engineers will trade off a COTS solution against build. Inexperienced engineers will machine 2000 M3x12 screws by hand.

Just because you're an engineer doesn't mean we want you to sit in front of a lathe/mill all day.

Libraries wouldn't exist if we didn't want to reuse work. With respect to more bugs in libraries, this is rarely the case for established products. In fact by writing our own code with similar intent will almost certainly incur more test effort, more odd edge cases and more $$$.

Final point: I wrote some code a few years ago in Java that spoke to .doc files, databases, a SOAP API and a service bus. It was (excluding blank lines and bracketed lines) 2900 lines of code with 850 unit tests. It handles over a million insurance contracts a year. This would have not been possible if I'd written ANY component myself.

I was paid to solve the problem, not write those libraries again.

We didn't really. They, respectively, didn't finish the entire test, over-engineered a few of the other questions and failed the comprehension test (we test the ability to understand requirements as well).

The thing is clearly marked "pragmatic solutions" rather than most interesting as well.

yeah right.....and what's the XML parsing library called? java.util.regex? And the SQL parameterized query library? string.format?

I wonder how hard it would be to port all of the python standard library to java?

Sort of have python.csv.reader, python.csv.DictReader, etc, which all conform as java-ish as possible to http://docs.python.org/release/2.7.3/library/csv.html

The problem of course is that it would probably be some external library like the apache commons stuff and never get integrated into the main library.

And there's still all the old poorly thought out junk still crufting up the standard library.