Chrome: Back to Firefox
Posted by James | Filed under Web
After a day of using Google Chrome, I’ve gone back to using Firefox 3. My biggest complaint with Chrome is the lack of extensions (although it has been noted that these could appear in future). I find it much harder to do my job without Firebug, Web Developer Toolbar, et al.
I was perturbed by Google’s EULA for the browser, giving Google potential rights to everything posted via the browser, however they have since modified this to alleviate users’ fears.
I’ve also been put off by a couple of issues I’ve read about/discovered:
- A flaw in the version of the WebKit browser engine Chrome uses allows an attacker to use a Java carpet-bombing attack, whereby a user can be tricked into launching an executable Java file.
- Typing ‘:%’ into Chrome’s omnibar crashes the app hard, taking all tabs down with it. So much for tab process isolation!
However, I love the V8 Javascript engine:
It achieves great performance by compiling JavaScript to native machine code, rather than to a bytecode. Thus, JavaScript applications will run at the speed of a compiled binary.
photo credit: themaxsons
Tags: Browsers, Chrome, google, java
Sun Worried Android Could Fracture Java
Posted by James | Filed under Code, Future, Mobile
Earlier this week, Google release programming tools for its new Android mobile phone software project, that shun the existing Sun standard-setting process in favour of a Google-specific variety. Sun responded on Wednesday by expressing concern that Google’s Android project could fragment Java into incompatible versions.
"Anything that creates a more diverse or fractured platform is not in [developers] best interests," said Rich Green, executive vice president of Sun’s software work, speaking to reporters at the Oracle OpenWorld conference in San Francisco. "The feedback from developers is, ‘Help us fix this.’"
He said Sun wants to work with Google to nip any problems in the bud. "We’re really interested in working with Google to make sure developers don’t end up with a fractured environment. We’re reaching out to Google and assuming they’ll be reaching out to us to ensure these platforms and APIs will be compatible so deployment on a wide variety of platforms will be possible," Green said.
Google unrepentant
Google didn’t adopt a terribly conciliatory tone in its response, arguing that when it comes to Java fragmentation, Android is the solution, not the problem.
"Google and the other members of the Open Handset Alliance are working to help solve fragmentation and supporting the developer community by creating Android, a mobile platform that responds to the needs of the developers, has the backing of industry leaders, and will be available as open source under a nonrestrictive license," Google said in a statement.
And asked whether it would discuss the issue with Sun, Google said, "We’re talking with industry leaders around the world about Android and the Open Handset Alliance but we’re not commenting on any of those discussions."
On Monday, Google indicated that it expects fellow members of the Open Handset Alliance phones who are working on the Android phones to help keep its variation of Java familiar to programmers.
Java today is governed by the Java Community Process, in which a number of companies vote on which features to accept into the Java system and create standard mechanisms called application programming interfaces (APIs) by which Java software can use those features. The extent to which Android will or must conform to these APIs is not clear.
For those who need a refresher on the Microsoft history here, the software company licensed Java back in the 1990s, way before it became open-source software. However, Microsoft added some features to Java that meant that it could work differently on Windows machines, a move Sun saw as undermining the "write once, run anywhere" promise of the technology.
Welcome to Jimmahdigital.com, personal blog of James Simm, Wigan/Manchester-based .Net developer.
