This post originated from an RSS feed registered with Java Buzz
by Fred Grott.
Original Post: Flashlite and ServerSide Headache II
Feed Title: ShareMe Technologies LLC-The Mobile Future
Feed URL: http://www.jroller.com/shareme/feed/entries/rss
Feed Description: A Weblog about Java programming and digital convergence on mobile devices in such areas as P2P and collaborative technology.
HEADACHE AHEAD WARNING! Part of the problem of choice a server side solution for flashlite delivery other than no benchmarks for Apollo, OpenLAszlo4, and haxe is the complexity of of tool integration. This is nothing against those tools, I am glad they are in fact there for me to use.
With Apollo and OpenLazslo4 because the as and other classes are in java we can use code generation, bytecode manipulation and et to accomplish great things. For example, XDoclet(Eclipse doclipse) or FreeMarker(Eclipse Freemarker IDE) for code generation. You would than of course use something like J2AS and you could even switch between as2 to as3 by switching compilers.
And of course because you might have bytecode outliner as a plugin in Eclipse and a few other tools you could compose PMD rules just for java2as flashlite optimization.
With haxe even with the Eclipse HXDT plugin you do not have these options because haxe is in fact a different bytecode. To be fair the haxe users, developers, and some students are in fact proposing some Google Summer of Code projects for 2007 to address these issues.
Thus, it comes down to which trade-offs you can live with for a particular project. Of course the optimization of flashlite code probably is a common problem to all 3 RIA engine solutions. Basically, you do want access to bytecode manipulation tools to come up with optimization code workflows.
Previous Topic
