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

111–120 of 151 posts

Re: Java Pain

#111

Post by jamesmiller5 »

lmm wrote: post #103
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…

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.

Re: Java Pain

#112

Post by patio11 »

One thing which I noticed during the Stripe CTF, where Node, Scala, and Go were all first time languages for me, was that the baseline experience of getting a dev environment assuming you have a Linux box is, in 2014, really freaking awesome. I was doing Java in 2004, and think it would probably take me half an hour going from zero to "minimum viable Java dev environment." I was hello worlding after maybe three console commands in Go/Node/etc.

This is partly a technology problem, partially a philosophy problem (Java does not have a scripting language heritage which counsels e.g. having a REPL or really obvious options for program invocation), and partly a marketing problem. I rather doubt that anyone at Oracle has the job "Make people's first experience with Java suck less." Web devs thankfully have standardized on "batteries included; max five minutes to install" for new platforms in the last few years (Rails strikes me as the conspicuous first example, and ironically is harder to install now than it used to be).

Re: Java Pain

#113

Post by yellowapple »

mateuszf wrote: post #96
binarycrusader wrote: post #92

Earlier quoted context omitted.

Installing updates is a complete trainwreck for almost every product they've ever released and that's one of the most basic tasks for a software vendor." Then you haven't used Solaris 11, because in general, installing updates for the OS (and Java and many other things) is as simple as: pkg update Also, your generalisations about 'no cultural tradition of taking toolchain usability seriously' are simply not true, I c…

Are you saying that every JDK install should come with Solaris? Or that operating systems should be built specifically to suppport java installation?

> Or that operating systems should be built specifically to suppport java installation?

Not even "specifically"; these updating woes rarely exist on platforms where you have a proper package manager (be it APT or YUM or Zypper or Pacman or Homebrew or whatever). Software devs shouldn't have to worry about writing updaters, since updating should be handled by the OS.

Re: Java Pain

#114

Post by yellowapple »

Eridrus wrote: post #83
skywhopper wrote: post #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 Rub…

I'm not sure why Java is taking a bullet on this. 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 sc…

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

Re: Java Pain

#115

Post by yellowapple »

adamc wrote: post #98
exabrial wrote: post #85

Earlier quoted context omitted.

Amen for breaking backwards compatibility. Needs to happen soon so the CRUFT can be cut out of JEE.

I see the appeal but... Python's long, slow march to widespread adoption of 3.x, and Perl 6's much less successful experience, both suggest there would be a lot of danger in that.

Yep; I'd rather just have Perl5 on Parrot than have to relearn Perl.

Not to mention that the O'Reilly book for Perl6+Parrot doesn't have a parrot, or even a camel. Deal-breaker right there ;)

Re: Java Pain

#116

Post by abalone »

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 editor scripting, no compilation, no deployment, lots of stuff built in, just go.

Re: Java Pain

#117

Post by logn »

Java supports Runnable JARs. This bundles all dependencies into the JAR so you can just run:

  java -jar foobar.jar
And if it's a webapp, you can use something like Jersey so that the JAR itself if a webserver (launched from main function). And with Jersey+Grizzly you can make webapps that have zero XML config, btw.

Java's SSL handling is definitely annoying, though. But I think it's better than how other languages do it which is to simply bypass cert validation.

Also, I don't think it's fair to lump anything Android-related into complaints about Java. Google yoinked the Java syntax and the name and then added their own stack underneath.

My main pain point with Java is dependency management and builds. I don't like any of the systems out there. After years of Ant, Ivy, and Maven, I've just resigned myself to using Eclipse and downloading JARs manually, storing them with the code. It's ugly but not as ugly as Maven.

Re: Java Pain

#118

Post by glimcat »

patio11 wrote: post #112

One thing which I noticed during the Stripe CTF, where Node, Scala, and Go were all first time languages for me, was that the baseline experience of getting a dev environment assuming you have a Linux box is, in 2014, really freaking awesome. I was doing Java in 2004, and think it would probably take me half an hour going from zero to "minimum viable Java dev environment." I was hello worlding after maybe three conso…

It still often takes me 30+ minutes to set up the environment for a new language, but that's mostly spent doing some reading on how to set it up "right" vs. just executing an apt-get.

Most of which comes down to the fact that official documentation for first-time users is somewhere on the spectrum of nonexistent to crappy. Many languages have pretty good tools for managing virtual environments and dependencies and such these days, but odds are that a new user won't find out about them for quite some time unless they know to go looking.

Re: Java Pain

#119

Post by x0x0 »

haddr wrote: post #90
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…

Ad 2: Things evolve. If you stopped somwhere in the mid 90, you won't notice. But in Java 8 you can do null checking easily using Optional. Your example would be: String address = a.map(A::b).map(B::c).map(C::d).orElse("UNKNOWN");

I find that quite wordy, but thank you

Re: Java Pain

#120

Post by tormeh »

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.

Let me quote from a C++ post: "We already "fixed" C++ largely by writing sane libraries, by having great compilers and IDEs, detecting issues with linters and so on."

This is how old languages work. You want a nice language? Switch! People get Scala working on Android, I hear.

Post reply on HN