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

101–110 of 151 posts

Re: Java Pain

#101

Post by scotty79 »

jcape wrote: post #87
scotty79 wrote: post #79

Earlier quoted context omitted.

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

tl;dr: Other environments are insecure out of the box, and require applications specifically opt-in to security. Java requires you opt-out of the security. HTTPS is built on top of PKI, which involves a list of trusted root authorities who verify that the certificate for blahblah.com is actually for blahblah.com. A self-signed certificate won't have that, and any application that doesn't validate that the certificate…

I never understood how trustworthy is cert that you could buy for 100$. What that certificate proves? That whoever signed the stuff had a 100$ at some point?

Besides ... why can't java just pull the certs out of the system (like you did manually) or ship with them like every browser does (I presume).

Re: Java Pain

#102

Post by norswap »

Very true, I was thinking about this recently. Note there's no technical impediment to making the right tools, so if you're tempted, have a blast :) (Otherwise maybe I will)

Re: Java Pain

#103

Post by lmm »

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 your way and you can get on with writing your code.

Re: Java Pain

#104

Post by Someone »

simonw wrote: post #16
CmonDev wrote: 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.

In my mind, the difference is clear: scripting language == has REPL == lets you treat it as a calculator, and (in practice) has a one-line, one-statement "hello, world".

So, I don't think go is a scripting language. It requires you to write a function and then call it before it will output anything.

So, forth, JavaScript, lisp, lua, perl, python, ruby do qualify as scripting languages in my book.

Re: Java Pain

#105

Post by agibsonccc »

pron wrote: post #97
agibsonccc wrote: post #57

Earlier quoted context omitted.

Yeah I use uberjars sometimes too. Java deployment in general is awkward/subpar. Some of the newer tech like dropwizard has helped with this, but it's still far from ideal.

Take a look at capsule[1] (I'm the author). [1]: https://github.com/puniverse/capsule

This is what I was going to bring up. Also: hello again ;).

Re: Java Pain

#106

Post by jcape »

scotty79 wrote: post #101
jcape wrote: post #87

Earlier quoted context omitted.

tl;dr: Other environments are insecure out of the box, and require applications specifically opt-in to security. Java requires you opt-out of the security. HTTPS is built on top of PKI, which involves a list of trusted root authorities who verify that the certificate for blahblah.com is actually for blahblah.com. A self-signed certificate won't have that, and any application that doesn't validate that the certificate…

I never understood how trustworthy is cert that you could buy for 100$. What that certificate proves? That whoever signed the stuff had a 100$ at some point? Besides ... why can't java just pull the certs out of the system (like you did manually) or ship with them like every browser does (I presume).

They typically ask that you perform some step of the transaction using an e-mail address tied to the domain, so it's not quite that terrible. The 700USD EV certs actually require corporate registration paperwork, tax IDs, etc. and are far closer to a credit check in terms of depth.

I agree that Java should use the certs the system provides, and that is a PITA to wrestle with keytool, but I also know that the self-signed cert that apache is using is not trusted by your PC either (so you've got work to do regardless).

Re: Java Pain

#107

Post by jwr »

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 building yet another VM (reference counting, anyone?).

Re: Java Pain

#108

Post by abalone »

Play targets this exact pain point in Java. The "I want to script stuff easily in a text editor not an IDE and by invoking from the command line and/or by loading a web page without a compilation and deployment step" case.

Here's the manual page for calling an HTTPS service [1]. You just call WS.url("https://example.com").get(). And if it's a self-signed certificate then it's more or less one line in a config file to add it. That's about as easy as it gets short of deliberately making HTTPS insecure.

My experience: I very quickly evolved beyond this case and prefer the robustness of standard Java with the convenience of a bundle like Dropwizard [2]. Dropwizard packages up and glues together various best-of-breed libraries for building services. That was the real pain point for me, not so much having to use an IDE.

[1] http://www.playframework.com/documentation/2.3.x/WSQuickStar...

[2] http://dropwizard.io

Re: Java Pain

#109

Post by jebblue »

aikah wrote: post #73
spullara wrote: post #58

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

Right, you don't need the script as long as it's an executable jar, it will run fine with:

  java -jar Product.jar
If there are any native libraries then they need to be built into the jar, you could do one jar or one for each platform.

Re: Java Pain

#110

Post by acdha »

binarycrusader wrote: post #92
acdha wrote: post #66

Earlier quoted context omitted.

Agreed - and both Sun and Oracle have no cultural tradition of taking toolchain usability seriously. 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. Fundamentally, I think the problem is arrogance – companies like Oracle or Sun historically assumed that their products are so important that it's someone's full-time…

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…

You're right, I have never used Solaris 11. I stopped at Solaris 10 because the TCO was too hard to justify versus Linux – the then-new updates bricking a whole shipment of servers was the final straw for us.

I've used both Sun and Oracle products since the mid-90s. The only one which I can recall seeming to respect my time was DTrace and maybe ZFS. Oracle is by far worse (updates shipped as a flat ZIP file with text instructions where to install them?) but both really left the impression that they assumed my time was cheaper than them hiring a packaging engineer.

Post reply on HN