I know this was meant to be a joke, but this was more an issue in wording by Schofield (the writer) than anything else. A Microsoft account is pretty much global across all their products. So it's also their email account, their OneDrive account, their Azure account... I'm assuming he picked Office 365 simply because that's the product he thinks is most likely to be already used in the school.

As for the optimization; the JIT's main optimization from what I've researched is inlining. Which is really beneficial for Java because you tend to end up with a nest of getter method calls all to get a single field somewhere, and wouldn't it be nice if the JIT could just inline that field for you? I suspect that, especially if performance is at stake, it's less typical to end up with patterns like that in a C++ codebase.

If Microsoft can get schools to use Office 365 instead of Google apps, then $2.5 billion for Minecraft was cheap.

If you're a teacher, it's a huge boon to be able to re-use existing accounts. You really don't want to make dozens of classes of kids set up and remember new IDs and passwords for a single application.

I definitely think that most of the speed increase is coming from the fact that Minecraft is being rewritten, and not which language it's being rewritten in.

The JVM can do a lot of optimisations C++ apps don't benefit from, but I think the loss from not having value types more than drowns them out.

1. ActiveSync! This is the only reason I'm still putting up with this garbage.

2. My company also uses O365, extensively. We have a wiki of sorts in OneNote. I can't contribute to it. Logging into the corp account and clicking "open in desktop" results in an error that claims that I don't have a license. I do. On an on-premise licensed domain-joined machine. I don't on my own O365 account but I didn't log on with that.

3. No layman interface. Want to disable password expiry for your 89yr old father? You'll need to download and install a powershell plugin before you can start reading documentation.

4. Inexplicable login problems. No UI to enter my login email because I had logged into a temporary SP online site I was debugging with. Later I found a "forget this login" link under the temporary login; restoring my access to any other account.

5. "Live login? Microsoft login? We don't know, tell us every time. Oh! You can't use Live with this service anyway!" I no longer know which of the two accounts my stuff is on.

TLDR; O365 is great for corporate/business. I'd recommend it. For personal stuff stay the hell away. They really want to give O365 to kids?

Read that line instead as:

Good news! Your teachers and their students won't need yet another password to be able to use this application.

It always saddned me not to have this option in the reference JDK, only on commercial JDKs.

Whereas we already had Java like safe languages with Eiffel, Oberon and Modula-3 compiling AOT to native code, and with JIT also available before 1996.

Oh and with value types and proper generics as well.

Now maybe Java 10 will become what Java 1.0 should have been.

However it'll be a commercial feature. The main reason being, they think it only really matters to rich trading houses that want to hit full speed when the market opens at exactly 9am. The tricky part is that there'll still be JIT compilation happening, because otherwise the program runs quite a bit slower, as the adaptive optimisations can make a big difference.

Which is sad, because if I want to pay for it I don't need to wait for Oracle, almost all comercial JVMs already do it.

When I got into Java, I always expected it to eventually support AOT on the standard compiler.

Java in finance is actually slowly eroding overall. Performance-critical logic is being moved into Python modules written in C. "That's how we do it" anyway. The trouble is that Java code development is too slow and just getting your code deployed into a test environment is often ridiculously complicated (lots of middleware) whereas with Python "you write, you run, you're done."

Where latency is really critical, things are implemented in FPGA though.

http://mechanical-sympathy.blogspot.de/

I guess C++ progress in the last years has helped this.

A lot of the stuff that makes Java great for building high level systems quickly is still kind of missing from formal C++ though (IoC, JMX, etc...), and it would have been nice to see some of the internal stuff get open sourced.

I wonder if people are starting to avoid Java because of Oracle (e.g. vs Google).

But in those days it was a big mess to write portable C++ code, given the discrepancies between compilers.

I don't miss those CORBA and DCOM libraries, but I miss OWL and VCL.

Java is still quite strong in the Fortune 500, and most managers don't care about Oracle vs Google, as it was caused by Google trying to avoid to pay Sun anyway.

However I sense some signs similar to when CA started loosing CLIPPER's direction, or when Borland attitudes started scaring people away from Delphi and C++ Builder.

On the other hand, Java is just too big and it will take generations to replace all those systems.

Java is definitely still really popular for development overall (TIOBE 2015 #1). My personal concern with Oracle vs. Google though is that Oracle does not own the language, and the copyright claim on APIs seems pretty aggressive. The JVM and Java have open specifications which in theory anyone should be allowed to implement (practice is admittedly a bit different). Even the official JDK was open source, which Oracle seems a bit hostile toward considering what they've done with purchases like MySQL and how the community largely responded.

Claiming copyright on an API seems somewhat akin to Keurig 2.0. Although, I think courts are having trouble keeping pace with technology.

Our university adopted it right away and made it in 1997 the official language for compiler development and distributed systems classes.

Without bothering to search the Internet, NIO was either introduced in 1.4 or 1.5.

Yes they have open specifications, but they also have trademarks and compliance certifications.

The JDK was open source, but the license prevented its use for mobile devices without a Sun approved license, that Google didn't want to pay for.

So now Google has actually created a fork in the Java community.

Just imagine when you have Java 9 with modules, or Java 10 with reiffied generics, value types, JNI replacement, official unsafe package, among many other roadmap features, how to keep the code portable between Android Java and the real Java.

edit: The article does state at the end that google will still modify OpenJDK for their own needs, but that still means that the vast majority of the implementation will be the same, so this seems to avoid most incompatibility issues.

I know Redhat is one of the other major OpenJDK contributors, and a lot of distributions are relying on IcedTea. It will be interesting to see how this develops.

They still don't tell anything about newer versions.

In C++ you can arrange your access patterns so you don't cache miss, much harder to do that in Java.

It's fundamentally a data structure + execution flow problem so it's not something that a VM/compiler can help with. The fact that everything in Java is a ref(to be fixed some point in distant future) just means that every object fetch is a cache miss(really bad).

So, we could conceivably claim that if that is fixed, Java might be able to JIT compile run code a bit faster than C++ in a wider application that currently, but then again by the time that happens, C++ might have a plethora of other tricks up it's sleeve to make execution a little faster.

IIRC, a register-based virtual machine would alleviate the cache-miss behavior the GP talks about. (Because larger, more complex instructions = fewer hits to cache)

It's been a while since I've mucked around with this type of stuff, though.

The issue is that each object is a reference, and because it's a reference it's position in memory is by nature ambiguous(compacting GCs make this even worse by moving things around).

Until you can guarantee memory location you don't know that the N+1 object you're going to access is in the same cache line(or prefetched) and any sort of cache optimization is shot to hell. Only by knowing your standard execution flow and data set size can you write code that's as efficient about cache misses as possible.

Hotspot only tends to focus on tight inner loops where the stuff I'm talking about involves looking at the larger program(and the structures you choose to put data into). Think Structure of Arrays(SoA) rather than Arrays of Structures(AoS). Possible to do in Java, but very painful.

For me what counts is the official Java, not forks.

Check the Android source code.

They updated to selected parts of OpenJDK 7!

I am not sure it is a fair comparison. had Minecraft been written in C++ with the same dev cycle, a complete rewrite in Java would also allow to improve its perfs ...

Hindsight is always 20/20 so it really doesn't surprise me any rewrite is faster than the previous version.

I have to wonder if they plan to keep the codebase portable though. One of the major benefits of Java was that nearly everything has a JVM.

[1] http://hubicka.blogspot.com/2014/04/linktime-optimization-in...

This was a big deal in the late 90's as C compilers were still catching up with ANSI C and ANSI C++ wasn't done, with each compiler supporting a different flavour of the ongoing work.

At least as I see it.

Today, with JDK8, that's almost true. With JDK9 it might be.

There's no reason Java can't be faster, it just hasn't happened yet.