Live data from Hacker News

Java Pain

tbray.org

71–80 of 151 posts

Re: Java Pain

#71

Quite a lot of languages let's you do https, but just give you illusion of security. Not really validating it, which is trivial to spoof with certificate signed by "your own authority". "The Most Dangerous Code in the World: Validating SSL Certificates in Non-Browser Software" https://www.cs.utexas.edu/~shmat/shmat_ccs12.pdf

Wow, does this imply that the Heartbleed bug might end up being even more damaging that previously thought? This paper shows that even if you've already revoked your old certs, many pieces of widely used software don't even bother validating them.

Re: Java Pain

#72

I'm seeing a lot of comments here along the lines of "this is just a problem Java newbies would have and this Tim Bray guy, whoever he is, doesn't want to take the time to learn the tools." Well. True, to a degree, I suppose, but whoever this Tim Bray guy is adds some pretty important context. He co-authored the XML spec and was director of web technologies at Sun. You know, the people who made Java and promoted it a…

I'm surprised he thinks the core platform should offer that, the JDK is large enough as it is thank you. Any number of countless application generators and libs make it easy. Even a quick glance at maven central would've answered his question. In other words, Java wont search the internet for you.

I'd argue Maven is a giant kludge in the very spirit being argued about. If the underlying platform was better Maven would go away, but the existence of it prevents useful discussions about how to improve the underlying platform with "why aren't you using maven?" "because it sucks the life out of my soul" etc.

The other classic example is the increasingly popular multi-cursor editing editors, which should be a giant red flag over the lack of expression in the programming language. What happens is they make it almost tolerable, and the incentives to improve are thus diminished greatly, to the point the problem will be ignored by most.

Re: Java Pain

#73

IMHO, the best way to distribute java programs is create a single jar and the append that jar to this shell script: #!/bin/sh exec java $JAVA_OPTS -jar "$0" "$@"

and then it doesnt run on windows...so much for run everywhere...

the best way to distribute a package is to create a proper package for each plateform and encapsulate any java "gimmick".

Re: Java Pain

#74
post #47

The confusing series of shell scripts most Java services (Cassandra, Kafka, Elasticearch) come wrapped in are a constant annoyance. Not only do they rarely if ever follow common shell command idioms, but trying to configure production services turns into tracing environment variables through a series of shell scripts sprinkled across my system. It's nothing wrong with Java the language, but the platform just seems to…

I was about to say "omg yes" -- as someone who writes piles of java code, this is a constant pain. However, look at the other tools: I run python out of a virtualenv. I use rvm to run multiple rubys, and that shit breaks all the time for me. (Or rather, I use it infrequently enough that I never learn it well enough; I use it for the first time again every 2-3 months). That said, java is a special bit of shit. Those s…

"I use rvm to run multiple rubys, and that shit breaks all the time for me."

You are doing it wrong then.

Re: Java Pain

#75
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.

Re: Java Pain

#76

There are many Java pains, both little and big. Most of them are more related to the JVM than the language. It's why I still don't use Clojure significantly (or even ClojureScript), even though I really like the language. Things just break or simply never work and it appears random. Other environments I use get a lot less wrong (although node is pretty bad too).

What pains come from the JVM? From my viewpoint the JVM is the best thing to come from the Java ecosystem.

Re: Java Pain

#77
There is a lot of truth in what Tim says.

The Java + Clojure + JRuby ecosystem has been very good to me. That said, I have been spending more time writing Haskell code that anything else this year and being away frmm the JVM, and being able to build compact executables is a breath of fresh air, especially since I am looking at Haskell now more as a strongly typed and perhaps better Lisp.

Re: Java Pain

#78

Quite a lot of languages let's you do https, but just give you illusion of security. Not really validating it, which is trivial to spoof with certificate signed by "your own authority". "The Most Dangerous Code in the World: Validating SSL Certificates in Non-Browser Software" https://www.cs.utexas.edu/~shmat/shmat_ccs12.pdf

Wow, does this imply that the Heartbleed bug might end up being even more damaging that previously thought? This paper shows that even if you've already revoked your old certs, many pieces of widely used software don't even bother validating them.

Yes. Like Chrome. And Android devices. And more. Yes, this is why Heartbleed is/was bad.

Re: Java Pain

#79
post #39

In java to be able to crawl a https url you have to do the following - http://www.coderanch.com/t/134619/Security/JDK-trust-Certifi... Its easier in other languages but its not that hard in java. Just export certificate via IE and save to disk and from the jre/lib/security folder and issue one command keytool -import -alias mycert -keystore cacerts -file d:\mycert.cer. (default password is changeit) Done.

Why must you do that? And why you don't have to do that for environments of modern llanguags?

Re: Java Pain

#80
Given Suns history with EJB 2.0, I would humbly submit that "ease of use", work out-of-the box etc should not be the default expectations with Java.

Having said that (snarky response) having worked with Java from 1.1, I think the language is moving in the right direction. The latest release (8) adds a ton of syntactic sugar and there is a real impetus towards easier more dev friendly features.

Plus Java needs a non-backwards compatible version soon. I suggest Java X be that where it gets rid of a lot of the cruft that has built up.

(Go Duke!)

Post reply on HN