Feeds

Fat or thin: an insider's view on Java's destiny

Evolution, not revolution

Remote control for virtualized desktops

QCon I was fortunate to be a member of this week's QCon panel billed as the event where "influential leaders of the software development community" would debate Java's future.

I see Java's evolution more in terms of the overall platform, not just the language. The platform improvements that I look forward to most include simplification of the deployment of the Java platform, like what we're doing with the upcoming Update N release. I said I would also like to see further improvements in the platform libraries, to offer increased functionality and easier programming paradigms.

There was a response to this point that maybe we should be taking things out of the platform instead of adding them into it.

Some on the panel - I will claim this was a small minority, but I obviously have a bias here - would like to see deprecated or unused functionality stripped out of the platform. But the other side, on which I count myself, sees the platform as a clearly defined entity: Java is what it is and you cannot now start taking things out of it. If you do so, you will break existing applications.

So the issue boils down to whether we should create a new platform, which no longer has these dependencies. This decision then comes down to a question of resources: should we spend limited time trying to improve what we have or trying to create something new?

I personally feel Java still has a long life, so it is worth continuing to work on and improve what we have. And given limited time and resources, it seems like we'll do better by focusing the efforts on that problem for now, rather than giving up and starting afresh.

Having said that, if and when we (meaning Sun Microsystems and the larger community) have time, it would certainly be worth thinking about some future platform as well.

Chet is an architect in the Java Client Group of Sun Microsystems, and spends most of his time working on graphics and performance issues. He is also co-author of Filthy Rich Clients: Developing Animated and Graphical Effects for Desktop Java Applications.

Top 5 reasons to deploy VMware with Tegile

More from The Register

next story
PEAK APPLE: iOS 8 is least popular Cupertino mobile OS in all of HUMAN HISTORY
'Nerd release' finally staggers past 50 per cent adoption
Microsoft to bake Skype into IE, without plugins
Redmond thinks the Object Real-Time Communications API for WebRTC is ready to roll
Microsoft promises Windows 10 will mean two-factor auth for all
Sneak peek at security features Redmond's baking into new OS
Mozilla: Spidermonkey ATE Apple's JavaScriptCore, THRASHED Google V8
Moz man claims the win on rivals' own benchmarks
FTDI yanks chip-bricking driver from Windows Update, vows to fight on
Next driver to battle fake chips with 'non-invasive' methods
DEATH by PowerPoint: Microsoft warns of 0-day attack hidden in slides
Might put out patch in update, might chuck it out sooner
Ubuntu 14.10 tries pulling a Steve Ballmer on cloudy offerings
Oi, Windows, centOS and openSUSE – behave, we're all friends here
Was ist das? Eine neue Suse Linux Enterprise? Ausgezeichnet!
Version 12 first major-number Suse release since 2009
prev story

Whitepapers

Cloud and hybrid-cloud data protection for VMware
Learn how quick and easy it is to configure backups and perform restores for VMware environments.
Forging a new future with identity relationship management
Learn about ForgeRock's next generation IRM platform and how it is designed to empower CEOS's and enterprises to engage with consumers.
High Performance for All
While HPC is not new, it has traditionally been seen as a specialist area – is it now geared up to meet more mainstream requirements?
Saudi Petroleum chooses Tegile storage solution
A storage solution that addresses company growth and performance for business-critical applications of caseware archive and search along with other key operational systems.
The hidden costs of self-signed SSL certificates
Exploring the true TCO for self-signed SSL certificates, including a side-by-side comparison of a self-signed architecture versus working with a third-party SSL vendor.