Ubuntu to get open-source Java heart implant
Sun and SpringSource possible donors
OSCON: Exclusive Canonical has been in talks with Sun Microsystems and SpringSource to support one of their open source Java application server stacks in the Ubuntu core, to increase Ubuntu's enterprise adoption.
Canonical told The Reg that it is in the process of selecting which open source Java Enterprise Edition (Java EE) framework to make available in the main part of its popular Linux distro. Sun's streamlined GlassFish 3.0 and the modular Application Platform are contenders.
Canonical's Ubuntu server engineering manager Rick Clark called it: "Very, very important to us to get a full Java stack out of the box."
It's unclear when a decision will be taken, but Canonical's Ubuntu server team said implementation is unlikely in Ubuntu 8.10, which is due in October. Users will have to content themselves with Apache's Tomcat 6.0, which Canonical said would meet 70 per cent of needs, by providing a serverlet container.
Those wanting full Java EE "will have to wait a little," Canonical's Ubuntu server manager Nick Barcet told us.
While no decision's yet been taken and Canonical was not giving anything away, The Reg was left with a sneaking suspicion Canonical will go for GlassFish.
Ubuntu's seeing massive uptake as part of a stack with Sun's MySQL database. Also, Sun has certified Ubuntu on Intel and Sparc systems from Sun and part of the Ubuntu 8.04 LTS - Hardy Heron - multiverse. There was a sense talks with SpringSource had wrapped up without result, although Application Platform was - by last count - still in beta.
Ubuntu's proving popular in one- and two-U rackable servers and blades running file, database, mail and web servers. Enterprise Java, though, would help Ubuntu power applications like online banking. Ultimately, Canonical wants big application providers SAP and Oracle to certify on Ubuntu.
Presently, you download your copy of Ubuntu and your Java application server from different locations. Also, there is no formal support for Java in the hand-selected list of components that comprise the main part of Ubuntu. Both facts make it harder for corporates to use Ubuntu in mission-critical, business applications.
"There's a separation between the distro and the Java," Clark said. "You install the Java that comes with [IBM's] WebSphere or [BEA/Oracle's] WebLogic. Wouldn't it be nice to supply one package that comes fully supported?"
Canonical is being deliberately choosy on the Java EE platform it supports. Canonical believes GlassFish 3.0 and Application Platform would be simpler to maintain than other open-source application servers, such as Apache's Geronimo.
The problem is most application servers pull in a very large number of packaged features as standard in the form of Jar files through Maven. This makes them swell in size, and they're difficult to maintain from the perspective of features and licensing. That's a problem for a distro like Ubuntu that owes its growth to ease of use and stability, and also a problem for the integrated Launchpad platform that's used to find, fix and report common bugs in Ubuntu and more than 6,000 open source projects.
GlassFish and SpringSource have been architected to pull in a relatively small number of Jar files: Glassfish 3.0 consumes up to 40 compared to Geronimo's 280. Application Platform combines the enterprise Java Spring Framework, Tomcat and OSGi specs to deliver a modular architecture with a smaller footprint than regular Java EE.®
Every JAVA project I've been involved with has been:
Painfully slow in development.
Painfully wasteful of resources.
Painfully slow in action.
Painfully unable to scale up.
And we want to run this awful stuff why? Java apps can instantly turn a screaming fast ferrari into a yugo with a bad clutch. My motto is anything but Java (ABJ all the way).
This ranks right up there with Who gives a sh.....!
PHP makes me want to scoop my eyes out with a stick
PHP is, quite simply, a crawling horror. It was conceived as a filthy hack by people who couldn't get their heads around PERL* but who somehow felt that, despite this, they were competent to specify a language and write a parser.
They were wrong.
Unfortunately for the rest of us, there were lots of other people in a similar position, and they flocked to it, as web developers are wont to do with whatever the trendy 'next big thing' happens to be. But as any fule kno (and any freetard will repeatedly explain to you until you bludgeon them to death with something), just because something achieves widespread adoption and market domination doesn't mean that it's any good.
If PHP were a song, it would be the bastard child of two bottles of thunderbird and a rhyming dictionary.
Really, it's that bad.
*HINT: This is why the PHP syntax is almost, but not entirely, quite unlike PERL.
PHP vs Java
I program in both, and I like (and hate sometimes) both languages. They're very different languages, with different background and design intent. It's the old apples vs oranges thing...
PHP -> interpreted scripted language derived from Perl for dynamic web pages.
+ Fast development, large library, plenty of libs, quick to learn, free.
- namespace is a nightmare as someone pointed out earlier (getting bit better since v5 though), doesn't scale too well, though in its context of CGI not a huge problem (load balancers upfront, database pool on back) unless you're the size of yahoo/google/etc.
Java-> compiled to byte code, c++ influence, orig. for embeded systems, w/ sandbox for web applets.
+ Straightforward to learn if you've a C/C++ background, no pointer headaches, "complie once run anywhere"tm, large sandard lib, plenty of free code avail., free.
- Bloated VM and standard lib these days, verbose factory get instance create object stuff sometimes, slower development cycle, requires more resources.
I _could_ write a jabber client in PHP, and use Java to pull data from a mySQL DB and display it on a web page, but I'm not going to :-)
My ideal language would be Pascal with OOP and automagic GC, but that's just me :-)