Tag Archives: java

google, java, oracle, search, Sun

Oracle still foisting Google Toolbar on Java users

1 Comment

Oracle may be suing Google over its use of Java in Android; but the company is still happy to take the search giant’s cash in exchange for foisting the Google Toolbar on users who carelessly click Next when updating their Java installation on Windows. If they do, the Toolbar is installed by default.

image

This is poor practice for several reasons. It is annoying and disrespectful to the user, particularly when the same dialog has been passed many times before, bad for performance, bad for security.

Sun at least had the excuse that it needed whatever income it could get.

I know certain other companies do this as well with their free runtimes – Adobe is one – and I like it just as little. However, as far as I can recall Adobe only adds foistware on a new install, not with semi-automatic updates.

google, java, mobile, oracle, professional, Sun

Apple not Android is killing client-side Java – so why is Oracle suing Google?

3 Comments

Oracle is suing Google over Java in Android; the Register has a link to the complaint itself which lists seven patents which Oracle claims Google has infringed. There is also a further clause which says Google has infringed copyright in the:

code, specifications, documentation and other materials) that is copyrightable subject matter

and that it is not possible for a device manufacturer to create an Android device without infringing Oracle’s copyrights. Oracle is demanding stern penalties including destruction of all infringing copies – I presume this might mean destruction of all Android devices, though as we all know lawyers routinely demand more than they expect to win, as a negotiating position.

But isn’t Java open source? It is; but licensing is not simple, and “open source” does not mean “non-copyright”. You can read the Java open source licensing statements here. I am not a licensing expert; but one of the key issues with Google’s use of Java in Android is that it is not quite Java. Oracle’s complaint says:

Google’s Android competes with Oracle America’s Java as an operating system software platform for cellular telephones and other mobile devices. The Android operating system software “stack” consists of Java applications running on a Java-based object-oriented application framework, and core libraries running on a “Dalvik” virtual machine (VM) that features just-in-time (JIT) compilation.

Note that Oracle says “Java-based”. Binaries compiled for Android will not run on other JVM implementations. I am no expert on open source licensing; but if Google is using Java in ways that fall outside what is covered by the open source license, then that license does not apply.

Despite the above, I have no idea whether Oracle’s case has legal merit. It is interesting though that Oracle is choosing to pursue Google; and I have some sympathy given that Java’s unique feature has always been interoperability and cross-platform, which Android seems to break to some extent.

James Gosling’s post on the subject is relevant:

When Google came to us with their thoughts on cellphones, one of their core principles was making the platform free to handset providers. They had very weak notions of interoperability, which, given our history, we strongly objected to. Android has pretty much played out the way that we feared: there is enough fragmentation among Android handsets to significantly restrict the freedom of software developers.

though he adds:

Don’t interpret any of my comments as support for Oracle’s suit. There are no guiltless parties with white hats in this little drama. This skirmish isn’t much about patents or principles or programming languages. The suit is far more about ego, money and power.

The official approach to Java on devices is Java ME; and Java ME guys like Hinkmond Wong hate Android accordingly:

Heck, forget taking the top 10,000 apps, take the top Android 10 apps and try running all of them on every single Android device out there. Have you learned nothing at all from Java ME technology, Android? Even in our current state in Java ME, we are nowhere as fragmented as the last 5 Android releases in 12 months (1.5, 1.6, 2.0, 2.1 and recently 2.2).

Fair enough; but it is also obvious that Android has revived interest in client-side Java in a way that Sun failed to do despite years of trying. The enemy of client-side Java is not Android, but rather Apple: there’s no sign of Java on iPhone or iPad. Apple’s efforts have killed the notion of Java everywhere, given the importance of Apple’s mobile platform. Java needs Android, which makes this lawsuit a surprising one.

But what does Oracle want? Just the money? Or to force Google into a more interoperable implementation, for the benefit of the wider Java platform? Or to disrupt Android as a favour to Apple?

Anyone’s guess at the moment. I wonder if Google wishes it had acquired Sun when it had the chance?

Note: along with the links above, I like the posts on this subject from Redmonk’s Stephen O’Grady and Mono guy Miguel de Icaza.

java, open source, oracle, Sun

Oracle breaks, then mends Eclipse with new Java build

Somewhere in the JVM (Java Virtual Machine) is a company field, identifying the source of the JVM. Following its acquisition of Sun, Oracle reasonably enough changed the field in version 1.6.0_21 to reference Oracle rather than Sun.

Unfortunately some applications use the field to vary some command-line arguments according to which JVM is in use. “If Sun JVM do this, if IBM JVM do that.” Eclipse was one of these, so Oracle’s update caused “crashing and freezing issues” for Windows users. There is more information here.

When the problem was discovered, Oracle issued an update that reverts the change. Hence Ian Skerrett at Eclipse has posted Oracle Demostrates Great Community Support and Fixes Eclipse.

The issue demonstrates that almost any software change can have unintended consequences, especially if the software is an application runtime.

Should Oracle have checked for this before release? Possibly; though it cannot check every build against every application on every platform. Still, everyone has done the right thing here.

Will the JVM now say Sun for ever? I would think for some time to come, bearing in mind that companies may standardise on specific Eclipse builds and stay on them for an extended period.

adobe, apple, flash, google, java

Google advances its platform – or should that be advances the Web?

Yesterday Google presented its latest platform innovations at the Google I/O conference in San Francisco. Its strategy is relatively clear: to improve web applications so that you can do everything you need in the browser. The client pieces are HTML 5 – though bear in mind that this is not yet a fixed standard – and especially the Chrome browser, whether installed on a traditional operating system or delivered on a Chrome OS device.

Chrome has always had lightning-fast JavaScript. We’re now seeing other pieces in the Chrome-as-application-platform story, including:

Integrated Adobe Flash

The  Native Client for secure native code, typically coded in C/C++, running in the browser

Announced yesterday, the WebM video and audio format. This includes VP8, acquired with On2 Technologies and now open source, as well as Vorbis audio and the Matroska multimedia container.

The Chrome Web Store, also announced yesterday, which will be an App Store equivalent for web applications.

image

Web Store apps are “installable” which may mean little more than a shortcut in the browser, similar to a bookmark or favourite link. However, there will be a payment infrastructure as well as ratings and user reviews.

Serverless apps. This is another aspect to the Web Store. A Web Store app can be designed to run offline, with all the necessary HTML and JavaScript bundled into the .crx format used by the store. Google calls these Serverless apps, and in many ways the concept is similar to that in Palm’s WebOS – HTML and JavaScript applications that run locally. This is interesting for Chrome OS as it makes it easy to create applications that work offline.

The Google Font API and Directory. This is big news. Most of us stick to the same old web fonts, or use images, or a plug-in like Flash or PDF, for going beyond the standard browser fonts. Using Google’s API, it is easy to include any font in the new directory, with nothing more than a specially crafted CSS link.

The Google Font API hides a lot of complexity behind the scenes. Google’s serving infrastructure takes care of converting the font into a format compatible with any modern browser (including Internet Explorer 6 and up), sends just the styles and weights you select, and the font files and CSS are tuned and optimized for web serving.

On the server side, there is Google App Engine for Business. Google is cooperating with VMware so that you can host Spring applications on its web application platform, App Engine. Spring Roo, a rapid application development tool for Spring, has been integrated with Google Web Toolkit (GWT) to make it easy to build browser-hosted clients for Spring applications. GWT lets you code in Java, but run in JavaScript. Using Spring gives you a choice of where to host your application: on-premise, on App Engine, on the Salesforce.com platform with VMforce, or on another platform such as Amazon EC2.

Spring’s Rod Johnson explains the goals here:

Until the announcement of VMforce and today’s announcement, Java developers lacked a PaaS destination to which they could easily deploy their applications. This was an important gap that threatened to become a danger to the long-term future of Java. I’m delighted that VMware/SpringSource is leading the charge to fill this gap.

Another feature worth highlighting is SQL for App Engine:

SQL database support on App Engine gives enterprise developers access to the full capabilities of a dedicated relational database, without the headache of managing it.

though Google adds that this is a “premium service” which may come at extra cost. According to the roadmap, this is coming in Q3 2010.

While there is a lot to take in, there is a consistent theme: making the web and browser platform more capable, and making desktop applications and on-premise servers less necessary.

Whereas Apple aims to lock us into its devices and App Store, Google’s approach is more open. It is happy to give away stuff like the WebM multimedia project and the Font API in order to improve the Web overall; though of course every time we use the Font API Google can record the traffic on our site and mine that data if it chooses to do so. It is in line with the strategy unveiled at the Mobile World Congress in February: a little bit of everything you do. Google will take its cut of any Web Store sales. What is Web and what is Google is deliberately blurred.

I still think that the forthcoming Chrome OS is an amazing experiment, and the new offline application support announced yesterday makes sense as an alternative to traditional local applications.

A good day for Adobe and Flash, or a bad one? Adobe’s Kevin Lynch demonstrated new HTML 5 capabilities in Dreamweaver, via an add-on pack. As expected, Adobe is becoming a little less Flash-focused in its PR. Google’s emerging platform is a tool opportunity for Adobe. Still, that is a lesser role than establishing Flash as the universal client, a possibility which Apple seems to have killed. Google is supporting Flash, of course, by building it into Chrome, but at the same time things like WebM, Font API, HTML5, and Native Client (shown as the natural client platform for browser-hosted games) undermine the need for Flash.

Apple is a problem for Google too. Will native client ever work on iPhone or iPad? WebM? The big question – who will marginalise whom?

.net, adobe, flash, java, microsoft

Java versus C/C++ performance – which is really faster?

9 Comments

Cliff Click of Azul Systems has an excellent post on Java vs C/C++ performance:

Is Java faster than C/C++?  The short answer is: it depends.

He then presents three categories of cases: the first C/C++ beats Java, the second where Java beats C/C++, and the third and longest, where C/C++ proponents claim Java is slower but in reality it is not.

My quick summary: there are few cases where Java (or C#) is so much slower that it matters, save for one big issue which Click mentions early on – start-up time:

Flash games beat Java games mostly because it took 30+sec to load the JVM from disk… and so now the web-game developer community has settled on Flash as the standard (and it still takes 10+sec to load the JVM).

Start-up time makes a big difference to usability, for reasons which I cannot entirely explain. Just for fun, I’ve been running Microsoft Office 95 in a virtual instance of Windows XP recently, and the fact that Word 95 loads in a blink makes it feel much faster than Word 2010, which takes 5-10 seconds on first load, even though the productivity difference must be negligible.

If I had to theorise about this, I’d say it is to do with the way humans learn from experience. We don’t like waiting, and if an application take a while to start then part of our brain tells us to avoid it in future. We override that instinct when it is an app we need to run, but it contributes to a negative impression.

The opposite is also true. If an application starts instantly – I mean to the point where we can use it, not just a splash screen – it contributes to a positive impression and we are more inclined to use it in future.

Incidentally, Click thinks that Java is generally faster than C#, though he adds that he is “not able to give C# a fair treatment” because he does not track it closely.

.net, adobe, apple, iphone, microsoft, mobile, oracle, software development

Building for multiple mobile platforms with one codebase

6 Comments

Individuals may have strong opinions about the merits of Apple iPhone versus Google Android versus the struggling Palm WebOS versus the not-yet Windows Phone 7; but sit them round a table to discuss app strategy and those diverse platforms change from a debating point to a problem. Presuming a web app won’t cut it, how do you target all those devices without the unreasonable expense and complication of managing multiple projects? The native languages are all different; Objective-C for iPhone and iPad, Java for Android and RIM BlackBerry, JavaScript for WebOS, C# for Windows Phone 7.

There are three possibilities that come to mind. One is that all the platforms will eventually allow you to write in C or C++, making this the unifying language, though you still have some fancy footwork to do overcoming library differences. Android now allows this via the NDK, and Palm via the PDK. There is currently no alternative to Java for Blackberry, and Microsoft says native code won’t be possible on Windows Phone 7, but well, you never know.

The second is Adobe Flash. This is an interesting one, because Apple prohibits Flash on the iPhone, but Adobe has a Packager for iPhone that builds native iPhone apps from Flash projects. Another issue is that although Flash is available or promised for all the main non-Apple devices – Apple’s gift of a selling point to its rivals – it is not Flash alone that does what it needed, but AIR, the “desktop” or out-of-browser runtime. This has been previewed for Android and promised for other devices including Blackberry. AIR for Windows Phone 7? Maybe, though I’ve not seen it mentioned.

A third idea is a clever framework that does the necessary cross-compilation under the covers. This cannot depend on deploying a runtime, nor compiling to native code, because these approaches are blocked by some mobile platforms. Rhomobile has the Rhodes framework, where you code your app in HTML and Ruby and compile for devices including iPhone, Windows Mobile, RIM Blackberry, Symbian, and Android. Rhodes includes an MVC (Model View Controller) framework and an ORM (Object Relational Mapper) to wrap database access. There is also a RhoSync server component to enable offline data with synchronisation back to the server when reconnected; and the RhoHub hosted IDE for buildings apps with a web browser.

Rhomobile tells me that Palm WebOS support is in the works. They also promise Windows Phone 7 support, which intrigued me because Rhodes says it compiles to “true native device applications”. Has Rhomobile gotten round Microsoft’s opposition to native code? Apparently not; VP Rob McMillen eventually told me that this will mean a .NET IL (intermediate language) implementation.

The Rhomobile approach reminds me of AppForge, a company which produced the well-regarded Crossfire add-on for Visual Studio and compiled Visual Basic to a wide variety of mobile platforms. Unfortunately AppForge was acquired by Oracle, and its new owners showed callous disregard for existing customers. Not only did development cease; it also became impossible to renew existing licenses. Thanks to an activation component, that also blocked new deployment of existing applications – every developer’s nightmare.

That said, there is no activation requirement for Rhodes that I know of, and the framework is open source, so I don’t mean to suggest it will suffer a similar fate.

What about Java? On the face of it, Java should be ideal, since multi-device support is what it was designed for. It is a measure of how far Java has fallen that we hear far more about the lack of Flash on the iPhone, than the lack of Java. Microsoft says yes to Flash on Windows Phone 7, though not on first release, but nothing about Java.

Java as a mobile runtime needs a strong dose of lobbying and evangelism from its new stewards Oracle if it is not to fall by the wayside in this context. Hmm, AppForge.

adobe, apple, flash, mobile

Flash developers are now mobile developers

1 Comment

Adobe’s announcement of AIR for mobile today at the Mobile World Congress means that any Flash or Flex developer can compile an AIR application that will run on a supported mobile device. I understand that AIR for mobile is a subset of desktop AIR, but does include Flash Player 10.1, local database support with SQLite, and access to local storage, so it is not lacking in capability. Apparently it will be possible to have a single .air file that will run across desktop and devices, perhaps with conditional code to account for differences in device capability. Some features, such as multitouch and accelerometer support, are more likely to be found on a mobile device than on a desktop, though things like screen size and available storage will be more constrained.

Until now it has been Java that comes closest to providing a common runtime across desktop and devices. Flash promises a more consistent runtime as well as stronger multimedia and graphics capability. Thanks to Apple, the app store concept is now well established and AIR applications fit well with this model, though not exclusively so. It will also be possible to deploy AIR applications from your own web site. I think there will be considerable interest and take-up for AIR on mobile.

Initial support will be for Google’s Android OS, with others to follow – with the exception so far being Apple.

This is where it gets interesting. Whereas Flash in the browser is blocked on Apple iPhone and (as far as we know so far) iPad, Adobe has a native compilation option for Flash applications targeting these devices, preserving some kind of deployment story. Clearly from Adobe’s perspective it would be better and easier if Apple allowed the AIR runtime onto the device. It’s less clear that Apple device users are really losing out though, and there is even an argument that they benefit, if you think that native code is a better solution for a mobile device.

In other words, the introduction of AIR for mobile does not really put any pressure on Apple, since Adobe has already come up with a good alternative. There may be some indirect pressure, since growing use of the Flash runtime outside the browser may also increase its significance within the browser.

A lot hinges on the quality of the mobile AIR runtime, particularly in respect of memory usage, which has tended to be greedy in desktop AIR.

.net, agile, google, internet, java, javascript, software, software development, web authoring

Technology trends: Silverlight, Flex little use says Thoughtworks as it Goes Google

1 Comment

Today Martin Fowler at Thoughtworks tweeted a link to the just-published Thoughtworks Technology Radar [pdf] paper, which aims to “help decision makers understand emerging technologies and trends that affect the market today”.

It is a good read, as you would expect from Thoughtworks, a software development company with a bias towards Agile methodology and a formidable reputation.

The authors divide technology into four segments, from Hold – which means steer clear for the time being – to Adopt, ready for prime time. In between are Assess and Trial.

I was interested to see that Thoughtworks is ready to stop supporting IE6 and that ASP.NET MVC is regarded as ready to use now. So is Apple iPhone as a client platform, with Android not far behind (Trial).

Thoughtworks is also now contemplating Java language end of life (Assess), but remains enthusiastic about the JVM as a platform (Adopt), and about Javascript as a first class language (also Adopt). C# 4.0 wins praise for its new dynamic features and pace of development in general.

Losers? I was struck by how cool Thoughtworks is towards Rich Internet Applications (Adobe Flash and Microsoft Silverlight):

Our position on Rich Internet Applications has changed over the past year. Experience has shown that platforms such as Silverlight, Flex and JavaFX may be useful for rich visualizations of data but provide few benefits over simpler web applications.

The team has even less interest in Microsoft’s Internet Explorer – even IE8 is a concern with regard to web standards – whereas Firefox lies at the heart of the Adopt bullet.

In the tools area, Thoughtworks is moving away from Subversion and towards distributed version control systems (Git, Mercurial).

Finally, Thoughtworks is Going Google:

At the start of October, ThoughtWorks became a customer of Google Apps. Although we have heard a wide range of opinions about the user experience offered by Google Mail, Calendar and Documents, the general consensus is that our largely consultant workforce is happy with the move. The next step that we as a company are looking to embrace is Google as a corporate platform beyond the standard Google Apps; in particular we are evaluating the use of Google App Engine for a number of internal systems initiatives.

A thought-provoking paper which makes more sense to me than the innumerable Gartner Magic Quadrants; I’d encourage you to read the whole paper (only 8 pages) and not to be content with my highlights.