Shrky's Blog: Linux

Thursday, January 14, 2010

Genuitec introduces MyEclipse IDE for the Spring Framework

By Paul Krill Paul Krill – Tue Jan 12, 8:00 am ET

San Francisco – Genuitec will introduce on Tuesday a version of its MyEclipse IDE for use with the popular open source Spring Framework for Java development, sans the backing of the major developer of the framework itself, SpringSource.

Also in the Spring vein Tuesday, SpringSource is discontinuing dm Server, a Java application server based on modular OSGi technology, as a commercial product. SpringSource is looking to farm out continued development of dm Server to the Eclipse Foundation.

Genuitec, for its part, is offering its $199-per-year MyEclipse for Spring IDE at the end of this month. Based on a collaboration between Genuitec and Skyway Software, MyEclipse for Spring offers MyEclipse functionality as well as scaffolding technology allowing access to editors for rapid creation of applications, Genuitec said. Application scaffolding generates large portions of the application using best practices, said Todd Williams, Genuitec vice president of technology.

The MVC (Model View Controller) scaffolding generates Spring MVC CRUD (Create Read Update Delete) applications from database tables, plain old Java objects and Java Persistence Architecture entities.

Currently, Spring developers can use the Genuitec MyEclipse Pro IDE for code-level development. "What's new [with the Spring-centered IDE] is a level above [Pro] that enables you to create entire tiers or connected tiers of the application," Williams said.

Spring technologies supported include "everything from their database persistence layer through their services layer through [Spring] Web Flow," which is Spring GUI technology, Williams said.

But Adam Fitzgerald, director of developer relations at SpringSource, was dismissive of the Genuitec product. He instead endorsed the free SpringSource Tool Suite as a mechanism for building Spring applications.

"I would recommend going with the tool that comes [from] the company that created Spring," Fitzgerald said. "[The suite] really is the most cutting-edge way to build Spring apps."

Also featured in the MyEclipse for Spring are project bootstrapping, for building Spring configuration files and adding Java libraries and Web resources. Enhanced development editors offeri simplified configuration of services, controllers and Spring Web Flow.

Meanwhile, SpringSource Tuesday will detail plans to hand off development of dm Server to Eclipse, but with SpringSource still participating in development and offering support subscriptions. The project under Eclipse jurisdiction would be called Virgo; the formal switchover to Eclipse is expected to take a couple of months, Fitzgerald said.

In explaining the move, Fitzgerald cited difficulties in getting mass adoption of OSGi at the enterprise level, even though OSGi offers greater control of system dependencies and modularization of application components.

"Certainly, dm Server was not as successfully adopted [as] something like [Apache] Tomcat or [SpringSource] tc Server," but there have been successful use cases, said Fitzgerald.

The move to Eclipse means project hosting, home pages, forums, and downloads will be at Eclipse.org. Licensing will change from a largely GPL license to Eclipse Public License.

The combination of the license change and community hosting at Eclipse.org opens the code base to a much broader set of users and developers, according to SpringSource. "We think this is an opportunity for opening up dm Server to really push OSGi to the forefront of enterprise Java development and make it more than just a tool for cutting edge companies," Fitzgerald said.

SpringSource Tuesday is unveiling dm Server 2.0; the planned 2.1 follow-up release would be developed by Eclipse. The Eclipse nickname for the project is Virgo.

Version 2.0 of dm Server features changes to how modules are provisioned; modules can be built across local and remote repositories. SpringSource debuted dm Server in Fall 2008.

This story, "Genuitec introduces MyEclipse IDE for the Spring Framework," was originally published at InfoWorld.com. Follow the latest developments in application development at InfoWorld.com.

Tuesday, January 12, 2010

An Android Developer's Top 10 Gripes

Jan 12, 2010, 18 :02 UTC
By Chris Haseman

1. Open Source

Leave it to Google to place all the code for their handset platform in the hands of the masses. Not only does this mean anyone can download and roll a new version of their phone firmware, but it also means absolutely any maker can roll its own Android device. I'm looking forward to an Android-powered toaster oven any day now. What's worse is Google knows how to protect valued code; Its Maps, Gmail, and Store applications aren't open source. Figuring out when it's okay to include one of those in your own application requires a crack legal team with a hotline to the EFF. This is the most benign on this list, and it's only here because now everyone and their brother is going to make a new "Android-powered" device.

2. The Tyranny of the Activity

Through the Activity, Android forces developers to build apps in smaller, bite-sized chunks. For example, in their sample text editor code, they have one Activity for picking from a list of editable files and another Activity for actually editing a file's contents. Android also encourages developers to communicate among their Activities using Intents (more on why I hate those later).

This design would be dandy for mobile software except for one thing: exactly no one else works this way. J2ME, the iPhone, BREW, and Blackberry all work with the notion of a centralized application object (The Blackberry/J2ME Midlet or Brew's IApplet). Android, by contrast, pushes you to design everything as small, self-contained mini-applications. This decision leads to some really interesting behaviors. By default, for example, when a user rotates the screen or pushes the keyboard out, Android destroys the current Activity and then recreates it.

In the end, professional mobile developers are left with two options:

They can design their software on other platforms to use the Activity/Intent model so that Android ports easily.
They can hack, slash, burn, and duct-tape Android into behaving like every other mobile platform does.

I suspect you, dear reader, can guess which direction this grumpy author has had to take.

3. Device Debugging

Back in my day (and by "in my day," I mean two years ago), debugging on the handset was a trying proposition at best. I've written my own logging systems for J2ME, relied on beep codes to tell me if code had been hit under Brew, and lost sleep wondering if a particular log line was really the last log line to be rolled over before a crash. Google, curse their cotton socks, has quite literally taken a process that used to involve hours of work and reduced it to simply pressing F11. Not only is it straightforward and easy to use, but it also works on every platform out there (Mac, PC, and Linux).

Why do I hate this extremely useful tool? I hate it because it makes about 40% of my debugging skills nearly useless! Next thing you know, Google will enable anyone to design a mobile app UI using nothing but XML... oh wait.

4. Applications Never, Ever Quit

Once an application starts on Android, it never quits—ever. Your applications might be unloaded in the background, but your icon stays in the list of running tasks (in case your application is ever spun up). This strange yet central architecture decision makes for some interesting software bugs and necessitates some quirky application design workarounds. Further, it leads to "Process Killer" applications and to what one of my college textbooks correctly dubbed "The Developer Cooperative."

5. The Developer Cooperative

Remember back to college and that Economics 101 class you didn't take. In that mythical class, they might have talked about a term called the tragedy of the commons: the misuse and overuse of a collectively owned resource. In the case of Android, that common resource is the memory, processor, and battery life of the handset. The tragedy is that any application, while in the background, can use any amount of resources. This is why performance and battery life on Android handsets can be so unstable.

Google just expects programmers to use fore and background cycles wisely, which most of us do, right? However, one careless developer can single-handedly demolish a weekend's worth of battery power in a matter of hours.

6. Java—Thanks, But I'll Take It from Here

The Java language, a very powerful tool, is on this list for two reasons: It's big, and it can be very hard to optimize. As a programmer, it makes me feel like I'm getting a very slow lobotomy. While it might speed time to market by freeing us from chasing down heap corruptions and memory leaks (two of my least favorite tasks), it can make it nearly impossible to, say, write an anti-aliased font library that renders in a reasonable amount of time. Sure, a developer can write custom libraries in C with their NDK, but now we're debugging two languages instead of one.

7. "Intents"

This is a technical writer's third-worst grammatical nightmare. An Intent in Android is the class used to communicate between Activities, Services, or Content Providers. Intent is a noun that commonly also works as an adjective, but never, ever, should it be plural (And "for all intents and purposes" doesn't count. It's pretty much a colloquialism). This has led to some very awkward conversations with my copy editors in the past year or two. Every time I use Intents in a sentence (say, right now for example), I'm left feeling like my elementary school grammar teacher is doing summersaults in her grave (Although, to be fair, she probably does the same thing every time I misuse a comma).

8. Platform Fragmentation

It's not just a buzzword, it's a real problem. Quite possibly it's the problem that could sink the Android platform as a whole. While Android's design might be geared towards the hobbyist developer, having to buy 50 handsets and validate your mobile app on all of them is real ordeal for the pros. As more devices with more screen sizes arrive on the market, maintaining an application is going to be a more and more exhausting process. This process won't be made any easier as Google's already loose grasp on the platform as a whole continues to loosen.

Worse, there really aren't any easy solutions for Google to implement. As Android becomes more popular, each OEM will manufacture devices with their own quirks, bugs, and oddities. Which, unless Google counters with a liberal dose of the forbidden 'Evil' word, is going to make this platform impossible to fully support for all but the most dedicated hobbyist or well paid professional.

9. A General Lack of 'Evilness'

Sure, Google is "open;" they publish all their source code. (Except the bits that power the giant money press hidden somewhere in their Mountain View office.) OEMs may have to clear a compliance hurdle in order to get Maps, Store, and Gmail apps, but either the hurdle isn't high enough or Google isn't very good at keeping OEMs from going under it. This lack of an iron grip (which both Apple and Verizon have effectively, if obnoxiously, employed on mobile developers) is exactly what is leading to the current and future fragmentation of the platform. Who knows, perhaps NSTL will swoop in to the rescue and start regulating app developers. (Anyone who's developed for BREW will know no greater fear than hearing those four letters.)

Google, with luck, will learn when it's good to be evil and when it isn't... but there's always that pesky slippery slope.

10. Hardware, Hardware, Hardware

The current crop of Android hardware, for lack of a better word, sucks. It's come a long way since the G1, but it's nowhere near the iPhone. Further, handset OEMs seem to be chasing the iPhone rather than making their own design decisions. The Droid was a step in the right direction, and the Nexus One looks to be another big step towards real hardware viability. Frankly, I'm tired of my smug iPhone developer friends lording their platform over mine. Further, I'm tired of them being right.

That's my list. I've checked it twice. After all's said and done, I really must admit that Android, despite its relatively few flaws, is one of my favorite platforms to work with. Quite honestly, if my complaint about how the word 'Intent' makes for awkward grammatical constructions ranks in the top 10, I'd say the Android platform is doing pretty well for itself.

Shrky's Blog