Chris Kranky

Recent Posts


What Oracle doesn’t like about Google

Chris KoehnckeChris Koehncke

download (2)

“We strongly recommend Java users consider alternatives to Chrome as soon as possible” those sound like fighting sounds and indeed Oracle doesn’t mince words if you try and install Java within Chrome. Mind you, Oracle didn’t throw the first punch, Google for “security” reasons is in the process of deprecating Netscape Plugin Application Programming Interface (NPAPI). Of course, NPAPI is from 1995 and a good funeral at sea is probably warranted at this stage. Nonetheless, this hasn’t left Oracle with any options for Java on Chrome.

While Google may not like Java, enterprises clearly do and there are thousands of legacy applications that are used daily by these companies, there are also thousands of programmers who know Java (Oracle says the number is 9 million but I’m only counting those still alive). These developers are quite happy to work with it and see continued employment in that field.  Legacy applications have long staying power as there is often little reason to re-work them if in fact, they’re still doing their job with the odd bit of TLC.

In short – Java ain’t going anywhere soon and this means users will need a browser that supports it, thus IT departments will lock down their users to a Microsoft browser, which means (ta da) that Enterprise WebRTC is going to be a Microsoft owned area for the moment. My university logic classes coming back to memory.

Oracle, on another side of their house, has been very supportive of WebRTC (they’ll be speaking at the forthcoming Kranky Geek Event) and in fact I’ve been impressed their enterprise communications offerings. Clearly they see browser based communications as being relevant.

Both Google and Microsoft are wooing developers to build solely on their platform. With both Oracle and Cisco tipping more towards Microsoft than Google, it will clearly be interesting to see how this plays out. I’d argue all to stop trying to pretend they’re cooperating (plus it’s a really slow process) and simply get their clan together and execute the best possible solution and let the best man win.

The risk of slow meandering is baffled users, no progress and the eventual introduction of an previously unknown 3rd party who simply shows up to steal the entire scene.

With all this mess, there is clearly room for a cloud based service provider to attempt to make life easier for all. The challenge will of course be in doing and doing it at a reasonable price. This is almost unavoidable as I don’t see the world of WebRTC compatibility coming together in the near or medium term.

An alternative is to simply ignore all of this, build for a single environment, try and force users to move to your chosen platform or simply give up that segment of the market. Doesn’t sound like a great investment pitch however, but probably the more reasonable one.

Comments 5
  • Philipp Hancke
    Posted on

    Philipp Hancke Philipp Hancke

    Author

    Mind you that disabling NPAPI is just an evil plan to push WebRTC according to http://www.linphone.org/technical-corner/linphone-web/overview


  • Amtpm
    Posted on

    Amtpm Amtpm

    Author

    Great article Chris. I disagree with “Google may not like Java”… most Android applications are written in Java-like language. I guess you are specifically speaking about the Java plugin in the browser, and in that particular case of Java, nobody like it, not even enterprises or Java developers, it’s just an outdated technology because there are good javascript frameworks to provide all the functionality without a plugin. Java for the backed-end, Java in the desktop (JavaFX), java embedded, etc. are different animals, with a healthy status and it’s important don’t confuse them.


  • Tsahi Levent-Levi
    Posted on

    Tsahi Levent-Levi Tsahi Levent-Levi

    Author

    Well… Oracle did hunt Android for royalties on using Java – and recently won in court for Android using Java APIs (ridiculous as it may seem).

    My guess is that those running Java in their enterprise also run ActiveX stuff, which in turn ties them down to Microsoft anyway. Leaving Java installable in Chrome or ditching it changes nothing in this regard. Java based enterprise software is also shifting towards HTML frontend views – the way of the world. It will take time to migrate there, but it is a trend that cannot be stopped nonetheless. Google probably decided it is time to take this plunge – same as it did with throwing Chrome Frame out the window last year.


  • Tim Panton
    Posted on

    Tim Panton Tim Panton

    Author

    Chris, you really have to separate java applets which run in the browser from all the other places Java is run.
    (most often server side).
    Java applets have had their day. there is (almost) nothing you can do in a java applet you can’t do better in html5.
    There is no excuse to still be running java applets for anything. I say this as an early adopter of applets – in fact my first applet (an SNMP monitor) is one of the few things you can’t do in HTML5.

    Java on the server side -or on the desktop – or running in IoT – or in Android is just as safe as the equivalent C++ program. The same can’t be said for java applets. Applets made a promise to sandbox the downloaded code so that it could not put the host browser at risk. This promise was repeatedly broken until the browser makers got fed up and started to pull the plug(in).

    Personally I wish this had happened sooner, since the continuing applet security flaws tarnish the reputation of the whole java platform. Oracle should have gone into damage limitation mode 4 years ago when they realised they couldn’t justify the costs of keeping the applet security promise – and deprecated applets themselves then and there.


  • Chris Koehncke
    Posted on

    Chris Koehncke Chris Koehncke

    Author

    The spark for this article was a recent experience. As part of another business, I have log on access to the US 800# routing system (SMS800) this is where ALL toll free numbers are assigned and controlled in how they are routed. It’s a quasi-gov’t type organization. The web application uses applets.

    SMS800 touts that the new web application is a vast improvement over the “previous IBM 3270 terminal emulation program” (I’m not kidding). With great fanfare, they needed me to update my version of Java (they were already several releases behind) as they were making “system improvements.”

    I don’t see applets much anymore, but reasoned that any large enterprise likely had one elderly one chugging along, working fine and likely with no $$$ allocated to update it. A single application can drag and entire organization back. Not surprising the telecom industry probably has plenty of applets left!


This site uses Akismet to reduce spam. Learn how your comment data is processed.