2

I don't remember where I've read that a JavaBean is a POJO which is managed by a dependency injection container. Does this always hold true? Or there is some other context in which JavaBean stands for something else?

EDIT:

This answer doesn't mention a DI container at all. So being managed by DI container isn't a required condition for a Java class to be a bean?

Community
  • 1
  • 1
Max Koretskyi
  • 101,079
  • 60
  • 333
  • 488

1 Answers1

3

The JavaBeans standard predated DI frameworks, originally a prevalent use case was supporting drag-and-drop components (like those in Delphi or VB, which had component palettes of reusable widgets that could be dragged onto a form and wired together), with support for things like PropertyEditors and property sheets. Visual programming environments were huge back then, there was a market for third-party components, and Sun probably wanted something similar for Java.

Once people started conceiving of DI frameworks they needed a predictable way to set dependencies on their managed objects, so they appropriated the existing standard. From Rod Johnson's Expert One-on-one J2EE Design and Development:

If we make all application components JavaBeans, we maximize our ability to separate configuration data from application code. We also ensure that application components can be configured in a consistent way, wherever configuration data is held.

The term POJO was coined in 2000, with the idea of describing code that did not have explicit dependencies on a framework:

Ideally speaking, a POJO is a Java object not bound by any restriction other than those forced by the Java Language Specification

where the poster child for how not to do it was EJB prior to version 3, with invasive dependencies on framework classes that inhibited out-of-container testing.

DI frameworks were interested in providing functionality in a transparent and noninvasive way, JavaBeans provided a common standard that POJOs could use in order to expose their configuration, so they were a good match.

Nathan Hughes
  • 94,330
  • 19
  • 181
  • 276
  • +1 for mentioning the visual programming influence on the development of that standard at the time - I remember it well. – sparc_spread Jul 08 '15 at 13:53
  • thanks, can you please elaborate on this? _Once people started conceiving of DI frameworks they needed a predictable way to set dependencies on their managed objects, so they appropriated the existing standard._ – Max Koretskyi Jul 08 '15 at 14:23
  • Thanks a lot for the clarification! I was wondering whether I should read the book you referenced - Expert-One-One-Design-Development? It's a bit old. – Max Koretskyi Jul 08 '15 at 22:26
  • @Nathan Hughes, can you please answer to my previous comment? – Max Koretskyi Jul 09 '15 at 07:48
  • @NathanHughes, thanks for you response. I have a copy of it already, I'm just worried that I might spend time on learning staff that's out of date. However, I think there can be something of value in the book. Maybe you could recommend a few particular chapters I should get familiar with? – Max Koretskyi Jul 09 '15 at 13:18
  • @NathanHughes, yeah, I'm looking for conceptual back-end architecture approach explained in a more elaborate way than _design your application with 4 layers - UI, Services, Domain model and Perstistence model_ - will I find it there? – Max Koretskyi Jul 09 '15 at 14:08
  • @Maximus: not so much i think. Maybe try Eric Evans' DDD book? Rod Johnson's book is good for "why spring is designed the way it is". – Nathan Hughes Jul 09 '15 at 14:11
  • @NathanHughes, got you, thanks a lot! – Max Koretskyi Jul 09 '15 at 17:34