Ted Neward is an independent consultant specializing in high-scale enterprise systems, working with clients ranging in size from Fortune 500 corporations to small 20-person shops. He speaks on the conference circuit, including the No Fluff Just Stuff Symposium tour, discussing Java, .NET and Web service technologies, focusing on Java-.NET interoperability. He has written several widely-recognized books in both the Java and .NET space, including the recently-released "Effective Enterprise Java". He lives in the Northern California area with his wife, two sons, two cats, and eight PCs.

Hi Ted, would you like to introduce yourself to the community?

Nah. My name is Ted Neward, I'm the Editor and Chief of TheServerSide.NET, I'm also a long time Java author and provocateur and I've been called other names, not many of which are pronounceable on public video, so we'll just leave it at that.

You've just written "Effective Enterprise Java". That's a pretty bold move. Why'd you do it?

Well, you know, I got really drunk one night in Vegas and next thing I know I've got a signed contract in front of me and the folks at Addison and Wesley were like: When can we expect the book?

No, it was--the genesis of this book is actually somewhat interesting. Initially, in a former life, in a current life, I'm a Developmentor instructor as well in both the .NET and Java curriculum. And Developmentor has a book series with Addison and Wesley and shortly after Don Box left to work at Microsoft, I was up visiting him in his office and I said: Ya, we'll talk a little about Java, Enterprise Java, EJB, blah, blah, blah

And he said: Dude, you should do this book in the Developmentor series with Addison and Wesley, and Don, when he's got an idea in his head, he moves immediately on it.

And so, next thing I know I get an email from the folks at Addison and Wesley saying: Hey, we hear you've got a book idea. What is it? Talk to us about it.

Well, I met with the editors at Addison and Wesley and said, basically, what I want to do is a book entitled "EJB Sucks" and the editors at Addison and Wesley convinced me, it wasn't very hard, that they could not realistically sell a book entitled "EJB Sucks". For some reason they didn't think the EJB community would go for it.

So we talked for a bit, and this was at about the time when the "Effective Series" was starting up. "Code Reading" was just underway and "Effective XML" and of course everybody knows about "Effective C++", "More Effective C++", "Effective Java". And they said: Well, how about "Effective EJB"?

And I said: Well, I don't want to talk exclusively about EJB, how about "Effective Enterprise Java"?

And the said: Great! Sign here and let's go.

And this was about two and a half years ago. This book's being under development for quite a while and it's undergone and interesting transition from where it was to where it becomes.

How has it changed?

Well, initially a lot of the book's items, they're written in the traditional effective style. Here's the single sentence item and here's the explanations behind it. A lot of the book's items really started out as kind of negative items. Don't do this, Avoid this, This sucks.

And one of the beautiful things about writing in the Effective series is you get Scott Myers as an editor, and Scott is an amazing guy. He just has this ability to reach in to your pros and shred it in such a constructive way that what comes out of that process is so much better than what went in, quite frankly.

And one of the things that he said is: Look, don't tell someone what not to do, tell them what to do. You can have a couple of "Don't do this" kinds of items, but for the most part, focus on the positive. And so, the book sort of transformed itself in to this, instead of: Don't use entity beans, right, which is an over, simplification. But instead of "Don't use entity beans", instead it became: Prefer objects first, persistence to preserve your domain model. And it's just a better way of saying, basically, the same stuff. But in a lot of ways, the deeper genesis was I came to realize, for all this was, EJB doesn't suck, it's just been horribly over sold.

So what's good about it?

Well, EJB is really all about transactional processing. I mean, at the end of the day, you go through the EJB spec and easily 60% of the entire spec is talking about transactional this, transactional that, transactional the other thing. Some of the remoting aspects, they're very quickly taken care of. Some of the life cycle aspects, very quickly taken care of. This is not hard stuff for them to do.

The hard stuff, in many respects, was the transactional support. The distributed transactional support for: When do I specifically start the transaction? When do I implicitly commit the transaction? Etc., etc., etc. And the problem that we face with EJB today, in my opinion, and always prefaced with my opinion, is simply that I thought is was over sold.

I think it was really a situation where Sun and their associated partners, vendors, whatever you want to call them said: We see the success of NTS, COM+, and we want some of that love, and we want to try to build upon a market and it just spiraled out of control. Enterprise Java Beans should never have been called Enterprise Java Beans, there's 101 EJBs damnation lists out there, and they said it best. It should not have been called Enterprise Java Beans, it should have been called Transactional Java Beans, because that's really what the spec focuses on.

That's really interesting because in TheServerSide Symposium conference in the last few days, they've been talking about EJB3, it's almost like they're trying to make it even more general. What do you think about that?

Well, EJB3 is interesting. On the one hand you're looking at it and you say--basically what EJB3.0 has done is remove angle brackets, they've just removed deployment descriptors from the Java architect's perspective. There's just no more XML. We're all using metadata attributes and right now that's the politically correct thing to quote. "Oh, we're using metadata, we're metadata driven, we're annotated driven," you're going to hear this over and over, and over again over the next six months, I guarantee it.

But, they really haven't changed their perspective and focus in many respects. The emphasis, unfortunately, in my view is still back on the entity beans, it's still back on object relational persistence and unfortunately, they still insist on an objects, and only objects, view of the world. And I just think, ultimately, that's a limiting perspective.

What would you have done if you could have gone in there, waived your wand and come out with EJB3?

They'd make me God over the spec maybe. Well, step one, every distributed technology that we're looking at today; the Web services stuff, you go back and look at CORBA, you go back and look at RMI, even look at Servlets. Every one of these technologies has some kind of interceptor capability. Servlet filters, CORBA interceptors, the RMI service socket factories is and opportunity to put in your own hooks, particularly if you're using dynamic proxies and so forth. Everybody's got an interceptor stack, except EJB, where arguably it's the most necessary.

So, step one is let's just take a month, because that's all it's really going to take. Let's just take a month and write a stupid little interceptor stack. Just take JAXRPC's handler API and just adopt it and move that over and standardize that as part of the container.

Why do you think they haven't done that?

Well, there's a variety of answers that one could give ranging from the conspiracy theory to the "can't do anything by committee correctly". I don't really want to speculate why they haven't so much, as I want to try to build momentum to force them to. I really, sincerely believe that the EJB3.0 spec is on the right track with their pursuit of simplification.

I think that if they could create an interceptor stack for the container, such that they would standardize, I think that they would open up a large degree of customization that would be in fact standardized across the containers. I think a large part of the problem would be the backwards compatibility. Will these EJB interceptors, will they apply to EJB2.1, 2.0, 1.1Beans, etc., etc., etc.. I think that's probably where the sticky point would be But frankly, for my money, let's do it anyways and just say that they don't apply to 2.0 and 2.1, and I'm happy, let's just ship it.

How important do you think all this backwards compatibility is? Some people would rather make with EJB 3.0, have it optional to be backwards compatible, and then if you've already got an application, you choose a vendor that happens to have that check marks. What do you think about that?

I think it make sense to a certain degree. I think it makes, I think it opens up some opportunities for some new players in this phase and the conspiracy players will say well that is why they do not want to do it. Unfortunately, I think the expert group, this has been getting better over time, but I think the expert group is a little over dominated by the vendors. I really do I think. You go through the EG member lists and it is rare to find an individual frankly. On the JSR175 Group for example there is like two or three individuals and the rest are all vendors of one form or another and that just worries me.

What was your experience being an individual in the group?

Oh, I loved it I loved it. I thoroughly recommend the opportunity to work within the community process. If only because, you know, as much as people may not like the reference, it is interesting sometimes to see how sausage gets made right. Go inside the sausage factory and to see what gets done right. We have all heard the horror stories and to see it for real right, I mean everybody knows about the whole logging experience, Log4J, and what a complete travesty that was, you know, and if you want to see conspiracy theory, you can see that, it is not too under.

The experience of 175 was wonderful. I do not know if it was just because of Josh Block as an expect group lead, I don't know if it was because we all sort of knew that this was going to be a big thing and that we wanted to get something good done. I do not know, maybe we just all like each other and you know we did not all agree.

There were a lot of cases where we wanted, you know, person A wanted to do feature X right as part of the annotation spec and we sit down and we have reason discussions and you know, there was emotion. These guys are all passionate about Java and what they see as the necessary steps, but we all, you know, at the end of the day there was no melodrama. It really was a good experience.

How do you feel it compares to the .NET attributes on the other side there?

There are a couple of really minor differences that, I don't think anybody will notice, but on the whole I think we have produced something that is just as approachable as the .NET spec. I think it is just as good truthfully.

What do you think are going to be some of the best practices or maybe even anti-patterns that are going to come out with Metadata?

Oh man. First of all I despise the term best practices. I mean just I had to fill that out simply because best practices implies that this is something that everybody should do in all circumstances and frankly there is no such thing and I would much prefer the more patterns like approach which is to say, you know, I have a problem in a context, I have a solution that yields certain consequences right and best practice basically says anybody who has this problem they should all solve it the same way and shows I can go red herring.

As far as the anti-patterns of Metadata, I remember when Reflection was introduced and JDK 1.1. I remember how many articles were written about use Reflection to do this, use Reflection to do that, use Reflection to cook dinner at night. I mean it was Reflection everywhere because this was new, it was weird, it was interesting.

I can do things I could never conceive of before. I have been reading some articles in Java World about using reflection to do, you know, servlet based systems, every single time a request came in and they were reflecting on a class and looking for method and invoking it. It was just Ahh! what a terrible idea. We are going to do exactly the same thing with Metadata.

I really sincerely believe that everybody and their brother is going to start looking for ways to use Metadata. I see it happening in .NET very frankly. And so we are all looking for ways to apply the bright shiny _____1329 to the problem of the today and we are going to do the same thing with the Java space and we are going to figure out what works and what does not over time.

Let's go back to the book. What are the other pieces that are on EJB that you talk about in the book?

Well. Most of the book really is about EJB per se, it is really tended to be a collection of patterns in a sense, but more in the, you know, the prose style, the effective style, which is to say in these scenarios you apply this rationale, this thinking. I remember very clearly Scott and I having a conversation one time about the reason why you always present sort of the context and the consequences of these items. He said he was doing, he had written effective C++ and one of the items there as if you override operator new, always override operator delete.

If you customize how things get allocated, customize how they get de-allocated, you have to. He was doing some consulting for a group of government contractors and they had brought him in for a three-day seminar or something like that, he said yes. So if you are override new, make sure to overwrite delete and they said Scott you can skip that one we don't need to worry about it and Scott said no no no, really you do need to worry about this.

No, no Scott. You don't understand. The systems we write are the guidance computers on a missile. If our program is successful, the computer is destroyed, Poof right, way out on a Sidewinder or something. At that point, you do not care about de-allocation I mean. If the PC is going to explode when the program runs to completion, you don't care about de-allocation at this point, a necessary, you know, it is a necessary element to say under the circumstances you need to do X, you need to do Y, you need to do Z and that was the large part of what I was trying to say. Right, that was the large part of what I came to over time.

That is kind of what the EJB does suck _____1525 came from. There is a place and a time for EJB, I think any of the people out there criticizing EJB have at least thought about it. I was talking with Rob Johnson at the Symposium, he said exactly the same thing like there is a place for EJB.

It is just not big a place as everybody has made it out to be and that is really what I am trying to bring out in the book. Be aware of transaction affinity, be aware of how many times you are moving across the wire, be aware of security elements, I mean very frankly the J2EE spec in my opinion it is a travesty how little it does for the security elements.

It is a little like declarative things I can do for authorization and so forth, but the rest of it they just pound on and I really think that they can go a long way towards better standardizing some of the security aspects of J2EE, so I talk a little bit about security. It is not an overwhelming treatise, but it is like five or six items that I think every J2EE developer at least needs to be aware of. Things like the SQL injection attack, things like sharing, user input, validate early and validate off and do not assume. That just because you are validating in your HTML form using Java scripts that it has been validated by the time it gets the server because attackers now have to use Telnet and makeup HDV packs so likely they can bypass your UR. I mean, lots of these kinds of things that enterprise developers just haven't been told.

So it is really a large part of what the book is trying to do is trying to say what you heard the design patterns, you heard the best practices, right, you heard all the stuff, but even so they focus on this amount of stuff and there is more to talk about. There is really a lot of more to discuss. So it is not limited to EJB in this sense.

Yeah, we talked before about some of the things that seem to be underused, like messaging, and things like that. You talk about messaging in the book right?

I talk about what I call context complete communications. You just stop looking at messaging and you start looking at for example Doclib or web services. You realize that these are basically two sides of the same coin. One has angle brackets and one does not, and so I was looking for something that has sort of captured that higher order construct, which is to say I do not want to deal with object RPC because that implies a certain amount of context. If I go often I create for example a stateful session bean.

There is an implicit state and an implicit identity that goes along with that object and I have to make sure I get back to that exact same object if I want to do more with it. So, I say start work, which means set some state, then I got to go to work, work work and, I got to do complete work, that context out there, I have to get back to that exact object in order to be able to reference the context that I have implicitly established.

I go through an example in the book where I talk about a telephone conversation right. Just like you and I are chatting, Hey Dion you want to go to lunch?, Sure, Where do you want to go?, How about we go to the Italian place down on the corner?, Great, When do you want to go?--and assume that right at this moment somebody walks into the middle of the conversation right--Lets go at 12, lets go where, who, when, you know what day? All of this implicit context which gets created as part of this conversational communication style.

A context complete communication style, it is much more awkward when you see it done out loud, but it is much more robust right. I can say Dion would you like to go to lunch? Ted, I would love to go lunch. Where would you like to go, Dion? Lets go to lunch at the Italian placed down on the corner. Dion says back, Ted when do you want to go to lunch at the Italian place down on the corner, I say Dion lets go to lunch at the Italian place down on the corner at 12 o'clock today.

You know, we look at this and we go, oh my god, this is hideous, but at any point in this conversation if you die, forgive me, if you die somebody else can step in and take your place and there is no context that got lost. This is exactly what Web services are trying to push. This is very much what messaging is trying to push. This is very much what stateless sessions beans are trying to push.

This notion of context complete communication, everything I need comes as part of this package and the beautiful part about that is when you do that, like even if it is a stateless session bean, I can take all those parameters, send them off to some kind of permanent storage and then if it container crashes I have not lost the call.

So, won't the OO guys cringe when they hear about this stuff?

Absolutely, absolutely, but like I said, I think that viewing the world from an objects only perceptive limits us, in depth as we all bought so deeply into this idea that objects are not only the best thing, but the only thing. They are the only way to solve problems and that is so stupid. I mean the is the carpenter, you know, the classic example like hammer and nail, when all you have got is a hammer everything looks like a nail.

We have been trying to solve problems with objects, objects, objects, since 1995 right with C++ and then later Java and now C#. I mean, objects are a useful abstraction, but at the end of the day, that is all they are, It is not a religion, it is not like you gain points in heaven for using objects only and you throw away procedures and you throw away transaction scripts and you throw away--it is one way of solving a problem and there are places where it is good, and there are places where it is not so good, and we are starting to run into those.

That's probably the same case for Web services? Where do you think Web services are going to be fitting in and how is that going to evolve in the next couple of years do you think?

Web services are a platform, may I note the speaker panel at the Symposium, I think it was Benjamin Renow the CTO of BEA, you know, Web services are not a platform, they are not a programming platform, they are basically an agreement on how we are going to package and ship stuff back and forth. But you know Benjamin, you seem like a great guy man, but at the end of the day, programmers think in APIs and if we go at Web services as a distributed object technology we are done.

It is just CORBA with angle brackets you just walk away it is not going to be any more successful then CORBA was. The key here is to recognize that distributed objects suck, but if we go off and we build an object system the way we traditionally build object systems inside the same process, when you try to distribute that, it does not work, it just does not work.

Now there are a number of people out there on the Web in blog space who are saying, well distributed objects right, you have to make them coarse grained, you just have to see this, that, pass DTOs around, that is not objects man. I mean, that is much object oriented programming as writing C code was doing object oriented programming.

What about Genie?

Genie's an interesting case. I think there is a lot we can learn from Genie. Very frankly. I wish I had time to pursue from my WebLog and from my web site, I talk about wanting to pursue the idea of Genie in enterprise systems. Because Genie is by definition a service oriented architecture. Oh god I have done it, I have said the buzzword, I am now officially BCA, buzzword compliant architecture. You know, Genie was all about services, it was all about explicit communication boundaries, it was all about making it clear, for example, that I am getting ready to call out of process.

It was really in may respects about policy more than it was about objects or for example trying to create this notion of interfaces and so forth. Right now, it is just a crutch to agree on context on both sides. They really encouraged what we are now calling service oriented architecture if we cannot get an agreement on what SOA is.

What do you think it is?

What do I think it is, it is a buzzword, it is a buzzword. It is an opportunity for those of us who sell consultant services to make more money, that is all it is.

Do you think we're, at the moment, technology you know, Dave Thomas talks about how we're marketing driven rather then technology driven. Are we going to be able to change that?

I don't know, it is not just that are creating this market though. I mean, if you talk to a lot of the developers, you talk to a lot of people who are actually getting ship done, lot of these guys, they're just like: I use whatever you tell me to boss; you tell me go into Java, I will go into Java; you tell me go in .NET, I will go in .NET. The people at the Symposium, the people on TheServerSide, they are the minority compared to the unwashed masses of people out there writing code on a daily basis.

The people who are actually writing applications, we are the architects, we are the outspoken. I will use the term that honey hates so much, the thought leaders and the people out there in the field, they want to write code and go home at five. So I do not know that this is something that the developer community can fix except possibly through education of our superiors.

I think Dave's right. Dave and I, we speak a lot together on the No Fluff Just Stuff Symposium tours and I heard him give this story over and over again and he is right. At the end of the day, we as developers have to recognize, particularly the enterprise developers, we have to recognize that we are just a means to an end. The key proposition here is business value right. We are hired to do a job, to make the business run more smoothly. We are not what the business produces. We are not the keys of the kingdom within the business. We are simply there, they could fire us, they can give it to every last one of us and the business would still continue.

It might be hard, might not be as efficient as we can make it, but we are not the reason that they are there, we are not the one that signs their paychecks, we are there to help, but we are not the key element. I think in some cases developers lose sight of that fact. We get so wrapped up in our little technology wars, our religions; I do .NET, I do Java, what not. Just grow up and recognize that all you are doing is looking stupid to the people who sign your paycheck.

We need to get back to what we were supposed to be doing in the first place which is making their lives easier and the longer we squabble about technology the longer we insist on newer and cooler features, I mean look at J2EE, look at .NET, look at Web services, look at CORBA, how many times do we have to reinvent middleware before we finally say we are done, it is time to move on to the next problem.

So, what is an enterprise developer anyway? Who should be reading your books and all that kind of stuff?

Well, an enterprise developer has this for an answer that is not an answer right. Enterprise developer is a guy who has enterprise software ' next question.

What's enterprise software?

I'm glad you asked Dion. Enterprise software is basically any software that basically shares data across people. People look at the vertical applications like Microsoft Word, and they say that clearly is not enterprise software. But if you look at the idea, for example, of multiple people having to work with Word or Excel files off a shared network drive, you run into exactly the same issues that we run into when we are trying to access a relational database. They have got concurrency problems, they have got load problems, they have got accessibility problems. Every time you are doing stuff, you are storing the file on the network share, doing a lot of back and forth, Word pushes the data out, pulls it back and has to check to see if the file has been in use by somebody else.

This is all enterprise level concerns. Of course, if I build a web application that runs on a server container that is running off of my local machine and nobody else accesses my machine, all the problems and issues that we deal with in enterprise software completely fall away. Nothing to worry about concurrencies, nothing to worry about transactions, you don't need to worry about remoting in some respects because we got in-process databases like HSQL and so forth.

The key element in enterprise software is the fact that two people have to use the same stuff at the same time. That's what makes enterprise a software and if you fall into that tab, you need to know about things like optimistic concurrency, pessimistic concurrency, can I do local modifications and update them to the database, do I have to worry about communications back and forth, and all this stuff starts to apply to you.

Now taking a step back away from the theoretical, who needs to read this book? You are a Java programmer and you write enterprise software, and if I can be allowed to be that arrogant, that is who needs to read this book.

So we have these enterprise concerns, transactions, and certainly others, and we also have simplification. How much of this stuff does the enterprise developer need to have in front of them? How much do they have to understand? And how much can we, kind of, simplify and wave our hands around a little bit?

I mean, this probably won't come as a great surprise to anybody who knows that you know I am a trainer, and an educator, and a speaker, and a writer. But frankly, I think that guys kind of need to be aware of a lot of it if not all of it. One of the chapters in the book, for example, is Systems; talking about class loaders, garbage collection, serialization and weak references. This is stuff you do not see in any other book and the reason for it is, the justification for it is, how many developers, all you out there, raise your hand if you have ever been bitten by the mysterious class cast exception.

You are twiddling along inside your servlet container, you can make a change to the code on this and the next time you hit this thing with a request obviously you're getting class cast exceptions everywhere. Then you go: What the heck stopped the container, get ready to attach it to the letter, you are back up again and the problem disappears.

You look at the code and you are like: My bean B equals ( ) my bean session that I can attribute or like my bean my bean, because this is an artifact of the incorrigibly busted Java class letter facility. I learnt class letters, I can be wrong, but it is horribly busted.

How? We ask too much of it. We ask our class loaders to be both a code loading mechanism and an isolation mechanism. We desperately need isolates. JSR, I don't even remember the number, basically, which sets off, in .NET we call it the _____ 3119. In Java we call it an isolate.

This basically is the same idea. If I want to call it code, if we are running side by side, an isolate can setup basically a barrier between us so that your classes and my classes are completely partitioned. It is almost as if we have two entirely separate garbage collecting heaps, and the media of the isolate is if I want to cross the isolation boundaries, I have to do so as if it is a remoting call. The isolate API had some abilities to sort of push things across using what effectively turned out to be NIO buffers back and forth, but it made it extremely explicit that you are crossing this barrier.

Class loaders would scoped to isolates with the exception of the boot loader. The most primordial loader. We desperately need this in Java, because we have been asking this isolation to come from class loaders, and the architecture was never intended to do that, and so you go off and you read like this, there is a white paper from IBM about their class loader architecture in WebSphere. It is arcane, it is the most God-awful thing you could possibly imagine and I just cringe at the thought how many complexity is there?

Just to do a simple problem of, I do not want my code and your code to conflict. I mean at a certain level you are almost tempted to say look we are just going to let one web app per JVN. If you have a servlet container I am just going to fire up a new JVN and run the web app inside of that then I can make my class code extremely simple, extremely straightforward. I don't have to worry about, for example, the servlet container having its class loader off the main delegation truce of the servlet container uses an XML parcel that is not the same as your XML parcel. Hey don't clash. It is a nightmare.

It's actually a nightmare, but this is the stuff that the J2EE developers got to know about. Because, at the end of day, this is the stuff that people run into in the field. So, you got to talk about this stuff. It has to be done. It is painful, but just go through the chapter read it and you will be a happier person for it.

What are some other things, like isolates, that we can look at the .NET world and use? Are there any others things that when you're working in the Java world, you kind of, oh I wish I had that, and vise versa too, .NET and Java.?

I really miss delegates from .NET and this was kind of what started the whole lawsuit between Sun and Microsoft, right. You can think of it almost as a Java language reflex method object or a function pointer if you knew what those were from C or C++, and the delegate concept basically gives me the ability to separate to decouple caller from target. Just like today, if I wanted to do that I can just hand you a method object and say: Here man, place your signature, delegates are strongly typed. Here's your signature, call invoked, pass me the parameters and you don't care where the call goes. It just goes off into the ether and eventually will come back with a return of type X that is step one of what delegates do.

Step two then is to say I can chain a bunch of these delegates together so that I make one delegating location. I say _____3456 and that multicast delegate goes off and makes one call to each target, so it is an immediate fan out approach, which lets me as a developer, just focus on making the one delegate call and .NET hooks events off of multi-cast delegates, so that instead of doing this anonymous inter class listener approach, which tends to lead to all kinds of memory leaks because you got all kinds of back pointers pointing in various directions and so forth. You think you have thrown away an instance of a swinging form and it is still floating around because all it takes is one reference to keep that thing alive and is just sitting there forever. Delegates and events are very tightly coupled in that sense that events use delegates. It is just trivial. You literally say form window closing plus equals new delegate is the object and method name to invoke. I know you can do this multi-cast stuff as I said.

Then you go to step three, which is the really really cool part, which is to say in .NET I have a thread pool, I have a delegate, put the delegate on the thread pool what a thread from the thread pool invocated. How many times haven't we written code like new thread (runnable instance goes here) fire and forget I don't care when it comes back. Just let it go and I do not care about the thread I just want it to run on its own. How many times don't we have to do that? How many different times hasn't one library or another one container or another written a thread pool.

We finally get this with java.util.concurrent. Now what is made is up with the concept of the delegate and you to just make it easy, trivial even, for me to just spin this thing off.

Where do you think the java.util.concurrent is actually going be used by the actual developers out there?

I think they will use the concurrency constructs to read or write a lot, the boundary barriers and so forth. The thread pool stuff I hope they do not use. Similarly from the standpoint that is really the container's responsibility if you're in a container environment. You should not be spinning off of your own thread form the servlet container. You should not be, the EJB spec forbids it. You cannot spin off threads from the EJB container because that is really the container's job.

That is one of the items from the book, let the container manage resources because the container at the end of the day can do a better job of it than you can. You think you know scope to your application, what you have to recognize is that particularly in the larger shots you are going to be deployed alongside of other applications who thought they knew what was going on. So, if you say to yourself, oh well, I know that a given two way CPU, Windows server, a Linux server can support up to 500 threads before we start to see a degradation in performance, and since I can see that I am only going to be supporting 50 concurrent clients at a time or I will just spin off the thread left and right and do all this other stuff that I want to do.

While you spin off 100 threads, they spin off 100 threads, you are mixing it up, you are all competing for that crucial little time slash where you have gone way down the other side that the point of definition returns, but the container has the resources. It should be, and hopefully it will be, but I doubt we are going to see it in our lifetime.

There should be an API from the containers, from the EJB container, from the servlet container. Let me pass you a runnable, you invoke it on a separate thread. I mean how hard will this be to do? Let the container manage the threads because at the end of the day it is important in some cases where we have to do a certain amount of polling. We have to do a certain amount of non demand driven behavior. It used to be there but it is not.

What about things that when you're working in .NET that you wish you could have taken over from the Java side?

Lets see, I think very frankly that the in the J2EE architecture--I am not going to get myself into trouble with my, you know, my Microsoft buddies--but I think the J2EE architecture is a bit more thought out, I think it is a bit less ad hoc than the COM+/.NET architecture. I think in some cases Microsoft has too much on making sure that all the cool stuff comes from them and I think they have not focused enough on trying to build an ecosystem of people doing interesting things.

I just joined, you know, I just signed my name in blood on some piece of paper that Rob Johnson gave me, I just joined, for lack of a better term the spring.net effort. I am probably not going to get a chance to write much code, but I will, you know, advise and talk and try to show them the .NET way as opposed to the Java way. It would be interesting to see what happens at spring.net particularly in the face of Indigo and what is coming down the pipe from Microsoft.

In terms of some concrete things in the Java space, I love Servlet filters. .NET has what they call HTTP modules, which you can almost think of as like events in the pipeline. So at predefined points you can register callbacks basically and as the request moves down the pipeline, they will call you. The filter #1 is a much simpler model and it can achieve much the same degree of support by chaining filters in front of one another, again it has interceptors for HTTP. The other thing that I can do with the filter, that I have not yet seen how to do in ASP.NET, is I can replace certain elements of the request with my own custom implementations.

So, for example, if I don't like the default servlet container's session mechanism and I want to use something like Genie, Java spaces or IMT spaces or I want to go off to the database. I just write an HTTP session replacement and then do a request lapper, but hand back my session instance instead of the default one. There is no way, no documented way at least, but I seem to do this on ASP.NET and very frankly I think that is something that is .NET likes. People ask me all the time, which one do you like better? Java or .NET? I say neither. They say no, no, no, really, nobody is around, I am not going to quote you, what do you write code in on a regular basis? And the answer is I do both.

I write some Java code, I write some .NET code. In some cases it depends on what it is exactly I am trying to do. A bit right now I don't trust IIS so my web login limitation is written in Java because I have got Tomcat running on my box, you know, could I rewrite my web login in .NET and be happy about it. Sure and so would they. At the end of the day, these are just technologies. These are tools on your toolbar, couldn't make it amount to religion. We have enough religious strife in the world can't we all just get along?

What do you think about the dynamic languages that seem to be getting a little bit more steam?

You got Groovy and Ruby and suppose, I think it is good to explore primitives frankly, you know people have been reading my web log now that I recently picked up Smalltalk. I downloaded the Smalltalk implementation, I started playing with that because I have been reading various--I forget exactly what it was I was reading--but I don't know how to write code in Smalltalk, I can sort of read it. I don't know how to write code in Smalltalk. I want to know what the big deal about Smalltalk is?

What is the zen of Smalltalk? Why are these guys so _____4233, they are raving right. You start talking about OS2, you start talking about Smalltalk and they start drooling and I'll flex the _____ 4240. It is so dedicated to this platform. I want to know what is going on with this, and I can see sort of what makes Smalltalk interesting. I can see sort of what makes them happy, right. The same thing is true with some of the dynamic languages. I think there are things that we need to explore with the dynamic languages, that Java needs to explore, that .NET needs to explore.

I think .NET has stolen a march on Java in the sense that they are explicitly language agnostic, at least at the CLI level. Now, certainly there is a bias inside the CLI towards object oriented languages like, surprise, surprise, C# and J#, and you know C++ and so forth. There is a lot of interesting stuff. I talked with James Strachan, Mr. Groovy and, you know, if I can find somebody to cover my mortgage for four months, I want to go off and do Groovy.net

I want to see what it looks like, I want to see what, could I get closures and delegates have this really nice energy. I think it will be a beautiful thing. You know there is already an implementation of Smalltalk for .NET X#, forget who does it, but you know you go to God's home page, www.google.com and they will tell you as X# out there implementations of prologue. There is some functional languages, there are a lot of interesting things that are happening in the .NET space from a language perspective, but I would like to see Java get some more of.

What about the whole X# thing. What's that?

X# is kind of interesting, right. In October, during the week of PDC we also had OOPSLA down in LA, but at least what parts of LA did not burn out. That was the week of the wild fires and so forth. X# is a research project within Microsoft, that initially, they sort of denied existed, right. A part of the reason, Microsoft does that is they get accused of bugs so much, that you know a lot of times these projects do exist, but they never make it out the door because they are just research projects that proves a concept, so you have to be careful about it. Unfortunately, these things still manage to get out, X# was one of them.

The basic idea is right now we have languages that understand objects as a first class concept. What we do not have are Tupples as the first class concept.. What other people would look at as a relational table row. It is not a quick class concept. We have to go add it to these objects APIs like JDBC and the same thing is true of XML, right. So, if I want to consume XML, I have to go though this object API like DOM or SAX or JDOM or stacks or whatever, pick your favorite one. Eric Meyer, the guy who invented X#, which was also known at one point XEN.

Basically they just made Tupples and XML first class concepts in the language. Lets just be able to take an XML fragment and treat it as a literal instead of as a string that used to be parts. Just treat it as a literal, be able to create classes using Schema, for Web services this stuff makes a hell of a lot of sense. Some inspection went down this road once already in the Java space, we call it SQLJ and SQLJ had has this incredible ability to compile by SQL code at the same time I compiled my Java codes.

So, I can get statically, tight check, SQL instead of waiting until runtime to see whether or not the query works and everybody was so thick and focused on objects again, but they said: Oh! Embedded SQL, well nobody wants to touch that. You know, download the reference implementation and play with it. I think people will find if they give it a fair shake, that SQLJ has some really interesting properties to it like these, these static type. XEN is just an extension of that concept.

So how important is all this static typing to you?

Well, Java is a type safe language, right. We work back, if you go back years ago and you look at C code and so forth, they went to a stronger type system because I mean I need to break this to anybody if they are already not aware of it, but programmers make mistakes, right. I know, for example, Dave Thomas, a couple of other guy, say we do not need strongly typed programs, we need strongly tested programs. That is fine, I will give you that, right. Yes, we do need an element of unit testing in our code, but I do not necessarily think that we can just rely on unit testing, which is not intended to be comprehensive in the first place remember.

Ii is intended the focus on, find a sweet spot between the code that is most often called and the code that nobody ever calls except in edge cases. Unit tests are not supposed to find the edge cases. We think about what is the possible edge cases and if we find a bug, we write in the unit test to verify the bug. All of that is good but there is a security concern that goes on with this. If I can mark up a type at runtime, then we are opening ourselves up to a certain class of command injection attacks like SQL injection, but at a language level.

I think that a lot of the Java code access security model, the Java platform security model bases itself on the idea that types are static, that types cannot change once they have been defined, that we know who is calling what, and when, to make sure that you are not accidentally accessing private fields and so forth.

I mean there is a lot of goodness in a statically typed language and I think we do not want to--the image that comes to mind is the one that was used on the panel at the Symposium. If anybody has ever watched second graders play soccer, as the referee used to call it bunch ball. The ball goes over there, the goalies stand inside the goal at either end of the field and 20 kids follow the ball, just the entire 4 quarters, the ball goes this way Pfrrrrrrrr, the ball goes this way Pfrrrrrrrr. I kind of feel that we are doing that as development community, Object oriented Pfrrrrrrrrr, aspect oriented Pfrrrrrrr. We just keep running around following the ball.

I think we need to stop that. I think we need to explore dynamic language and I think we need to explore loosely typed systems. I do not think that means you immediately drop Java and run off to Groovy and start rebuilding everything in Groovy. I think Groovy works great for small-scale systems. I am not convinced that it's going to work for large-scale systems like the kind of things J2EE was intended to solve.

But then that kind of brings us back to "What is a large-scale system". I mean is it 30% of the things out there, 10%, or is it just 0.01% of the things people are building?

That is a fair question, and I do not know the answer to that. It is kind of like the supreme court justice who said "I do not know what pornography is, but I know it when I see it." I think it is one of those things where you just sort of get a sense after a while that this thing is starting to move out of your control.

I think that for the way they taught us, for example, in vision the use of Groovy, he envisions lots of little atomic program working together, and there, I think that is a good use of Groovy, because if it is small and atomic, one guy can walk up and maintain this program, certainly small a scale system.

If you look at some of the larger you know million lines of code J2EE systems out there, that is not small scale. Whether that is medium scale or large scale or enterprise scale or Oh My God! Scale, it really to me is kind of a differentiator, small scale versus large scale. If I have to have a team of multiple people and if they are not touching each other's code on a regular basis, I guess that would be my definition of large scale. If there is a code you have not touched in three months, and nobody else has touched it that is probably a large-scale system. Just off the cuff definition. I am sure there are holes with it, but that is just kind of my gut reaction.

Like if there's code that no one in the company actually knows what's going on anymore. There's code [...] around.

Well, we call that C++, but, I think that is the code that desperately needs to be refactored, lets do that. I will say that right now, it just works. No I mean, it does not even have to smell bad, it is just we wrote that. It is done and yes we call it and someday we may change it because there are new features coming down the pipe and so forth.

I think today's message in particular needs to be heard that we want to favor smaller atomic programs like the set of UNIX utilities. That is really what the whole restful model is all about. You know just small atomic well defined APIs, well defined command sets that are restful, UNIX program uses pipes for example, take input over one pipe and send the output over another pipe.

I think we should be striving to do that. That is probably the reason why I like messaging so much as it re-enables that kind of--here we go, more acronym soup--we are now calling it ESB Enterprise Service Bus.

At the end of the day, it is just I am throwing stuff out onto a common well known place where people can pick it up whether is Java space or T space whether it is UNIX command line pipes, whether it is JMS. At the end of the day, it is just the data that you care about wrappered by something a JMS message construct with some headers or just a SOAP message. It is the same basic idea. We need to focus on building smaller atomic programs other than these big monolithic monsters that just require a team of 20 to compile a silly thing, that is obviously not working.

What are some of the performance things that you talk about in these large- scale systems?

Probably a good number of the items can be summed up in three words, "avoid round trips." I do that because now nobody is going to buy the book, avoid round trips, great, I am going to buy the book. Avoid round trips is basically saying, avoid doing really slow stuff like pushing data across the wire. That is why we say you know coarse grained interfaces. That is why the sessions side was first created. That is why a lot of people say, do not use distributive transactions because there is a lot of back and forth communication there.

A lot of the stuff boils down to avoid round trips, and there is a large number of variations on that, which is why that is not like the one and only time I say that. I think probably from a performance prospective the biggest thing I want readers of the book to understand is the difference between a performance problem and a scaleability problem.

Case in point, we are here in the middle of this really, really big hotel with 4000 rooms in this hotel. Imagine for a moment we have, let us say, 4000 bathrooms stalls behind one locked door, and one key and, okay how fast you are at going to the bathroom. You will never be able to service everybody who needs to go, particularly around about 1:30 or 2 o'clock, it is just not possible. This is not a performance problem. Making the toilets flush faster, making people take less time in the stall in not the answer to the problem. The problem here is to get the lock off the door. To make that just a standard revolving door and put the locks on the stalls. That is a very crude level.

That is basically the difference between a performance problem and a scaleability problem, and people think that: Oh by throwing more hardware at this we solved all of our performance problems. Building more stalls does not help if it is one lock on the door with one key. That is just not going to work. We need to recognize the difference between them, and in some cases you choose to sacrifice performance in favor of scaleability and that is a good thing if you have got a wide scaling application.

So how do you unlock the door?

Well, you find the locks, you find the places where you are taking out locks. If I could require something that developers are in my teams in J2EE, I would require them to tattoo across their forehead that contention is the enemy of scaleability. That any time I take out a lock somebody else is going to want that lock. So I need to minimize the amount of time I am holding that lock.

At the end of the day, we can't get away from locking entirely because this all about shared data, but I need to minimize the amount of time I spend holding that lock. Lock as little as possible, for as short as possible and there is a wide variety of different ways we do that, job synchronize monitors with transactions, fill in the blank.

You got a chance to say one thing here to the TSS.com Community, what do you want to say?

One thing to say to TSS.com: Do not fear .NET truthfully, don't fear. It is not a Java killer. And Java is not a .NET killer. You know this is not a religious war, we don't want it to be a religious war. There is enough religious strife in the world right now. We have got enough problems between Christians and Jews and Muslims and Hindus, you know, leave that to the politicians leave that to the people who have their own agendas to push, let us not create another division in the world. At the end of the day we all want to have a job.

We all want to have a job we enjoy. We all want to remain gainfully employed. Really, a lot of this concern is rooted in, am I still going to have a job when I go back to work tomorrow. You know don't fear, these two platforms are so similar that a Java developer can walk up to .NET and really understand a good part of what is there and in many cases you will understand the platform better than the Microsoft COM programmer who is coming to .Net because the two share so many concepts.

You know, whatever your political concerns regarding Microsoft are, I think if you ignore .Net you do so at your peril, because I fear this is just quoted over, over and over again, by 2005 over 80% of programmers, people out there, will be having to deal with a heterogeneous .NET J2EE scenario. You can either adapt to that or learn this very special phrase that will help in you in your next career. "Would you like fries with that?" it comes down to that.

Well, thank you brethren for putting a Tech Talk on the TSS.com side. Thanks a lot.

We've got to stick together.

Dion: Thank you.