Developing for Healthcare - .NET vs J2EE?

An anonymous reader asks: "Our small southern shop (an eleven man team) is about to commence development on some medical software geared for physician's offices and hospitals. Since we have never developed in this area before (our primary source of income comes from developing software for regional transportation offices of the government) we are at loss for the reigning technologies. The two technologies we are considering are J2EE and .NET. What are the opinions of the Slashdot crowd? Surely others have developed for the monstrous healthcare industry. Thanks!" "My senior manager recommended using .NET. His argument is that most desktops he has seen in hospitals already run Windows, the development time will be cut down for this small to mid-size project, rich desktop clients are possible and there will be no application server costs involved. He also contends that .NET has more templates and abilities than J2EE (which is simply 'web targeted' in his opinion.

Half of my coworkers are with him and the other half have suggested using J2EE due to portability--we do not want to cut off any potential sources of income with an already dwindling future. Has GNU/Linux become widespread in the healthcare industry that we should consider developing for it too? What about Mac OS X server?

The last problem we have is winning over the IT staff hearts. They are the ones who ultimately give the go ahead to purchase the software. Java gets a bad rap for being slow, while Microsoft (and by extension) .NET has the shadow of being insecure. How can you possibly win?"

Comments

Re:Slow

[Mr. Shiny And New]

His point isn't that he's ignoring a problem; though the argument is badly worded, what was meant was that Java's memory overhead was considered high in the early days, but it has remained mostly constant compared to the ammount of ram available to programs, and compared to the size of the java application program itself. So what used to seem like a huge overhead is not even noticable now.

And Java's JIT compilation actually out-performs natively compiled C++ in some cases. So it's not a clear-cut "Java is slower" question; for some jobs it will be, but for many, many jobs it is either A) fast enough, and the speed lost is worth the savings in security and dev. time, or B) faster than native code.

Of course, all of this doesn't mean that you should always use Java. But you should always try to use the right tool for the job, even if that tool is Java or .Net.