Java beans, annotations: What do they do? How do they help me?

Question

Here is what what I understand so far:

Java beans are just to help other things (visual things?) interact with your code. I think that this is mostly for UI stuff because it is easier to design this visually. Is it bad practice to use Java beans for non-UI things?

Java beans have getter and setter methods (bad OOP practice) and are serializable.

In terms of annotations, I think that user defined annotations do not provide any functionality. Some annotations like @depretiated raise compiler warnings. Can user defined annotations do this somehow? Are user defined annotations good for anything other than documentation? How can I use them? Does eclipse or intellij have some feature that involves annotations?

Have a good weekend.

Jake

Update: that is starting to make more sense. Could someone refer me to an example of when it would be appropriate to use the java bean format and when it would not?

Also I read somewhere that several classes can be a bean and it is a way of packaging classes.

Just to clarify one more thing. I am 95% sure that being a java bean is somewhat like being a singleton (or other pattern). It does not affect what the compiler does.

Answer 1

Annotations are a form of declaritive programming. First, you have to grok the benefits of declaritive programming before the utility of annotations becomes clear. In essence, you can add functionality or behavior to a block of code simply by "declaring" that it has a certain characteristic. This is in contrast to actually writing out a series of statements to apply or setup the same behavior.

The JPA annotations are an example of adding functionality with annotations. I don't know of "user created" example off the top of my head, but the JPA annotations are implemented exactly the same way that you or I would do it.

As far as Java Beans, the original use of them was for GUI-programming. The "easy" way of using JavaBeans was to use naming conventions to define the "attributes" of a bean--hence getters and setters. As far as I know, JavaBeans were originally an implementation for GUI-based editing of forms and UI's. So the getters and setters made it easy for the UI software to discover user-viewable or editable attributes. With a Bean Descriptor you can change the way descriptors work a bit...

The reason they persist to this day is they provide a de facto way to inspect objects for publicly exposed properties. It is not bad form to use JavaBeans outside of a GUI. The preference in Java seems to be to use the no arg constructor and then inject your dependencies rather than using RAII style of programming (not that it's strictly available)...

It's actually quite common, particuarly if the object will be manipulated by code that does not know a priori the object it will be manipulating (take a look at Hibernate for a good example).

Answer 2

JUnit uses annotations since version 4 of JUnit. That is an example of user-defined annotations. You add the @Test-annotation to a method and the JUnit-framework recognizes it and executes the method as test.

Beans will be used by some frameworks to work with otherwise unknown objects. An examples that comes to my mind are persistance-frameworks, they duplicate some registered objects into databases and uses the bean-properties for that.

Answer 3

I suspect that you're confusing Java beans and EJB (Enterprise Java Beans) - these are different concepts. Actually they're almost the same now, but this was not always so - the history is rather confusing.

James gives a good explanation of the history of Java beans - they're much older than annotations (which were introduced in Java 1.5). EJBs are also much older, but they have been radically revised and are now basically Java beans with special annotations running in an EJB container.

This is actually a perfect example for how useful annotations can be.

"Old style" EJBs (prior to version 3 of the spec) were horrible to code. You needed to define (IIRC) two interfaces, one implementation class (that did not actually implement the interfaces) and an XML descriptor that linked them together. And if you made a typo anywhere, there was no compiler error - just a totally cryptic runtime error that did not help you narrow down the problem.

Why was this so? Because it allowed the EJB container to control how the actual implementation code was called, and to transparently do things like access control, transactions and replication.

In the EJB 3.0 spec, this was simplified radically, so that now you need only one class (which can be a "classic" Java Bean in the case of entity beans), which actually implements the EJB's logic - and annotations that tell the EJB container how to treat it. Instead of a separate XML file, information about the code lives right next to the code itself in the same file, and since annotation syntax is checked by the compiler, many potential errors are caught at compile time.