Live data from Hacker News

Java Pain

tbray.org

11–20 of 151 posts

Re: Java Pain

#11
How is the classpath problem different from manually specifying the -L and -I compiling that little c program exactly?

Re: Java Pain

#12
post #7

"Dear Java: I can run Ru­by and Python and Go and JavaScript and C code from the com­mand line on my Mac." - to be fair most of those languages are scripting languages.

They're programming languages that people use to solve programming problems, just as Java is.

Re: Java Pain

#14
post #8

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).

I have always had the feeling that JVM is very stable, but I don't have much Java experience. Is that a wrong assumption?

Stable != Convenient to develop with.

Re: Java Pain

#15
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 make common UNIX best practices hard.

Edit: Just remembered Kafka is Scala, not Java, but I think it just supports my asssertion that the Java/JVM ecosystem just makes common best practices hard.

Re: Java Pain

#16
post #7

"Dear Java: I can run Ru­by and Python and Go and JavaScript and C code from the com­mand line on my Mac." - to be fair most of those languages are scripting languages.

In my opinion, the difference between "scripting" languages and other languages hasn't been relevant for about a decade.

Re: Java Pain

#17
Use a programmer testing framework (e.g. JUnit) even if this is an integration test, even if you're going to "ignore" it later. If you feel the need to create a main() method just to test your code, IMHO, it is a type of code smell and I think this should belong with your programmer tests.

Re: Java Pain

#18
post #11

How is the classpath problem different from manually specifying the -L and -I compiling that little c program exactly?

-L and -I are specified at compile time, so if you distribute/deploy a binary the runtime doesn't have to care (except in the case of dynamic linking - eek!)

$CLASSPATH is purely runtime, so it's all the fun of dynamic linking, all the time. Monolithic shaded JARs can solve this problem but introduce some of their own.

Re: Java Pain

#19
Without the code and error message, this is just a rant from some (famous) guy who can't/won't figure out his tools.

  First of al­l, it took me for­ev­er to fig­ure out the ja­va
  command-line in­can­ta­tions to tell it that it need­ed my
  project’s class files and the json.org li­brary (which I’d
  al­ready down­load­ed so I could com­pile the suck­er). Yeah,
  I used to know that stuff ten years ago, but there re­al­ly
  shouldn’t be any com­plex­i­ty here.
"in­can­ta­tions"? It's not wizardry.
Post reply on HN