Software Development

J2EE Servers Stink


I had a glorious 11.5 hour day at work today. Indeed, nearly the entire server/network team had an 11.5 hour work day today. My boss cut out only an hour late, but he will be testing from home tonight. Our top tester worked 11.5 hours today. Our project is behind schedule. My other projects are now way behind schedule.

All because of the complexity and low quality of J2EE servers.

In today’s case, it was BEA WebLogic, and BEA’s inability to provide components that work right with IIS to forward requests to WebLogic. Specifically, the newer DLLs do not work but the older ones do. Funny how PHP, Perl, and ASP.Net can all plug in seamlessly to IIS, but no J2EE server can, isn’t it? And they plug in seamlessly to Apache too. Every J2EE server that I have been inflicted with requires itself to operate on separate ports and then jury rig the Web server to forward requests to it if you want to use your other Web server for the rest of the site. And most J2EE servers stink for non-Java server tasks.

The first time I encountered Java programming, it took a coworker about a day to set up Tomcat on my desktop, and he had done it before. Of course, code that ran on Tomcat and Apache in Windows did not work the same in iPlanet on Solaris, so it was a royal mess anyways. The last time I tried to set up Tomcat, it was on a FreeBSD server; installing Java took hours, installing Tomcat took forever, and I never did get the linkup between Apache and Tomcat working well enough for it to seamlessly put a Java application on the site without using a totally different directory for it.

I am just baffled and amazed by this. Why do J2EE servers need to be so complex? Maybe I am missing something, but I do not see why they need to be any more difficult than setting up PHP or ASP.Net. But they aren’t. They require bizarrely complex directory structure, impossible links to the Web server, funky ports, have lousy management tools, are slow, error prone, require constant maintenance, and the list of problems go on and on.

I have simply never had a positive experience with a J2EE server. As a developer trying to write for them, a develop trying to deploy to them, a developer trying to debug within one, a developer trying to set up a test environment, or a systems administrator trying to do any of those tasks, I have always walked away feeling frustrated and with the task half done. It is a wonder to me that Java has made the server side inroads that it has, simply because setting up J2EE is such a miserable experience. Even the configuration files are frequently nonsensical. I just do not understand why no one can seem to make a J2EE server with the level of polish or quality of Apache or IIS, or a J2EE environment that plugs into a Web server as easily as PHP, CGI systems, or ASP.Net. I have not used Ruby on Rails, but I bet that it is easier than J2EE too.

Sheesh.

J.Ja

About

Justin James is the Lead Architect for Conigent.

51 comments
gweinman
gweinman

I've never had a problem with Tomcat, JBOSS, or WebSphere. WebSphere takes 90 minutes or so to install because it's so big. Tomcat installs in 5 minutes and JBOSS in less than 15. WebSphere administrator provides full guided control of application deployment with everything but EJB installing in two or three minutes. Tomcat and JBOSS applications deploy even faster. I've mentored many in the companies I've worked for and never heard the complaints you voiced. I don't see any significant time difference deploying J2EE or .NET applications. I see a lot more effort securing IIS than Apache or WebSphere but all in all each are straight forward installs.

Jaqui
Jaqui

they are extremely complex. they are designed to handle the badly designed java language after all :p I'll stick with technology that is easier to implement, I like having a full head of hair. [ lower stress levels and no ripping it out in frustration :D ]

georgeou
georgeou

This is what you get for a $40,000 per CPU socket license :). This is where those QUAD core Intel CPUs make immense sense if they're counting by the CPU socket.

Mark Miller
Mark Miller

...you have to accept the way it does things. RoR is set up with the idea of convention over configuration. In other words, it sets things up in certain places by itself. While other technologies like ASP.Net allow you a certain amount of latitude to put things where you want, in terms of where files go, RoR does not allow this. So if you understand the convention, you'll understand where everything is. From what I understand, RoR works exceptionally well for simple apps., in terms of developer productivity. The scaffolding framework does a lot of things for you. You can override the scaffolding if you want. For anything but a "hello world" app. you probably will. It handles page templates similar to ASP.Net or JSP, and the template code integrates easily with HTML/CSS. From what I've heard it has some constraints that for more complex apps. may feel like a straightjacket, particularly when it comes to database access. I've only looked at example code. It has its own built-in ORM. It handles one-to-one and one-to-many relationships with ease. I don't know how it does joins. It might be necessary to set up named views that do the joins, to which Ruby could have read-only access. When I tried out Rails the only configuration I had to do was deal with a simple configuration file, providing information to Rails on how to connect to the database. On the positive side it'll handle any of the popular databases: MySQL, PostgreSQL, SQL Server, or Oracle. It also has its own table versioning, unit testing, and debugging infrastructure. It's an all-in-one package. As I've probably mentioned before, the language itself is kind of strange if you're used to C++, Java, or .Net. It is object-oriented, but the syntax and the way it works resembles Smalltalk, Python, and Scheme to a certain extent (there aren't excessive parentheses, which is nice). As to your first post on here, I haven't worked with a J2EE server. I've avoided that whole mess. It's funny, but two years ago J2EE was the cat's meow among the open source developer community, as best I could tell. Java could do no wrong. Now that I've gotten more involved with some open source myself, I hear people complain about Java all the time, particularly developers who have converted to/discovered RoR and Squeak/Seaside. I've heard that RoR is drawing away Java developers, because it does things so much more easily. I can believe that. If you're interested in learning RoR in-depth, there's "Programming Ruby: The Pragmatic Programmer's Guide" First Edition at http://www.rubycentral.com/book/. This is a free online tutorial on the Ruby language. For the RoR framework I'd recommend buying the book "Agile Web Development With Rails", by Dave Thomas. There are some free online tutorials, but they're not too useful beyond the "hello world" stage. If you go by www.rubyonrails.org you can find the now famous screencast on "building a blog in 15 minutes" with Rails. This gives you an idea of what it can do.

Justin James
Justin James

What do you think of J2EE servers? The Java language itself aside, do you love 'em or hate 'em? J.Ja

slicer777
slicer777

Tomcat's not hard to set up. I have about 15 instances running on one machine. If I need a new instance it takes me about 5 minutes to set up. You do need to keep track of your ports and so on, but so what, you need to do that with any server product. To be fair, there was a learning curve. When I started with Tomcat back in version 3.3.1, it took we a while to get it working, but once I got familiar with it, setup is a breeze. I can even get it hooked up to IIS if you give me another 10 minutes. I think the big problem is documentation (but this a problem all server products share). While Tomcat documentation is pretty good, it's not great and if you aren't familiar with Tomcat you can have problems. WebLogic isn't bad either, if you get a full version. I'm used to working with the custom versions that come with PeopleSoft and WebCT, which can be a pain because they don't always support all the features of the full product, but it does have a nice web interface. As for deploying applications, what can be simpler that tossing up a WAR file. What you have to remember is that if you want a higher degree of control/power you have to be willing to trade-off by dealing with a little more complexity.

Justin James
Justin James

There's something to be said for CGI, the only deplayment tool you need is FTP (or the cp command, or some other file copy tool), and the only software you need is a basic copy of Apache. No muss, no fuss, no mess, no pain. Universal, standards based, and unless you are using an OS-specific language or library call, it is downright tough to write CGI code (in any number of languages) that is not nearly 100% portable, even to bizarre platforms like Solaris ;). Indeed, the only time I ever found a platform incompatability in Perl was trying to slurp a text file on Solaris... J.Ja

Justin James
Justin James

Yup, and lots of VMs to create staging and production environments without having to pay for more of the garbage software. :) "Enterprise Software" is like those plastic sushi displays in restaurant windows... looks good until you realise that it is bogus! J.Ja

Justin James
Justin James

In the interview I did with the folks from Spiceworks about a month ago, they had nothing but good things to say about Ruby and RoR. I saw some of RoR's demos, the forced scaffold really, really bothered me. It felt a little jury rigged to have my whole application being dependent upon adhering to a particular directory structure, with nary a config file in sight to override that behavior. As you noted with the join issue, I had a lot of questions about that too. Which is my biggest concern with RoR... my experience with any like that is that the moment your business rules deviate from the technical rules of the framework, everything falls apart. It is really bad when the initial project soecs let you do it like that, but a later change doesn't, so you are forced to rip & replace the whole thing... J.Ja

alex
alex

How about JBoss? Is it as complex and buggy as Weblogic, Websphere, Tomcat, and the rest?

gbrisson
gbrisson

I have had a few Microsoft Based projects and .Net projects in the past... they all went well till we had some significant number of concurrent users... that is where it fails miserably. On the other hand, every single J2EE project I have worked on proved to be a bit more difficult to implement, but then never failed under heavy loads. Of course, I had to "grow up" a little and learn (master) more complex environments, but the effort was worth it. Good luck with you kindergarden projects!

dstein42
dstein42

Four groups love J2EE - if you're one of them you'll love it too. Otherwise, it stinks! 1) IBM - a services firm masquerading as a product company. WebSphere is the loss-leader for IBM Global Services. 2) Enterprise consulting firms that bid T&M contracts - train once (Java) and no matter what J2EE your client demands you can say "sure, we have J2EE developers". Hey, complex configuration means lots of billable hours. 3) Sun - without Java they'd have disappeared long ago since all they had was a POSIX-(mostly)compliant Unix running on overpriced hardware. Java gave them the time to dump SPARC, lower their hardware costs, and embrace Linux. J2EE was their bid to remain relevant. 4) Any ISV or enterprise IT department that likes big labor-intensive projects. In short, if you make money by doing IT makework, you'll love J2EE. If, on the other hand, you make money by providing services and products to folks who don't care how it's implemented but need it to just work, you should pick something else.

comp
comp

In 2001 I had Java training and decided then not to pursue it as a career option. Slow, complex and difficult to work with.

tnelson
tnelson

I recently wrote my first web service, using annotations and the Sun app server. Everything worked just fine, did the debug & deploy dance a few times, everything was OK. Then I tried to deploy it on Websphere.... First, the version we were using (6.0) didn't support Java 5 (even though 5 has been out for over a year). I upgraded to V6.1, which permitted Java 5, but didn't support the JSR181 annotations. So I got a (beta) Web Services expansion pack. Now my web service would compile, but I couldn't access it, because I didn't have a WSDL file! The Sun app server automatically generates one when you deploy a service, but WAS has to have one in order to route requests. Oddly enough, it would deploy the service just fine, it just wouldn't let me get to it :|... Sun, BEA and JBoss all have their quirks, but WAS is just a PITA...

Justin James
Justin James

I will say this, the installation itself for these products is generally no more difficult than anything else. It's the configuration. The documentation is pretty lousy, as you've mentioned. What made Tomcat particularly disappointing is that I find the Apache documentation to be of a high quality. It is not that I mind some complexity, but there is a way to build complex products that are still easy to use. Apache is a good example. Complex product, but out of the box it works with little effort, and the effort needed is quite obvious once you locate the configuration file. It is only as difficult as your needs. J2EE servers, on the other hand, seem to require way too much knowledge upfront, almost forcing you to have an expert on staff, and even worse, throw out nonsensical, meaningless error messages. For example, WebLogic was throwing off I/O errors "at random" which were actually a result of the log file location being a directory that the server did not have access to. Just dumping a Java exception is NOT useful, particularly for a system administrator for whom running a J2EE server is not a primary responsibility or core competancy. J.Ja

Jaqui
Jaqui

cgi is not equal to perl since even a java applet can be used as cgi. any scripting language can be used for cgi. most cgi scripts are done in perl, like 99.95% of them. :D it's just not the only language option for cgi. I agree that for keeping application logic separate from site presentation, cgi is by far the best tool available, for the simple fact of it being fully standards compliant, and robust. It's to bad that since it's an "old" tech that most people won't even look at using it any more.

Mark Miller
Mark Miller

I'm not an expert on Ruby at this point. The best person to talk to would be someone who has used it on real world, better yet large, projects. Just for a little clarification, it looks like you can define your own queries in RoR. Here's an example: def update_sales_tax update = @db.prepare("update orders set tax=? where id=?" ) @db.select_all("select id, amount from orders" ) do |id, amount| tax = calc_sales_tax(amount) update.execute(tax, id) end end It prepares an update statement, which will update a sales tax field in the Orders table. It then sets up a loop to go through the Orders table, gets the subtotal, calculates the sales tax, and enters the value into the parameter in the prepared update statement, and then executes the statement to have the Orders table updated. I'm sure you've done this in ASP.Net. It looks simpler, no? So you can set up your own queries and DML statements, which would conceivably take care of joins. The scaffolding I was referring to is the defaults of the framework: The default page views, the default database model (ie. how it accesses a table or a set of tables), the default testing stubs, etc. From what I understand these can be overridden with your own code. The directory structure for where these things go is fixed, however. It's not as if it demands that it be placed in a certain directory on C: drive. You can adjust that easily. It's just that once you get into a project directory, the subdirectories for the pieces of a project are fixed. They're fairly general. Your application goes in an "app" directory. The directories under it are "controllers", "helpers", "models", "views" (it uses the MVC model). Page templates go in the "views" directory, for example. I'd still say RoR is worth a look. It's really a matter of understanding it. If after that you still think it would constrain you, then yeah, I'd say don't use it. The main criticism I've run up against again and again is that Ruby is "slow". I have a friend who works with Ruby (though not with Rails) a lot and he disagrees with that notion. Ruby is an interpreted language. I used to think it could be compiled into something, but that wasn't true. When I've tried out some RoR demos on my own machine, they run at least as fast, if not faster, than what I'm used to with ASP.Net. Maybe it doesn't scale as well as PHP, or something. I honestly don't know. RoR might be best used on "greenfield" projects, ones you're starting from scratch.

Justin James
Justin James

...that is one I have not used, sorry. J.Ja

k.p.thottam
k.p.thottam

J2EE was built by vendors who are trying to cater to the high end of the requirements spectrum. I am not sure how long you have been in the J2EE space , but I can assure you getting Tomcat with Apache working isn't more than a half an hour job. And this is coming from a non coder, who does a POC once in awhile. Practice makes perfection, you work on my team for 4 months and all the items you listed will be done in a breeze from the 4th month onwards. The learning curve is no doubt steeper but then so are the number of flex points. What I really find interesting is human nature, 2-3 months of working on the same thing changes your views dramatically, this I have observed on my team over and over again.

Justin James
Justin James

... I didn't write the app, nor did I install the app server. I just facilliate a lot of stuff at this point. It isn't just a matter of the complexity, it is a matter of the quality. A minor component (the proxy piece) breaking by using the latest version is simply unacceptable, and reflects quite poorly on the rest of the product. J.Ja

gweinman
gweinman

As I read through the replies posted to this BLOG I can't shake the feeling that the majority of complainers tried to hack their respective ways through development and deployment. I mean, everyone knows reading manuals is for sissies. - I love .NET as much as I love J2EE. It's just any tool that offers extensive options and vast libraries of functions requires due diligence to master. That diligence includes a few trips to the on-line manual sites. Who among us can put together a complex MS Word document without the same diligence? Now take Adobe PhotoShop and try to hack your way through a complex retouch. Go-o-o-od Luck!

dstein42
dstein42

My current company built thoughtfully with .NET and serves 1.6 million kids (tens of thousands concurrently) on a fairly small infrastructure. You can get grown-up results with either J2EE or .NET if you architect sensibly. The biggest flaw in J2EE is all the poorly coordinated moving parts. The biggest flaw in .NET is the seductive nature of the "wizards" and other quick-start tools. You can avoid .NET's flaws pretty easily; it's a lot harder to avoid J2EE's.

Justin James
Justin James

I never put two & two together, but you're right. Java really is the Oracle of languages, in terms of the number of billable hours to consultants that implementing it seems to inevitably incur. Since third party vendors love those billable hours, of course they push it! I find it ironic that .Net was put out as a result of Java, but it was only a few years before .Net was beating Java in every way that I can think of, save cross platform compatability (not that Java has that nailed down either). .Net's "fit and finish" feels so much more pleasant that Java's. It is obvious that Java is a Sun creation. Sun usually makes well engineered things that are just completely unusable by mainstream IT professionals, Java is one of them. J.Ja

Justin James
Justin James

See, that's just it... I've never found a "quirk" in Apache, IIS, CGI, PHP, etc. I did not need to "learn" much of anything at all. J2EE servers on the other hand all have "quirks". :( J.Ja

slicer777
slicer777

I can appreciate what you're saying. The learning curve can be steep. At this point I would have to consider myself an expert in the use and configuration of Tomcat. I've been through the pain of figuring out how to configure it and what the error messages mean (which isn't too bad for Tomcat, usually). When (if) I get some free time, I've been planning on sharing my experience in some kind of online forum to make using Tomcat easier for those who don't work with it daily. Where I currently work as a developer/architect, I actually do the setup of Tomcat on the production hardware and if there is a problem the sys admin (a MSCE) comes to me to help diagnose. Fortunately, when set up properly Tomcat is very stable. We almost never have problems with Tomcat itself once it is installed (the applications that are deployed on it can be another matter). About the only time I have to touch it is to do the upgrade when new versions come out.

Mark Miller
Mark Miller

To Justin: Re: F#, Ruby.Net, etc. I've heard of these language adaptations. As I remember I told you about them a while back. :) I wonder what the differences are between dynamic languages in .Net and those for the JVM. I've heard about Jython for years. More recently I've heard about JRuby and Groovy. I've latched on to Smalltalk for the time being. I'm learning about forming domain-specific languages, and Smalltalk is a great tool for it. This is just my opinion but it's the most beautiful language I've seen. I recall that there were a couple of implementations of it for .Net at one point. S# is no longer being targeted to the CLR. It looks like the other one is still available, Sharp Smalltalk, but nothing's been done to it in a while and it's pretty basic, enough for what you were talking about--implementing the business logic, but little else. One bright light on the horizon is Vista Smalltalk, being developed by Peter Fisk. It's designed for the .Net 2.0 CLR and .Net Framework 3.0.

Tony Hopkinson
Tony Hopkinson

people who think access is an enterprise DBMS, JavaScript is a good OO language, monolithic software is easier to manage and re-factoring is an expensive waste of time, and invisible list boxes are the best way to sort items. If I hadn't got so many jobs correcting these screw ups, I'd despair.

Justin James
Justin James

... are people who slapped together some Access turd and think they know SQL. They get into a real project, and I guarantee that "hilarious hijinks will ensue". J.Ja

Justin James
Justin James

Mark - Because .Net is an interpreted environment at the end of the day (the CLR interpreting the MSIL bytecode), language authors are actually finding it refreshingly easy to port dynamic languages to it. The IronPython project actually started as a "rebuttal in code" to show how crummy the .Net system was, and the original author became a .NEt convert. There is also F# already, an O'Caml dialect that can write 100% pure O'Caml code as well as integrate into the .Net Framework quite nicely. There is Perl.Net too (not too happy with its implementation as it currently stands though), and there are many people racing to port Ruby to .Net. There is even a version of APL written for .Net. This is why I few .Net as the most exciting thing happening in programming right now. You can use the right language for the right parts of a project. For example, you can use C# or VB.net to handle all of the interface events, and the "glue these libraries together for the final solution" type code, and then a more specific language better suited for an individual task to write the "Secret Suace Libraries". Remember our DSL conversation? It's like that... if F# or Python or Ruby or Perl is better suited for a particular task, go ahead and use that instead! From a business standpoint, this makes great sense too. Have an army of shake 'n bake programmers doing most of the work, and a rock star or two working on your domain specific problems in the language of their choice, and you have resolved the problem of the hassle of managing large projects (using OO languages for the bulk of it, and splitting out the "weird" stuff and intergrating it as objects) as well as working around the limitations of OO languages. J.Ja

Tony Hopkinson
Tony Hopkinson

Anyone capable of writing CGI (well) can muddle through a script just as well as those who can't. Scripting environments per se aren't the problem. The perception that someone who once wrote a worksheet macro at college on their advanced flower arranging course qualifies as a programmer is though. Some scripters are very, very good programmers, a lot aren't. There again I've bumped into one or three programmers holding down a job, who I wouldn't let write a script.

Mark Miller
Mark Miller

My examples weren't the best. I'm still learning this stuff. A lot of what I showed in my examples was actually the strength of Smalltalk's class library. I've discovered that the reason "strong language" and "weak language" have some meaning is that some dynamic languages have uniquely powerful features. The procedural world is catching up though. A couple things you'll find in dynamic languages like Smalltalk are closures and continuations. Closures are segments of code that have lexical scope. I used them in my examples. The closures were the code segments enclosed in []'s. They're capable of accepting parameters and returning a result. In .Net 2.0 they're analogous to anonymous methods. The Linq project implementation has them. They're called "Lambda expressions". This enables a more compact expression of what I'd call "composite logic": an object using a code segment that is given to it to do some custom processing of its own data. It's also in a master-servant relationship with the code segment. The object chooses when to run the code segment, and determines what parameters are passed into it, and how it handles the output. It maintains encapsulation. The object only reveals to the code segment what it chooses to. Something similar can be implemented in more traditional languages like Java, but it's more verbose. You either have to put a traditional code structure around the object, like a loop and manipulate [i]it[/i]--the object is treated as the servant of the surrounding code, or define another method or class that does this custom processing. I realize my examples were just of the "hello world" type, but they illustrate some powerful principles. A continuation is a representation of an executing program, like a call stack. In a language that features continuations the program logic has access to its own execution state. Seaside, a web framework for Squeak (an open source implementation of Smalltalk), uses continuations to save and restore the program stack for individual web applications automatically, thereby persisting all objects in use during a session. It relieves the application programmer from having to save objects to session state that need to be persisted between callbacks. That's a big plus in my book. It might be possible to implement the same thing in Java and .Net, using reflection, but I think it would be complicated and quite messy. That's the reason the programmer has to handle it. Smalltalk uses a message passing system to call methods on objects. This enables a kind of infix notation. The examples I gave demonstrated this. For a more real world example, I've been working on porting a web app. I wrote in .Net to Seaside. Part of it was some screen scraping logic, getting data from the Bureau of Labor Statistics: query := (WebQuery fromAddress: 'http://data.bls.gov/cgi-bin/srgate') where: 'series_id' is: 'CES0000000001'; where: 'year' is: '2001-2006'; where: 'format' is: 'block'; ...etc... page := query retrievePage. The C# code was: Hashtable valuesTable = new Hashtable(); valuesTable.Add("series_id", "CES0000000001"); valuesTable.Add("year", "2001-2006"); valuesTable.Add("format", "block"); ...etc... StringBuilder sbHttpQueryString = new StringBuilder(); sbHttpQueryString.Append(WebUtil.DictionaryToHttpQueryString(valuesTable)); string htmlData = WebUtil.PostURL("http://data.bls.gov/cgi-bin/srgate", sbHttpQueryString.ToString()); I didn't write my C# code to be deliberately complicated. I used an open source class library that was available for it, which required me to give my inputs this way. I think the Smalltalk example expresses my intent much better. That's a strength that dynamic languages have. I don't mean to be a chauvanist. Really. Java and .Net do have some features in their class libraries that lend themselves to corporate computing, like internationalization. They also have more interoperability support with other technologies. I'm sure all this could be done in dynamic languages, but I imagine programmers would have to write them. The procedural world is coming along though. Groovy 1.0 was just recently announced for the JVM. It's a Python/Ruby-like language that compiles to bytecode. IronPython was recently released for .Net. Microsoft is going to be adding dynamic language features to C# and VB.Net later this year (tentatively) with the final release of what's been known as The Linq Project. It's an exciting time.

Justin James
Justin James

Yes, you are right that Java brings to the table a number of benefits that more "efficient" (good word, BTW, conveys what I mean without the negative value statement of "weak language" clouding the debate) languages can't. In fact, ANY OOP language does this, to an extent. While I personally prefer working in Perl, for example, I would be quite cautious about having a team of more than a few people working in it. OOP languages simply and ease management headaches significantly. While I beleive whole heartedly that for any given individual programmer that they are less efficient than many procedural or functional languages, I also beleive that the overhead of working in those other languages compared to an OOP language make the OOP languages better when evaluating the team as a whole in most circumstances. It stinks that technical good (as I see it, at least) loses to business good, but it has to be that way. Now, to find a language with the lines-of-code efficiency of Perl or Lisp, with the management conveneience and readability of a verbose OOP language... J.Ja

jean-simon.s.larochelle
jean-simon.s.larochelle

...a weak language is. For some application you need more than just a high ratio of features/lines_of_code. Because I work with other programmers I need a language that lets me specify class in a very formal manner. I like to be able to use Java interfaces to specify APIs. I like to be able to use annotations to enforce or check the implementation of higher level design issue. This requires more work but it is needed in the domain I work in (large Pharmaceutical CFR-21 part 11 compliant application). Java lets me do this with a better features/lines_of_code ratio compared to other methods and/or languages. This being said I would agree that Java is not an efficient language for many type of applications. There is no such things as a perfect language for the same reason that there is no perfect tool (hammer, screwdriver, ...). The strength of a language depends on the task you want to perform and other factors (context, ...) Another point I would make is that examples such as the "Hello world" type are not really reliable. Measurements done on real applications have shown that Java as a better features/lines_of_code ratio than C++ for example. JS

Mark Miller
Mark Miller

To Jaqui: [i]problems in that are the effectiveness in the terse code in handling errors.[/i] Error handling is certainly different in Smalltalk. I don't want to get too far into it as I didn't mean to turn this into a discussion about this language, but there are some mechanisms for it. One way is to make error handling part of the method you're creating. Some methods, particularly for collection classes in Smalltalk, have an extra parameter called "ifAbsent:". The Array class has it in some methods. For example: element := someArray at: 3 ifAbsent: [-1] What this means if someArray doesn't have a 3rd element, the call should return -1, or whatever I put in the []'s. It could just as easily be some logic, like a method call, that produces this result. That's one way of doing it. There are also exception objects that can be used, and standardized error calls that can be made. I know they exist, but I haven't learned much about them yet. [i]It would also kill any use of java, since having to build a framework for every object, every time it's used, makes for hard to maintain code.[/i] Not sure what you mean here. I'll take a stab at it. One of the nice things about Smalltalk, though this is true with other dynamic languages like Ruby and Python, is you can add methods to standard types easily. I find it makes the language easier to use, not more complicated. An example I used in my last post illustrates this: '\d+' asRegex matchesIn: '...' When I loaded the regex class library I mentioned, it added the "asRegex" method to the String class. It converts the string to an RxMatcher object, which can then receive the "matchesIn:" message. Having a rich set of methods is nice, so long as they're pertinent to the class they're assigned to. I love doing stuff like: 1 to: 10 do: [:index | --some action--] This does the same thing as a for-loop. It takes an Integer object and turns it into an iterator.

Jaqui
Jaqui

use the language that dos the most work with the least effort. problems in that are the effectiveness in the terse code in handling errors. using tools like operator overloading in any language leads to debug "he||" in any app throwing errors and is not somthing I encourage or use because of that. regex, extremely powerful tool, that can be a problem if the person / people trying to bugfix don't understand regex as well as the person that wrote it. There are trade-offs in every decision made in a project, if developers keep in mind that those who may have to maintain the code might not be as skilled then it would make the maintainence far easier. It would also kill any use of java, since having to build a framework for every object, every time it's used, makes for hard to maintain code.

Mark Miller
Mark Miller

Here is kind of what Justin is talking about. You can tell the power of a language by looking at how much code you have to write to accomplish something. I'll use C# and Smalltalk since they're two languages I know. I'm sure you'll find similarities between the C# code and Java. Problem #1: Take an array of integers and produce a new collection containing only the even integers. In C#: ArrayList evenNums = new ArrayList(); foreach (int num in GetInts()) {if (num % 2 == 0) {evenNums.Add(num);}} In Smalltalk: evenNums := (self getInts) select: [:num | num even] These come pretty close in terms of lines of code, but the Smalltalk version is shorter and simpler. Problem #2: Create a collection of matching substrings from a string and a regular expression. In C#: Match m = Regex.Match("123abc abc abc123 1a2b3c", @"\d+"); ArrayList matches = new ArrayList(); while (m.Success) { matches.Add(m.Value); m = m.NextMatch(); } In Smalltalk (using a regex class library): '\d+' asRegex matchesIn: '123abc abc abc123 1a2b3c' Here the difference is more pronounced. 1 line of very simple code in Smalltalk vs. 5 lines of code in C# (not counting the curly braces). I was tempted to use .Net's Regex.Matches() method, since it produces a collection of matches in one call. Only problem is it terminates the collection at the first unsuccessful match. I wanted the program to skip over unsuccessful matches. So I had to go with the more expensive solution. Both of these are very simple examples. The differences will become more pronounced the larger the problem. In terms of developer productivity, which is more preferable? Personally I like the terser expressions of Smalltalk. It does more with less code.

Justin James
Justin James

Compare the total lines of code needed to write even "Hello World" in Java, and the effort to architect it in a Java-y way, to doing it in another language, even C++. I call that "weak". But you are correct, in this case, my problem is the Frankenstein monster of J2EE servers, not the Java language or even the JVMs. Today's horror story? Getting the BEA WebLogic ISAPI plug-in that does proxying to work in a way that sends the request to a different app server based on which directory the request came in through. Took about 6 hours of my life. I should mail a bill to BEA and have them deduct it from or lisencing bill. J.Ja

jean-simon.s.larochelle
jean-simon.s.larochelle

I don't think "Java is such a weak languages". Now don't give me the "Java is broken because of multiple JVM" argument. I don't think your problems have anything to do with this. Your problems have to do with J2EE complexity not the language.

Justin James
Justin James

My first paying customer for freelance Web work was my uncle! I may add, he is still one of my best customers. And his site uses CGI. First put together in '97 or '98. :) J.Ja

Tony Hopkinson
Tony Hopkinson

it will scale. Why aren't more sites CGI? Because developers capable of doing it well aren't cheap and they have no method of bashing together some crappy inefficient script to impress their uncle so they get a job.

Jaqui
Jaqui

odd, I know of several community sites that are completely cgi. with active membership in the millions. cgi will scale, if it is written to handle the load, exactly as any other tool set, you have to write the code for your app to handle the load for enterprise use.

gweinman
gweinman

Why aren't more sites CGI? Because CGI won't scale. My personal site uses CGI for the reasons noted above. My company's site uses J2EE and .NET for performance.

Jaqui
Jaqui

of your comment. I would only add that programming in c++ is far more than creating the same app in perl for a cgi implementation. I personally like working with c and c++, but I'll use perl over them for cgi or web scripts. less code used for more work done is a big offset in perls favour, it also makes perl cgi scripts as fast or faster than the same work done in c r c++. [ performance speed as well as development time ] even assistive technologies work with cgi sites, as long as they don't use mainly cgi:push for image maps, and stay away from framesets. [ framesets actually break them because each frame is a separate site. ]

Justin James
Justin James

I didn't mean to imply that Perl was the only way to write CGI, but it is a great language to use for it! The idea of CGI/Java makes me cringe. More and more, I have come to beleive that all of these various frameworks are so hindered by the poor languages behind them[ J2EE is a good example, it is "everything but the kitchen sink" and makes writing an application a snap, but Java is such a weak languages that a lot of the gains from the framework are lost by having to write Java. .Net is the same way when using VB.Net or C#. At least with .Net you can use a better language while still leveraging the massive framework. But then again, Perl and C++ also have huge libraries, are good languages (I feel that C++ is only a bit more difficult to write code in than Java or C#), and will run much more quickly than Java or .Net, while also being much more portable. J.Ja

Justin James
Justin James

I didn't mean to imply that Perl was the only way to write CGI, but it is a great language to use for it! The idea of CGI/Java makes me cringe. More and more, I have come to beleive that all of these various frameworks are so hindered by the poor languages behind them[ J2EE is a good example, it is "everything but the kitchen sink" and makes writing an application a snap, but Java is such a weak languages that a lot of the gains from the framework are lost by having to write Java. .Net is the same way when using VB.Net or C#. At least with .Net you can use a better language while still leveraging the massive framework. But then again, Perl and C++ also have huge libraries, are good languages (I feel that C++ is only a bit more difficult to write code in than Java or C#), and will run much more quickly than Java or .Net, while also being much more portable. J.Ja

alex
alex

There is a company called Azul Systems that offers a solution for accelerating Java apps by offloading compute-intesive tasks to a dedicated Java processing engine. Here is their website: http://www.azulsystems.com/ And here is an overview of how their technology works: http://www.azulsystems.com/products/network_attached_processing.htm I don't have personal experience with this solution, but they have an impressive client list. Does anyone else have experience with this solution or one like it?

Justin James
Justin James

Mark - If I recall, you are thinking of the Pico CPU. I beleive (this is all ancient history, of course) that Sun developed the CPU, and that Oracle was going to use them as part of a "Net PC", a PC that just had a Java CPU, NIC, sound, video, I/O, and ran all applications as Java apps off of a central server, like a mainframe terminal with local processing. Again, my memory is that this was not an expansion card, but the primary CPU itself. The failure of this to go anywhere is why I beleive that such an effort must be an expansion card. No one wants the CPU to only run one type of code, although .Net does handle enough languages now to say that it covers probably about 95% of the lines of code written for Windows. I think that a .Net acellerator card (or Java accelerator) could be extremely well received in the server room, but not on the desktop. J.Ja

Mark Miller
Mark Miller

[i]On the other hand, someone could make a CPU that could run .Net or Java bytecode, making that language a non-virutal machine and actual native code, which would run quite fast... but why would they? Maybe if it was an expansion card...[/i] I think this is within the realm of possibility. Back in the 90s I recall hearing about the possibility of a Java card that would run Java bytecode. I guess it went nowhere. I think there's a possibility the same thing could be fabbed for .Net. Windows Vista, or its successor, will probably help that along, since .Net will finally be included with the platform. It wasn't worth it before because .Net has been an optional install. Right now having it as an add-on card would be the only way to go. Machine code CPUs are still needed to run the OS, of course, plus most applications, since they're still written in machine-code-compiled languages, not least of which are compilers and interpreters themselves. I can see this changing though, over the next 10 years. As I understand it .Net Framework 3.0 is a complete Windows API. There's no need to P/Invoke native DLLs anymore. There's a managed API call for everything. Also, from what I understand WPF, WCF, and WF only have .Net interfaces. From what I had heard a couple years ago it sounded like Microsoft had promised C/C++ interfaces to everything in Vista, including what was implemented in .Net Framework 3.0. I talked to a beta tester several months ago and he said he saw no C/C++ interfaces to them. So it looks like in order for developers to use them they MUST switch to managed code, or use Managed C++ at least. It has the ability to produce hybrid programs that are part native and part managed. Maybe the native C/C++ interfaces will come later.

Justin James
Justin James

Mark - I was talking about the directory layout of the project too... the idea that the framework is so dependent upon it bothers me. In terms of speed, I have not used it so I cannot evaluate it. Of course, your fastest Web app will be C/C++ in a CGI environment, or even faster, a native app that eschews a Web server entirely and acts as its own Web server; then again, you'll spend years writing it. That is the trade off. In general, the less programming you do, the slower it runs. .Net is compiled, so it can run fast, but it is a virtual machine that loads a ton of libraries, which slows it down a lot... the same can be said for Java. It may very well be that the performance ding from these mamnaged code environments is much bigger than the interpreted language penalty. My experience has been that Perl will run tens, if not hundreds of times faster than VB.Net for a program that does the same thing. I would imagine that Ruby's performance is a bit slower than Perl's (truly object oriented, less mature language, less developers tweaking the interpreter, etc.), but still much better than Java's or .Net's. On the other hand, someone could make a CPU that could run .Net or Java bytecode, making that language a non-virutal machine and actual native code, which would run quite fast... but why would they? Maybe if it was an expansion card... J.Ja

Justin James
Justin James

... any software that, when asking for a Windows directory path, will not work right if the trailing backslash is omitted is pretty stupid. That's the kind of thing I have a problem with. Windows admins are used to leaving off the trailing backslash since 99% of Windows apps are smart enough to not require it, since every Windows language I ever used does not require it. Not so WebLogic! If you leave off the trailing backslashes on the classpath, it does not seem to work. I am sorry, but for $40,000 per physical server, I expect a bit better. That kind of thing barely warrants a footnote in most manuals, yet it is a showstopper. J.Ja

Justin James
Justin James

... and in my mind, one of the biggest "poorly coordinating moving parts" in J2EE is the app server itself. .Net can be truly wretched when one just rolls with the wizards. That's how Microsoft hooks developers in, make it easy to create working (on the surface) crapware, just long enough to get them to commit to the codebase and the platform, and hope they learn to write it better. J.Ja

Editor's Picks