Comment by lmm | Hacker News Reader

Comment by lmm | Hacker News Reader

Parent Full thread

> Although Java has a huge standard library, if you don't use a lot of third-party libraries, you will be viewed as a non-professional Java programmer.

The standard library is where modules go to die. The fact that this phrase originates in the Python world tells you that this isn't a Java peculiarity.

> Most popular Java tech stack look open sourced, but are backed by lots of money provided by many companies with bad reputations on pure open source culture.

The sad reality is that those companies are the only organisations that commit serious resources to open-source development, outside a couple of specific niches (web development, unix-like OSes, scientific research up to a point). Those stacks aren't open-sourced in other languages, they just don't exist. And the whole point of open-source is that it benefits everyone regardless of how pure or otherwise the original motives were.

> the library use way of Java, by putting library jars into your projects, is not good as the way of other languages, by putting library sources into your projects. By putting library sources in your projects, you can view how the libraries are implemented easily. Yes, you can also put Java library sources into your projects, but the main stream culture of Java doesn't recommend to do this. Just look at maven.

WTF are you talking about? You declare your maven dependencies and they can be resolved as source or binary. In eclipse I can click through to any library function and see its source immediately. (It's one of the best dependency-management systems going, in any language; there's a single central repository that everyone uses in practice, but it's easy to run your own if you want. It's years ahead of everyone else in terms of package signing. There are multiple independent codebases using the same repositories, not just in theory but in practice).

> [edit 2] just my personal opinion. I don't like the way to use a separated VM to run many apps. This makes it is hard for me to use a different permission setting for each app. Sometimes I want to block a Java app to access network, but I must block the whole Java VM to achieve this.

Again completely normal - Python, Ruby, C#, OCaml... will have exactly the same issue. Get a better firewall.

> You declare your maven dependencies and they can be resolved as source or binary. In eclipse I can click through to any library function and see its source immediately.

Surely, you can view Java dependency sources. It is just that most Java programmers don't care about the sources, they are just care about the jars (the default culture).

In my honest opinion, cross-platform by bytecode has few advantages over cross-platform by source nowadays, on the other hand, cross-platform by bytecode has many inconveniences.

And, (in my taste), single central repository is bad. That's why I don't like Node also. The npm central repository is the source of many Trojans. Many Java and Node developers are not aware of and have no ideas on what they have downloaded through chain dependencies.

> Again completely normal - Python, Ruby, C#, OCaml... will have exactly the same issue. Get a better firewall.

Normal != good.

> Surely, you can view Java dependency sources. It is just that most Java programmers don't care about the sources, they are just care about the jars (the default culture).

Not my experience. Actually getting to the source of your dependencies, in practice, is easier in Java - just one click in your IDE - than in any other language. Doesn't that suggest that Java programmers care more about sources than other language users, not less?

> In my honest opinion, cross-platform by bytecode has few advantages over cross-platform by source nowadays, on the other hand, cross-platform by bytecode has many inconveniences.

Well you're entitled to your opinion but you should probably back it up with something more specific if you want to convince anyone else.

> And, (in my taste), single central repository is bad. That's why I don't like Node also. The npm central repository is the source of many Trojans. Many Java and Node developers are not aware of and have no ideas on what they have downloaded through chain dependencies.

You don't have to use a central repository if you don't want to, and some people don't, but it's very convenient to have the option if you want it. Maven central requires PGP signatures on anything published there, so it's very easy to enforce that all the dependencies you depend on come from trusted people if you really want to - as far as I know there's no non-JVM language that does that, certainly not with anything like as large a base of signed libraries available.

> Normal != good.

Agreed, but you started out by claiming that Java's culture is very weird. It isn't.

> Well you're entitled to your opinion but you should probably back it up with something more specific if you want to convince anyone else.

The only benefit of bytecode is to save compiling time. Nowadays, CPU becomes much faster than the time Java was invented, 20 years ago. So the benefit is weak now. Another promoted benefit of bytecode is compile-once-run-anywhere. However, I think this is a hoax. It is not special, for script languages code runs anywhere without compiling.

> Another promoted benefit of bytecode is compile-once-run-anywhere. However, I think this is a hoax.

I was once working on a large project on the JVM: our Fat-JAR was really working on Linux, Mac and Windows. The exact same JAR. And it didn't matter on which system we have built that JAR. This may not be possible for every use case - but I don't think it is a hoax.

> It is not special, for script languages code runs anywhere without compiling.

IMHO scripting languages like Ruby, Python, etc. are quite hard to deploy, especially if they have dependencies. In comparison to languages like Java, Go or Rust.

> The only benefit of bytecode is to save compiling time. Nowadays, CPU becomes much faster than the time Java was invented, 20 years ago. So the benefit is weak now.

In terms of throughput I agree with you. But start-up latency is already Java's weakest point, and having to compile on startup would make it worse.

> Another promoted benefit of bytecode is compile-once-run-anywhere. However, I think this is a hoax. It is not special, for script languages code runs anywhere without compiling.

True as far as it goes, but certain types of code simply aren't practical in scripting languages. You'll never see people implementing e.g. an image format decoder in a scripting language; they'll use bindings to a native-compiled (C) library instead, with all the problems distributing that entails. This is why things like docker are so popular with Python users: in theory Python is write-once-run-anywhere, but in practice most Python codebases end up depending on one or more native modules and need to have the correct version compiled. Whereas Java bytecode is adequate for things like image codecs, and in the real world you really do see large Java codebases that don't use any bindings to (non-JVM) native libraries.

The phrase possibly originates originates from the old quip, "ISO standardization is where languages go to die".

Reply on news.ycombinator.com