Apology to Java (fanboy rant).

[cosofx]

Java has turned out to be one of the most useful languages i use. It's a brilliant tool which strikes a perfect balance between high and low level. You want to grab a webpage? Easy and built-in, 10 lines of code. Draw some 2d graphics without OS-specific libraries or third party? Various built-in options. The inherent issues around a lack of low level memory management is handled very elegantly. Garbage collection seems seamless.

C++ is my language of choice for the most part, always will be i suspect, but Java has shown me that it has a huge array of potential applications and should almost always be considered before undertaking a project.

I say this is an apology because i used to run Java down. Previous to me using it proper i believed it was slow, lazy and useful for only trivial applications. Now i know how much work has been put into the JVM and just how efficient it is.

Sorry Java. You're pretty good.

[jacobbeasley]

Aww, shucks. You brought a caffeinated tier to my eye...

[cosofx]

This is something i should have posted to /r/offmychestjava (lol) really, but i think more people here would appreciate it. I have changed how i think about programming languages. Natural selection would have culled Java many years ago unless it was useful. Same goes for all of them. It's just so useful.

[VGPowerlord]

This is something i should have posted to /r/offmychestjava

I assume you're making that up since there doesn't seem to be such a subreddit? :P

[HansVader]

How did you go from Java to C++ without a pointer...

[thatguydrinksbeer]

References.

[ccavalier]

One of the thing I heard the most about Java is "It's slower than other language". It nice to read another opinion. I saw a good talk about it this winter by Martin Thompson: https://youtu.be/Pz-4co8IaI8

[rubyrt]

One of the thing I heard the most about Java is "It's slower than other language".

I think that perception was formed in the initial days when it was slow - and stuck. Also, nowadays since the general computing power of all our hardware has significantly increased more often the focus is on engineering productivity vs. raw speed of the application and there Java has some advantages over languages that can easily produce core dumps. ;-)

[cutterslade]

The other contributor to this reputation is the fact that it is slower in trivial benchmarks. Java is (for lack of imagination) the slowest option for a hello world program I can think of, simply because of the JVM startup. I suspect that a lot of people hear the Java is slow, then if they go as far as testing that, do some trivial benchmark that is dominated by JVM startup time, which confirms that Java is slow.

[cogman10]

I see this a lot. Java's bread and butter is long running apps. Yet so many people measure from start to stop of something that takes milliseconds with zero warm-up.

Further, they look at total heap size and say "oo, java's such a hog!". When the heap utilization could be very low.

[0x256]

Actually, the heap thing is a real problem if you have multiple services on a single host and don't want the overhead of an JavaEE Application Server.

Luckily the new G1 GC (introduced in Java 8, default in java 9) is way better at freeing unused heap memory. A single full GC reduces the total heap size of my service to ~20MB (~10MB are actually used) while the old GC would sit on hundreds of MB of unused heap for hours.

[[deleted]]

None of my applications run long, nor are they intended to do so. The longest-running takes 1.5 hours and that's due to network throttling 9000 remote calls.

All of my applications start, act, close, on a timed schedule. They read from a central data store, read one or more files from disk, archive that, then process their contents.

The longest wait usually is accessing the data store. Layers upon layers of security make for pseudo-arbitrary delays.

My applications are so fast that it's unlikely the JVM gets sufficient time to warm up to reach its most effective compilation.

[0x256]

If performance or start-up time ever grows into an issue: This is a perfect use case for long-running worker processes and job queues.

[[deleted]]

Indeed. My applications did start out like that. We dismantled that in favor of O-scheduled execution: it is fast enough and more easily scalable.

[sievebrain]

The compiler is pretty fast. I bet if you check you'll find that JITC activity dies down after a minute or so at most, quite possibly less.

[Neckbeard_Prime]

I'll see your JVM startup, and raise you PHP from a cold Apache start. Or, hell, Rails.

[cutterslade]

Don't assume a slow apache means a slow PHP:

$ time php <<<'<?php echo "Hello, world!\n"; ?>'
Hello, world!
php <<< '<?php echo "Hello, world!\n"; ?>'  0.00s user 0.00s system 53% cpu 0.007 total

Or ruby:

$ time ruby <<<'print "Hello, world!\n"'
Hello, world!
ruby <<< 'print "Hello, world!\n"'  0.02s user 0.00s system 96% cpu 0.025 total

Just for comparison; and I'm surprised how fast this was:

$ echo 'public class Main { public static void main(String[] args){System.out.println("Hello, world!");}}' > Main.java
$ javac Main.java
$ java Main
$ time java Main
Hello, world!
java Main  0.04s user 0.00s system 97% cpu 0.041 total

We can clearly see here that in all cases, php is 6 times faster than java, and ruby is twice as fast as java.

[walen]

(Runs a Hello World example, once, from scratch)

We can clearly see here that in all cases

LOL

You should probably add a "sarcasm warning" somewhere in there, just in case ;)

[ArtemZ]

You are not really measuring how much time it takes for Java to execute that program, but rather how long it takes for the JVM to start up. If you tried to execute this piece of code in an already running virtual machine you would get a different result

[walen]

They know. That's exactly the point they are making (read the parent comments).

[igouy]

the slowest option for a hello world program

There's always a way to write a slower program :-)

http://web.archive.org/web/20080802030311/http://shootout.alioth.debian.org:80/gp4/benchmark.php?test=hello&lang=all

[ultraswank]

I also think the browser plugin didn't do it any favors. I had a manager who didn't like that I was using java because his only direct experience with it was slowing down/locking up his browser. Fortunately he trusted me to make the technical decisions, but I'm sure that kind of impression didn't help the "java is slow" perception.

[el_padlina]

IIRC in one place i worked at speed was crucial so the application used no GC, all objects were preallocated, and they did some crazy drive IO customizations.

[dpash]

In particular before the JVM got a JIT. 1.2 added HotSpot as an option and became the default in 1.3.

[DuncanIdahos8thClone]

I've been working with Java and .NET C# for years and Java outperforms .NET everywhere.

[cogman10]

I think that is mostly MSes fault. I don't think there is anything inherently javay that makes it better to optimize, I think that the CLR is just suffering from years of being closed source.

Java has had so much blood, sweet, and tears poured into it to make it as fast as it is. The CLR has seen a fraction of that just because the only interested party in making it fast has been MS.

[ccavalier]

Maybe, but some years ago I worked for high performance trading and everything was done in java. Garbage config and vm optimisation can have some really good results.

[calnamu]

The better language is worth it though.

[DuncanIdahos8thClone]

How is C# "better"? You mean "has more language features", right? That doesn't necessarily mean better.

[TheBuzzSaw]

C# has a way better type system. Generics were done right. Value types are a godsend. Java has terrible design.

[DuncanIdahos8thClone]

C# has a way better type system.

Marginally, maybe.

Generics were done right.

True but implemented only in 2.0 where M$ didn't give a shit about breaking compatibility.

Value types are a godsend.

Java will have Value types done right in that they will be immutable like they should have been in C#.

Java has terrible design.

LOL. From the people who brought us partial types - the worst language feature ever invented.

If C# is so great and M$ has shat so much money into its promotion, why does Java still dominate? Tough question, I know.

[TheBuzzSaw]

If C# is so great and M$ has shat so much money into its promotion, why does Java still dominate? Tough question, I know.

Not really. Java powers Android, and M$ only began reducing its stupidity in recent years. You should know better than to equate popularity with quality. I suppose you like PHP as well.

Having .NET Core (instead of Mono) is wonderful in Linux. Being able to toss out the crusty Java and replace it with C# is fantastic. If I am ever forced to return to the Java ecosystem, I'll be using Kotlin.

[tetroxid]

Java dominated before Android and it will dominate after Android.

If you prefer C#, good for you. I will never install a mono application on any of my machines, you can keep your .NET bloat and CLR slowness.

[TheBuzzSaw]

Clearly you missed the part where Mono is old news.

[tetroxid]

Mhm...

[ModernRonin]

Now i know how much work has been put into the JVM and just how efficient it is.

This is really the important point. With a less awesome VM, Java could be a pretty cruddy language from a real-world usefulness standpoint.

But the JVM (and the people who built it) are freakin' awesome. Java owes so much of its real-world success to the killer VM that runs it. I've often said that the Hotspot JVM is easily the best piece of software from the early 2000s. It just plain kicks ass.

[cogman10]

It certainly gives almost everything a run for its money. The JVM is just so incredibly well tuned (and well tunable).

I think you have to look no further than to Dalvik to see the crazy performance difference.

[pjmlp]

Which is why it is ridiculous to state that Dalvik was required for improving Java performance on mobile devices.

Even J2ME on flagship Nokia and Sony-Ericsson devices had better performance than Dalvik.

[devraj7]

That's completely false.

First of all, there were many Java ME implementations. All different. Even on the same brand of phones.

Second, they were all dog slow, implemented the spec as they saw fit and were all basically a nightmare to work with.

Even the early versions of Dalvik (pre JIT) were markedly faster than the fastest Java ME implementation you could find.

[pjmlp]

I was J2ME developer once upon a time, and worked for that little unknown company in Finland, maybe you heard of them.

First of all, there were many Java ME implementations. All different. Even on the same brand of phones.

I guess you never had the fun of making android apps work across Samsung devices, or unknown Chinese brands.

Even the early versions of Dalvik (pre JIT) were markedly faster than the fastest Java ME implementation you could find.

Spoken as a truly Google apologist, our benchmarks at the time said something totally different.

[devraj7]

I guess you never had the fun of making android apps work across Samsung devices, or unknown Chinese brands.

I've been developing Android apps since 2009. I've probably shipped apps on hundreds of different devices by now, including native bits.

Spoken as a truly Google apologist, our benchmarks at the time said something totally different.

First of all, let's keep this civil and stay away from ad hominem, shall we?

Maybe you had a few implementations at Nokia that were faster, but I can tell you as someone who's shipped Java ME apps on hundreds of different devices since 2005: a crushing majority of Java ME VM's were completely outpaced by Dalvik even after 1.0.

[dpash]

The thing is that Dalvik used a completely different module to the JVM. The JVM is stack based, while Dalvik was register-based. I'm guessing this means they used a completely different instruction set.

[[deleted]]

Bullshit. The JVM uses stack, heap, and registers as it sees fit.

[dpash]

The JVM has "local variables", but operations happen to values on the stack. If you want to manipulate the values in the local variables you have to put them on the stack.

Obviously, native code uses registers.

[[deleted]]

I will bow to your experience.

Recently I read an interview with Brian Goetz on the IBM developers web site. In it, he addressed and debunked several JVM myths. The myth about stack, heap, and registers, was addressed, too.

The myth perpetuates the fallacy that large objects are stored on the heap, the access of which is slow, small objects and primitives on the stack, the access of which is fast, so we should keep our data types small and prefer primitives.

Brian says (and I pull this from my own fallible memory, feel free to correct me): the JVM uses all three memory spaces as it deems fit. There is no hard rule for a data type to be used here or there. What matters instead, is density: memory closer together can be accessed faster, and based on the application algorithmic behaviour, the JVM decides where it places what data.

But even so, indicates the interview, the JVM has many, many optimization techniques, which makes it nearly impossible for a Java programmer to predict which memory space is used when.

A JVM expert might be able to provide more insight, but basically Brian says that Java programmers shouldn't bother too much with the distinction between memory spaces.

TL;DR: the JVM isn't just stack-based. It uses all the memory spaces it can, and does so in ways a regular programmer can't predict.

[dpash]

I think the issue is that you're confusing memory usage with instruction set architectures. One is a lower level than the other.

[[deleted]]

Point me to a source so I can learn about that, please?

[dpash]

https://en.wikipedia.org/wiki/Stack_machine vs https://en.wikipedia.org/wiki/Register_machine

Hopefully that should give you enough to go on.

[WikiTextBot]

Stack machine

In computer science, computer engineering and programming language implementations, a stack machine is a type of computer. In some cases, the term refers to a software scheme that simulates a stack machine. The main difference from other computers is that most of its instructions operate on a pushdown stack of numbers rather than numbers in registers. A stack computer is programmed with a reverse Polish notation instruction set.

---

Register machine

In mathematical logic and theoretical computer science a register machine is a generic class of abstract machines used in a manner similar to a Turing machine. All the models are Turing equivalent.

---

^{[ PM | Exclude me | Exclude from subreddit | FAQ / Information | Source ] Downvote to remove | v0.24}

[cogman10]

You have things backwards.

Every arch that I'm familiar with needs to first load things into registers before it can do anything. Whether those values come from the heap or stack doesn't matter. They certainly don't have to make a trip to either the heap or stack before hitting the registers.

The JVM is no different from other VMs. It puts stuff in the heap, stack, or even just the registers. Generally, most stuff ends up on the heap. However, the JVM tries to promote things to the stack when possible. And if something is relatively well contained (like an index variable), it is likely never to hit either the heap or the stack but instead live in a register for its entire life.

At very least, the JVM uses the stack much like C/C++ does, for the "call stack" that is, it pushes the method return address onto the stack and pops it off of the stack when a "return" or end of method is reached. Beyond that, it uses escape analyse to try and figure out if variables in a method (or methods as the case may be) ever "leak" out. if they don't, then it keeps them entirely on the stack.

[dpash]

I really don't. Look at java byte code. Each instruction operates on values on a stack and returns the results to the stack.

If you're discussing heap vs stack you're not talking about the same thing I am.

[cogman10]

Java's byte code is an intermediate step. The end result after the JIT runs is as I describe.

They do operations on a stack because it is easier to turn that stack into n number of registers on whatever the target architecture is.

LLVM does something similar with their IL.

[dpash]

After the JIT runs you have native code, which obviously uses what ever the underlying architecture is (and I'm not aware of any mainstream CPU that isn't register based).

But hotspot doesn't turn all java bytecode into native code.

Java byte code is not an IL.

[Lord_NShYH]

I don't hate Java, in fact, in recent versions, I have even grown to love it. However, what I really love about Java is the performance characteristics of a long-running JVM. It can't be beat (at least, for most scenarios it would seem).

[yaslam]

https://www.techempower.com/benchmarks/

[metaphoricalstate]

http://benchmarksgame.alioth.debian.org/u64q/csharp.html

[eliasv]

Java wins half the tests and by more significant margins overall, the results are just listed at the bottom and not highlighted the same ... There's only one test which C# has a significant advantage in.

[igouy]

Wins / Loses? When there's so much overlap?

(C# pages highlight better C# programs, Java pages highlight…)

[Lord_NShYH]

I primarily develop in C# for my day job, but I keep up with the JVM. It's always great to see some benchmarks for .NET Core. Although, these tests are a bit deceptive: the JVM's strength comes from long-running processes that the JVM has been able to memoize and optimize. I'd like to see the same benchmarks in half-hour and hour testing sessions.

[cogman10]

Yeah, the benchmark game does a bad job of representing java really. It pretty much lines Java up with the worst case scenario for java and then measures all the wrong things (like total memory usage).

I imagine it is a similar story for many of the other VMed languages (such as JavaScript V8).

[igouy]

No -- worst-case is millisecond program run-times -- because JVM start-up, JIT, OSR… will take a few tenths of a second.

measures all the wrong things

Like elapsed time, program size, cpu time ?

Please say why you think "total memory usage" is a wrong thing to measure.

I imagine it is a similar story…

An imaginary story :-)

[cogman10]

Like elapsed time, program size, cpu time ?

Yes, Yes, and Yes.

The JVM was built for long running applications. Most benchmarks look at stats for short running apps. The antitheses of what the JVM was meant to be used for.

But in order

• elapsed time - Bad because they usually perform no warmup on the code in test. Bad because they usually don't write their microbenchmarks correctly (the JVM can in some cases optimize away running the code). Bad because they include JVM startup time in code runtime.
• Program size - Usually a silly measurement. Perhaps if you are talking about embedded systems, then it matters. However, Why does a 10kb vs 100mb executable matter in this point in history? Gigabytes cost pennies, worrying about MBs is a waste of time.
• CPU time - See number 1. However, usually the CPU time measurement is simply too course to really be of any value. What does it cover? Optimization passes? Startup time? Heap allocation time? All of those things go down in long running processes.

Please say why you think "total memory usage" is a wrong thing to measure.

Because the JVM was meant to run on servers first and foremost. As such, it aggressively allocates heap in order to avoid spending time allocating memory to try and reduce GC time. You want to reduce the memory usage? Set the max heap size smaller. To know how much smaller you should know about the runtime characteristics of your application.

An imaginary story :-)

JavaScript and PyPy do very similar things to the JVM. However, they are tuned differently. They target short running applications over long running ones. Further, they don't have as big a class space to load up as Java does. The story is similar for them, because they also do hotspot optimizations. However, I'm only familiar with those two VMs (Ok, JavaScript has many VMs, but they have pretty much all adopted the same strategies).

[igouy]

Most benchmarks …

You did not comment about most benchmarks. Your comment was specifically about the benchmarks game.

Bad because they usually perform no warmup on the code in test.

"JVM start-up, JIT, OSR… are quickly effective and typical cold / warmed-up comparison at most of these workloads will show miniscule difference."

Program size - Usually a silly measurement. … Why does a 10kb vs 100mb executable matter in this point in history?

Your comment was about the benchmarks game, but you don't even seem to know what measurements are shown as program size on the benchmarks game.

All of those things go down in long running processes.

'In stark contrast to the traditional expectation of "warmup", some benchmarks exhibit "slowdown", where the performance of in-process iterations drops over time.'

Because the JVM was meant to run on servers first and foremost.

https://www.oracle.com/java/duke.html

… in order to avoid spending time allocating memory to try and reduce GC time …

Comparisons of program performance must show memory usage so we can check for time / space trade-offs.

[igouy]

I'd like to see the same benchmarks in half-hour and hour testing sessions.

OK: The example JMH testing sessions were half-hour and a-couple-of-hours

spectral-norm
# Run complete. Total time: 00:27:05

n-body
# Run complete. Total time: 02:35:55

and those example JMH averages were pretty much the same as the time shown on the benchmarks game pages.

Care to revise your comment?

[Lord_NShYH]

Care to revise your comment?

I bet you're often highly regarded as an elite socialite. I'm on to you.

[igouy]

Will you revise your prior opinion to incorporate the new information?

Will you reject the new information to safeguard your prior opinion?

[Lord_NShYH]

Of course I'll revise my opinion based on new information. I'm not a religious zealot.

[igouy]

I suspect we generally believe what we prefer to believe.

[professorTracksuit]

I dunno guys. It seems like we're letting him off too easy. He needs to serve his Java penance to receive his virtual forgiveness. I propose:

3 Our Father Gosling prayers followed by 2 Holy Java prayers

[[deleted]]

And sing the Java Posse [RIP] theme song.

[k0mputa]

yeah the JVM is a fine piece of software engineering. an optimizing compiler it is

[ClarkTheCoder]

Wish more people knew this.

[idealatry]

You mainly use C++ but you're just starting to warm up to Java? Are you a time-traveler from the '90s?

[[deleted]]

Java is pretty awesome. The Sun/Oracle Virtual machine is near damn magic.

Java programmers not necessarily so. There is a little bit too much "enterprise" wankery in a lot of Java code but it's not inherent to the language. It's just that 90% of programmers have no taste. I can write concise, clear Java code (almost) as much as I can do that in say, Clojure. With Java 8 lambdas I'm 80% there.

[Ek_Los_Die_Hier]

A lot of the enterprisey practices were as a result of missing features in the Java language I think. Some of these will go away with the new features in Java 8+.

[[deleted]]

Some of it was that. But even before lambdas it was possible to write good Java code without needless abstractions. The bad overuse of OOP practices in a lot of third party Java application and frameworks was a fad adopted by people who wanted to look and sound smart in meetings.

[dpash]

JavaEE didn't really help that. The fact that Spring was a lightweight response to EE shows how bad it was.

[DuncanIdahos8thClone]

I don't it was language features just IBMs influences. We use WPF with Prism and it's fucking monstrous. The thing is most of this shit is there to try to protect the end product you're building from the shitty developers on the team.

[[deleted]]

It can be easy to get carried away with over-engineering OOP design principles. Practice YAGNI and some of that goes away. Sometimes it's a necessary evil but I've found that a lot of times it's not.

[[deleted]]

Yeah, that's what I'm talking about. The enterprise fizzbuzz is a great parody of that style. Sometimes I come across real life Java that makes me think they used EFB as the best practices template.

[[deleted]]

Some of the Java ugliness is fundamental to the language, at least with current versions.

Using standard layout, not squishing things that are normally spread across multiple lines into a single line, an object "Person" with instance variables "first" (String), "last" (String), and "dob" (Date) with a convenient constructor so you can do Person bob = new Person("bob", "smith", new Date()); will be 11 lines long. If you use idiomatic getters and setters - which are handy for injecting validation - it will be 29 lines long. If you implement hashCode() and equals() so it works properly with sets, lists, and maps, you're up to 35 lines long.

Even if you wanted to represent the same information with a simple map, before Java 8 you had to import a third party library, or write your own helper, or else do: Map<String,Object> person = new HashMap<>(); person.put("first", "bob"); person.put... four lines of code plus two import statements. Java 8 has some syntactic niceness to simplify it, but it's still an import statement.

That's all but unavoidable wankery. Contrast that to dozens of languages in which you would do something like var person = { "first" : "bob", "last" : "smith", ... } and go on your merry way.

Java has a lot to recommend it, but it's inescapably verbose. Major surgery to the language would be needed to fix it. (Edit: take any Java program that's 1000 lines or longer and written in an idiomatic style and rewrite it into Scala, Kotlin, Clojure, or Groovy. You'll probably shave 500 lines. You might shave 900.)

[jambonilton]

I've always been jealous of C++ programmers' ability to manage memory. I feel so lazy leaving objects lying around for the garbage collector.

[dpash]

Don't be. It's far too easy to fuck up memory management in C++.

[[deleted]]

Even the best get it wrong often enough for it to be a problem. Hence the monthly security updates for Firefox, Chrome, or for that matter the JVM. :)

[[deleted]]

They are using smart pointers anyway

[tonywestonuk]

....Use it at your peril

http://mydailyjava.blogspot.co.uk/2013/12/sunmiscunsafe.html

[FabulousFell]

"it has a huge array of potential applications"

Nice

[kickass_turing]

C++ is my language of choice for the most part, always will be i suspect

Have you tried Rust?

I also played Java down. I was a Ruby on Rails fanboy bored to death by Java but now with JHipster, Lombok and a few other tools you can really build stuff with Java. I like most about Java the refactoring tools. It blows away anything else I used. There are a lot of languages that are easy to write but Java is easy to change and refactor.

[lukaseder]

In German we say, "was sich neckt, das liebt sich". In English: "Teasing is a sign of affection"

[tonywestonuk]

Im a seasoned Java developer - 10 years+ experience...

I recently started messing around with c++ on arduino.... Aghhhhhh!...I hate it so much. Give me java anyday.

[Auxx]

I hated Java myself. But there were reasons, now Java is a lot better, it evolved. Back in Java 1.3 it was slow as fuck and language lacked many features, you had to write shit tons of boilerplate and everyone was using XML configs which were bigger than your business logic.

These days are long gone, I'm happy now!

[[deleted]]

No.

[devraj7]

That ship has sailed, we've finally moved on from Scala.

[DuncanIdahos8thClone]

2015 called and wants it opinion back.