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.'"
the death of java?
he who controls the spice controls the universe
Suicide? Sounds they are working on ending Java in a hurry. :(
leather-dog muksihs
Blog: @muksihs
Either Larry Ellison is smart beyond my imagination, or he's too stupid to understand that he's basically killing MySQL, OpenOffice and Java - arguably the three most valuable software assets he bought with Sun.
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.
Wouldn't that be like racing whales?
Java has become the Digg of languages.
Goodbye Java, we hardly knew thee...
Oracle already has free and pay-for JVM: HotSpot is free, JRockit is not. I expect the free JVM will be just fine for desktops and small servers. I'd expect pay-for JVM to target enterprise solutions. And again, I expect them to ship this JVM for free with their middleware products (Weblogic etc.). But yes, this sucks for JBoss.
... Ballmer et al are wringing their hands nefariously as they see the future of C#'s marketshare increase by leaps and bounds. And that's good for Microsoft in every way, since every application written in C# instead of Java means a license for Windows is being purchased to run each copy of the software. In web apps, it's a server license; in workstation applications, it's a desktop OS license. Either way, it's a win-win for Microsoft, and a massive loss for Oracle.
.Net versions, there would actually be an open source OS alternative to running modern C# applications.
Not that I mind, per se. I prefer C# in every way to Java... but from Oracle's perspective, I don't see how they see this would do anything but hurt Java and their reputation that's rather ubiquitous.
Now if only Mono would get their asses in gear and not lag so far behind
At least they are consistent: first they killed OpenSolaris, then they managed to split the OpenOffice community and now they will marginalize Java. I am sure they have something in store for MySQL too...
CU, Martin
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.
Yes, because allocating short-lived objects in a modern JVM is a very expensive operation. No, wait, it's an increment on a pointer value stored in a register. Disposing of them is marginally more expensive, but if only very slightly. The cost is roughly equivalent to allocating a C++ object on the stack.
I am TheRaven on Soylent News
1000's of big companies (telcos, utilities, retailers, gov, defence) use java in their back office, and... well everywhere.
This may cause them to change their policy for new software development, and it may also squeeze the java developer market badly, but for sure there will be strong arguements for splashing £50k here, £90k there, £20k somewhere else, on getting the new JVM to pick up the performance of application x, y, z which are long in the tooth and a pain in the arse.
The alternative is to rebuild, which carries risk - although would be a good move in the long run. In the meetings someone will say "yeah, but we are all dead in the long run" and that's that basically. As a CIO you just pay over £50k, get your users back on side, keep your job for another year, collect your bonus, put another years pension contrib into the pot.
So, Oracle will make money, lots of money, off this. You guys can squeak, MS will cheer, the Python community will see a boost (perhaps), but Larry and co will be richer.
Mysql (in the future) = Oracle feather light (down load it and run it and you are up and going in less than 1hr - oracle normal = 6hrs to setup?) But, if you are an enterprise DBA then you want the management and recovery features that Oracle gives you (as well as the scaling - even though it gets so mind bendingly expensive).
Open office - who cares?
Oracle bought Sun to be IBM mark 2. Expect them to buy Accenture next.
--------------------------------------------- "In the end, we're all just water and old stars."
You do realize that Google uses Java extensively ?
Let's take JVM as an example: you have defined instruction set (bytecode), well defined ABI (this one is much better than in conventional operating systems) and well defined set of standard services (standard libraries). You also have class loader which somewhat resembles dynamic linker functionality in the conventional OS. Oh, and there is a pretty damn good debugging/profiling/monitoring infrastructure built in. And from application programmer point of view JVM is pretty much like a OS. Programmer can use many languages to target this platform, not just Java. It is possible to implement almost any language on top of JVM (albeit some things have no practical sense, for example C/C++ with its pointer arithmetics).
Would Larry prove its intent to totally screw Java (I'm still not sure of it yet), we'd need to have another platform rather than another language. There are enough cool languages to choose from, but aside from JVM and CLR there are no viable, widely supported multi-language, multi-paradigm platforms. JVM is propably the best one available but as it ages, there are more and more shortcomings visible. Having enough support from companies and developers (and from Larry screwing up Java) one can design and implement a new VM addressing some additional things, like:
- native support for dynamic dispatch (albeit OpenJDK7 seems to support it in some way) - what I mean by that is trying to achieve performance somewhat comparable to statically typed programs (now we mostly compare to C implemented couterparts, eg. JRuby vs. Ruby, Jython vs. cPython etc.);
- support for big memory heaps - most VMs suck at this (except for Azul), so we have to slice server machines and run many instances of JVM on one machine, then cluster/farm these JVM which is both silly and troublesome;
- better support for massive concurrency - again, most JVMs suck at this and Java thread model isn't perfect and isn't suitable for everything;
- support for multiple independent garbage collector zones - some language may utilize this to mitigate concurrency/big memory heap problems (Erlang, anyone?); ability to use different garbage collection algorithms in different zones if it makes sense (ex. big heap as in Java vs. small heaps as in Erlang);
- ability to execute on multiple target devices at once - to utilize GPUs/APUs directly from bytecode (maybe with some limitations), without those crappy hacks we see today; it also applies to memory management that seems to be a horrible hack in current GPGPU solutions;
- better support for long running VM processes, mainly hot code loading (Sun JVM sucks at this but some other solutions like JRockit seem to do a better job), maybe some code versioning, better tools to administer / tinker with running VM process (similiar to what Erlang has);
There is more than 15 years since Java was published. There is about 10 years since Microsoft built its CLR. And there is a lot of new things that appeared (GPUs, huge memories, multicores) and lots of new knowledge we obtained since then (look at all these JS interpreters in modern browsers!). There is also a pretty good base to build on (LLVM, V8, BEAM, PyPy and tons of other projects). On top of such VM we can implement various languages (including Java), maybe even better than JVM.
With enough help from friendly enough companies (RedHat? Google?) we can propably do much better than JVM and leave Larry and his corporate cronies in the dust. As long as there is a good quality reference implementation we don't need to chase Java APIs nor we do need to beg for TCK access.
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!
You obviously aren't familiar with what transpired.
Sun stock went into the toilet with the .dot com crash and McNeely spent more time talking a good game than in developing a viable business strategy by failing to diversifying away from SPARC or making SPARC good enough to make it worth the premium price. Their Java efforts turned out to be misguided as a means of accomplishing the latter, since it only emphasized that from a customer perspective there was little premium to be had by buying SPARC. Schwartz came on board too late to steer a different course, particularly as th tech economy was like the rest of the market in a tailspin. Board members like McNeely, who were near retirement age anyway, decided to sell out knowing it was the only way they would get that golden parachute they had been dreaming of. Towards the end as is usually the case, you saw more and more of Sun's profits directed toward big exec bonuses as they prepared to sell out, insuring the ultimate death of the company as a viable independent business.
Microsoft investors should be getting nervous about Ballmer's recent announcement of sale of 1.2 Billion in stock. This is how the stock market works these days. Its an inside game played by insiders, while boilerplate fantasy is sold to the public and the poorly informed.
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!
(*) In order it to be a "sharp" the symbol in use must be (1) in italics, and (2) in a musical clef. In Microsoft's language definition it is neither, that makes those two vertical and two horizontal lines a "pound" no matter how much they want you to call it a "sharp".
a) The pound symbol is that cursive L shaped glyph with the verital cross through it.
b) Only in the US is # called the 'pound sign'. Canada calls it the 'number sign', most of the rest of the english speaking world calls it the hash.
c) Technically you are correct that # isn't an actual sharp sign, but you are incorrect on both counts as to why. A sharp does not need to be on a "musical clef". And it has nothing to do with italics. The sharp must have true vertical bars, and slanted horizontal bars. A number sign must have true horizontal bars, with optionally slanted vertical bars.
d) The language C# is called C-sharp. Wandering around calling it c-pound and actually arguing that this is somehow correct is just pointless. Why "c-pound" and not "c-hash" or even "c-octothorpe"?
C-sharp is the clearly stated intention of the people who named it, and at the end of the day language rules are descriptive not prescriptive. The symbols use to write things do not dictate how we pronounce them. Written language is simply an approximation using a mix of tradition, convention, and convenience.
The programming language was named "c-sharp". It was then rendered conveniently as C#. Suck it up.