1 Reply Latest reply on Oct 8, 2009 9:00 AM by msakrejda

    Java to Flex: questions about technology stack for Flex-based apps.


      I've been a Java developer for the last 10 years and I'm trying to get into something new i..e Flex. Can someonne give me the typical stack they use

      when developing Flex 'applications'? For instance, I recently purchased a book called 'Flex On Spring'. The technologies used in this book follow:

      Flex, Spring, Hibernate, BlazeDS, Cairngorn, Tomcat and MySQL; this is a bit overwhelming since I only have experience with Spring and Hibernate (but not together). Is this stack typical? If not, what would people out there suggest taking on after getting the basics of Flex down?



        • 1. Re: Java to Flex: questions about technology stack for Flex-based apps.
          msakrejda Level 4

          I'm not sure about typical, but we use a Java / Flex stack as well (we provide a real-time analytics solution and use Flex for the front end). We're not currently using any frameworks in Flex, but we are looking at a re-architecture on top of Mate so that our core Flex infrastructure can also be used as a library and enable our customers to easily adapt our front end to their needs. From what I've seen so far, I like Mate a lot because it does not tie your business logic or your views to any particular framework (unlike Cairngorm or PureMVC), and it makes testing easy avoiding coupling between pieces of your application.


          In Java, we use Hibernate for persistence of our data (and security) model (with TruCQ, our core analytics engine that is essentially PostgreSQL + stream processing, serving as our persistent store for Hibernate), Tomcat as our servlet engine, and GraniteDS for AMF (we originally chose it because it was around pre-Blaze and we have found no reason to abandon it). We don't use an application platform like Spring.


          For AMF serialization, we let Granite generate our ActionScript classes from our Java classes. This works reasonably well, but we have found some bugs in Granite's generation (especially around interfaces). Also, beware mxmlc's "I don't see any references to this class, so you're probably not using it, so I'm not going to compile it in" linking behavior. This leads to cryptic errors during AMF calls and is a nightmare to debug. I really wish there was a way to explicitly tell the compiler "Yes, really, I want to link all classes in a given directory, even if it doesn't look like I'm using them."


          Overall, I'm pretty happy with the stack. Some parts of Spring may have made the Java side nicer, but overall, it would be too constricting for us. Granite's been pretty solid, and the maintainer, Franck Wolff, is very responsive (a minor Enum feature request I had was in by the next release). We've run into some minor hiccups with Hibernate, but they're definitely worth it relative to the features it provides. Tomcat and TruCQ (i.e., the PostgreSQL parts) have been pretty transparent and solid as far as our app is concerned.