I became a java developer (and not a C developer for example) because java takes a lot of the pain away. I just love the garbage collector. Sure it can give you a hard time, but 99% memory is not an issue in the projects I am working on. The object oriented paradigm also made it way easier to write the big complex systems, enterprise applications seem to be these days. In this layers of abstraction we do loose a little performance, or actually a lot, but again: 99% of the time performance of java code is not an issue at all. Performance is controlled by network and database access.

So I should be pretty happy right? Well in the general sense actually I am, but as a developer, I have the feeling that I am operating on the wrong level of abstraction. A lot of the time I am working directly on the code level. Writing getters, setters, exception handling, logging. There are some areas, where the abstraction level moved considerable upwards in the last years. Persistence comes to the mind. Hibernate is pretty reasonable, although it has it's problems, and it's enemies. Another one might be rules engines, I haven't tried those. But other then that ...? Of course there has been progress. A lot of progress. We have hundreds of languages, many with very interesting features. We have a large choice of databases with innovative concepts to choose from, and of course a pletorea of java libraries for almost every purpose. We have IDEs so smart, I sometimes wonder if they are really just another piece of code. So what am I complaining about?

I think it is about time for the next paradigm shift. Why are we still coding objects? An example: I want to build the ubiquitous shopping system. I take a jar I found somewhere on the web to get started. Of course I have my own little idea, about how this thing should work, so I want to tweak the shopping cart a little. So what do I do?

public class MyCart extends somebody.elses.Cart {

    public void setRealyCoolFeature() { ...

But most of the time, this doesn't work. Because the new attribute doesn't get saved in the database. Or maybe it does, but the repository returns only Cart's and not MyCart's. The gui doesn't show the new attribute, actually the gui of the component is for swing, but I want a web gui. No problem I can write that, but now I have tons of fireProperty noise in the code, that really nobody cares about. Of course it's better than the other way round, because it is extremely tricky get fireProperty calls into a class without changing the source files.

Hold on a second I know what you are thinking: You fix that with a little AOP here, and this won't be a problem if the component was cleanly designed in the first place. Agreed. But my point is: I want to use the concept of a shopping system. I don't want to deal with technical detail like AOP, IoC and similar. Or from the perspective of the component provider: I want to code the concept of a shopping system, and I do not care, how the users want to store it, how they want to show it, and how they want to extend it. That is what I'd call a new paradigm.

Of course I am not the first calling for the next paradigm since OOP. Actually there are many alternatives out there on various levels: AOP, Functional Programming, Meta Programming on the very technical side. Business Process Modeling, Rule Engine, and Components pretend to operate on a higher level, but sometimes I get the feeling they're just a glorified version of Basic. None of those come even close, to what I imagine. And I don't even use drugs to get there. Still there might be a solution in sight. Imagine something along these lines:

If you write a component, you use a language that is much more expressive than java, possibly like groovy but two steps further and with a strong type checking (I'm a fan of strong type checking). In this language you specify the structure (the relationships) of you component. Using the equivalent of annotations on stereoids you specify things like transactional behavior, logging behavior, GUI representation, concurrency options, but on a very high abstraction level. For example for concurrency you don't specify locks, latches and stuff like that, instead you specify data that is related and there for needs protection against concurrent access.

All this is not compiled into a single jar (or whatever we will call it), but actually ends up in separate ajars (Aspect Jars). So as a user, I can take the differnt pieces, and create a extension, specifying the various aspects in the same way, thereby extending all the aspects I need to extend. This is possible, since the aspects are still separated, and not compiled in one big blob. And the original developer separated those, because it was the easiest thing to do.

The guy actually using the component, somebody else created, and extended be  me, uses the components in a high level DSL, that allows him to glue pieces together. For example he could specify which kind of order and invoice component should get created from the cart component. And although the three components come frome completely distinct developers, they would be joined automatically using domain information from the semantic internet. This joining would of course need some tweaking but it should give you a head start. I think this sounds extremely nice, doesn't it?

Will it happen? Most certainly not. The description is to specific to fit whatever comes, yet way to vague for anybody to actually implement it. BUT I am pretty optimistic something along these lines will actually happen in the next 10 years. DSLs and AOP and new languages that allow Aspects to be written as easily as a for loop will be key players at it.

So if you are a genius with lots of time and a strong developer team at hand, get into contact with me to exchange ideas. If you just a stupid enterprise application developer as I am that needs a job for the next 30-40 years to come, get used to AOP, watch the new languages and don't worry to much about concurrency.