Java Isa Dead End

Finally...

The last decade's greatest FuRphy. Byzantine libraries, insoluble political troubles, inherently crippled performance, and the WriteOnceRunMaybe problem make this platform the last place you want to be. Dead slow for GUI work, innappropriate for real-time, and completely overmatched as a component architecture, Java is a goner. Get out while you still can.

Sounds like it's going to be a storming success actually, given the history of widely adopted languages. Also JavaIsPlatformDependent? BillDehora

Aha! But what about Java for application servers? (Security, multithreading, componentware, NoPointers, and the cross platform problem isn't an issue.) I suppose someone is going to recommend Smalltalk?

You don't need Java for application servers. Most of what EJB adds is irrelevant to writing an application tier except for B2C e-commerce, and for that it's overkill. WriteOnceRunMaybe means crossplatform problems are still an issue. Smalltalk may not have made inroads in the domain of application servers, but COM+ is an adequate language neutral alternative. Or just grab an ORB. ACE TAO is free and will do fine for most purposes. Or roll your own - most application tiers are trivial to write and you'll almost certainly do a better, simpler job by yourself than if you have to support all that extraneous bean bumf.

While enterprise beans can sometimes be extraneous, and certainly they don't make database access easy, they're still a much better solution than having to write / manage your own thread pools and mutexes. And I seriously doubt that COM+ is a cleaner/simpler alternative.

Folks, I need to say this: Writing thread pools in Java is a piece of cake! Writing JDBC connection pools is a piece of cake! And, guess what? Once you've written them: They continue to work. On, and on. I see these given as primary reasons to use EJB over and over. These are poor reasons to use the worst development framework ever devised. And, yes, I mean to say that EJB ranks worse than MFC. -- JeffPanici

Wow. I haven't tried to use EJB --- but if it is even worse than MFC I will have to make sure it stays that way ;)

Eek! Talk about Byzantine. The June issue of the CplusPlusReport? should prove to anyone why CeePlusPlus is Byzantine. And this opinion is from someone who worked as a senior CeePlusPlus programmer for years, and has experience using ACE and the ACE ORB (and other ORBs), (M)IDL, D/COM, and the other usual suspects. Trust me, Java/RMI is much easier. You don't have to buy into the whole EJB and J2EE thing. I just use J2SE with RMI and Jini and have actually had great success with reactive system. In fact, I just finished work on a EDF and Rate Monotonic Scheduler for Java written in Java. You should also take a look at the RealTimeJavaSpecification? located at http://www.rtj.org/public/book.html. This is turning out quite nicely.

However, I will agree that their libraries are bloated and some are even perfect examples of an AmorphousBlobOfHumanInsensitivity. The collection hierarchy is worthless and seems like it was designed by a C++ programmer. Instead of all those horribly performing iterators, they should have done something more like Smalltalk with iterative functions that take anonymous inner predicates and functions. This would have given them a huge increase in performance since the iterator functions know the details of the implementation and can, for example, access elements without performing range checks on each access. Also, their merge sort implementation is just awful. Nonetheless, the language is much smaller and cleaner than C++ but not as nice and neat as SmallTalk.

--RobertDiFalco

Shall have a look at the rtj spec, thanks for the pointer. RMI is fine ... but then so is RPC ... anyway I have in the past been very cranky at C++ - see AllPanaceasBecomePoison for a rant - but have recently become content with it using AlternateHardAndSoftLayers with python as the soft layer. I'm trying to get my use of the python CXX module tuned before I talk about this at length. As to your second paragraph, yes, certainly. --PeterMerel

Ok, Pete, so the point of comparison for server-side stuff should be JPython, Java and RMI vs Python CXX, C++ and RPC. I'm enjoying using, well almost enjoying using the former combination. The only thing I know about beans is not to eat them before being in polite company. J2EE I'm leaving to others to find out the very few things that may eventually be important about it.

I'd agree except for RPC, apologies for the apparent misdirection. There are of course no IPC mechanisms that aren't available in one form or another for C++, and I've always been fond of GenerativeCommunication, usually rolling my own MultiCasters. Still, since most C++ these days is VC++, the most apt IPC for the comparison is probably ComPlus ...

Some questions for rad (how clever to choose the Wiki moniker RapidApplicationDevelopment). Have you looked at Voyager from ObjectSpace? How's it getting on as a pure Java orb now that Jini's out and about? What does Jini add to RMI in your situation? We certainly thought Voyager 1.0 was a vast improvement on RMI in the days before Jini. And try building easy to use mobile agent stuff like Voyager in C++ (that one's for Pete!) -- RichardDrake

Actually, that's RapidAssimilatorDiFalco? to you! But yes, I've looked at Voyager. I have to say that I have created my own agent based system on, yeah guessed it, Jini and TupleSpace (this could be JavaSpaces, TSpaces, or any other good Java implementation of AssociativeMemory). I'm not a big fan of either CORBA or DCOM as they are both MessagePassing idioms -- I've become a big fan of GenerativeCommunication as an alternative and find that, at least for my uses, has really made life easier.

Syncrhonization, autonomous collaboration, availability, and scalability are all so much more natural in the generative model. It certainly has some problems, but these pale when I think of going back to a MessagePassing model for distributed communication.

Agreed on this - see more comments along these lines on MultiCaster.

RMI is very, very simple. Making it use SSL is not difficult either. If I had a need for multi-language support, I'd probably continue to use RMI but would use the newer RMI/IIOP to give CORBA an in. I explain a little bit about my current system using Jini/JavaSpaces at http://www.cdegroot.com/cgi-bin/jini?RobertDiFalco. --RobertDiFalco

Sounds like a very sweet way, Robert, and good luck with it. Okay, I'll give over, none of the problems I've mentioned are necessarily Java killers. They just make it ickier for some of us than we're content to tolerate. --PeterMerel

I will say that I think Java is neurotic in many ways, especially when it comes to its type system. It's in the middle of SmallTalk and CeePlusPlus when it comes to types, not committing either way. Personally, I like both approaches for a type system. What I don't like is this in the middle approach of Java. I would much rather Java have no type checking (ala SmallTalk) then the concept of types Java currently has. It makes programming very difficult and brings up issues like Contra/CoVariance. I suppose the introduction of Genericity (parameterized types) in 1.4 will help this ease my disgust in this regard. I think it is almost evil to require so much casting, but also charge the user for each cast. It's like pushing you up against a brick wall while saying, don't touch any bricks. All in all, I have to say that I still like Java, but sometimes I do get irritated by its philosophy about types. I also hate its solution for lexical-closures (i.e. code blocks). Anonymous inners are very verbose and don't allow you to return from the enclosing context. However, it's certainly better than STL's mock closures (i.e. unary_predicate, binder1st, binary_function, etc). Okay, I feel better now. --RobertDiFalco

You should check out the truly cool C++ BoostLambdaLibrary. Forget binders - they're pass� --Pete.

It sounds like you might like the RubyLanguage

Hmm. Python without the cool syntax?

Actually I was about to say Python without the ugly syntax, but maybe that's just me...

CategoryJava