Slashdot is powered by your submissions, so send in your scoop


Forgot your password?
Java Oracle The Almighty Buck

Oracle To Monetize Java VM 641

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.'"
This discussion has been archived. No new comments can be posted.

Oracle To Monetize Java VM

Comments Filter:
  • Good. (Score:1, Interesting)

    by Anonymous Coward on Sunday November 07, 2010 @05:20AM (#34152828)

    Good, now maybe someone will come up with a better language to use.

    not trolling or anything, the only reason java is tolerable at all these days is because finally, most devices, including mobile devices, have become powerful enough to withstand the sheer bloat. 10 years ago, running anything java was painful.

    now modern mobile devices are more powerful than those systems from 10 years ago, I think that's the only reason java is usable.

    wanna bet the premium version will promote cross-platform compatibility while the free version is restricted to whatever platform oracle chooses? (ie, more than likely windows)

  • by Sycraft-fu ( 314770 ) on Sunday November 07, 2010 @05:35AM (#34152882)

    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.

  • by polemon ( 743631 ) on Sunday November 07, 2010 @05:53AM (#34152938) Homepage Journal

    It's out of question, that this will kill Java as preferred language in academia and science.

    But who cares, really? There are other languages, that would be a more than adequate "replacement" - if I may call it that - for Java.
    So professors will have to teach Python in university, how is that something bad?

    Java was chosen a few years back, because it was modern and cross platform, but that is Python as well. I also suggested using Lua in academia. For teaching programming and data structures, this is arguably one of the favorable languages.

    I'm a Perl developer, so I'll wait and see what happens with Perl6...

  • by Stevecrox ( 962208 ) on Sunday November 07, 2010 @06:03AM (#34152968) Journal
    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++.
  • by Ruke ( 857276 ) on Sunday November 07, 2010 @06:13AM (#34153004)
    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.
  • Re:mm (Score:5, Interesting)

    by levell ( 538346 ) on Sunday November 07, 2010 @06:19AM (#34153024) Homepage
    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.
  • by zlogic ( 892404 ) on Sunday November 07, 2010 @06:26AM (#34153058)

    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.

  • I agree with this statement, this is indeed the birth of new opportunity - A new technology to replace Java...

    If you want to replace Java you can just use Scala. It can do all that Java can do and is a lot better. Or did you mean to replace the Java-VM, or Java-SE or Java-EE. Then please be more precise in future.

  • by Eelco ( 8198 ) on Sunday November 07, 2010 @06:29AM (#34153064) Homepage

    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.

  • by bertok ( 226922 ) on Sunday November 07, 2010 @06:44AM (#34153108)

    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.

  • Re:Wow... (Score:1, Interesting)

    by Anonymous Coward on Sunday November 07, 2010 @06:50AM (#34153130)

    NOKIA will be assimilated by Microsoft. The process is already underway.

  • by shristov ( 815759 ) on Sunday November 07, 2010 @06:57AM (#34153144)
    According to Oracle (TFA), "There will always be a high-performance gratis JVM." Well, perhaps Oracle are just going to add enterprise-class features to Java - for example, the JRockit hot swapability mentioned in the article. Once you need such features, chances are you are able and willing to pay for these. The rest of the community could continue using Java for non-mission critical purposes. In time we'll see if this strategy is successful, or not. If demand for features like the ones Oracle is planning to develop is great enough surely open alternatives for some of these will pop up in foreseeable future. When/if this happens we'll hit the major issue worth discussing: how the Oracle-led and OpenJDK evolution paths will stay at least close to each other. If they diverge substantially, at least one would be doomed... if not both.
  • by VendettaMF ( 629699 ) on Sunday November 07, 2010 @07:19AM (#34153218) Homepage

    >> 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.

  • by Anonymous Coward on Sunday November 07, 2010 @07:31AM (#34153252)

    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.

  • by Anonymous Coward on Sunday November 07, 2010 @07:31AM (#34153254)

    We already got better languages like Scala for the JVM.

    Yay, let's push a language that's even more bent on allocating trillions of disposable objects per second than Java.
    But no, that's not a problem, because if you reserve 2GB of RAM per application to amortize the speed cost, it's not that slow!

  • by swilver ( 617741 ) on Sunday November 07, 2010 @07:44AM (#34153294)

    ...and how would it effect those languages when there's only a sub-standard free JVM available?

  • by TheRaven64 ( 641858 ) on Sunday November 07, 2010 @07:58AM (#34153364) Journal
    Or use a compiler that supports autovectorisation. Actually, this is where it gets more interesting. In theory, the Java version can be faster, because Java lacks pointer arithmetic so the compiler / JVM is free to rearrange the memory layout to better suit the vector unit. In practice, I'm not aware of any implementations that actually do this.
  • by arendjr ( 673589 ) on Sunday November 07, 2010 @08:12AM (#34153418) Homepage
    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.
  • by Anonymous Coward on Sunday November 07, 2010 @09:11AM (#34153698)

    Interpreted languages, such as Perl, Python, Lua, Ruby and whatever pet scripting language is trendy at this moment, do not nor they should have any place in any academic curriculum. Let me explain.

      First of all, a higher education courses which are based on programming languages should be designed to educate the students on fundamental topics such as programming paradigms and design patterns. It is unthinkable for a higher education course to waste both the teacher's and student's time doing vocational training. After all, if you are enrolled in a higher education program then you should be smart enough to handle that stuff by your own. Llet the teachers teach the important technical and scientific concepts which are harder to grasp.

    Then there is the reason of applicability. If a course is based on a technology which doesn't have a stable basis and which is likely to drastically change due to a project leader's whims then it is certain that the code written in that particular technology will suffer from bit rot and that your skills which you earned throughout your course will essentially become meaningless. In short, due to a technology's dynamic nature, those who invest their time and effort in a degree or course which is based on that single tool will soon find out that they have wasted their time.

    Then there is the issue of control. If a language is not standardized then you don't have any assurance that your code will run at all in the future. This issue is particularly problematic if a language does not provide any specification regarding the implementation or is based on a single reference implementation whose project leadership often invests their time and energy in complete rewrites.

    So, knowing this, languages such as Python, Perl, Lua, Ruby or whatever trendy language you just picked up is not nor it ever could be sanely adopted by a higher education degree. Doing so is a recipe for disaster and it does a disservice to all students.

  • Re:mm (Score:5, Interesting)

    by Tanktalus ( 794810 ) on Sunday November 07, 2010 @10:05AM (#34153940) Journal

    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.

  • Re:I don't get it (Score:1, Interesting)

    by Anonymous Coward on Sunday November 07, 2010 @10:17AM (#34154010)

    Anybody who can take the steaming pile of monkey dung of a db that Oracle is and make yacht-loads of money from it, is truly a genius.

    Even with as much as I can't stand Oracle, I have to admire Ellison and their leadership for their unbelievable business capabilities.

  • by Haeleth ( 414428 ) on Sunday November 07, 2010 @10:23AM (#34154032) Journal

    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.

  • by gtall ( 79522 ) on Sunday November 07, 2010 @11:15AM (#34154376)

    Synergies? You aren't a real programmer, are you? Just kidding, sounded like you swallowed a marketdroid sometime in your past.

    I wasn't interested in web scaling a gui, but I'll admit that is an important consideration for some. Isn't that segment of the market getting taken over by Javascript, html5, and all the other weboria crap? I just wanted a good cross-platform gui language that gives native looking app and maybe requires a few tweaks here and there to make it work like native what I had to do for Java.

    When I used Java, I used the AWT. Swing was too new and seemed to suffer speed problems. Sun never got small machines. So, their graphics objects got allocated for every damn object on the screen in the paint call chain when all that was needed for most was merely the correct bounding box. Once I circumvented that, it sped up quite nicely.

  • Re:Good. (Score:5, Interesting)

    by SanityInAnarchy ( 655584 ) <> on Sunday November 07, 2010 @11:38AM (#34154502) Journal

    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.

  • by turkeyfish ( 950384 ) on Sunday November 07, 2010 @11:59AM (#34154650)

    There is an obvious trade off. One could not expect ubiquity if your "product" is not either free or very low cost. Yet that implies less revenue.

    Oracle's strategy could work very well, where Sun's has failed, by providing two parallel tracks. One a premium track and two an open track. The premium track would essentially put paying customers perhaps a year or two ahead of the community open track users, who might see these features in the free "community" track a few years later, after something better is in place in the premium track. From a business perspective users would be happy to pay if it gives them a business advantage. From a community perspective users would be happy as they could rely on essentially free code that they could incorporate and tweak to their own ends, acknowledging that free doesn't always mean access to the most "valuable" code in the market place of ideas and corporate balance sheets.

    For Oracle to succeed it need only better refine Sun's model. They really don't have to kill Java as a free language, for on the language side they are in a position to differentiate between a free and a premium track on the JVM. The difficulty will be that they will need to bear more of the burden for developing the JVM on the universe of platforms they wish to see a "write once run anywhere" Java t actually work on.

    As a former Sun investor, who lost BIG TIME for Sun's failure to grasp a viable strategy of how to monetize Java (not that I was expecting to make a killing in the first place), I wish Oracle well in the goal of making Java succeed. The Java concept is still a worthy goal, but it will only work if the "write once, run anywhere" philosophy doesn't disappear at its core. If that happens, Java will become highly fragmented and its fate and influence in the market (open source + private source) going forward will slowly diminish. If they handle it badly, Java's lock on corporate computing might be pretty short lived and perhaps many of Oracle's products that are now intertwined with it as well.

    As always, customers will buy into a software-platform, if they believe it is in their interest to do so. This will vary as not all customer interests are aligned. Oracle has the option of choosing just how much of a differential it will make between "premium" and "community". They may make more money over the short term if they set the difference to great but loose in the long run, if they drive the community elsewhere. It will be interesting to see what happens or just where within the many elements of the Java universe, the differences are placed.

    Its not as if others haven't made mistakes with Java. Sun erred in failing to establish a clear two tiered strategy and then late in the game demanding too much of some of its bigger customers who became too dependent on Java, such as Google, who went off to develop their own "JVM" like construct (whether its different enough from the original Java is for the courts to decide). In the long run, if Oracle can keep the difference small, it will capture a larger share of the entire market. If not, expect numerous forks to appear in the future as they are beginning to do so now as Oracle tries to figure out if it is extending an open hand to the Java community or just a fist.

  • by melonman ( 608440 ) on Sunday November 07, 2010 @12:53PM (#34155020) Journal

    > Interpreted languages, such as Perl, Python, Lua, Ruby

    I'm not sure about the others, but Perl isn't an interpreted language. The script is compiled, and then the compiled code is executed. That's not a million miles from a JIT compiler.

    > is trendy at this moment

    Maybe I missed somethng, but wasn't Perl running half the Internet before Java was a twinkle in Gosling's eye? There are many things to be said about Perl, but "new-fangled" isn't one of them.

    > It is unthinkable for a higher education course to waste both the teacher's and student's time doing vocational training

    Right, but why is that an argument for Java? You can teach Java as a way to tick CV boxes, and you can teach other languages as a way to really understand programming.

    > If a course is based on a technology which doesn't have a stable basis and which is likely to drastically change due to a project leader's whims.

    You're saying that the Perl community rushed into Perl6? Or maybe that a decade-long upgrade cycle for C++ standards is too rapid? And that the future JVM roadmap as of today is very clear to you?

    > Then there is the issue of control. If a language is not standardized then you don't have any assurance that your code will run at all in the future.

    Not sure why this is an issue for education but, in any case, backwards compatibility in Perl is legendarily good. There are plenty of production sites running Perl code that is decades old.

    I can see an argument for teaching CS using C or assembler (because they force you to understand what a computer does under the hood). I can see an argument for teaching CS using functional languages such as Haskell. I can see an argument for using Perl because it's possible to demonstrate a much wider range of programming styles than with Java. ("Whatever the question, the solution is an object" doesn't seem to me to be ideal in an educational context.)

    But I can't see offhand why Java is different in kind to any of the other languages in your list as far as suitability for education goes. It's not a very pure implementation of OO programming, it doesn't teach you anything about memory management. If you are not careful, you give students the impression that it's impossible to write code without an IDE. Java has its merits, its fans and its detractors. But it's not self-evidently The One Right Language to use to teach CS.

  • Re:mm (Score:3, Interesting)

    by jon3k ( 691256 ) on Sunday November 07, 2010 @12:58PM (#34155058)
    Wow, someone mod this guy up. Excuse me while I take my first serious look into Mono.

    (not sure if that sounded sarcastic - but I'm being serious I had no idea)
  • Re:Good. (Score:5, Interesting)

    by SanityInAnarchy ( 655584 ) <> on Sunday November 07, 2010 @03:19PM (#34156116) Journal

    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?


    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:

    struct foo * createFoo() {
      struct foo val;
      val.a = 1;
      val.b = 2;
      return &val;

    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:

    struct foo * createFoo() {
      struct foo *val = malloc(sizeof(struct foo));
      val->a = 1;
      val->b = 2;
      return val;

    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:

    class B: public A ...
    A a;
    B b;
    a = b; // whoops, the contents of b just got sliced!

    Or if I decide to use the heap...

    A *a = new A();
    a = new B(); // whoops, I just leaked the old value of a!

    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.

  • Another IMO worse example is MySQL AB themselves, before they got bought by Sun. They were going to do a support model, but the big problem is that the distributions already is taking all the support money. So they tried to make money by providing support on Windows. Obviously this was flawed, so eventually they tried to make some new features proprietary (in a different way than what Oracle is doing with Java), resulting in a backlash. MySQL was almost going to IPO with such a bad business model when they got bought by Sun.

"Atomic batteries to power, turbines to speed." -- Robin, The Boy Wonder