Summary
My discussion with an experienced but disillusioned Java programmer
Advertisement
In my last newsletter, I laid into those who criticise Java for what I see as simple jealousy. That lead to the following discussion with one of my readers, who I call "B" (I'm the "J" correspondent in the following discussion).
B. I've been a J2EE programmer for 3 years now, and a Java programmer for 6. But, I only use them to pay the bills. Never under any circumstances have I written a personal application in Java. I feel I fall into the category of one who thinks Java is woefully uncool, and knows intimately why.
J. Okay, I've been one for 9 years, and written dozens of personal Java apps. And enjoy it all the time. But let's hear what you have to say.
B Firstly, you said 'In I.T. it seems, only new or unsuccessful niche things are cool'. Well UNIX is still cool... as is C... and they are both older and more popular and more successful than Java. You can't hop online at all these days without using both of those technologies... the same cannot be said about Java.
J. I'd hardly call Thompson and Ritchie's Unix cool. Or BSD. Maybe you mean Linux? Or do you throw in those early ones and the whole of HP/UX, Solaris, RS/UX, to mention but a few? Linux isn't so much cool as a stand against M$.
J. And C is cool? I think you are living in the past. C is a workhorse, but cool? To say that a 35 year old language that is still going is more successful than a 10 year old language that is still going is a truism. And Fortran is even more successful than both on that basis - there is still more scientific computing using Fortran than C or Java. Though my experience is that Java is finally weaning them off Fortran. But I don't understand your point about hopping online. Mosaic and IE were written before Java was released, and all commercial browsers are derivatives of these, so that is hardly surprising. Are you suggesting that if Java is a better language, then everyone should quickly move onto a Java based browser? Why? Technology that works should be used until it no longer works - our industry has a woeful inability to eliminate bugs rapidly, so the older the product the less buggy.
B. Most of the folks I talk to think C is 'cool' (along with BSD), mainly because coding it gives you the bare-metal feel demanded by hard-core programmers. Its not great for consultants, because of the learning curve, and you have to reinvent the wheel sometimes. But Perl and Python can save you there, with even less code than Java.
J. Okay, I guess we'll have to disagree on this one. I just cannot see C or BSD as cool. For "bare-metal" feel, Perl is way nicer, you can hit any sys call in a very flexible way, and it is way more dynamic. I used to do that kind of thing. But nowadays that's real boring. The action for me is a "bare-web" feel. And if you want to hack around the web, Java is perfect.
B. Okay, we'll agree to disagree. Let's move on to your 'J2EE is in a thousand successful commercial applications and cannot be considered acedemic'. But you didn't really address the question there. J2EE is woefully academic - they focus far too much on what is RIGHT, as opposed to what makes sense from a practical standpoint. Alas, the most popular piece of the J2EE framework is JSPs, and almost didn't make it into the spec. Its popular in large part because it is INCORRECT. There is no MVC, barely any seperation of components, its all one big mess. Its the most popular piece of J2EE because its least academic, and most like those horrible ASP/PHP frameworks... and nobody at Sun has bothered to understand why.
J. But JSP is J2EE. And so is JDBC. And JMS. And Servlets. I suspect you mean EJBs when you are talking about academic. But EJB shortcomings are well known in the Java community. Personally I normally recommend not to use them unless you know why you need them. Why tarnish the whole of J2EE because of EJB? You might as well say Linux is a failure because it has fragmented into multiple versions. You can always find things to pick at in anything.
B. Okay, I'll make this point: if J2EE worked as well as other frameworks did, then what would be the purpose of your site? Why on earth would so many people be begging you for performance tuning advice, or tips and tricks for avoiding J2EE pitfalls?
J. You've got this backwards. Java made my site possible because there are so many tools for Java and capabilities in the JVM. Kirk and I made the site a success by working damn hard. There are plenty of other tuning sites for different things - like linux, just about every database, C, C++, and much more. When I was researching for my book, I gathered together a whole list of C tuning stuff - and found half a dozen books with one or more chapters on tuning C programs. And I found many C programmers bemoaning that lack of tuning information available for C. I just wasn't interested in writing a 'C tuning' book. There isn't a language that doesn't need tuning, because of human programmer inefficiencies, and because of the number of possible contention points in any complex program - especially concurrent request handling distributed applications.
B. Let's move back to the core gripe. I like Java... I just dont like the direction its been heading for the past 3 years, and I dont think it has much of a future. And I'm not alone. Half the Java programmers I know feel the same way... the rest either dont know any other languages better, or have faith that eventually Sun will make things work well.
J. Chuckle. Well I guess I'm betting my career that you are wrong. I'm sure there are better things than Java. But not at the moment, at least nothing mainstream is in my opinion - not C, C++, C#, VB, Perl, PHP, Delphi, Python, SQL, Javascript. Which are the next 10 most popular languages nowadays. Of these, Perl is nice, and I still use it for lots of things. But back when I was a full time Perl programmer, we tried to build large scale projects with Perl and found it impossible, the stuff was just unmaintainable no matter how rigorously you tried to follow a set of coding standards. A 7,000 class project in Perl would never be feasible. A 7,000 class project in Java is commonplace.
B. My main gripe is that Java peaked in 'coolness' around about Java 1.1. Since then very little work has been done on the 'guts' of Java, and instead they kept focusing on bigger, more academic, and more bloated features. Java 1.2 added 'Swing', the academically correct yet ultimately useless GUI toolkit. J2EE brought us lots of things very few people need (like EJBs, JNDI, and RMI in general), as well as old concepts from people outside the J2EE group entirely (Servlets, JSPs, JDBC, JMS, etc.) Even today, some of the 'coolest' Java work these days is being done by IBM, not Sun.
J. I think this is called "making it a success".
B. In the minds of hard-core developers, allowing the branching of Java is the only way to ensure it can evolve into a better language. In the minds of consultants and project managers, branching is ALWAYS a nightmare, so it should be stopped. Problem.
J. Again, I guess we'll disagree. I see Linux fracturing as one of its really big problems. It would be significantly more successful if there was one guaranteed version rather than a free for all. And that's exactly the reason Windows beat out the other Unix's - MS guaranteed a single reference point compared to the Unix vendors who fought each other into a lose-lose situation. Saying you support Java branching is the same to me as you saying you want .NET to become the monopoly developer environment.
B. The most insightful comment I saw on this subject was on Slashdot, where somebody said with all sincerity, that Java will be the next COBOL. Not that Java isn't a better language, but it will be what a lot of overly complex business apps will be written in, for better or worse... and they'll always need to be maintained. Good news - you'll probably always be able to find work if your speciality is J2EE.
J. LOL. Everything is the next COBOL. I didn't find that insightful the first time I saw it in the 90's, and you probably saw the millionth incarnation of "X is the next COBOL".
B. When the hard-core programmers stop thinking Java is 'cool', they stop making those so-called niche programs that extend it. And where would you be today without those crazy guys? Without Servlets, without JMS, without JDBC, without JBOSS, without STRUTS, without OSCache, and without Log4J. You should be VERY worried that they are leaving Java in droves, while Sun is tightening its grip... because now you have to rely on Sun alone to save Java.
J. Except there seem to be more and more projects in Java every day. And no, I'm not in the least worried, because I don't see people leaving Java in droves, I see them coming all the time. I guess we just move in very different circles. When Perl was becoming popular and CPAN was being set up in the mid-90's, I was in there helping do some (a very tiny bit mind you) of the core. The excitement was fantastic, and the result was a set of supporting modules which surpassed anything I ever believed possible. More comprehensive and extensive than anything any other language had. And Java has surpassed that as far as I'm concerned. Only recently mind you. But that's not surprising, its only just beginning to mature.
B. "I guess we just move in very different circles.". Bingo... the people you know and trust think Java is 'cool,' whereas the people I know and trust think its 'uncool.' Therefore, I see people leaving in droves, whereas you see people coming. So the question boils down to, which group is more reliable in making that judgement? Probably neither... but I'm still going to rant a bit more.
B. I generally attend O'Reilly conferences, since all the other ones are too full of marketing fluff for my tastes. 5 years ago, people were all excited about Java. I talked with a lot of the guys making Tomcat, and the guys who literally 'wrote the book' on a lot of the killer Java technologies, and J2EE. But recently, the people excited about doing work in Java are few and far between. Most of those guys have moved on to new projects, many of which do not use Java. And even those who do still work with Java criticise Sun and Java regularly because they are too focused on bloat, and not on functionality. A lot of them are closet Python or Objective-C bigots. Its really really rare for me to find somebody excited about using Java. And I also see no 'converts' anymore. Nobody who was using Perl or PHP or C who finds Java and says 'now THATS the way to do it!' It used to happen, but not in the past few years. How about you?
B. Without those crazy hackers (O'Reilly lamely dubbed them 'alpha geeks') thinking Java is cool and extending it... well... I'm concerned that Java will cease being innovative. Because Sun certainly doesn't get it. Maybe being closer to the Java pulse you know about some cool projects that I dont... but Ive been looking... and everything at java-source.net and sourceforge.com is just the same thing over and over. Extensions of old ideas, or ports of applications from other languages. Nothing new...
J. It's those different circles. I see lots of great creative projects hitting exactly the sweet spot for me. Standardized APIs to expert systems, fuzzy logic additions, internet spidering, better data structures, CRM projects, Java games, all the stuff I can use to do the things I want. Again, I guess we'll agree to disagree.
When I see people talking about Java this way, I sigh. What I generally see is people that have a very narrow interest in software systems. All the problems and all the solutions that they have seen or created are so anti-object or hardware-centric that they would truely be nasty to recreate or interact with the Java platform.
What is happening is that there is still a group of hackers that are so focused on old hardware centric problems and solutions that they can't step up to the next level and see how many really exciting applications there are, which are really abstract and really separate from hardware concerns.
As software systems have evolved, we've seen this take place. The people who have always designed OSes and drivers have that mindset. That's a box that they are stuck in it seems. If you've experimented with enough different types of applications using Java, I think that you will have seen the wide range of benefits that the language and the platform provide to solving problems.
Add on all the J2EE people who haven't learned about Jini and you've exposed another boxed in crowd...
<i>>...Standardized APIs to expert systems, fuzzy logic additions...</i> Hey Jack, can you post some links to these? (Or should I just search SourceForge?)
Although I have to admit I side with B at heart. Its not that Java isn't "cool" (I loathe "cool" BTW - I like "useful").
I'd say the key problem is that Java is just unbelievably dull and inexpressive. It is a plain old meat and potatoes language with built in limitations that pretty well precludes doing anything innovative or slick.
IOW, there's no fun in Java (unlike something more playful like Smalltalk). Meta programming is possible but so painful one would have to be a masochist to bother.
Java may be fine for building well designed systems but as a language of INVENTION or EXPLORATION it blows chunks.
Frankly, I approach programming as art. So I'd never write anything for myself in Java (did once, was profoundly disappointed with the experience).
> When I see people talking about Java this way, I sigh. > What I generally see is people that have a very narrow > w interest in software systems. All the problems and all > the solutions that they have seen or created are so > anti-object or hardware-centric that they would truely be > nasty to recreate or interact with the Java platform.
That can also be turned around onto Java, too. At the risk of being completely unfair: There's only so many e-commerce sites you can work on before losing your enthusiasm for J2EE.
Java isn't suited for low-level hardware-related problems, like you say. On the other hand, it also isn't suited for very high-level problems where a domain-specific or non-imperative language might be better. What Java does, it does extremely well, but like most languages it has already developed an implicit theory about what it's "for", and anyone working outside those areas there will not choose it.
Personally, I'd like to think that multi-linguistic applications are the way of the future. Choose the right tool for the right job. Code your performance-sensitive numeric stuff in Fortran, your bit hackery in C, your GUI in Java and your domain-specific scripting in an embedded DSL which you cooked up for the purpose. The reality, however, is that assembling and managing a team to work on such a best is going to be such a nightmare that it isn't going to happen in most shops.
(BTW, people who complain that Java is the new COBOL seem to forget that COBOL was extremely well-suited for most of the tasks that it was used for at the time it was used. I take the point about legacy systems, but if I had to hack on a legacy business system, better Java than COBOL.)
> That can also be turned around onto Java, too. At the > risk of being completely unfair: There's only so many > e-commerce sites you can work on before losing your > enthusiasm for J2EE.
I use Jini, not J2EE to do integration. Jini doesn't kill the expressiveness of Java like J2EE does. There is no container beyond J2SE when you use Jini, so you can design your application from all directions, as needed.
> Java isn't suited for low-level hardware-related problems, > like you say. On the other hand, it also isn't suited for > very high-level problems where a domain-specific or > non-imperative language might be better. What Java does, > it does extremely well, but like most languages it has > already developed an implicit theory about what it's > "for", and anyone working outside those areas there will > not choose it.
If you just consider Java the language as the only form of expression, then you might draw this conclusion. But, if you consider Java the platform as a tool, then I'd suggest that there are many more things you can do.
A domain-specific language can be built into an API that is properly targeted for that domain. This will greatly simplify your work. Just because Java does have a platform solution in the domain you are working doesn't mean you can't be the one to create it!
> Personally, I'd like to think that multi-linguistic > applications are the way of the future. Choose the right > tool for the right job. Code your performance-sensitive > numeric stuff in Fortran, your bit hackery in C, your GUI > in Java and your domain-specific scripting in an embedded > DSL which you cooked up for the purpose. The reality, > however, is that assembling and managing a team to work on > such a best is going to be such a nightmare that it isn't > going to happen in most shops.
And this is precisely why everyone must work on developing Application Oriented Languages in API form so that the language of the API maps onto the domain of the problem. Many programmers are either too lazy, or too inexperienced to make this choice with Java. They see an existing API laying around in another language, and it it is close enough, they'll use that language. Then, for the next phase of the project they end up with a huge language interworking problem when the next problem requires some other solution and they pick another API for that domain from another language.
I understand the instant gradification of having that solution laying there. But the long term effect is that the problems that should be solved once either get solved 100 times, or they are never solved.
> I use Jini, not J2EE to do integration. Jini doesn't kill > the expressiveness of Java like J2EE does.
Point taken. The original discussion did mention J2EE heavily, which is why I did mention that.
> A domain-specific language can be built into an API that > is properly targeted for that domain.
That's true if the language that the API is written for supports the abstractions appropriate for the domain.
Java, for example, does not support overloading of numeric operators. This isn't a problem under most circumstances, except for when you want to embed some kind of mathematical DSL (e.g. BLAS), where the most natural way to express some operation is using mathematical operator notation.
Even if you ignore operator overloading (and there are good reasons to do so!), Java has a limited set of abstraction mechanisms compared with other modern languages and non-object-oriented paradigms. At a time in history where most new programming languages (well, those useful enough to gather a following, at least) are multi-paradigm, Java is the odd one out, only really supporting one object model and not a lot else.
Don't get me wrong. Java deliberately chose to use a limited set of abstractions for what I understand to be a very good reason: Most modern programming languages have safety properties which depend on the compiler. With Java, on the other hand, you don't need to trust the compiler. Rather, you can prove these properties direct from the generated code. When you need to run code from untrusted sources, this is a huge win. However, if you're using Jini, you've already given up these safety properties.
> Many programmers are either too lazy, or too > o inexperienced to make this choice with Java. They see > an existing API laying around in another language, and it > it is close enough, they'll use that language. Then, for > the next phase of the project they end up with a huge > language interworking problem when the next problem > requires some other solution and they pick another API for > that domain from another language.
If the API is over a certain level of complexity, or would be tricky to get right, then you will probably still end up ahead. An example is software related to security. Using an existing API in another language, if it's mature, stable and well-tested, will almost always beat doing it again.
"I use Jini, not J2EE to do integration. Jini doesn't kill the expressiveness of Java like J2EE does. There is no container beyond J2SE when you use Jini, so you can design your application from all directions, as needed."
You're talking elmers glue vs rubber cement here. My complaint about the lack of fun in Java had nothing to do with web apps. Swing is also a ponderous pile of fairly stupid bits. If I'm going to do a GUI, I'll build it using Cocoa and Objective C on the Mac or VisualWorks Smalltalk if it has to be portable. It'll be less work and look nicer.
I'll get it done in about 1/5th the time too because the default behaviors in Swing's layout widgets is STUPID and requires tons of tweaking. Also the compile edit debug cycle is too slow.
Java, the language, is boring. Java the platforms is also pretty dull. Java the VM only performs well on statically typed languages.
Previous Topic
