Tags

, ,

A hundred years or so ago, I used to write a column about JavaBeans. Later on, I wrote a book about Enterprise JavaBeans. Back then, I was still doing a lot of work in the Windows world. In that world, there was a strong marketplace for third-party components in the form of VBXs and, later, OCXs.

If you’re not from the Windows world, these were binary compiled objects that you could treat as components in your application. They were in a standard format understood by the development environments, so you could drag-and-drop them onto your user interface, manipulate their properties in the development environment, etc. This was the usual way of making use of third-party code in the late 90s and early 00s. It worked very well, chiefly because you didn’t need to understand the internals of the objects at all. You simply interacted with the interface, got the behavior you needed, and got on with development.

So, when I first encountered JavaBeans, I figured that this model of reuse would become common in Java. Further, when I encountered Enterprise JavaBeans, I figured that we would see this sort of reuse at an enterprise level — that is, you’d buy a library of enterprise widgets for, say, case management, drag them around in a visual app builder, and code enough to glue them together.

None of this happened. Well, I’m sure there were some products created, but then never really caught on, and Java code reuse seems to focus on libraries and frameworks instead of components. Why is this? Who knows, but I can make some guesses:

1) A lot of the early-2000s Java developers started working in Java as their first language. They hadn’t worked with components before, so they didn’t see a compelling need for them.

2) Economics. Open source became a huge factor in the Java world in the early 2000s, as people became disenchanted with Java Enterprise Edition and went off to invent their own enterprise frameworks. The net result was that the community became used to using free open source frameworks to build apps. In that environment, a company wishing to make money selling a widget library had to convince developers that it was worth paying for a library when one was available for free.

3) Drag-and-drop visual development never caught on in Java. We still build our user interfaces in code. Components become more obviously useful in a visual development environment. (There were some innovative visual development environments early in Java, but they’ve mostly fallen by the wayside).

4) On the positive side, the core Java libraries deliver a pretty solid set of functionality. This means that there are fewer gaps that can be filled by third-party developers.

5) The “patterns” movement also became a huge influence in Java in the early 2000s. Library developers focused on implementing GoF patterns.

6) It’s a bit more work to produce a JavaBean, rather than a Plain Old Java Object. Not necessarily a lot more work, but some, and you have to follow the same conventions across all the components you wish to treat as Beans.

Those are just some educated guesses. But for whatever reason, components didn’t catch on in the Java software-provider ecosystem, so they’re not typically used as core elements of development. I think this is a missed opportunity.

Advertisements