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

131–140 of 151 posts

Re: Java Pain

#131

Post by djeikyb »

logn wrote: post #117

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…

For those who can accept ant+ivy, I feel this is a stab in the right direction for console apps: https://github.com/djeikyb/simple-console-app

The script target creates a runnable shell script that has the jar and all dependencies embedded. The last step might be using packr[0] to also embed the java runtime.

[0]: https://github.com/libgdx/packr

Re: Java Pain

#132

Post by rspeer »

fsdfweafwe wrote: post #26

This is what I hear: "I am java newb and it doesn't work!" . Its true that other languages are simpler but he is missing the point why in java you have explicitly set classpath. Java allows not only for having multiple versions of libraries on the system with no installation whatsoever, but allows running components requiring those different versions of same lib in the same process (OSGi).

> This is what I hear: "I am java newb and it doesn't work!"

You might want to check your hearing, because this is Tim Bray.

Re: Java Pain

#133

Post by ivanr »

Tim's rant is misplaced. The reason he can't connect to https://keybase.io using Java 7 is because Keybase have (mis)configured their server so it doesn't offer any cipher suites Java 7 could use.

https://www.ssllabs.com/ssltest/analyze.html?d=keybase.io&s=...

You can see this in the SSL Labs simulator, in the bottom part of the report. Clicking "Java 7" will show the cipher suites available by default.

Re: Java Pain

#134

Post by [deleted] »

idbehold wrote: post #71
jakozaur wrote: post #63

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.

[deleted]

Re: Java Pain

#135

Post by nailer »

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…

Last time I used Solaris they didn't have proper package names. Everything was VNDRacnm where the first part was the vendor second part acronym was a minified piece of some bit of information that would have been useful if it wasn't minified.

Re: Java Pain

#136

Post by nailer »

sehugg wrote: post #21

tl;dr: Missing certificate in keystore. It'd be helpful to know the details; it's hardly an issue limited to Java (although it's harder to bypass certificate checking than in, say, curl)

Yep, it happens in node. There you fix it with:

    require('ssl-root-cas').inject();

Re: Java Pain

#137

Post by [deleted] »

Someone wrote: post #104
simonw wrote: post #16

Earlier quoted context omitted.

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.

[deleted]

Re: Java Pain

#138

Post by binarycrusader »

nailer wrote: post #135
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…

Last time I used Solaris they didn't have proper package names. Everything was VNDRacnm where the first part was the vendor second part acronym was a minified piece of some bit of information that would have been useful if it wasn't minified.

As I said, then you haven't used Solaris 11.

For example, the vim package name is 'editor/vim'. A similar naming scheme is used for almost every package.

Re: Java Pain

#139

Post by binarycrusader »

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?

In this case, every jdk install is available from the Solaris network package repository. Just like many Linux distros.

Linux distributions have the same problem so I don't understand the downvotes.

Re: Java Pain

#140

Post by binarycrusader »

yellowapple wrote: post #113
mateuszf wrote: post #96

Earlier quoted context omitted.

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.

Exactly, Solaris 11 has a "proper" package manager: Network-based repositories, SAT-solver-based dependency management, signed packages, boot environments, etc.
Post reply on HN