Pragmatic Dictator

The vast majority of server-side Java programmers have J2EE on their resumes, they pride themselves for being experts in this particular technology but there’s a problem. Many of these programmers have their minds warped into the J2EE way of thinking:

1. There is nothing beyond the database
2. POJOs focused purely on business logic
3. This is distributed programming
4. Ops is someone elses problem
5. Deploy more or bigger boxes to scale

Most enterprises can comfortably tolerate systems built this way but what if you’re not most enterprises? What if you are an eBay or a MySpace? eBay for example have thrown out almost all of J2EE and built their own libraries to tackle the problems they face around:

1. Monitoring
2. Hot Upgrades
3. Scaling

Basically once you’re beyond a certain level of challenge the J2EE way of thought and patterns of design don’t work. So where does one find Java programmers that can cope with such a challenge? They’re going to need serious knowledge of:

1. Deployment
2. Monitoring
3. Networking
4. FLP
5. SEDA
6. Threads
7. REST
8. …..

But put that on a job advert and see how many responses you get! J2EE is a raging success to be sure but if you’re a company that can’t use it you’re likely going to be a victim of that success when looking to hire server-side Java programmers.

All of this has me wondering how one should frame job adverts of this nature. Should we even bother asking for Java experience or simply drop the language/platform constraint entirely? What should we be asking for? Multi-user online game programming perhaps? What else?

Technorati Tags: distributed systems, gaming, Java, J2EE, Web

Update: I’ve added REST to the list as I suspect that it won’t fit well with existing J2EE-derived thinking.

Update 2: For an idea of MySpace’s challenges see here and here.  And then grab a copy of the slides from the Mix06 site entitled “Running a Mega-Site on Microsoft Technologies” (under Breakout, Next Generation Browsing Experience).

I see many a comment talking about concerns with roundtrips in SOA/distributed architectures. For example in “The Fractal Nature of Web Services” the author starts totalling up additional round trips taken once we disassemble what was a single app into separate remote services. He then goes on to walk down the well worn performance path expressing concern about performance etc.

His concern is certainly valid but it makes a fundamental assumption about how you implement your services:

Each service is represented by some stub that communicates via some protocol to some remote back-end. Clients access the service via the stub and thus incur remote call costs.

Further whether he meant it or not, the author gives the impression that SOA can only be done with Web Services which is absolutely not true. Your choice of method for implementation for SOA is determined by your chosen architectural constraints and can often (and maybe, should always) lead to a hybrid model with “public” interfaces exposed via WS-* or REST and others implemented in Java.

And this is where it gets interesting because with Java we can break the stub/remote back-end constraint. Why? Because we have code-downloading. We can construct a service implementation that offers an interface and is advertised in a service registry as usual but at the point of access, downloads it’s whole self to the client. The service then runs in the client’s address space.

i.e. We have what appears to be a remote service with none of the roundtrip costs because in fact it runs locally.

From a practical perspective that means we can do things like:

1. Create a service that wraps a database and contains all the SQL etc
2. Advertise that service
3. Client downloads service and all it’s dependent code and configuration
4. Client invokes on service
5. SQL connection is made to database
6. Queries are run against database

Now, were the service genuinely remote we would incur two roundtrips:

1. Client to Service
2. Service to Database

But because we can “inject” the service into the client we actually only have the roundtrip to the database. Things to note:

• We keep all the benefits of late binding of services and clients at runtime.
• We taught the client a new protocol on the fly - we downloaded all the client/database communication code at runtime as part of service lookup.

Technorati Tags: distributed systems, Java, soa

Now it’s Java properties.

I say once again - the last thing to do is to extend the language. Before that try a new API or have your IDE do it. In the case of Java properties I really don’t see any reason whatsoever for this being in the language as it’s blatantly something that can be done in the IDE plenty well enough. That just leaves a couple of arguments:

1. More readable - I can understand perfectly well from the method name what set* and get* do, surely I’m not the only one?
2. Reduces boilerplate - Indirecting through a method allows more flexibility and a modern IDE can fold these things away so we don’t have to see them. Finally, some boilerplate actually makes code more explicit and therefore more easily understood which is far more important.

Elliotte and others already have the rest of the reasoning nailed so I’m not wasting any more breath.

Steve Jobs had some bad stuff to say about Java and Jonathan Schwarz has responded as part of his most recent interview with Scoble. If you haven’t heard any of this before, get the scoop here.

Now, whether or not you agree with Jobs on his stance in respect of Java and the iPhone, he is right on one thing: Java is getting heavyweight. And it’s not because of the language or even the platform but the way in which it’s all delivered to the desktop, server etc.

It comes as a monolithic package, all or nothing. You can extend it via classpath or whatever as you wish but there’s something deeply wrong with this picture……

And that is the fact that Java is designed to be dynamically extensible not monolithic and static as is the prevailing pattern pursued by Sun’s JDK development team and the world of J2EE. Remember, Java in it’s early days was all about code-downloading and dynamic extension. Yet, all of those leading the Java masses seem to insist on ignoring this fact and continuing to build structures that are perhaps even less dynamic than C++ with shared libraries?

Worse, we’ve tried to fix this sort of thing by adding support for scripting languages etc “because Java isn’t dynamic”. And we’ve got all these static compile time constructs we’ve added when perhaps a better solution would be better support at runtime to trap and fix these problems.

We’ve been dropping the ball for a long time - we’ve ignored a core construct of Java and now we’re complaining about the consequences. To Schwarz, Sun and the Java masses, stop leading Java down the path of static, ever-larger, monolithic bloatware. Go back to Java’s core, fix it and start building again. If you need help with understanding what might need doing, go read this paper then go talk to OSGi and the Jini community.