Fog Creek Software
Discussion Board




Does Java Suck?

I work for a company that builds web applications. We're currently in the process of moving from a scripting language that does everything we want to Java, simply because large numbers of clients will only consider solutions written in Java. Yes, this is stupid, but necessary for the company to survive. We have hired some experienced Java programmers to ease the transition. However, the Java code written by these programmers runs very slow and seems to take forever to change when clients ask for mods. This is a foreign world for the rest of us because if our previous code took over 1 second to do something we would be wondering what went wrong. Plus, unless a client request was really stupid (50% of them) then making substantial mods could be done pretty fast.

So my questions are: is Java slow and hard to modify and therefore unsuitable for a web apps?

Is the solutiuon to charge more to cover the increased development costs so the clients can get slower applications written in "JAVA!"

PS: our current script based apps are written in a very advanced manner to form an api-like interface that is very fast, robust and easy to modify.  The heavy lifting is done with c++ modules.

IPreferToRemainAnonymous
Sunday, June 29, 2003

Java is a large productivity and safety gain compared to C++ or C.

However, it is significantly less productive than Delphi, or Python.

Perhaps you can offer your clients 2 prices, one for using Java, one for using whatever scripting language you use.

John K.
Sunday, June 29, 2003

Well written Java is neither slow nor unmodifiable.

Walter Rumsby
Sunday, June 29, 2003

I'm always baffled by why clients care what language an application is written in. I don't care what brand of robot built by car.

I would be tempted to implement a small amount of the system in Java and leave the rest in your scripting language.

Which scripting language is it by the way?

Matthew Lock
Sunday, June 29, 2003

> Well written Java is neither slow nor unmodifiable.

Compared to what? This is the important question.

John K.
Sunday, June 29, 2003

The scripting language is Cold Fusion (yes, it can really suck, but it is possible to write good code in CFML if you know what you're doing). Actually CFMX is compiled to java servlets and then executed (only recompiled if they change). Perhaps that's the answer to my question - if they can run fast then there's no reason why other Java code can't run fast.

Maybe the design patterns used by your typical Java programmer result in slow code? Whereas the CFMX coders probably write really ugly code that is optimised for speed?

That still leaves the issue of development time. I'd say that Java takes 4-5 times longer to write - for the same result.

IPreferToRemainAnonymous
Sunday, June 29, 2003

"Actually CFMX is compiled to java servlets and then executed "

Uh, doesn't that mean you're already writing in Java? This seems like a complete no-brainer. If you're running Java bytecode, you're running Java bytecode. It's no business of the client what the source of the Java is...

How does the deployment compare? (Cost & TCO)

Philo

Philo
Sunday, June 29, 2003

Maybe it's the Java programmers you hired that suck.

Walter Rumsby
Sunday, June 29, 2003

[[ Maybe it's the Java programmers you hired that suck ]]

I wonder why this trivial option never occured to the original poster .. I'll ask another question "Does people enjoy asking why Java is slow and suck so much without pointing to the developers first ?"

Evgeny Goldin
Sunday, June 29, 2003

And here is an example of how a Java developer can suck:

for ( int i = 0 ; i < 100000 ; ++i ) {
    char[] buffer = new char[10000];
    ... // do something with buffer
}

instead of

char[] buffer = new char[10000];
for ( int i = 0 ; i < 100000 ; ++i ) {
... // do something with buffer
}

QA won't catch it - after all, both work, but it's a bad bug.

Note: the first example is actually a direct translation of *good* C++ code:

for ( int i = 0 ; i < 100000 ; ++i ) {
    char buffer[10000];
    ... // do something with buffer
}

This goes to the discussion previously held on this board about "leaky abstractions". The CF example is a justification of my assertion that working at higher levels of abstraction often results in more efficient code.

I assume that CF's developers did a lot of work to make sure that the generated Java code is efficient, work your Java developers must now "duplicate". Since they are apparently not as good as the Java developers working on CF, the result is not as good.

Also, it's quit obvious why an environment specifically created for Web applications is more flexible in that context than a general-purpose language such as Java. That is why system developers using high-level programming languages often like to create Domain Specific Languages (DSL) for a problem domain.

BTW, I agree with Philo - just give them the byte code and tell them it's Java.

Dan Shappir
Sunday, June 29, 2003

I don't think that the developers suck. Admittedly when I look at their code, it seems overly complex for what it has to do. But I don't think that I'm really qualified to make the call. Perhaps as I start to code more in Java, I'll also have to make very complex inheritance heirachies, etc in order to achieve the same results that can be done in CFMX.

I'd really like to quiz them on why their code is written in the manner it is, but they have no time to spend on educating me because their projects are already running well over time.

They have impressive programming credentials, which is why I just assume that programming in Java is labour intensive and difficult to get right. 

CFMX is around US$5000 - fairly expensive.
Java is about US$0 last time I checked.

IPreferToRemainAnonymous
Sunday, June 29, 2003

>> "If you're running Java bytecode, you're running Java bytecode. It's no business of the client what the source of the Java is..."

But the client may want to see webpages extentions with .jsp instead of .cfm. :)

Chi Lambda
Sunday, June 29, 2003

>> Perhaps as I start to code more in Java,
>> I'll also have to make very complex inheritance
>> hierarchies, etc in order to achieve the same results
>> that can be done in CFMX.

Are you refactoring your entire framework in order to work with Java instead of CF or is this just a one-off for that customer? If the former than it's quit understandable why it's so hard and takes so long - your programmers are basically recreating CF. CF costs a lot because it was a lot of work to build.

If the later, their implementation should be very specific and thus shouldn't require complex inheritance hierarchies (unless that customer has very complex requirements).

Could be they are simply over-engineering, as programmers are wont to do.

I also have to ask: given your investment, is this project cost effective?

Dan Shappir
Sunday, June 29, 2003

Dan - I think you're right.

CF gives us a lot of pre-built stuff right out of the box. In order to rebuild our applications using Java, we'll have to reproduce CF's existing functionality, including the optimisations to make it fast. No wonder it seems to suck to me.

I think that I'm under-estimating the effort required to move to Java. It's like moving into the countryside and trying to rebuild the city that you used to live in.

IPreferToRemainAnonymous
Sunday, June 29, 2003

You need to profile the code and attack bottlenecks.

The really sad thing about this is, you have a bunch of cold fusion guys who find java weird.  Suppose you were buying a webapp that you wanted to modify.  You'd want Cold Fusion over Java, wouldn't you?  That's because you find Java ponderous, and your team is full of Cold Fusion ninjas.

If you think about it, CF already had a few Java optimization cycles, whereas in your case, the emphasis was probably on time-to-market and not efficiency.

sammy
Sunday, June 29, 2003

"Admittedly when I look at their code, it seems overly complex for what it has to do."

Perhaps you should judge the produced code by the following rules:

"Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it. (...)
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea."

Although written with Python in mind, I'd say they're valid for any higher level language.

Johnny Bravo
Sunday, June 29, 2003

Assuming this post isn't just designed to get java lovers and java haters all fired up I would suggest the following.  It is entirely possible that for a given application a JSP implementation would be slower than a ColdFusion implementation but there is really no exuse for it being ponderously slower.

What is the nature of your application?  What is it running on?  Does it do a lot of database interaction and if so are your developers failing to use connection pooling?  Have they looked into all the prewritten tag libraries which are available (in fact, wasn't cold fusion supposed to be available as a JSP tag library by now?).  Are they only using JSPs or are they using other aspects of J2EE such as EJBs?  In many situations Message Driven Beans (or just your own JMS code) can make apparent performance improvements by decoupling operations.

The short answer to your question is no, Java doesn't suck.  Like any other programming language it has strengths and weaknesses and requires good programming and code optimization to be at its best.  Yes, I know a pure C++ implementation will usually be faster with less effort, but if you were to code in all the extras that Java gives you (no buffer overflows etc.) I'm certain you could slow it down quite a bit.

Also, switching languages because a customer wants you to is stupid.  The proper response is to try to talk them out of it, but if they insist you need to decide if the cost of the new development is higher or lower than the money these customers will or will not pay.

Erik Lickerman
Sunday, June 29, 2003

Back in 2000, I wrote a few dynamic web pages using Java servlets (I used Apache's Tomcat). They were the standard database driven stuff. A form post would write to a database and each page displayed information in a database.

The speed of a page fetch was fast. No noticeable delay at all.

Perhaps the programmers you are using aren't very good. In my time I've seen Java programmers do silly things. For example, database connections weren't being cached and so each page fetch would have to make a new database connection. Very sloppy and very slow. I've also seen some Java programmers forget to close (or better still return to the pool of cached database connections) the database connection after the database query was over. A few dozen page fetches and all the connections will be used up.

Savage Planet
Sunday, June 29, 2003

Yes, Java does suck.

Clutch Cargo
Sunday, June 29, 2003

I can not help … Slow weekend, I have to enter the fray …

Dan Shapiro: I mean no offense, but everything is relative…

1. One may notice your example number one sucks in any language but some are more resilient due to fast memory allocations and a lack of GC.

2. How do you know how
“char[] buffer = new char[10000];”
compares to
“... // do something with buffer”
without profiling?

As far as the casual observer knows “char[] buffer = new char[10000];” can be completely insignificant in the grand scheme of things.

3.  An experienced designer would point out even example number two sucks since creating a memory pool will avoid unnecessary heap fragmentation and memory allocations for you entire application.
I know… This solution sucks.

coresi
Sunday, June 29, 2003

It's Shappir not Shapiro :-)

Anyway,

<i>One may notice your example number one sucks in any language</i>

Not so. I provided the C++ example to show that it need not always suck. Indeed, in C++ it's better to put such a buffer definition inside the loop for scoping reasons. I actually saw this error while reviewing code that was translated from C++ to Java.

<i>be completely insignificant in the grand scheme of things.</i>

<b>Everything</b> is insignificant in the grand scheme of things, but doing 100000 allocations of 10000 words when a single allocation would suffice is generally a Bad Thing.

And yes, I never optimize before using a profiler (well, almost never; sometimes I just can't resist ;-)

Dan Shappir
Sunday, June 29, 2003

>>It's Shappir not Shapiro :-)
I apologize, my honest mistake.

>><b>Everything</b> is insignificant in the grand
Exactly. No reason to bash one language or another…

>>but doing 100000 allocations of 10000 words when a single allocation would suffice is generally a Bad Thing.

My Electrical Engineering background says while allocating more than necessary is a waste, if it takes one order of magnitude less time than the “// do other things” line you can safely ignore it.

coresi
Sunday, June 29, 2003

Not to be pedantic, but the C++ equivalent would have the same problem.

you could do:

for ( int i = 0 ; i < 100000 ; ++i ) {
    char* buffer = new char[10000];
    ...
}

In which case you would also have an enormous memory leak!

I don't really see how this is an example of Java developers sucking.  It just means when you translate from one language to another, you should:

1. be careful, I could see anyone doing this if they were rushed with a deadline
2. actually know both languages and know their differences

Andy
Sunday, June 29, 2003

yes, java sucks.

beaver
Sunday, June 29, 2003

What app server are you running on?
is it tomcat/bea

or resin/orion

also are you using ejb's

Daniel Shchyokin
Sunday, June 29, 2003

I'm curious that you say the Java programmers have good "programming credentials." What does that mean? They have little certificates? It doesn't sound like they are experienced i.e. good developers.

Java and especially J2EE can suck badly. Things like EJB's encourage developers to bloated overkill. Struts is a good way to make code dangerous.

As Walter Rumsby says, it is possible to write good code in Java, but it's common to see poor code,  perhaps because J2EE has attracted all the little certificated trendoids.


Sunday, June 29, 2003

I'm still wondering what you're trying to do with your migration CF to Java. My understanding is that .cfm pages these days are alternatives to/implementations of JSP pages - basically CFML is not unlike Velocity, Struts, WebWork, etc as an alternative view technology.

So, all your view logic should/could still be in CFML tags. It's stuff like <CFQUERY> that shouldn't be being used - Java should be doing the "heavy lifting", ie. anything that is not simply outputting, looping over for instance table rows, etc.

Is my understanding of CF MX correct? My impression is that basically the CF server is now JRun and .cfm pages get turned into .jsps and/or servlets? Do your Java guys know this or are they potentially recreating CFML without realising that it already exsists?

"Complicated inheritance hierarchies" also raises a red flag. Overuse of inheritance suggests a naieve understanding of OO. Using EJBs where they are not needed can also be problematic.

Finally your clients insistence that your applications be Java and not Cold Fusion based seems to reflect Allaire / Macromedia's thinking - larger scale applications should be written in Java with CF as the view technology. This seems to suggest that your clients simply want flexible applications. Given all of this you can give them CF-based applications that are also J2EE applications - maybe they need to know that.

(Aside, Ben Forta's JSP book is very very bad - he is/was the author of the most well regarded CF book when I was working with CFML in 1998, but the JSP book is riddled with syntactical and ideological errors).

Walter Rumsby
Sunday, June 29, 2003

"Beautiful is better than ugly.
Explicit is better than implicit."
etc.

This list is probably one of the most useful comments I've seen on the Joel on Software Forum.

Neil Bloh
Sunday, June 29, 2003

No, Java does not suck. However, it can be argued that most Java programming teams suck (as do most C++ programming teams, and most LISP programming teams, and most Visual Anything programming teams, ad infinitum.)

Think about it this way: your team spent years finely crafting and honing a solution tailored to specific circumstances. The new Java guys came in and slapped something together. The question isn't "Does the new stuff suck?" Of course it sucks. Nor is it "Why does the new stuff suck?" The question is "Do the new guys have the talent and management have the patience, savvy, and money for the new team to gell into a highly-productive team?"

Another way to  think about it: were the Java guys told to optimize their solution for performance and flexibility or were they told to get something operational as fast as possible? Teams optimize what they are told to optimize and they do it at the expense of other things. This is commonly aphorized as "cheap, fast, good: pick two." For large values of cheap and fast, it ends up being "pick one."

Jim S.
Sunday, June 29, 2003

Java can work for you.  It requires more knowledge to build fast apps with java than many other languages.  I base this on the fact that many believe java to be slow.  Where did that impression come from.  From witnessing slow java apps. 

I do not mean to imply java cannot be fast, simply that it is apparently incredibly easy to write slow apps concluded by the fact that there are so many slow apps.  Maybe there aren't enough smart java developers. 

My opinion - write it in whatever you want, it is your product, not your customers.  If you make it do what you clients want - that's it. 

Mike
Sunday, June 29, 2003

Just write an app in Java and then the same app in C++.

Let's say you write something without a GUI.

Then, time the two programs.

You will find out why Java is considered slow.

Because this is, simply, the naked truth: Java is slow.

I did this test for myself, and you can do it, too.

Avenger
Monday, June 30, 2003

Avenger,

For client based applications what you say is correct and can be relevant, however for server side applications it matters not.

On the server side, you should program in whatever gives you the greatest productivity. I'm sure your client would be much happier spending $50k less on consulting time and $5k more on server hardware.

There seems to be a concern that Java is slow. Sure it is slower than C++, just as C++ was slower than asm. However, these days for business applications it really doesn't matter, as computers are sufficiently powerful. The reason C++ won is because of the productivity advantages associated with writing code at a higher level, thus reducing both time to write and time to debug.

Secondly, Java itself is no slower than C#. The Swing Java windowing APIs is slower, because it is written for cross platform compatibility and attempts to do more (generate scroll bars and menus), rather than just farming it off to the OS. Try doing a trivial proof of concept console app in Java and C#, and you'll find similar start up times and similar processing times (I did anyway).

I'm sure (and hope) that in 10 years Java is dying off, and is replaced by a higher level language that does more for less. The Java/C# programmers of that time will be seen as low level hackers :)

Rhys Keepence
Monday, June 30, 2003

PS: our current script based apps are written in a very advanced manner to form an api-like interface that is very fast, robust and easy to modify.  The heavy lifting is done with c++ modules.

You can probably reuse the C++ stuff in Java.

There is this thing called JNI - java native interface,
You can write a java class that calls into native C++ code;

(you just have to write a transition stub,
I have done that several times for my customers).

Michael Moser
Monday, June 30, 2003

"Struts is a good way to make code dangerous."

Can you elaborate please?

John Topley (www.johntopley.com)
Monday, June 30, 2003

I'd also like to know how using struts could make my code dangerous!

Konrad
Monday, June 30, 2003

I realize I am on the tail end of this discussion, but perhaps I can shed some light on the subject.

I have developed Java in many projects and your apps will run slow if you use one of these Integrated Development Environment tools (IDE) like JBuilder, Visual Cafe, etc.

The faster apps are the ones that are made with a text editor like notepad.  Also, use Object Orientation to your advantage.  Java is great for that.

A well constructed OO app is a breeze to modify.

Bryan Shaw
Monday, June 30, 2003

Why should the tool used to create the .java files affect the runtime performance of a Java application?

John Topley (www.johntopley.com)
Monday, June 30, 2003

Unlike client-side java, server-side java generally performs well without requiring gurus or magic tricks, as long as you don't make heavy use of EJBs.

Did they use a lot of EJBs in the system?  If so, that probably explains why the performance sucks even though the programmers have "impressive credentials".  Some programmers will deliberately and unnecessarily use EJB just so they can make their resume look more impressive.

T. Norman
Monday, June 30, 2003

Using a java IDE in the way that you would use VB or Delphi to create a UI results in poorly performing Java code. 

For example, you put a JTree (treeview) onto a window.  Then write some code to populate it.  An IDE would probably create a DefaultTreeModel to hold the data (Swing UIs separate the data model from the view displaying it). 

DefaultTreeModels are slow - as the name suggests, they are a placeholder container for the actual data model.  In most cases you actually want to write a custom tree model to store your data.  But the IDE shoves the code in for you; and many developers wouldn't go back and change it.  Hence the IDE can result in poorly performing code. 

Zealot
Monday, June 30, 2003

Since we are rewriting parts of our product in java from ColdFusion I guess I have some experience.

Why we did it? - we now require a lot of functionality that is hard to do in CF - outputs in pdf, word, excel using fancy graphs, real time simulations where CF is much too slow.  CF is expensive and getting talent to work with it is getting harder.

Our java code is faster, but it took some time to get there.  It irratated the manages because CF can show UI(though incomplete) much earlier, so they thoguht we are not doing anything.  The Merrant DB Drivers in CF are fast, optimized with great connection pooling.  The standart Java ones were not that good and we had to do recreate things.  It is much easier to overly abstract things in Java.  Some of our first Java code was riddled with performance mistakes like the example given earlier, but I guess we were quick learners.

tekumse
Monday, June 30, 2003

"The faster apps are the ones that are made with a text editor like notepad.  Also, use Object Orientation to your advantage.  Java is great for that."

This is either sarcasm, or incredible boneheaded stupidity.

Neil Bloh
Monday, June 30, 2003

"I'm always baffled by why clients care what language an application is written in. I don't care what brand of robot built by car."

BRILLIANT!!

Norrick
Monday, June 30, 2003

We sometimes lose competitive evaluations because our software is not written in language-of-the-month. It used to be Java, now we're fighting .NET. And losing.

I'm loath to change our development language, which is currently C due to its combination of portability, efficiency and performance. Because our main development environment is Visual C++ we can sometimes claim to be more "modern" (evaluators words, not ours) by stating that the software is written in C++. That would let us occasionally beat the Java issue, but is not working against .NET competitors.

Personally I agree with the person who made the car/robot comment. It shouldn't matter. But our customers have made internal choices about the languages and platforms they will support, and their choices often become internal religions. You have as much chance changing their minds about this one application as you have in moving Osama Bin Laden into the Vatican.

HeWhoMustBeConfused
Monday, June 30, 2003

Are these clients going to be responsible for maintaining the source code after the application is delivered?  If so, then obviously they should be concerned about which language it is written in.

You may not care about the robots that built your car, but if you were planning to maintain the car with your own hands, you'd be wise to be concerned about the specific engine and parts that make up the car.  Similarly, if the client is going to maintain the code any point in the future, they shouldn't be concerned with which IDE or version control tool you used while developing it, but they would be foolish not to care about the language.

NoName
Monday, June 30, 2003

This is one I blame on Sun. Before the "Java" campaigns choices like development language were largely confined to the developers/techies. Sun however aimed below the belt by targetting the Sales/Managers/Users with an extreme advertizing war aroud the Java brand.
The result: since that time platform decisions that are irrelevant to the operation of the product (read: should be invisible) are now taken by people who have absolutely no clue on the technical merrits and are oblivious to the consequences of that decision on development cost/quality of the end product.

Just me (Sir to you)
Tuesday, July 01, 2003

That business of selling technology to the nontechnical decision makers was going on long before Sun came with Java.  Look at Oracle and Developer 2000.

T. Norman
Tuesday, July 01, 2003

As someone who has done both C++/MFC and Java, and combined the two in a commercial product, here is what I've found. Take it for what its worth: a single data point.

In general, Java IS slower than C++, and the "degree" of slowness depends on what part of Java you're using. Also, depending on what you're using Java for, the slowness may or may not matter. There aren't any two second answers here.

Java/Swing is considerably slower than any of the platform-dependent equivalents. Java for DB access is not that much slower --- noticable, but not nearly as bad.

Now, I do know the advice given by the Java gurus: that we need to work at tuning performance to make it acceptable. This strikes me as a cop-out. Remember that a large part of the justification for Java was that it simplified programming tasks and boosted developer productivity. Where's the productivity gain if you have to fine-tune performance to that degree. Bad, bad, bad.

Here's an example of why the C++/Java decision is not as clear cut as it may seem.

Prior to doing Java, my group was involved in a heavy C++/COM effort; I mean HEAVY COM, as in COM as a replacement for the C++ object model (stupid since we weren't going to be using the COM-ified stuff in a way which really justified the investment in COM).

If I compare the C++/COM code to the equivalent Java code, then Java is the hands-down winner in reduction in complexity and developer productivity. Its just far easier to develop the Java in the first place, and its just far easier to maintain the Java code. But, it is definitely slower than the C++ equivalent. Also, much of the early productivity gain is lost as we perform extensive performance optimizations.

I think that the moral of the story has to be, don't apply sweeping generalizations to the situation. Know what you're getting into and make decisions accordingly.

If cross platform concerns are significant to you, then you may not have any choice, and must go with Java, with all the attendand performance and tuning considerations.

If web-based apps are the target, then Java will probably be sufficient -- no performance bleeding Swing to get in the way. This is really where Java shines, in my opinion.

If you are developing for a single platform, then why go Java at all? You've simultaneously erased one of the important reasons for Java's existence (cross-platform), and will also incur the significant penalty of guaranteed performance loss with no reason for justifying it.

This is not a question of developer capabilities, as it is "time-to-market" and other such competitive concers. Smart developers can do anything, given enough time and resources. Who ever has enough time? Therefore make the Java/No Java decision in the light of these considerations.

As things stand right now, if you use Java in situations where it is perhaps not the best choice -- client server on a single OS, with large rich clients, then it is probably a mistake. This may change in the future as Sun optimizes the Java platform, but it could be a while.

If you are developing web apps, then Java is probably a good choice.

Just my $0.02.

AnMFCAndJavaProgrammer
Tuesday, July 01, 2003

Having read some books recently like Richard Gabriel's _Patterns of Software_, I hear business's obsession with languages started really long ago, at least since COBOL.  Sadly, there's some justification to this; Grace Hopper certainly increased the net of programmers by inventing programming languages so people didn't need to have a deep background.

As for it being a "copout" to suggest performance tuning... maybe.  Just hard to argue the point when no one here knows the true reason the webapp is slow.  We need his Java monkeys to say...  And obviously it's disempowering when you have to rely on someone else's skill to pick the best solutions.

sammy
Tuesday, July 01, 2003

So no one can tell us why Struts is a good way to make code dangerous?

John Topley (www.johntopley.com)
Tuesday, July 01, 2003

I say (a) TRY TO DETERMINE WHICH IS THE SUPERIOR TECHNOLOGY and (b) STICK TO IT!!  "a" is difficult because, it takes a lot of work to master (i.e. "get to the bottom of", ESPECIALLY with Java -- serious flaw???)  two divergent (e.g. procedural vs. oo) technologies.  Usually, we get into them deep enough to get a gut-feeling/impression, then we PICK OUR HORSE AND RIDE IT.  I started in Java (when that was in), then I tried C, fell in love with it, and then I COULDN'T GO BACK TO JAVA!!  (Of course, I was pretty fried at that point!!)  Also, "b" is tough, because Java got so darned trendy!!

Importantly, I do think Java has a lot of built in doo-dads, which are handy for gui web applications.  However, it's speed makes it impractical for a lot of other applications.

Final thought:  if you are hosting the applications, too, it might be practical to use some rewrite rules in your Web server to change the  file extensions from jsp to cfm, maybe providing a helpful "work around"!  JUST A THOUGHT!!

And (c) don't forget to always GIVE THE PEOPLE WHAT THEY WANT!!  (as in a good dowling!!)  ;P

IPreferToRemainAnnonymousAsWell
Wednesday, July 02, 2003

Why does struts cause people to write dangerous code? I'm legitimately curious ... most people that I talk to seem pretty happy with struts. It's a bit of work to get up to speed on, but I haven't seen anything that seemed really DANGEROUS yet.

jimbo
Wednesday, July 02, 2003

My business site (Javadesk) is completely written in Java. There are over 250 JSP pages and 1000 classes. It runs on PIII-800/512Mb. You can see our architecture in one of business articles on the home page.

To summarize : Java is fast and secure. What is really matters is the system design and lines which connect your system to the outer world - say bandtwith/traffic.

Evgeny
Wednesday, July 16, 2003

As my name implies, I am the dept. bitch for coding and have seenhigh level gurus code comples xprojects ranging from bash/pelr scripting to C#. Although, as an innocent bystander I foound out that through analysis over the ears, it is really how you coulde the project than blame the language. However, if you would use a screwdriver to do a hammers job, well Then YOU SHOULD NOT BE DELLING SOFTWARE

coderServent
Tuesday, July 13, 2004

*  Recent Topics

*  Fog Creek Home