Slashdot Mirror
Oracle To Monetize Java VM
jtotheh writes "According to the Register, Oracle is going to make two tiers of Java Virtual Machine — a free one and a premium paid one. 'Adam Messinger, Oracle vice president of development, told QCon that Oracle plans to offer a "premium" edition of the JDK in addition to the open-source JDK. Both, it seems, will be based on a converged JRockit VM and the Hotspot JVM from Sun Microsystems. The converged JVM will be released under the OpenJDK project. ... Messinger didn't explain how the premium JVM would differ [from] the free version, but the premium edition will likely see performance tuning and tie-ins to Oracle's middleware.'"
I'm going to laugh as their Sun acquisition goes down in flames and they end up losing money on the whole deal. They seem to be working to identify any market they can that things are working in and eliminating it. They've done a great job at getting us to work at getting rid of all our Solaris systems as fast as we can.
While in theory this could be fine for Java, I can't imagine it will be being how poorly Oracle has handled things so far. Most likely it'll be a case where the free JVM will be a piece of crap on purpose, and the pay for JVM will be required for anything to work well. Ya, well, that'll fly like not at all. People are not going to go and buy something to make Java apps work better. Perhaps companies who rely heavily on Java on the back end will, but more likely they'll just stop upgrading and switch to something else.
I guess we'll see, maybe I'm wrong and the premium version of the JVM really will provide worthwhile premium features that high end users want, while the normal JVM remains for normal people. However I doubt it. I think they'll try and charge every person for the JVM on their computer, which just won't fly.
Java isn't that much slower than C++ these days, if you do it right Java/C++ performance is so close as to not matter.
It's also more maintainable, has better frameworks and you don't have lots of beginner/intermediate level programmers introducing memory holes left, right and center.
Saying all that I work for a company which has invested millions into Java applications. Considering how Oracle has been acting the tech leads are pushing to moving us back to C++.
That's a nice list of scripting languages you've got there. And don't get me wrong, scripting languages are nice. However, if speed is an issue, Lua's never going to cut it in the same way that Java does.
Given that Google is on the sharp end of Oracle monetizing Java, anyone else think they might start to push Google Go really hard? It's immature at the moment but it looks really nice and I think as it matures it could really catch on.
Struggling to find a day everyone can make? WhenShallWe.com
Hear, hear. I've developed an image processing algorithm in Java and C++ (pretty simple: for every pixel in floating point array, compute some basic stuff, create a few classes to simplify the storage of temporary values and save the result into another array). The code was as close as possible in both languages, with no obvious screwups like memory leaks or unnecessary copying of stuff. To my surprise Java ended up being 15-20% faster than C++. And C++ is THE language for image processing, every new image processing algorithm is written in C++ (with the occasional exception of C) because of performance reasons.
Over the years I've seen lots of companies trying to combine the open source development model with a for profit (and publicly funded) business plan. While this seemed okayish at the time, this whole Oracle debacle is clear proof that the opensource development model combined with some corporate entity controlling it is risky from an opensource perspective. Big opensource projects hopefully have learned from this and go the Debian route : turn yourself in a NGO or something and never worry about shareprice or corporate takeovers again.
It is a real shame that big projects like MySQL and OpenOffice are in this position. Maybe it was more or less opensource, it sure as hell was not independant. Sure forking works, but recreating the entire organisation (and funding) will keep you from developing quite some time.
Now try using SSE intrinsics. With Java, you can't do that. In C(++) you should get a nice speedup ending up several times faster than Java, unless you're bound by memory bandwidth.
Or use a better C++ compiler, like the Intel one, which gives a substantial speed boost with no developer effort.
There's also ready-made C++ maths libraries for pretty much everything, many with SSE optimizations.
These micro benchmarks also ignore cache thrashing, which kills Java performance for large apps.
>> I am sure more than one group of developers is
>> seriously looking at core language jump.
I know we are.
Oracle is quite simply not a rational enough company to entrust with our ongoing development.
Decisions, decisions.C# on MONO or C++ as itself. Pros and Cons for each are obvious, but the actual final scores will be hard to determine efficiently.
Individually I'm leaning to C++ and arguing the point that sooner or later MS will do to C# & associated platforms what Oracle is doing to Java now, and what lawyers may say about MONO now will count for nothing in reality when MS decides it's time to drop the hammer.
kartune85 : Incapable of reason, observation or learning. A kind of dim, drab, flightless parrot.
Working in a senior role within a global investment bank, we buy a lot of vendor product, especially from what is now Oracle (Oracle Databases products, Weblogic products, etc.) - and if they want to charge us for the 'better' JVM going forward, no doubt we will pay for it. As will the other banks.
And Oracle knows this. It does not give a shit about small-scale Java customers, but the big corporates, like us, well, they know that even if we decided tomorrow that all new projects were to move to C#, or C++, or Objective-C, or whatever, that it would take a long time to change course, and Oracle can still bill for a long time.
One thing to remember - our bank gets and stays profitable because it pushes a lot of IT outside to third-parties (offshore developers are *much* cheaper than in London and NewYork), and they do not see any problems with getting a global price agreement with companies like Oracle and Microsoft.
Personally, I am brushing up my C++, learning Objective-C and C#, as I think the medium and smaller companies in the market will start to migrate away from Java, as the cost savings of cheaper Java developers is lost once you have pay large amounts for the Java install and licensing.
Stallman wrote the Java trap, and we all laughed. Sun is nice we thought, it'll be ok. We were all wrong. Stallman saw further, he saw that even if Sun was ok, if someone bought Sun, then things could get messy. Welcome to messy.
...and how would it effect those languages when there's only a sub-standard free JVM available?
Are you dynamically allocating memory during your calculations? Basically new and delete are pretty slow in C++. While garbage collection is slow as well, actually allocating of memory is much faster in Java. Fortunately, you can implement your own allocation strategy in C++ by overriding the new and delete operators. Admittedly, it's a bit more work but can in many cases easily result in a tenfold speedup.
Well, I think Java-the-language is already out there. I can't imagine a way for Oracle to get those worms back in the can. So we must be talking about the VM, and maybe their extensions (SE/EE).
My prediction? The VM continues to be free. EE becomes premium. SE, not sure about. And there may be a pay-for-fixes model for the VM that is, by definition, not free. If you need something fixed NOW, you pay. If you need more performance from the VM, you pay. Those fixes may or may not make it into the generally-available VM.
The community solution? IMO, it is to finish Parrot, get a "Java-the-language"-to-Parrot compiler built (perhaps by starting with a Java-the-VM-to-Parrot bytecode converter), and then you can pretty much discard Java-the-VM. Parrot already supports a bunch of different languages (at different levels of completeness), so it seems to me to be a natural fit.
After that project gets going, approach gcc to have gj able to target Parrot instead of Java bytecode, like all their other cross-compiling solutions. It makes Oracle irrelevant.
Maybe, though, we'll have to wait and see what Oracle's real plans are before we, as a community, start down this road. It's an expensive road (in manpower more than $$), and if everyone continues to be happy with Oracle's free offerings, there won't be much impetus to go around Oracle. That said, I can imagine some people still worried enough about Oracle's next move to start work on this, or a similar, solution.
You are confusing the theoretical cost of ideal garbage collection with the actual cost in a particular implementation.
I have worked on optimizing real-world Java applications that really were running too slowly. The problem really was that they were allocating too many short-lived objects in a modern JVM, and reducing the number of allocations really did improve performance significantly. Sorry if reality doesn't match your fashionable assumptions, but that's just the way it is.
Just look at some benchmarks some time. Scala performance is closer to Python than Java. Yes, often that's fast enough. No, it is not always possible to throw hardware at the problem when it isn't.
Well, there's also the fact that Java performance has caught up to the point where it's not quite twice as slow as C++, and faster in pathological cases. And there's the fact that Java, the language, isn't what's in question here -- it's the JVM, which means JRuby, Scala, Clojure, etc.
So it's not just 10 years of Moore's Law, it's 10 years of optimization. Java was pathetically slow. Now it's the fastest thing in its class.
So what would you replace it with? C# isn't necessarily faster, and it's got that wonderful Microsoft lock-in. Anything else is either going to be much slower (perl, python, Ruby) or much more dangerous (C, C++). It's possible there are some obscure Lisps that come close, but we're at the point where all the major optimization research goes into either C/C++ or Java, to the point where CPUs are designed to run C fast, not the other way around.
Oh, and I expect it'll be the other way around -- the free version will be cross-platform, while the premium version will be "vertically integrated" -- might be one Windows implementation, but very likely one more, maybe on Solaris, maybe on "Oracle Unbreakable Linux", but somewhere they can "integrate" it more thoroughly into the system. At least, that'd be the typical move for them, and the smart move -- just another way for them to grab the enterprise by the balls and squeeze, while ignoring everyone else, especially their smaller customers.
Don't thank God, thank a doctor!
Here's the problem: Intelligent, detail-oriented people make mistakes.
after a few years of training can instinctively and deliberately avoid bugs both the subtle and the egregious...
If you can find a single programmer who actually does that, post their "flawless" code along with a sufficiently-motivating bounty and see how long it lasts. To be fair, you should have some way to verify the amount of time it took to produce this code.
In the real world...
Wait, back up.
higher-level languages like Java that do everything for you including tying your shoes for you...
Wow. You're actually claiming Java ties your shoes for you? Java, the only language I know of where == can't be counted on for equality (because Operator Overloading is Bad, mmkay?), where primitives are special cases, where null is a special case, where threading is still handled via the same primitives as in languages like C or C++... That language?
Seriously?
I'm just going to pretend you didn't say that, so I can pretend you had an intelligent point worth my time to respond.
So, in the real world, where Java is only moderately higher-level than C/C++, programmers can and do make mistakes occasionally. Even the best occasionally make stupid mistakes. Just off the top of my head:
Yeah, I know it's stupid, first-year mistakes. But think about the concepts you had to summon up to tell me why that's wrong. And of course, if I do it this way:
Now the caller is responsible for cleaning up after me. Sure, I can create a function that helps, if foo had a bunch of additional stuff that needs to be individually free'd or otherwise released, but they still need to call that. If they don't, I leak memory.
We can do that, or we can do C++, where we get gems like this:
Or if I decide to use the heap...
Even if you do manage to do it perfectly every time, you're still spending far more time -- even the sheer amount of typing saved not having to deal with this bullshit is significant. And you won't do it perfectly every time.
And when you screw it up in C/C++, you leak memory, segfault, corrupt yourself, or introduce a security vulnerability. When you screw it up in Java, so long as you're not using threads, about the worst you do is a null pointer exception.
Yes, you can leak memory, corrupt yourself, or be insecure in Java, but an entire class of bugs are now not possible. It is no longer possible to segfault, and it is no longer possible to introduce security vulnerabilities or leak memory through your use of pointers or references.
And you know what? For 99% of what I do with a computer, I'll gladly take a 50% performance hit for fewer bugs. In fact, I'll gladly take a 95% performance hit (and I routinely do) for even fewer bugs and (much) faster development. It's just more important for it to be reliable and maintainable than it is to satisfy someone's ego about how smart they are that they can use pointers.
Don't thank God, thank a doctor!