After a lengthy Java developer job search...

[asookazian]

I received and accepted an offer this week with a small company in SoCal doing emergency notification systems.  They are looking into using JSF and Silverlight in the future (interesting combo, no?)

So this thread is a job-related thread on some basic observations I made based on job requirements for several IT Java shops in SoCal.

Very, very few shops are actually currently using JSF, RichFaces or EJB3.  My current employer seems to be one of the very few (we are Fortune 500 btw).  The vast majority seem to be using Spring with Spring MVC or JSP and JDBC/sprocs/Hibernate.  But typically Spring/Hibernate.

Accordingly, if there are very few adoptees of JSF and EJB3, nobody will be using Seam in production envmts.

So now I have realized the true root-cause of the lack of Seam adoption and RichFaces adoption in the industry:  very few shops are using JSF and/or EJB3.  The main culprit really being JSF as EJB3 is not required for Seam app development.

Seam is an integration framework (originally) designed to bridge JSF and EJB3 and improve/extend JEE 5 generally although now you can use GWT, Flex, Wicket, etc. for the presentation layer.  And we have known from the beginning that EJB3 components are not required (you can use plain POJOs as your Seam backing, business, DAO, etc. components).

I also noticed that Flex is very popular but Wicket, Tapestry and Struts 2 are not.

Good luck if you're in the job market, it's absolutely brutal right now in SoCal.

And btw, anybody think that JSF 2.0 will be good enough to generate enough interest in these shops for POCs and ultimate production deployments? 

EJB 3.0 was too late, will JSF 2.0 be too late as well???  It matters for the survival of Seam b/c JBoss (AFAIK) will not support Wicket, Flex, GWT integration projects.  Those libraries are outside of the JBoss stack...

[asookazian]

Hopefully this will help with the adoption rate: https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=1253

[asookazian]

Maybe I was wrong?

http://wiki.java.net/bin/view/Projects/RealWorldJSFLinks

did not see this adoption rate in SoCal, however...

[luxspes]

Arbi Sookazian wrote on Sep 11, 2009 18:12:


I received and accepted an offer this week with a small company in SoCal doing emergency notification systems.  They are looking into using JSF and Silverlight in the future (interesting combo, no?)

Yes... why not Flash ?

So this thread is a job-related thread on some basic observations I made based on job requirements for several IT Java shops in SoCal.

Very, very few shops are actually currently using JSF, RichFaces or EJB3.  My current employer seems to be one of the very few (we are Fortune 500 btw).  The vast majority seem to be using Spring with Spring MVC or JSP and JDBC/sprocs/Hibernate.  But typically Spring/Hibernate.

Well, for one, Seam does not support JSP (something like Spring MVC could be built using an AbstractResource but doing that does not seem to be interesting for the Seam community.

Accordingly, if there are very few adoptees of JSF and EJB3, nobody will be using Seam in production envmts.

So now I have realized the true root-cause of the lack of Seam adoption and RichFaces adoption in the industry:  very few shops are using JSF and/or EJB3.  The main culprit really being JSF as EJB3 is not required for Seam app development.

The thing is Spring integrates with anything you use, that is reason to be, integrate stuff. Seam is much more selective, Seam wants you to work with JSF, this gives you direction, but also prevents you from using Seam if JSF is not interesting for you.

Seam is an integration framework (originally) designed to bridge JSF and EJB3 and improve/extend JEE 5 generally although now you can use GWT, Flex, Wicket, etc. for the presentation layer.  And we have known from the beginning that EJB3 components are not required (you can use plain POJOs as your Seam backing, business, DAO, etc. components).

Yes, but all the other approaches (not JSF, not EJB3) and technologies are (IMO) not treated as first class citizens, I know I can use Spring Ioc even under Swing, but... can I do the same with Seam? (hopefully I will be able to do it with WebBeans... which BTW has a name that makes you think is only for web stuff)

I also noticed that Flex is very popular but Wicket, Tapestry and Struts 2 are not.

Well, Flex is like flash and silverlight, is shiny and end users love shiny (also it can do things that are really hard with JSF (focus, client caching) real easy)

And btw, anybody think that JSF 2.0 will be good enough to generate enough interest in these shops for POCs and ultimate production deployments? 

I hope so, it looks like a good technology, but it may be too late.

EJB 3.0 was too late, will JSF 2.0 be too late as well???  It matters for the survival of Seam b/c JBoss (AFAIK) will not support Wicket, Flex, GWT integration projects.  Those libraries are outside of the JBoss stack...

it is hard to guess. One question we should all ask ourselves is: our apps are mostly java code? or are they in fact mostly html and javascript and java is used only to persist stuff? because sooner or later javascript will learn to talk to databases (or services) directly, and that could make java and its technologies obsolete.

I do not like Javascript, but I can do nothing if the market is making it a success.

[asookazian]

The company I will be working for has a partner that is a Microsoft Silverlight partner (or similar?) so they are going with Silverlight.

The other reason is that the engineering director does not like the JavaScript-esque ActionScript in Flex and stated that Silverlight uses C# or at least something more similar to statically-typed Java code for front-end component building that sounds more re-usable to me.  Who wants to learn ActionScript?

I guess I'll find out soon enough but Silverlight is supposed to be very hot...

One of the best things I enjoyed about working with the Seam stack is not having to write any javascript functions at least 90% of the time.  That's great.  JS is hard to debug and finicky depending on the browser you're using (IE6 is buggy).  RF team already handled/solved all the browser compatibility problems for you.  You also have the CDK (which I never actually used to develop my own RF component) which is cool.

So if you use Silverlight or Flex in a Seam app, does that mean you won't use JSF 2.0 at all?  Or only in some components?

In other words, in one use case for one page flow, would you use Flex and JSF 2.0?  Or just one?

[arshadm]

Hi,

I am working on a project that uses Flex as a front end to a JEE app. Flex and JSF are not really compatible technologically because of the way all parameters are encoded by JSF for postback.

I had a choice between Granite DS or writing a small wrapper (resource) servlet with JSON output, I adopted the latter because it was simpler. GraniteDS looked pretty complicated and added another layers of servlets and filters, my app is slow enough already thank you :-).

Regards.

[william.drai]

Hi,

Using both Flex/Silverlight and JSF in the same part of the app just does not make sense (except maybe when just using Flex for displaying charts in a page). With a 'rich' client side, there is no point having a server-side component tree and the client should talk directly to Seam components, much like Seam remoting.

As for Granite, it is obviously an extra layer that implies slightly more configuration (a handful of jars and config files), but without any doubt it is much faster that JSON as it implements the AMF object encoding which is binary, very compact and native in Flex (to be fair, that would also be the case with any other AMF implementation).

(Note that I'm from the Granite team).

Regards.

[luxspes]

Arbi Sookazian wrote on Sep 12, 2009 01:29:


The company I will be working for has a partner that is a Microsoft Silverlight partner (or similar?) so they are going with Silverlight.

The other reason is that the engineering director does not like the JavaScript-esque ActionScript in Flex and stated that Silverlight uses C# or at least something more similar to statically-typed Java code for front-end component building that sounds more re-usable to me.  Who wants to learn ActionScript?

I hope that is the right decision, JavaScript certainly looks successful, right now, a lot of people say: My application is in PHP/Java/ASP.NET/JSF/RoR/GWT but,in reality, if you take a closer look, they are all JavaScript applications. ActionScript is IMO 90% JavaScript with 10% extra syntactic sugar for class oriented developers. (JavaFXScript it is also Javascript, just with a different kind of sugar: strong typing). GWT compiles Java in to JavaScript, JSF tries (unsuccessfully)to hide Javascript from us.... The future looks like JavaScript everywhere...

I guess I'll find out soon enough but Silverlight is supposed to be very hot...

One of the best things I enjoyed about working with the Seam stack is not having to write any javascript functions at least 90% of the time.

Guess my apps are much more complex than yours... I had hoped to use less javascript, but wihtout javascript , as I stated in my previous post a lot of simple stuff is plain impossible to do right now.

Maybe it is because I build intranet OLTP applications  for enterprise users, with what I have come to realize are very complex capture forms (very easy to build with Delphi or WindowsForms.NET, possible to build with Swing, hard to build with HTML+JavaScript), and apparently JSF and Richfaces were not designed to deal with that. That may change with JSF 2.0 and Richfaces 4.0 but that will be too late for my project...

That's great.  JS is hard to debug and finicky depending on the browser you're using (IE6 is buggy).  RF team already handled/solved all the browser compatibility problems for you.

In my experience, RF only scratches the surface of the browser incompatiblity problems, it does help, but it is not even close to the confidence of building something in Flex/Flash/Silverlight and know it is going to work 100% of times.

You also have the CDK (which I never actually used to develop my own RF component) which is cool.

This is one of the things I have always found problematic of building JSF/Richfaces stuff, the complexity of creating reusable components is just too big, in fact it is so big, that if you try to do so, you easily realize that the underlying platform can not even deal with simple stuff like scoped focus.

So if you use Silverlight or Flex in a Seam app, does that mean you won't use JSF 2.0 at all?  Or only in some components?

Why use JSF? Imagine plain HTML+Javascript could do everything Silverlight and Flash can do, imagine in could even talk to the database directly in a secure way... what would be the place for JSF and Java then?

In other words, in one use case for one page flow, would you use Flex and JSF 2.0?  Or just one?

Plain Flex communicated with a remoting service (integrating SeamRemoting with GraniteDS would be great), anything else is just a solution looking for an inexistent problem

[luxspes]

Robert Burns wrote on Sep 12, 2009 09:19:


Hi,

I am working on a project that uses Flex as a front end to a JEE app. Flex and JSF are not really compatible technologically because of the way all parameters are encoded by JSF for postback.

JSF+Flex makes no sense, because JSF it does not solve any problem for Flex. Seam WebRemoting+Flex (or DWR+Flex, or even better GraniteDS+Flex) would make sense.

I had a choice between Granite DS or writing a small wrapper (resource) servlet with JSON output, I adopted the latter because it was simpler. GraniteDS looked pretty complicated and added another layers of servlets and filters, my app is slow enough already thank you :-).

Regards.

Simpler? AFAIK GraniteDS already includes support for Seam (why reinvent the wheel), and the AMF protocol is much more efficient than JSON (faster serialization, less bandwidth use). The most likely scenario is that your application would be faster if it used Granite

[cash1981]

Arbi Sookazian wrote on Sep 11, 2009 19:27:


Hopefully this will help with the adoption rate: https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=1253

Absolutley. This is really a killer.