I know Java well, though I'm not primarily a developer. As a DevOps guy, there are a few places where I'd love to be able to write a quick program in Java to take advantage of one API or another, or to ensure compatibility with the app I'm trying to manage or what have you, but between the boilerplate, the classpath, the compilation step, and the awkward command line, it's almost never worth it, and I write it in Ruby or Bash instead.
The complaint about overstrict PKI libraries is spot on as well. Dealing with Java's PKI infrastructure for https URLs, etc, in a systems level setting where, you know what, sometimes the CN on the cert ain't gonna match the internal name, is a huge pain. Other languages are actually pretty bad about this too, and so too often I resort to calling out to curl -k because it'll just shut up and do what needs to be done.
It's clear that this is all because Java is built around the assumption that you're creating a big program and you're going to use an IDE and you're willing to deal with multiple steps before you have something that'll run on the server. That's fine and dandy. If the Java community wants Java to be more useful for smaller tasks, then Tim's complaints here are dead on target. But if not, I long ago gave up trying to use Java in this way, and I think Tim should do the same.
The default in other languages is often to not do any certificate validation.
That seems like the worse approach since no-one can tell their code is insecure. Maybe fine for a scripting tool, but I wouldn't want that on my production boxes.
I'm not sure why every language needs to be useful as a scripting tool. If there are things that help the common case and also scripting (eg classpaths being a pain), there's obviously an argument for "why the fuck hasn't this been fixed yet", but in other cases there are either fundamental tradeoffs or resource constraints.
> I'm not sure why every language needs to be useful as a scripting tool.
"Easy things should be easy, and hard things should be possible." -- Larry Wall
One of the reasons why I switched from Java to Perl. I didn't feel that easy things were easy in Java, and I don't run into enough hard problems on a daily basis to justify the verbosity and masochism involved.
That's unfortunate. I try to keep my code (no matter what language, Perl included) as readable and tidy as possible for the sake of those reading the code in the future (myself included). While creatively stringing an incomprehensible stream of punctuation marks into a usable program is fun, I'm with you in agreeing that such coding styles should be avoided in anything that's not a one-off mental exercise.
That said, too much verbosity can introduce the same problem of unreadability by making important things harder to identify. There's an important balance between verbosity and terseness that should always be considered.
The complaint about overstrict PKI libraries is spot on as well. Dealing with Java's PKI infrastructure for https URLs, etc, in a systems level setting where, you know what, sometimes the CN on the cert ain't gonna match the internal name, is a huge pain. Other languages are actually pretty bad about this too, and so too often I resort to calling out to curl -k because it'll just shut up and do what needs to be done.
It's clear that this is all because Java is built around the assumption that you're creating a big program and you're going to use an IDE and you're willing to deal with multiple steps before you have something that'll run on the server. That's fine and dandy. If the Java community wants Java to be more useful for smaller tasks, then Tim's complaints here are dead on target. But if not, I long ago gave up trying to use Java in this way, and I think Tim should do the same.