Improve Beans with collection - Java SE (Archived)

Or more generically...
[b]Fix the ancient JavaBean spec to modern realities[/b]
Everyone uses List and Map objects in their beans these days, yet the actual bean spec hasn't been updated in years. Its not just a documentation exercise, there is related code with beans too.

You said it better that I would ever do.
Gérard

Or get rid of JavaBeans completely.
--
Tom

Related

POJO's and JavaBeans - which is more widely used/best practice?

Do software system out there still develop using POJO (Plain Old Java Objects) especially with the emergence of JavaBeans?
JavaBeans doesnt seem that widely known though many people insists using JavaBeans is better. Or is it just the Acronym makes POJO sounds old fashioned and outdated?
Just curious..
regards 
Javabeans are simply a type of POJO. The term POJO is used to differentiate an object from an object that must extend a superclass or implement an interface for a given component model (say, extending Struts ActionForm or the various interfaces an EJB 2.x must implement).
All Javabeans, at least in my mind, are POJO's. Except they follow a convention such that any accessor (getter) is getXXX() and a mutator is setXXX() with a corresponding field name of XXX. (Booleans can use isXXX()). Now, that is just a sort of common, collloquial way to refer to JavaBeans. The spec itself does not require you to write your beans with accessors and mutators. However, when most people say "java bean", that is what they mean.
- Saish 
And to specifically answer your question. My feeling is that JavaBeans are more widely used, but POJO's are the best practice. (Ergo, I dislike creating a promiscuous object that allows anyone else to get and set its values willy nilly and without ensuring the object is initialized in a consistent state).
- Saish 
What are you talking about? The JavaBeans spec has been around since the very early days of Java. The term "POJO" was dreamt up less than a decade ago. 
Currently you will find POJOs gaining importance with Spring EJB3 and upcoming frameworks. Personally I use POJOs more as everytime you dont want to use setters and getters which you have to use with Java Beans, maybe constructors are an alternative too. 
ankur29 wrote:
Currently you will find POJOs gaining importance with Spring EJB3 and upcoming frameworks. Personally I use POJOs more as everytime you dont want to use setters and getters which you have to use with Java Beans, maybe constructors are an alternative too.I feel like I'm living in a parallel universe. You mean there's a version of Java that doesn't require POJOs? And as for constructors being an "alternative"....
I dunno....getting too old....I need a beer.
Winston 
ankur29 wrote:
Currently you will find POJOs gaining importance with Spring EJB3 and upcoming frameworks. Personally I use POJOs more as everytime you dont want to use setters and getters which you have to use with Java Beans, maybe constructors are an alternative too.Eh? There's nothing that says "If you choose to use JavaBeans, everything in your codebase must be a JavaBean". I think the entire point of the term POJO has been lost somewhere along the way. 
ankur29 wrote:
Currently you will find POJOs gaining importance with Spring EJB3 and upcoming frameworks. Personally I use POJOs more as everytime you dont want to use setters and getters which you have to use with Java Beans, maybe constructors are an alternative too.Those statements are either completely wrong or very, very badly phrased. 
Theresonly1 wrote:
Do software system out there still develop using POJO (Plain Old Java Objects) especially with the emergence of JavaBeans?
JavaBeans doesnt seem that widely known though many people insists using JavaBeans is better. Or is it just the Acronym makes POJO sounds old fashioned and outdated?I am curious how you decided that POJO and Java Beans are comparable at all.
Do you have a link or reference for your statement?
As noted in another reply Java Beans have been around much longer than POJOs. They are not comparable. 
georgemc wrote:
What are you talking about? The JavaBeans spec has been around since the very early days of Java. The term "POJO" was dreamt up less than a decade ago.True, but I think that POJO's, by definition, have been around as long or longer than anything else. It's the kitchen-sink category. They existed long before a snappy acronym was coined to describe them.
- Saish 
I was referring to Spring Framework basically. Thing is POJOs are nothing but plain old java objects. True JavaBeans must implement Serializable and have a no-argument constructor. POJOs don't have these. 
ankur29 wrote:
I was referring to Spring Framework basically. Thing is POJOs are nothing but plain old java objects. The acronym POJO stands for Plain Old Java Object.
By usage is stands for using them to access database data.
Spring itself is not a database layer framework. It is more than that.
True JavaBeans must implement Serializable and have a no-argument constructor. POJOs don't have these.No.
A "JavaBean" has a specific documented specification.
[http://java.sun.com/javase/technologies/desktop/javabeans/index.jsp]
However there isn't anything at all required about it. That fact that you have seen them used in certain ways and perhaps even required to do certain things for certain frameworks doesn't alter what the specification requires.
In Chapter 2 you will find this quote.
"A bean is not required to inherit from any particular base class or interface."
Notice that the above completely negates your statement about Serializable.
Also note that the specification does not require anything about constructors. 
POJOs have been around since the start of Java in the sense that objects have been around since the start of Java, and the JavaBeans spec started a little after...but I think you're missing the point.
The name "POJO", standing for "Plain Old Java Object", is just a formal-sounding way of rejecting complicated frameworks when a plain old object will do. It is itself not a framework. A bean can be a POJO inasmuch as an object can be very simple, and still qualify as a bean. JavaBeans I suppose could be described as a framework, I guess, but it's a pretty simple one.
Trying to put JavaBeans and POJOs in opposition to each other isn't very meaningful.
Better you should just think of an object as a POJO or not (does it have to fulfill a really complicated framework?), or a bean or not (does it qualify as a bean under JavaBeans lightweight requirements?). Maybe an object is both, maybe it's neither. 
I think I need to be a little more detailed maybe.
First of all I never said Spring is a database layered framework.
Basics: A POJO is a Java object that doesn't implement any special interfaces such as those defined by the EJB 2 framework. Martin Fowler, Rebbecca Parsons, and Josh MacKenzie coined the name to give regular Java objects an exciting-sounding name that encouraged developers to use them (www.martinfowler.com/bliki/POJO.html).
Decoupling the application code from the infrastructure frameworks is one of the many benefits of using POJOs. They also simplify development because rather than being forced to think about everything - business logic, persistence, transactions, etc. - at once, you can focus instead on one thing at a time. You can design and implement the business logic and then, once that's working, you can deal with persistence and transactions.
POJOs also accelerate development. You can test your business logic outside of the application server and without a database. You don't have to package your code and deploy it in the application server. You also don't have to keep the database schema constantly in sync with the object model or spend time waiting for slow-running database tests to finish. Tests run in a few seconds and development can happen at the speed of thought - or at least as fast as you can type!
As far as Javabeans go kindly refer to the following link: http://www.avajava.com/tutorials/lessons/what-is-a-javabean.html
A JavaBean is a POJO that is serializable, has a no-argument constructor, and allows access to properties using getter and setter methods. An Enterprise
JavaBean is not a single class but an entire component model. 
JavaBean != Enterprise JavaBean

Why use Entity Beans AT ALL?

Our approach currently is
BusinessDelegate->EJBSessionFacade->DAO-Hibernate(Which makes DTO very easly)->PostgreSQL
And we are very satisfied with this, but what I dont undersertand why when we would use Entity Beans?I believe hibernate have some transaction control mechanism(because we use it)is there any benefit on Eejb that I'm missing? 
User based Security Roles.
Instance Pooling
Remote Object Calling.
Database Locking.
Concept of Local Interface.
have to Check whether these are in Hypernate also ?
Moreover, if you are using EJBs then development time is very less. Even in my project we are not using EJBs. pure Java Classes. We are going to design our Persistance, transactions etc etc..
Ofcourse, without EJB you can also use JDO. ( Java Data Objects ). In this also Transaction mechanisms are there.
As you can see from my post, we use Session Beans, which have most(if not all) of the
benefits you mentioned, the only thing that bothers is the transactions part, what are the benefits of making transactions on an Entity? 
There are some benefits but the HEAVY WEIGHT natuer of the entity beans are making them hard to justify. More and more applications are moving towards hibernate for good reasons so much so that Gavin King has become a semi-GOD in J2EE community. He is also a member for the EJB spec team and has heavily influenced the EJB3.0 draft version. I have a link to the ejb3.0 spec features on my blog. http://roger.blogs.com/roger_rustin/2004/05/ejb_30_is_final.html
So going forward I guess hibernate is a good choice.
- Roger
I am an EJB nut, but I agree with Roger, the merge of ease of Hibernate and the power of EJB will come together as one kick ass spec!

EJB vs JavaBean

Hi
I'm new to EJB. I'd like to know wich are the main differences betwen EJBs and JavaBeans and when i should use EJBs instead of JavaBeans.
thanks for your time
Wow there is a massive amount difference. I think, about the only thing they have in common is the fact they may have getters/setters and they both have Bean in their names. 
Yeah - in fact there's not even that much similarity between them. Only entity beans come close to JavaBeans.
They're often confused but the motivations for the two "technologies" are different:
JavaBeans are a component model whereby classes expose their various properties through the use of a standard naming convention (getName, setName etc.). This enables them to be used by other applications without those other applications having to know anything about them except that they're JavaBeans. Ok, this is a very simplistic view of JavaBeans (there's plenty more to them than that) but it should suffice to help highlight the differences.
Enterprise JavaBeans are also a component model but one in which you write classes/interfaces describing and implementing (enterprise) business data and logic. The goal is for your code to be written in such a manner that it automatically can be wrapped up by an application server to provide persistence, security, transactions, concurrency and scalability (amongst other things).
Entity EJBs are similar to JavaBeans in some ways (in that they both usually represent application data) but an entity EJB can never be a JavaBean since the two standards have mutually-exclusive constraints.
You use the two in very different circumstances but, conceptually at least, there is some similarity - mainly that they both represent a means of exposing your classes in a vendor-neutral fashion so they may be integrated into existing software.
Hope this helps a little (it's by no means exhaustive, though). 
Hi,
I have already explained this when prevoiusly asked.Any way in brief I will tell both are reusable components but the environment in which they run are different.For EJB the environement is EJB container and for the Bean it is JVM.Both are the class files and will run in the JVM but there will be the additional features provided by its envoronment ie concurrency handling,security,pooling..... in case of EJB
If you would have worked with servlet then in that case the Servlet Engine provides the Enviroment to the Class file,yes the Servlet Type..
Hope this give you some basic understanding...
regards
Vicky 
Thank you very much
But i think i didn't expressed very well my question,my english isn't very good :-(
I want to know when it's better using EJBs than other technologies, in which cases should i use EJBs instead of JSP/JavaBeans, servlets or so on... I mean, for a very simple/small system i don't think it would be a good idea to use EJBs.
Hi,
You use EJB's when you mainly wanted to go for the Distributed Technologies.This is not the only reason there are also many more features but this is the main reason.
regards
Vicky 
You are right , ejb may be over kill for small application , since its inception, performance of ejb is doubtful.
Following may help you decide to use EJB
1. You want the application to be scalable. EJB containers provide this by pooling various objects like instance pools, connection pools etc.
2. you want your application to be DB independent. This is if you are using CMP entity beans
3. You may want to change the transaction attributes of your components without affecting the code.
4. Provide OO view of the database entities. Possible using Entity Beans.
5. Plus fault tolerance, automatic concurrancy handling.
--Ashwani                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                    
in which cases should i use EJBs instead
of JSP/JavaBeans, servlets or so on... You also might have a look on this article ("To EJB, Or
not to EJB", JavaWorld):
http://www.javaworld.com/javaworld/jw-12-2001/jw-1207-yesnoejb.html
Cheers, Carsten
Thank you Carsten, that's just what i wanted! 
Hi,
I read the article in hurry. EJBs are not as bad as portrayed in this article. every distributed technology is complex.Take the case of CORBA. Here developer has to put lot of efforts that are being provided to you in ejb by App servers. But CORBA is going strong. The flexibility and the performance it provides , needs to be noticed. The fact is that majority of telecom projects do use CORBA in some way or other way. There is not much hype about it because it is quite stable and reliable. than Web services which has to go a long way. Even most of the ejb servers are based on CORBA implementation.
--Ashwani
Hi!
I read the article in hurry. EJBs are not as bad as
portrayed in this article. Well, in my opinion the article doesn't say that EJBs are
generally bad...
However, if you feel that article is too biased you might want
to look at another one ;-) This is an excerpt from Ed Roman's
EJB book "Mastering Enterprise JavaBeans 2nd edition":
http://www2.theserverside.com/resources/article.jsp?l=Is-EJB-Appropriate
(By the way, there are many other interesting articles, discussions,
etc. on related topics on that site!)
Cheers, Carsten

J2EE - .Net benchmark controversy.

http://www.sys-con.com/java/articlenews.cfm?id=1738 
"Not everyone believes, though, that TMC did a disservice to the community. Greg Leake, Lead Product Manager for .NET at Microsoft, notes..."
Oh, so he'll not be biased then... 
I have to say that, though I haven't yet had occasion to user ejbs for real, I have done the course and I think the overheads must be horrendus. I'd estimate that for a web/database application there'd be something like 3-4 times the load on the database server than if you'd programmed it with conventional servlets. It saves stuff you didn't change. It always requires you retrieve your keys, and your data separately. It loads all the data for the bean, not the fields you actually need.
And you then have the EJB communications overhead on top of the database activity.
There are no facilities for inteligent caching at the bean level. AFAIKS the only concesion the machine efficiency is pooling empty beans so as to avoid garbage collection.
Well, theres a big discussion going on about Entity Beans, and whether they're any good, or whether the new versions are better etc. But not every J2EE system has to use Entity Beans, and in a lot of circumstances they won't be appropriate. Even using EJBs can mean using Session beans rather than Entity beans.

is there any difference?

in some books i have seen that they are mentioning enterprise java beans and java beans seperately.
what is the difference? 
Because EJBs are part of the J2EE specs, while Javabeans are basically just bad OO design. 
Because EJBs are part of the J2EE specs, while
Javabeans are basically just bad OO design.In what context are they bad design? There's actually a bean specification but most people who talk about beans do really mean classes with getters and setters in a web context.
The original specification was directed at how one would be able to write components that could be plugged in into e.g. an IDE.
Kaj 
In what context are they bad design? There's actually
a bean specification but most people who talk about
beans do really mean classes with getters and setters
in a web context.I think about beans as classes with getters and setters in any context. To me it's bad design because it's just a data-container anti-pattern. At least that's what I always understood of them. No coherency, no encapsulation.
The original specification was directed at how one
would be able to write components that could be
plugged in into e.g. an IDE.I know about bean containers. That the mechanism can be useful doesn't mean it's good OO. :) 
I know about bean containers. That the mechanism can
be useful doesn't mean it's good OO. :)No, but it means that beans are much more than just bad design :)
#Op. A description of what a bean is:
"What is a Bean? Why isn't a Bean an Applet?
JavaBeans components, or Beans, are reusable software components that can be manipulated visually in a builder tool. Beans can be combined to create traditional applications, or their smaller web-oriented brethren, applets. In addition, applets can be designed to work as reusable Beans.
Individual Beans will function quite differently, but typical unifying features that distinguish a Bean are:
* Introspection: enables a builder tool to analyze how a Bean works
* Customization: enables a developer to use an app builder tool to customize the appearance and behavior of a Bean
* Events: enables Beans to communicate and connect together
* Properties: enable developers to customize and program with Beans
* Persistence: enables developers to customize Beans in an app builder, and then retrieve those Beans, with customized features intact, for future use"
http://java.sun.com/products/javabeans/faq/faq.general.html#Q1
Kaj 
while
Javabeans are basically just bad OO design.LOL :) 
I think about beans as classes with getters and
setters in any context.Beans are more than mere getters and setters. They can be used for pretty useful purposes (for example: the FormBean in Struts has a useful method called validate which is neither a getter nor a setter). 
Also, don't forget balck beans, kidney beans, pinto beans...
Well you usually get and set them but there are other uses too. 
xHacker! Welcome back, I was looking for you for a long time! 
xHacker! Welcome back, I was looking for you for a
long time!Yes. Last I remember he has "teh codes". 
xHacker! Welcome back, I was looking for you for a
long time!Thanks :-) and good to know the face behind the handle too. 
xHacker! Welcome back, I was looking for you for a
long time!Yes. Last I remember he has "teh codes".I don't remember we met last time; which was a long time I s'pose. 
xHacker! Welcome back, I was looking for you fora
long time!Yes. Last I remember he has "teh codes".I don't remember we met last time; which was a long
time I s'pose.What's a troll?
;)
Anyway long time no see. Hope you are back for awhile. 
xHacker! Welcome back, I was looking for you for a
long time!Thanks :-) and good to know the face behind the
handle too.:)
Richard (right?), can you please do me a favor and drop a mail to renechennault at the FRench yahoo? Thanks. 
>
[url=http://forum.java.sun.com/thread.jspa?threadID=61
7954]What's a troll?;)
Anyway long time no see. Hope you are back for awhile.
Which one(s) of them is you? Well, that's somewhat obvious. :-)
That was refreshing to read.

Categories

Resources