Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Java Pain

tbray.org

Post reply on HN
Print view View original

121–130 of 151 posts

Re: Java Pain

#121

Post by nathell »

jwr wrote: post #107
lucian1900 wrote: post #3

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

Actually, Clojure improves the "Java experience" by quite a bit. As an example, leiningen as a build tool is quite usable, and it doesn't take much work to get a working (yes, also from the command line) application. As for the JVM "just breaking", I can't agree with that. The JVM is an impressive piece of engineering and I'm very glad I can make use of it in Clojure, rather than deal with half-baked attempts at buil…

Interestingly, Leiningen is very much usable as a Maven replacement even for pure Java projects. I've tried it, it works fine. Just specify :java-source-paths in project.clj, and you get all the goodies like lein uberjar for free.

Re: Java Pain

#122

Post by lmm »

jamesmiller5 wrote: post #111
lmm wrote: post #103

Earlier quoted context omitted.

But Maven is that toolchain. Invoking "java -cp ..." directly and complaining that it's complex is like turning off X11 and then complaining that it's harder to know which programs are available. A modern Java developer doesn't even need to know that the underlying interpreter happens to be called "java"; you can just work in Maven all the time and the conventions are sensible, the project infrastructure gets out of…

> Maven is that toolchain. The idea that I need to use an external build tool because my language provided build tools are inadequate is the argument. It should not be as hard to use Java as it was 10 years ago by virtue of it's own improvement. It was a sharp edge then, and remains unnecessarily sharp today.

I'd fear any language provided build tool would risk becoming, like the python standard library, the place where modules go to die. I think what we've seen in recent years (particularly with the example of node.js) is that it's best for a language core to remain as small as possible, offloading most functionality into external libraries which can have their own release cycles and development philosophies, and even be replaced if need be. With maven we even have a nice layering of this: maven's core is small and most of the functionality is in modules, which can be updated or replaced without having to rewrite everything.

If we bundled maven or maven-like functionality into the Java core it would slow down the release schedule and destroy the productively competitive build tool ecosystem we have at the moment. What is it you think we'd gain?

Re: Java Pain

#123

Post by chipotle_coyote »

abalone wrote: post #116
chipotle_coyote wrote: post #62

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…

> these tools largely haven't gotten any easier since 2004 That's not really true. I was doing professional Java development in 2004. Nowadays we have things like Dropwizard and Play. It sounds like Bray was intentionally trying to use just the Oracle-provided tools and libraries. If he wanted to do that he'd been better off with Play. That's a single distribution designed for exactly his use case: simple OOTB text e…

While I have to put up the big blinking disclaimer that I'm not a Java programmer so take this with a box of salt, I'm not sure that really invalidates his point -- out of the box it's (apparently) far harder to build at least certain kinds of applications in Java that seem pretty trivial in other languages. I don't doubt your word that if he'd started with Play it would have been much easier to write that command line app that fetches a document with HTTPS, but downloading a third-party, self-described "high-velocity web framework" probably shouldn't be a recommended way to solve this problem.

Re: Java Pain

#124

Post by vorg »

> Dear Java: I can run Ru­by and Python and Go and JavaScript and C code from the com­mand line on my Mac. If I can’t run you, that means you’re bro­ken.

These were the types of problems dynamic JVM language Groovy was created back in 2003 to solve. If only Groovy had stuck to its knitting when the new management, er, took over from its creator a few years later, it would still be a solution. Unfortunately, Groovy diversified into providing CompileStatic tags to compete with Java, DSL syntax to compete with Maven, a MOP to compete with Rails, and AST annotation hooks to compete with Lisp. It's now become obsolete for its original purpose of JVM scripting, missing the Java 8 boat despite several years advance warning, as well as being at best 2nd fiddle but usually 9th fiddle at the stuff it tried diversifying into.

Re: Java Pain

#125

Post by vorg »

x0x0 wrote: post #47
schmichael wrote: post #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…

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…

> why the fuck can't I import a directory full of jars?

Use the -Djava.ext.dirs command line flag to do it.

> like Groovy [...] String address = a?.b?.c?.d?.address

The Groovy backers have been talking for years every now and then about making ?. ripple though the . after it, so using a?.b.c.d.address would have the same effect as a?.b?.c?.d?.address , but nothing ever gets done. Better look for a language solution being actively maintained for its original purpose, instead of its backers going off on tangents looking to entangle itself in every pie.

Re: Java Pain

#126

Post by abalone »

chipotle_coyote wrote: post #123
abalone wrote: post #116

Earlier quoted context omitted.

> these tools largely haven't gotten any easier since 2004 That's not really true. I was doing professional Java development in 2004. Nowadays we have things like Dropwizard and Play. It sounds like Bray was intentionally trying to use just the Oracle-provided tools and libraries. If he wanted to do that he'd been better off with Play. That's a single distribution designed for exactly his use case: simple OOTB text e…

While I have to put up the big blinking disclaimer that I'm not a Java programmer so take this with a box of salt, I'm not sure that really invalidates his point -- out of the box it's (apparently) far harder to build at least certain kinds of applications in Java that seem pretty trivial in other languages. I don't doubt your word that if he'd started with Play it would have been much easier to write that command li…

It's not harder in Java.. if you use Play, which offers everything OOTB. How is that not a recommendable solution?

If you refuse to download Play out of some misguided principle that everything must be OOTB by the core language provider, then (a) that's arbitrary and (b) you're misunderstanding the design principle of low-level languages like Java and C++ that have enabled them to stick around for so long. They don't bake in (as many) opinions. Play does, which makes it easier OOTB. So does Dropwizard. Take your pick, they're all "Java". That's the beauty of it.. it can address a very wide range of needs from "I just want to get something done" to "I want to control every detail very close to the metal".

Re: Java Pain

#127

Post by coldtea »

chipotle_coyote wrote: post #62

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…

>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 as a web technology.

I'm partly joking, but I'd be hiding in shame if I had inflicted either of those things upon the world (that is the XML spec, and Java's web technologies, especially JSF and J2EE).

Now, it could just be me, I never found Tim Bray's posts interesting, and this is a case in point. The same blog post could have come from any random guy trying to run a Java app on the commandline. It might be a valid complaint for the status of java packages, but it's not insightful at all.

Re: Java Pain

#128

Post by coldtea »

justbaker wrote: post #74
x0x0 wrote: post #47

Earlier quoted context omitted.

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.

There are several problems with RVM (and a lot of extra "magic" it does compared to say rbenv). Those have been discussed in the community for years.

So, besides the use of a BS idiom "you're doing it wrong", the parent comment doesn't add much value to the discussion.

Re: Java Pain

#129

Post by voidlogic »

lmm wrote: post #122
jamesmiller5 wrote: post #111

Earlier quoted context omitted.

> Maven is that toolchain. The idea that I need to use an external build tool because my language provided build tools are inadequate is the argument. It should not be as hard to use Java as it was 10 years ago by virtue of it's own improvement. It was a sharp edge then, and remains unnecessarily sharp today.

I'd fear any language provided build tool would risk becoming, like the python standard library, the place where modules go to die. I think what we've seen in recent years (particularly with the example of node.js) is that it's best for a language core to remain as small as possible, offloading most functionality into external libraries which can have their own release cycles and development philosophies, and even be…

>'d fear any language provided build tool would risk becoming, like the python standard library, the place where modules go to die....

I used to think this, but Go changed my mind. Like Go or not, its an excellent example of awesome tooling.

Go run/build/install/vet/test make my life to much easier than it used to be in Java/C/++ world (and C# tool because I'm not enslaved to VS for my teams tooling).

Re: Java Pain

#130

Post by teacurran »

So many people commenting here don't seem to have read the article. His comment is that Java can't connect to an SSL encrypted URL out of the box. He is saying that because it can't do this it can't be used for a basic command line app. He isn't complaining that it is hard to write a command line app in Java.

He is trying to load this URL: https://keybase.io/_/api/1.0/user/autocomplete.json?q=someth...

This URL is not self signed and loads fine as a valid cert in a browser. In the Java application it throws an exception about a bad handshake. I believe this is because Java 7 and 8 ship with less trusted certificate authorities than browsers do.

I forked his project and made it easy to run via the command line without Android if anyone wants to try it out: https://github.com/teacurran/KeybaseLib

Just clone the repo and execute "./run.sh something"

Post reply on HN