4 areas of possible confusion in JEE 6

 

The JEE specification is released and maintained through the Java Community Process, which defines the different API’s that will be included in each release, and how they relate to each other. Due to the technical and political factors involved in the process, besides the time constraint, is no surprise that some areas of the specification may be confusing to new developers, especially with the rising number of annotations introduced by each API.
In this post, I will try to explain four areas where developers might find themselves confused when working with JEE 6.

1. Managed Beans and EL access

The following two annotations from the JEE 6 API are both used to make a bean accessible through the Expression Language (i.e. using the #{} notation):

• @javax.faces.bean.ManagedBean – Defined in the JSF 2.0 Managed Bean Annotations specification (JSR-314), it provides an alternative to the declaration of managed beans in the faces-config.xml descriptor file.
• @javax.inject.Named – Defined in the Dependency Injection (JSR-330) specification, is one of the built-in qualifier types of CDI (JSR-299) used to provide a name to a bean, making it accessible through EL.

So, which one to use? Always use the @Named annotation, unless you are working in a JSF 2.0 environment without CDI (a very unlikely scenario). There is just no reason to use JSF Managed Beans if CDI is present. You can check this article for more information.
Furthermore, there is another @ManagedBean annotation you might also get confused with:

• @javax.annotation.ManagedBean – Defined by the Commons Annotations specification (JSR-250), it is used to declare a managed bean as specified in the Managed Beans specification (JSR-316).

Most likely, you will never need to use this annotation. Let’s look why.
First, don’t confuse Managed Beans with JSF Managed Beans, they are different things. The Managed Beans specification, a subset of the JSR-316, is an effort to provide services like dependency injection, lifecycle callbacks and interceptors to POJO’s (Plain Old Java Objects), which is really cool! So, why not to use it?
CDI treats all POJO’s as Managed Beans! There is no need to explicitly annotate the POJO with @javax.annotation.ManagedBean. Nothing stops you from doing it though.

2. Duplicated @…Scoped annotations

The following annotations are duplicated in the JEE 6 API:

• @javax.faces.bean.RequestScoped and @javax.enterprise.context.RequestScoped.
• @javax.faces.bean.SessionScoped and @javax.enterprise.context.SessionScoped.
• @javax.faces.bean.ApplicationScoped and @javax.enterprise.context.ApplicationScoped.

The @javax.faces.bean… annotations are defined in the JSF Managed Beans specification (JSR-314) and the @javax.enterprise.context… annotations are defined in the CDI specification (JSR-299).
So, which ones to use? Always use the CDI annotations, unless you are working in a JSF 2.0 environment without CDI (a very unlikely scenario). As discussed above, there is no reason to use JSF Managed Beans if CDI is present.
One scope that is missing in CDI is the @ViewScoped of JSF. However, the problem is solved by creating a portable extension which will be included in the Seam 3 Faces Module.

3. Defining a Singleton

There are four annotations that provide very similar functionality:

• @javax.ejb.Singleton – A new type of EJB from the JSR-318 specification, it is used to maintain a single shared instance; it’s thread safe and transactional.
• @javax.inject.Singleton – From the Dependency Injection specification (JSR-330), marks a type the injector will only instantiate once.
• @javax.enterprise.inject.ApplicationScoped – One of the built-in scopes from the Contexts and Dependency Injection specification (JSR-299), specifies that a bean is application scoped.
• @javax.faces.bean.ApplicationScoped – Defined in the JSF 2.0 (JSR-314) Managed Beans specification, specifies that a JSF managed bean is application scoped.

They all guarantee a single instance of the class. But, which one to use?
We have already discussed the duplicated @ApplicationScoped annotations above, so we will just dismiss @javax.faces.bean.ApplicationScoped to move on. That leaves us with just 3 options.
@javax.ejb.Singleton is the only one that will give you out-of-the-box “enterprise” services such as concurrency and transaction management. So, if you need these features, this is the annotation to use. You can optionally add the @javax.enterprise.inject.ApplicationScoped annotation but you will not feel the difference, although, CDI will treat it differently. You can check this forum thread for more information.
Note: even though it is possible to use @javax.enterprise.inject.ApplicationScoped with a Stateful Session Bean, I can’t find any good reason to use it given that EJB 3.1 has introduced the Singleton Beans.
If you want to use POJO’s (called Managed Beans in the JEE world), instead of EJB’s, you can also annotate them with @javax.enterprise.inject.ApplicationScoped to guarantee that the class is instantiated only once. Be aware that you will lose all of the services provided by EJB’s such as concurrency and transaction management.
I would not suggest using @javax.inject.Singleton unless you are working in a JS2E environment without CDI support. You can check the Weld documentation and this forum thread for more information about how this annotation is handled in CDI.
Note: none of the annotations discussed above will guarantee a shared single instance in a clustered environment. Usually, you will have one singleton instance per JVM.

4. @Inject or @EJB

They are both used for injection. @Inject is from the Dependency Injection specification (JSR-330) and @EJB from the EJB specification (JSR-318).
So, which one to use?
In most of the cases you will use @Inject over @EJB unless you are working on an environment with EJB’s but no CDI (very unlikely since JEE 6), or if you need to define an EJB resource. You can check the this forum thread for more information.

Conclusion

1. If you need to access a bean through EL (i.e. from a JSF page), annotate the bean with @Named.
2. Usually, you will never need none of the @ManagedBean annotations.
3. Always use the @…Scoped annotations from the javax.enterprise.context package (CDI).
4. To define a singleton, use the @javax.enterprise.inject.ApplicationScoped annotation. If you need the EJB services such as concurrency and transaction, add the @javax.ejb.Singleton annotation.
5. Always use @Inject instead of @EJB, unless you really have a motive to do so.

(Source: http://germanescobar.net/2010/04/4-areas-of-possible-confusion-in-jee6.html)

The Software Manifesto: 9 Principles for Higher Level Coding

Very Good Article on Software design and project management

http://software.intel.com/en-us/blogs/2013/04/22/the-software-manifesto-9-principles-for-higher-level-coding-0

minifesto.org/


"......

There’s an interesting link being passed around today titled “Manifesto for Minimalist Software Engineers”. It’s a list of nine basic principles to keep in mind when developing good software and it’s definitely worth a read whether or not you’re in the developing industry.  Ranging from “fight for Pareto” to “think different”, these simple, thoughtful guidelines are a higher level look at the nuts and bolts of everyday coding.  We’re going to look at just a few of these helpful thoughts here.

The 80/20 law

There’s a business principle called Pareto’s law; it’s basically the same thing as K.I.S.S (keep it simple stupid). A more elegant explanation can be found below:

“The Pareto principle (also known as the 80–20 rule, the law of the vital few, and the principle of factor sparsity) states that, for many events, roughly 80% of the effects come from 20% of the causes. Business-management consultant Joseph M. Juran suggested the principle and named it after Italian economist Vilfredo Pareto, who observed in 1906 that 80% of the land in Italy was owned by 20% of the population; he developed the principle by observing that 20% of the pea pods in his garden contained 80% of the peas. It is a common rule of thumb in business; e.g., "80% of your sales come from 20% of your clients".  – Wikipedia, “Pareto’s Law”

When this principle is applied to creating great apps, the manifesto has this to say:

“Best engineers are those who can estimate the effort of new requirements and they are the only with enough information to refuse the 80% that is not in the optimal next scope…..The worst code you've ever written is the code that is no longer used. Is called YAGNI (You Are Not Gonna Use It). The best code you've ever written is the code you didn't write, simply because it's the only that never fails.”

Priorities

When you have a lot to do, it can be difficult to figure out what to tackle first. This is especially true for developers, especially when faced with a slew of bugs or errors or projects that, of course, are all due at about the same time. When faced with a long to-do list, some people stick their heads in the sand and procrastinate, while others attack on multiple fronts, while still others resolve issues in order of importance:

“Minimalism is not about not doing things but about focusing first in the most important.”

This is a thought echoed by productivity guru Leo Baubata, who writes the popular blog ZenHabits:

“Our work day is made up of an endless list of work tasks. If you simply try to knock off all the tasks on your to-do list, you’ll never get everything done, and worse yet, you’ll never get the important stuff done. Focus on the essential tasks and eliminate the rest….. – ZenHabits.net, “Simple Living Manifest: 72 Ideas to Simplify Your Life”

 It’s about the process

One of the strongest enemies of true progress is the quest for perfection. If it has to be perfect from the start, how will you ever be able to take a step forward?

“Look for perfection, but not yet. Iteration is that friend that gives you the right advises at the right time. First do it, then do it right, then do it better.”

This is something we observed over the course of seven weeks in the Ultimate Coder Challenge. Seven coder teams took on a seemingly impossible challenge – build a working perceptual computing app with a brand new computer, a brand new SDK, and technology that nobody really knows anything about. Instead of running away screaming (which any sane coder might have chosen to do), these seven teams pulled up to the table and dug in. From one of the Challengers:

“As I write this, there is no app, no design and no code. I have a blank sheet of paper and a few blog videos. The six developers I am competing against are established, seasoned and look extremely dangerous. My chances of success are laughable, so given this humorous outcome, I'm just going to close my eyes and start typing. When I open them in seven weeks, I'll either have an amazing app or an amazing lemon.” – Lee Bamber, Ultimate Coder Challenge: Going Perceptual

As we prepare to crown the winner in this Challenge, it’s interesting to note that all  the contestants had about this same attitude: it’s not necessarily about the destination, but the journey. Starting out with perfection as your ultimate goal is certainly admirable, but it doesn’t allow for the learning opportunities that are no doubt going to be dropping into your lap along the way.

Simplicity

With the popularity of touch designs in form factors, one of the issues that developers have to contend with is figuring out how to do more with less.  The old adage of “keep it simple silly” certainly applies to touch. It’s an input method that forces simplification; you have to decide which actions are most important, what stays on the screen and what goes away. It can be a difficult process, but you end up with software that is easier to understand and therefore much easier to use. Users need input methods that are streamlined, non-fussy as possible, and effective. In order to get people to interact with touch, developers have to design for predominately direct manipulation; i.e., you have to use your fingers to interact with the content. The content is the user interface, making a change from the graphic interface. Distance has effectively been reduced in touch, in other words, extra “stuff” like icons, fiddly little toolbars, and pointers just get in the way. Simple is best:

“We have to write code for humans, not machines and synthesis is the key of communication. A good example is the Pasteaurs's quotation "If I Had More Time, I Would Have Written a Shorter Letter". Try to keep methods as short as possible, classes with a single responsibility, few parameters, avoid redundant comments… The work is finished when you have nothing to take away.”

Simplicity in coding is easier said than done, but it can serve a dual purpose of providing a better user experience and a more powerful application:

“Remember that beautiful doesn’t always equal usable. Heavyweight designs often don’t serve the purpose of the user; they may be created to please the eye rather than to facilitate functionality. Treat accessibility and usability as top priorities….Simplicity is achieved by thoughtful reduction. When reducing, be mindful of your organization. Even if you are dealing with a large number of UI elements or a great deal of code, a proper hierarchy and structure can convey the feeling of simplicity.” – Adobe.com, “The Pursuit of Simplicity”

Seeing the forest for the trees

When you’re in the midst of a development project, it can be easy to lose perspective, focusing on all the myriad details that need to be accomplished rather than seeing the bigger picture. These nine principles for software developers are good reminders to keep that higher level thinking engaged in order to see a project through to its’ greatest potential.

Would you add to this list? What would your personal software development manifesto include – and why? Let us know your thoughts in the comments...."