Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Programming Java Operating Systems Software Windows Technology

Developing for Healthcare - .NET vs J2EE? 645

Posted by Cliff from the which-technology-would-you-use dept.
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?"
This discussion has been archived. No new comments can be posted.

Developing for Healthcare - .NET vs J2EE? More

Developing for Healthcare - .NET vs J2EE?

Comments Filter:

  • ARGH!!!!!! (Score:5, Insightful)

    by Anonymous Coward on Thursday December 23, 2004 @08:01PM (#11172994)
    1. Java is not slow
    2. .NET is not insecure

    • Re:ARGH!!!!!! (Score:3, Informative)

      by alpha_foobar ( 820088 )
      1. It is possible to build faster applications using a language that compiles to native/is not interpreted. Though Java is not much slower (if slower) than other languages when implemented with this in mind. For a really slow technology try microsoft distributed queries.

      2. It is possible to build very slow .NET applications. And all technologies are only secure as the code that was developed and the architecture that they are run on. You don't have to run .NET on windows, try it with mono.net with a LAMP(i
      • mono.net with a LAMP(ish) server build.

        What, Linux, Apache, Mono, Postgresql? It's good that there's a .NET Postgresql Client API that seems to work well.

    • Re:ARGH!!!!!! (Score:3, Insightful)

      by EvilTwinSkippy ( 112490 )
      Yes, but your app running of J2EE isn't going to die 6 months down the line if some well meaning nurse runs Windows Update.

      (Awaits the volley of flames)

  • You can't win.... (Score:5, Insightful)

    by Anonymous Coward on Thursday December 23, 2004 @08:07PM (#11173013)
    Because it simply doesn't matter.

    Either your client dictates the technology or he doesn't. The "Healthcare Industry" is a vast array of mixed technologies, so it doesn't matter that way. And if they're buying your solution, they're buying your SOLUTION (which typically involves hardware), so THAT'S not important.

    Go with what you know, go with what you're comfortable with. The success or failure of your project will have nothing to do with this decision, just in how you pull it off.

    You can find all sorts of excuses to fail in either platform, and you can find just as many reasons to succeed. Pick one, don't second guess yourself, and stick to it.

    Good Luck!

    • I work in the SouthEast now. I'm not directly envolved in software development for the medical industry but I do keep my eyes open. Most medical systems that are doing modern development have chosen J2EE over .Net and I have no clue as to why.

  • Why are you asking us? (Score:3, Insightful)

    by Jailbrekr ( 73837 ) <jailbrekr@digitaladdiction.net> on Thursday December 23, 2004 @08:08PM (#11173015) Homepage
    Don't ask us. You know the client better than us, and should be able to determine what the best tool for the job is based on the application you are writing, as well as the environment which you are installing it in. Don't make the decision based on what everyone else is using, base it on what will work the best.

    • Re:Why are you asking us? (Score:5, Insightful)

      by Anonymous Coward on Thursday December 23, 2004 @08:19PM (#11173063)
      Right on, he's obviously lost without a clue if all he can do is trot out these lame stereotypes about the technology (duhh, .NET is insecure, J2EE is slow) as arguments without mentioning 1 word about the friggin requirements.

      Not to mention, .NET isn't insecure and J2EE isn't slow... they're both insecure and slow if your development methods are insecure and inelegant. That's like saying "should I use a hammer or a screwdriver? A hammer can smash your thumb, whereas a screwdriver can gouge your eye out..."
    • I concur.

      I'm a Java developer for an enterprise-level J2EE shop. I happen to like Java: the rich libraries, the elegance that OO can bring, the cross platform support (we code in Windows, have Solaris and Linux for our staging environment, and deploy to Solaris.) I have no complaints about Java, and encourage its use.

      Having said that, however, ultimately a decision like this shouldn't be made on techonological grounds. I haven't used .NET, and typically cringe at anything Microsoft, but for Festivus's s

    • "Don't make the decision based on what everyone else is using, base it on what will work the best."

      Now if you mean to say: Use what most hospitals use, then sure.
      but many hospitals are not using whats best, just what the guy running the hospital told them to do.
      Cause he's a doctor, and as such is an expert in computer technology. Just ask him.

      Yes, I've worked with hospitals.

  • Nice troll. (Score:5, Insightful)

    by Anonymous Coward on Thursday December 23, 2004 @08:09PM (#11173022)
    Your project, assuming there really is one, is doomed already.

    You're asking an Internet message board for advice on a development platform? For software you're going to develop for an industry you have no experience with?

    • Re:Nice troll. (Score:3, Interesting)

      by Guido69 ( 513067 )
      Umm...not necessarily. Sounds like a small shop, and the feds have special programs to award them contracts. We're in the same business and often serve as the prime on the contracts. Often times they are agile enough to pull off the job and turn over a good product.

  • Either a troll or a REALLY clueless person (Score:5, Funny)

    by Anonymous Coward on Thursday December 23, 2004 @08:20PM (#11173064)
    you want to develop for a new vertical industry that you're not familiar with, you're not sure about your dev platform and you came to /. seeking objective analysis on a platform involving MS?? Well, you certainly deserve all the "PHP rocks!" and "11 lines of Perl are all u need" answers you'll be getting...

  • Think of Security (Score:5, Interesting)

    by Anonymous Coward on Thursday December 23, 2004 @08:21PM (#11173069)
    Any program written for the medical industry that involves capturing patient data is required to be secure. Read up on HIPPA (http://cms.gov/regulations/hipaa/cms0003-5/0049f- econ-ofr-2-12-03.pdf) before making a decision. The company I work for creates software for the medical industry and we chose J2EE for the security and relatively low barrier to entry using open source application servers and tools.

  • Healthcare industry? (Score:5, Insightful)

    by amalcon ( 472105 ) on Thursday December 23, 2004 @08:26PM (#11173089)
    Sounds like you're asking the wrong question. What sorts of applications are you expecting to develop? Is it primarily database stuff? Are you developing for a small or large organization? (given that you have an IT staff, I'd expect large).

    The only thing I can tell you for sure is that it's much easier to prove to an IT staff that something's not slow than that something's not insecure -- just show them Eclipse or anything else that...doesn't use Swing...which is the one really slow part of Java.

    Really, though, these technologies are so similar that you should probably just pick one and go with it.

  • J2EE and webapps (Score:5, Informative)

    by ip_fired ( 730445 ) on Thursday December 23, 2004 @08:35PM (#11173135) Homepage
    In my opinion, I think that webapps are the way to go with a project like this. I say this because we currently have an old legacy application that uses Borland C++ Builder, and it is very difficult to manage the all of the versions being used by staff members. As we've moved the functionality over to a web portal, we've been able to spend less time distributing executables and more time developing features.

    A webapp has the strength that all you need is a web browser to view the content. When you update the webapp, all clients are updated instantly, without having to push something out to them, or making them download something. This saves a lot of stress and headache.

    There are many technologies out there for writing a database oriented project like this a lot easier. These include
    • Hibernate [hibernate.org] for object relational mapping and cross compatibility with most major databases (ie, develop on MySQL, deploy on Oracle, Informix, whatever you want).
    • Spring [springframework.org] which manages your mappings and helps maintain consistency across your data connections and helps you abstract your business logic, keeping it out of the actual pages. It also integrates with . . .
    • Struts [apache.org] which gives you a great Model-View-Controller framework to practice good development and good security.

    Apache Tomcat, JBoss, and many of the other java based application servers are supported on many different platforms. You can run it on Windows, Linux, Mac OSX, and virtually any hardware provider you want.

    I've been working now on this project for 6 months, and I have to say, I love the structure of this way of working on webapps far more than the common hodge-podge of php or perl. This isn't to say you can't program a nice, easy to maintain app in these languages, just that there is a nice framework with examples and plenty of books to do it in Java.

    • Re:J2EE and webapps (Score:3, Insightful)

      by Audacious ( 611811 )
      From the sound of it I would have to say that their first step is to just decide whether it they want to create a webapp, standalone, or client/server program. My choice would be a webapp for the very reasons stated in the above post.

      For languages, although some differ, I would suggest Perl or PHP first (not only because they are fast but both languages run on a large number of systems in the same manner. So if your boss comes to you one morning and says you are moving from a Windows box to a Linux box y
      • With Perl you create packages.
        With PHP you create classes.
        With Java you create classes.
        With C++ you create classes.
        With .Net you create classes.

        Well, yeah, but I wouldn't consider OOD for each of these similar at all.

      • Re:J2EE and webapps (Score:3, Interesting)

        by rainman_bc ( 735332 )
        I hope you seriously aren't suggesting PHP over J2EE...

        The security holes in php compared to j2ee app servers... Ever heard of Weblogic?

    • Re:J2EE and webapps (Score:4, Informative)

      by mic256 ( 702811 ) on Thursday December 23, 2004 @09:24PM (#11173338)
      I generally agree with this opinion, especially about the part of using a web application if possible, because it simplifies distributing the application greatly.

      Some random thoughts though:
      * you can talk to you manager about the time you can save by using the orm (object-relational mapping) technique vs. sql in general (from my experience you can save a lot of time). Then you can tell him/her about hibernate. There is also ibatis which is available for .net
      * The opinion about java and .net that asp.net is fun to program and java is not really comes from (I believe) the legacy technology called struts (yes, I know, I have the asbestos suit, etc.) Two currently best java web frameworks probably are:
      1) Tapestry (jakarta.apache.org/tapestry). It is used by nhl.com and theserverside.net (check by seeing the source for the pages and search for the word Tapestry in it). Tapestry uses a component based approach. Sample components: a nice table, a tree, a date picker in js... It is trivial to write your own and there is a plugin for eclipse called spindle
      2) WebWorks - I have only heard good opinions about it, haven't used it personally.
      * when presenting and using/developing in java avoid using swing when possible. It is ugly, user unfriendly and slow. SWT/JFace is the way to go. You can also check out the eclipse rich client platform (rcp) tutorial on developerworks at ibm.com - it was two part, probably still available at their web page
      * if possible don't use ejb - especially entity beans. Hibernate/Spring (you can also check hivemind - another IOC), WebServices can be very useful
      * when talking to a manager - references, references, and one more time - references. Who uses this technology, what successful project is based on this technology, who backs that technology (you check who is behind eclipse).
      * Java and J2EE by itself (servlets, jsp, ejbs, swing, jdbc, JDO) as it comes from SUN is rather weak and I would recommend not to use it if it wasn't for open source addons and replacements.
      * .NET is ok, but it might be difficult if not impossible to use Linux for the server. If it was not for its lock-in to Microsoft - well, I would say it's a solid piece of technology (not in every aspect, perhaps, but rather good).

  • XUL, fast, light and stable (Score:2, Interesting)

    by Anonymous Coward
    We've been using XUL for stuff like this for a while
    = desktop like interface,
    = lightweight desktop install (eg. firefox)
    = backend choice of components - eg. prototype in PHP, then decide if you really need to go that extra mile with C for any of the slow bits.
    = Users think it's great
    = It's responsive, even on old win98 pentium II's
    = Alot cheaper to add/change develop. etc.

  • The platform doesn't matter. (Score:3, Insightful)

    by Anonymous Coward on Thursday December 23, 2004 @08:40PM (#11173157)
    For the past four years, I have been working for a company that develops healthcare software. We chose .NET for our applications, but I have also done a fair amount of development in J2EE environments. In my opinion, both J2EE and .NET are fine platforms and either one will work. It will be the user interface and features of your application that will ultimately determine its acceptance. People who use healthcare applications are not computer people and don't want to be. They just want to enter their billing, schedule their appointments, retrieve their lab results, etc. If your application allows users to do that quickly and easily, nobody will care what the platform is.

    Now, having said all that, I will fall back on the usual logic and say that if your application needs to be platform independent, J2EE is the obvious choice. If you want the easiest and most productive development environment, stick with .NET.
    • > if your application needs to be platform
      > independent, J2EE is the obvious choice. If you
      > want the easiest and most productive development
      > environment, stick with .NET.

      I'd agree with that, with the caveat that I don't have quite the same level of expertise with J2EE that I do with .NET.

      On the other hand, surely you're considering making some/most/all of your apps browser-based. If so, why not go with the following approach:
      - build back-end with J2EE or .NET (your preference; generally mos
    • If you want the easiest and most productive development environment, stick with .NET.

      This is rather a myth unless your team is a bunch of MS junkies who've never used anything but Visual Studio. Java development tools, overall, are more powerful than those for .NET today. And the Java development tools are mature and time-tested.. For those getting in on the ground floor of enterprise software development, just choose Java and don't look back. There's no compelling reason to choose .NET if you're just

  • Been there, done that (Score:5, Interesting)

    by christian simpleman ( 752938 ) on Thursday December 23, 2004 @08:52PM (#11173202) Homepage
    Last summer we developed a case management system from scratch for hospital admissions pre-qualifications and tracking. Our client serves the medical insurance industry, therefore HIPPA was a factor. We used LAMP all the way, finished the project in three weeks (no brag, just focus and swinging elbows), and they have fifteen nurses banging away 24/7, client access via https, and 100% uptime. All of their money went to us instead of software licensing, they paid less anyhow, and they are smiling ear to ear.

    If the PHP is not elegant enough, for the love of sanity please use Java. If we don't feed the monster that is choking, screwing, and robbing us, it may weaken and we can get on with an unshackled future. We do the entire world a favor whenever we choose sane engineering.

    "If no one tilts at windmills, the damn things will take over the world!"- Christian Simpleman

  • Hospital systems (Score:5, Insightful)

    by Anonymous Coward on Thursday December 23, 2004 @08:58PM (#11173227)
    I work for a small company that does almost exactly what you're talking about, but so far only for hospitals. We have been in business for twenty years now and are having some of the same discussions. We currently run on win32, SCO Unix and AIX. In the past we have supported DOS, HP-UX, Solaris, Linux, AIX, UNIX and WIN32. Most of our customers are running our software (which is character mode btw) on Windows, but our largest, highest paying, and most stable customers are on AIX. If you want large customers you may want to consider something portable. They will usually have a RS6000 running Oracle in the hospital and have many Windows machines connected to it. You can get away with ignoring the RS6000, but that's the most stable machine in the building and IS would love to put it to use. From a support point of view, our customers on AIX and UNIX have the fewest problems and call us the least. There is nothing like trying to diagnose a label printing problem on a Windows network while working remotely over a modem or vpn connection.

    Our debate is focused on whether we should support only one OS, probably Windows, or continue to support three. We'll be switching from UNIX to BSD at some point. (Personally I'd rather use Linux, but as a company we are familiar with UNIX and I'm told BSD is very similar.) The Unix variant side likes the security and reliability, the Windows side likes the graphical interface and the fact that Windows machines are everywhere. Plus we have both Windows and AIX customers that insist on their OS of choice. One thing that scares me about Windows is HIPAA, which makes the hospital liable if a patient's information is leaked. No court cases have been brought yet, but the thought of all that patient information on a Windows machine that could get hijacked is scary. A lot of these hospitals allow remote vpn connections and some of these networks get infected with a worm now and then. I wonder how long before someone decides to steal a patient database and bribe the hospital?

    Most hospital systems, and even some Physician software will communicate with other systems using HL7 protocol over TCP/IP. This is the thing keeping us busiest now and a lot of times it's what the hospitals find most useful.

    Just my two cents, but get used to having the customer tell you what they want and be prepared to do it, if at all possible. Flexibility is key, even more than taking advantage of the latest software trends. Support wise, they will need hand-holding, but they will be loyal customers if you respond to their problems quickly and kindly.
    • Yours is the most informed post in the thread, but you're contradicting yourself in your remarks about Linux.

      Supporting only one OS mostly makes sense only if it _isn't_ Unix. Also, Linux is more like most recent commercial Unix, unless the last Unix you supported was Ultrix. Seriously.

  • Use to work for UK healthcare solution provider (Score:5, Insightful)

    by plcurechax ( 247883 ) on Thursday December 23, 2004 @09:12PM (#11173276) Homepage
    Hint: There are fairly few recent PCs in many hospitals. So unless you are targeting only wealthy private hospitals, assume the worst.

    I use to work on a Unix based custom information system that over a decade old, and on a dozen Unix platforms, and they were developing a new Windows based system. It took multiple years to develop with the new product that was not good enough to replace their existing Unix solution, so hadn't sold a single copy of the new system.

    Of course, to your secondary question, I don't know, but I think it is a classic case of horse before the cart though.

    • There are fairly few recent PCs in many hospitals.

      I know a database engineer that works for a large national health care provider she says this isn't as true as it used to be. Y2k was a wakeup call for an industry that was still maintaining an amazing amount of COBAL and even MUMPS [wikipedia.org] code on old school big iron. This particular health care provider did an organization workstation upgrade during '99. All machines were not only required to be Y2k compliant but those that were running Microsoft OSes were


      • The hospital I work for has repeatedly ranked first in Hospital/Health System Information Technologylists published by Information Week and other like publications and organizations. The bulk of our clinical systems are based on Intersystems Caché, [wikipedia.org] which is basically the most current descendent of M/MUMPS. Increasingly, the front end is web based, but there are still apps that require terminal emulation. Although we too held a Y2K upgrade free for all, that was five years ago, and many of those deskt

  • Slow (Score:3, Informative)

    by Dan Farina ( 711066 ) on Thursday December 23, 2004 @09:17PM (#11173289)
    Java is not that slow. In ye olde days it had a pretty high memory overhead--it still does--but who cares anymore? Memory is cheap and expansive, and (rightly so) people would rather have security and dependability.

    I would choose Java over .NET simply because of maturity and to stay away from a dangerous MS. We all know that MS has the balls and the market share to squash an enemy by any means necessary, even if that means doing something nasty with .NET. Sun doesn't even has this option. I'm not sure if they have the balls, but they sure don't have the market share. It is in their interest to make Java a viable competitor, not a tool for entrenchment. Their biggest conflict of interest is probably in offering Java for Linux which competes with Solaris. Obviously they are not in a position to withhold support.

    While I don't have extensive experience with it, you could compile your Java into native binaries...see GCJ and JET.

    That having been said, I would definitely consider some of the options presented that do not fall in the binary choice you have presented us.

    Finally, while I have not done so personally, my cousin's husband works for a company that develops their product in Java, but apparently can, with not too much trouble, use some automated tools to generate C# for the occasional dead-set MS customer than they come upon now and then. I don't know if tools to perform the inverse exist. He made C# translation sound like fairly trivial an issue for them.

  • well... (Score:5, Informative)

    by domenic v1.0 ( 610623 ) on Thursday December 23, 2004 @09:36PM (#11173416)

    Both .NET and J2EE are good platforms for developing and hosting business applications. Both support n-tier architectures via client- and server-side component models for assembling enterprise applications. This allows for use of either fat or thin user interfaces with both platforms. However, .NET and J2EE are far from identical, and each platform has distinct strengths.

    The primary strength of .NET is its use of multiple programming languages running on a single platform. This eliminates the programming language as a barrier for adoption. Further .NET strengths include ease of use and speed of development as programmers might be transitioning from COBOL or C. (In contrast, transitioning to Java usually takes greater skill in object orientation.)

    J2EE takes .NET's multiple programming-language/ single-platform paradigm and turns it around: The primary strength of J2EE is its use of a single programming language capable of running on multiple platforms. This eliminates the platform as a barrier for adoption. Further J2EE strengths include vendor neutrality and the active involvement of a large, open-source community.

    Legacy applications: Can either platform make integration easier?
    Healthcare providers are moving from traditional reliance on paper-based records and isolated legacy systems. Most now embraced more systematic electronic exchange of patient data, exchanged both within and across organizations such as other providers, diagnostic and laboratory test facilities, managed care organizations, etc. Creating and maintaining patient records requires the ability to extract and integrate patient data from a range of "legacy" document and system formats. legacy applications constitute an even more difficult integration category. Consider a host application that was developed in-house 20 years ago, and written in COBOL. No J2CA resource adapters are available, nor will they be available, to help integrate these applications in a J2EE environment.

    From an integration standpoint, JDBC is actually more promising than J2CA. This API provides access to virtually any data source, from relational databases to spreadsheets and flat files. With a JDBC driver, all corporate data can be connected, even in a heterogeneous environment. In addition to its support for actual relational databases, JDBC can also support emulated relational models based on legacy information sources. But to do this, JDBC requires an integration product that can map the legacy-application functions to emulate a relational database model.

    The .NET platform, with its dependence on Microsoft BizTalk Server, has the same drawbacks for legacy-application integration as it does for packaged-application integration. So, despite the very real integration potential of .NET and J2EE, both platforms have their associated limitations. And when it comes to legacy-application integration, neither platform can complete the job on its own.

    Be aware that all vendors of application integration products do not provide equal support for .NET and J2EE. Many vendors have built their solutions exclusively around one platform or the other, heedless of the fact that both .NET and J2EE will still be the strongest presence in the years to come. Buying an integration product too hastily can tie your organization to a development platform they might not have chosen otherwise.

    Therefore, you should look to application-integration vendors that are closely aligned with--and can articulate a long-term strategic relationship with--both .NET and J2EE technologies. That means checking to ensure that a solution offers interfaces such as .NET Class Libraries, COM Objects, ASP, ASP.NET, and .NET web services to support your .NET-based development efforts as well as interfaces like JavaBeans, JSP, and Java web services to support your J2EE-based development efforts.

  • Coming from the healthcare industry... (Score:5, Informative)

    by databyte ( 321386 ) * on Thursday December 23, 2004 @09:37PM (#11173423)
    I work for a company that just landed a large install to a large hospital system. Here are some points to consider.

    My experience...

    1) Don't worry about the run-time in terms of a desktop requirement. Since you'll have to install your software, you'll have the opportunity to install the VM.

    2) Getting security clearance to run on a hospital system will largely be dependent on your application architecture and not on your application framework. Do you depend on certain ports or services, certain databases, file shares, web services, etc.

    3) A majority (overwhelming majority) of these systems do run Windows. If you find Linux in the mix, it'll usually be for very specific systems (PAX/DICOM) or back-end work (your mainframes and such). Due to the large number of small vendors in healthcare, a ton of applications are installed to the clinican's desktop. (And may have simple architectures or older frameworks like VB, Delphi, and even Terminal/Telnet). Everything from intergrated hospital wide systems to what a doctor uses on his own box to manage X, Y, and Z. [hint: look-up CCOW]

    4) Integration with an EMR is important, and again, most are Windows based. If you want to feed data into "the system", be prepared to work with the system. EMRs are heavy on HL7, light on Web Services and XML.

    5) Depending on your architecture, your GUI/interface and your "server" can be running on different systems, platforms, and/or frameworks. Probably not the best route but it is possible.

    General knowledge and opinion...

    1) Mono (.NET) for non-Windows applications is just as viable as Java for multi-platform use. You could do .NET AND Mono deployments (or just pick one).

    2) Hospitals pay huge $$$ for integrated systems. As such, they will purchase hardware dedicated to your implementation. If your worried about running on their existing OSX servers, don't be - sell them a Dell running Windows 2003 or a black box running RH. Your software will be more expensive than the boxes. You could also just include $2-10K in hardware costs as part of the PO.

    I highly recommend going to a trade-show or just talking to vendors "as a 100-300 bed hospital". You can see what others do by being a customer.

    Not saying you have to do what everyone else does - but it does help to sell something that won't take a lot to get going.

    • Re:Coming from the healthcare industry... (Score:4, Insightful)

      by tongue ( 30814 ) on Friday December 24, 2004 @12:41AM (#11174465) Homepage
      I find myself wondering exactly how much experience this chap really has in this market, as opposed to listening to a bunch of people with real experience talking, since "PAX" is actually spelled "PACS" (stands for Picture Archive and Communication System) and HL7 is an XML-based protocol.

      That being said, if your target market is small physicians offices, don't worry about the runtime; the overhead of installing it to the workstations is indeed negligible. BUT, if you plan on targeting hospitals at all, the lack of a runtime can indeed be a great selling point. While writing a web-based PACS/RIS/scheduling (RIS=Radiology Information System) my company found that in the vast majority of installs, the clincher to the sale was the lack of a required executable install (except for the radiologists who were doing diagnostic reads) and/or the end-to-end integration of our system, which meant they didn't have to cobble together four or five different vendors' software using obscure export/import procedures that usually ended up as a post-it note on the monitor of the technician doing the job.

      on the choices of software: if you go with .Net, despite the great strides mono has made, you're going to be a microsoft bitch^H^H^H^H^Hshop for the foreseeable future. if you go java, get ready to deal with the fact that there are a lot of areas of it that are overengineered for your purposes. There are downsides to both, but there are just as many upsides to each as well. If it were me starting from scratch, i'd go with java, if only because i like eclipse as an IDE better. (and for the record, i agree with anyone who says that's a bad reason to choose a toolkit--but i'd make the same decision six days a week and twice on sunday :) )

      honestly, if you're intent on going into this area, go for the little shops first. hospitals are attractive targets for the big boys like GE Medical Systems, and they will eat your friggin lunch, right after they kick you in the balls just for fun. There's a huge market for smaller offices who can't afford an entry-level price of half a million for a HIS system but still need practice management. This is what the ASP business model was born to cover. Tell a doc you'll install for less than 5k, charge him 5 bucks a patient/study/unit of work/whatever but in doing so allow him to better track his expenses, increase his payments from medicare/insurance, see more patients in less time, employ fewer people, or whatever promise your software makes, and he'll be foaming at the mouth to buy whatever it is you're selling.

  • Take a look at TAPAS. (Score:3, Interesting)

    by Yaztromo ( 655250 ) on Thursday December 23, 2004 @09:43PM (#11173453) Homepage Journal

    Take a look at the Technology Assisted Practice Application Suite [sourceforge.net], which is based on Zope/Plone (written in Python), the jSyncManager [jsyncmanager.org] (a pure Java (J2SE) synchronization protocol stack and toolkit for PalmOS-based handhelds), and some custom applications.

    This project is geared towards two areas: online access for medical offices, hospitals, retirements homes, etc., and handheld access using Palm Tungsten C handhelds. It uses open tools and open standards, and is released completely as Open Source. Phase One, currently under development, is implementing handheld management systems, security (both validation and encryption) calendaring, and messaging. Phase Two, starting Spring 2005, will be implementing patient data.

    Being open and using languages like Python and Java, the suite runs virtually anywhere. The prototype systems are running Debian, however I often do development and testing against a similar setup on Mac OS X (as I develop all of the handheld synchronization and management routines).

    Before you go out there and start writing soething similar from scratch, you might want to see if there are Open Source tools you can build upon and extend for your purposes first.

    TAPAS is, BTW, being developed in conjunction with a major university, a major hospital, a group of doctors, and a provincial Ministry of Health here in Canada. You might want to take a look at what we're doing before jumping in and starting from scratch yourselves.

    If you'd like more information, please feel free to drop me a line. In particular, if your company hasn't even considered the handheld side of your system, let me know as I have a lot of expertise in this area.

    Brad BARCLAY
    Lead Developer & Project Administrator,
    The jSyncManager Project.

  • Speaking from expierience, I worked several years as an IT Manager in the healthcare industry in Connecticut, the most important thing I was forced to consider was ease of use and speed. While security is always a concern, it sometimes had to take a backburner to speed and just plain old usability.

    I cannot speak for other healthcare industries in other areas, but we were a 100% Microsoft shop with the exception of our Web Server. Almost every application that I looked at in my time as IT Manager was a wi

  • .NET definitely works! (Score:3, Informative)

    by dantheman82 ( 765429 ) on Thursday December 23, 2004 @10:45PM (#11173779) Homepage
    Upfront statement:
    I'm a Student Ambassador to Microsoft, I've been promoting .NET on campus, and am currently not paid for this position. So, in a nutshell, I basically promote the technology because I really like it. However, I think Java's pretty cool too.
    My thoughts are that yes, it will definitely work in .NET - I've seen even some grad students putting together a pretty awesome application in C# .NET for a programming competition that was aimed at the health care industry and had great acceptance with the hospital. The development time is quicker (especially in VS.NET), there are definitely security/cryptographic libraries implemented, and there is a huge open-source community built around .NET programming.

    Also, the .NET framework has been ported in a large part to *nix with the Mono project [mono-project.com] and has been used quite successfully in Munich which has recently ported to Linux by a company called Volcker [novell.com].

    I've developed GUI applications in both Java and .NET and .NET was much faster and much cleaner as well. Plus, you can inherit from old C++ classes and leverage existing code/libraries in your new application.

  • Hospital Technologies (Score:5, Informative)

    by Anonymous Coward on Thursday December 23, 2004 @10:49PM (#11173796)
    FYI, here is a list of common technologies you will see floating around a typical community hospital:

    operating systems
    digital HP Unix
    AIX
    VAX/VMS
    Solaris
    Windows 3.1, 95, 98
    Windows NT, 2000, XP

    programming languages
    Mumps (ala the 'M' database)
    CCL (fourth generation SQL-esque language)
    SQL (a very little bit)

    databases
    oracle, oracle, oracle
    some SQL

    First of all, you have got to understand your (potential) client. Therefore, you need to understand FDA regulation of healthcare equipment, and of the HIPPA regulations. Because of FDA regulations regarding healthcare equipment, it often takes years (between 3 and 5, on average) for a piece of medical equipment to be designed, tested, run through trials, and (hopefully) approved. On the other hand, hospitals have a very steady stream of revenue, charge lots of money, generally have massive amounts of cash flow, and have major assets (like CT and MRI scanners, for instance). Therefore, it's common for a hospital to invest $1M for a new CT or MRI scanner at least every 10 years. However, that scanner had better be a workhorse for the hospital.

    So, what this means for you as a developer is that most hospitals still have legacy systems in production that date back 10 to 20 years. As a systems administrator for the department of radiology at a local community hospital, my production environment involves:

    > a Maxifile VMS/VMX terminal server running an 'M' database programmed in 'MUMPS'
    > 6 oracle database servers which 100+ non-admin end-users log onto each day
    > a remote-hosted oracle database which sits in Kansas (ala Cerner Corporation), which everybody at the hospital must access via a Citrix box.
    > a nuclear magnetic resonance imaging scanner running VAX/VMS
    etc. etc.

    So, to make a long story short, if you want to develop products for the healthcare industry, you had better start thinking about how to interface with products from Oracle, Citrix, Cisco, Microsoft, and so forth.

    Also, Linux is generally avoided in hospital settings. It requires too much computer knowledge (remember that hospital workers are healthcare providers, not information technology developers). More importantly, it's usually impossible to hold the developers accountable with Linux, and it's generally very difficult to obtain support contracts. All things considered, I have 1 linux machine in production, 200+ windows machines, and about 30 unix variations (AIX, VAX, HP Unix, DEC, Solaris).

    So, all this being said, I think that you're barking up the wrong tree and not necessarily asking the right questions. Personally, I would suggest J2EE over .NET.

    If you really want to start asking the right kind of questions, you could start with questions like 'should we start by developing an HL7 sniffer or a HIPPA auditing & compliancy application'? You would then find, either way, you will need to know Cisco (TCP/IP stacks), Oracle (SQL database connectivity), and HIPPA legal concerns (e.g. need for cryptography). In the end, you'll realize that you can do it in either J2EE or .NET, and that the question is kind of a moot point.

    anyhow, just my $0.02

  • Don't reinvent! (Score:2, Informative)

    by _Bucktooth_ ( 255094 )

    Instead of re-inventing the wheel, get involved in open-sourced solutions. You can find a good list here [sourceforge.net].

    From this list, I have personally only seen VistA [va.gov] which has been used by the Veteran's Affairs Department for a very long time. Certainly long enough to mature. It's scalable and will work with groups of hospitals. It's designed by Doctor's to fit the way they work and it's easy to use (so Doctor's have told me). It's open source, and there's a community [hardhats.org] web site.

    There are cons though: It uses a litt

  • Our small southern shop (an eleven man team) is about to commence development on some medical software geared for physician's offices and hospitals.

    I assume that you're delivering a product, and that you have some previous expertise and previous experience building a somewhat similar product in a different field.

    If so, my first answer would be to "do what you're an expert at". Why screw around with technologies that you all aren't expert in?

    Is this an "old fashion" attitude?

    You bet! You're there to d
  • No matter what you use, they will all die a horrible terrible slow and painful death.

    Why do they come to me to die? Why do they come?

  • on blogs.msdn.com. That way you'll get answers on both sides of the religious wars.

    (Go ahead, mod me troll. I'm already married so I don't have to impress anyone anymore.)
  • Design for easy HIPAA compliance. Will the system gather, use, or store Protected Health Information? If so, make it operate such that as little of the PHI as possible is even cached on the desktop machine, and that the desktop machine stores none of it.

    Platform-independece is nice. I am stuck with a vendor who provides windows-centric products. My docs have Apple laptops, and want to use the apps. :-/ You could make platform-independence a major sales feature.

    Most small to midsize clinics do not have IT
    • Even in large hospitals this can be an issue. Researchers pay their own way (grant money), and often quite a bit more. You can count on a Macintosh populations more or less directly proportional to the size of your research community. Also a few GNU/Linux workstations and the odd OpenVMS or Beowulf cluster (no kidding, I once found an unsanctioned Beowulf cluster in a lab).

  • Why fuel the Microsoft monopoly? (Score:4, Insightful)

    by raw-sewage ( 679226 ) on Thursday December 23, 2004 @11:38PM (#11174128)
    Technical arguments aside, there's something to be said for not buying Microsoft simply out of principle. Why would you want to deploy a tool that is forever tied to one platform (Windows/.NET) and subject to the wily licensing antics of Microsoft?

    No offense to the Mono folks, but I just don't see them ever having 100% cross-platform capability. It will never be possible to seamlessly change your development and deployment environments from Microsoft.NET to GNU Linux/Mono. And if it ever does become that easy, Microsoft will be ready with some kind of nastiness (patent lawsuits, forced upgrades, etc).

    The group I work in writes custom engineering (design and anlaysis) applications for our company (Fortune 100). Some of these applications have been ported several times over the years as the flavor-of-the-week OSes/platforms changed. And today we're still porting applications to Windows using MFC! What happens when Microsoft obsoletes MFC, or Linux becomes the standard for engineering desktops, or even Apple starts supplying top-of-the-line technical workstations? We'll port again! But now is the time to take advantage of open source, cross-platform development environments.

    Spend your time working on a solution for your customer, rather than worrying about future portability issues. I just feel that if you go Microsoft now, you'll regret it in the future; I just don't see how anyone can make a reasonable justification for going with Microsoft and claim to have a solid long-term vision.

    Even Microsoft's lame slogan, "Where do you want to go today?" supports their obvious short-term approach. Today just isn't as important as tomorrow: I know where I need to be tomorrow; once I figure out how to get there, what I do today will naturally be right.

  • Let me save you some time and embarassment (Score:5, Interesting)

    by Naikrovek ( 667 ) <jjohnson@ps g . com> on Thursday December 23, 2004 @11:42PM (#11174149)
    I work for a very, very large insurance company with tens of thousands of employees, and several dozen million policy holders. At least 25% of the nation has auto insurance with us.

    We used .NET in the enterprise for a while, until Humpty Dumpty (.NET) fell off the wall and all of Microsoft's Men and Women couldn't put it together again. For two and a half weeks customers were without quotes, or access to their policies online, and agents couldn't sell new policies or make changes to current policies. Customers were furious, agents were foaming at the mouth in anger.

    Two and a half weeks. With all of "the Shining Stars" of Microsoft's .NET team flown in they couldn't get it working again for two and a half weeks. Eventually they had to rebuild the entire server room with new Windows installations on every server because they couldn't find out the problem. That might seem bad, but let me make note that the whole system was provisioned, installed, and maintained by Microsoft personnel. They broke it and they couldn't fix it for, say it with me, two and a half weeks. That should make it seem worse, but it still sounds better than it actually was.

    A decision was promptly made to drop .NET. We don't even get Visual Studio.NET installed on our development machines anymore. We have a very strong bad taste in our mouth from the whole .NET craze, which Microsoft is going very far out of their way to remove, without result.

    We use J2EE and are very happy with where its going. Sun has spent a great deal of effort working with us to transition, and their support has been great. Our J2EE stuff Just Works. It works wonderfully. We are very, very happy with it. I'm using short sentences here to get the point across that we are very happy with J2EE. We've been using it for our web services and as our main development platform. We train on IBM's WebSphere Studio Application Developer, and it also is a great (but expensive!) tool.

    I, as a developer, recommend J2EE. I do not represent my company in this recommendation, in case you work out who it is I work for. I am speaking totally on behalf of myself.

    • Re:Let me save you some time and embarassment (Score:5, Insightful)

      by Anonymous Coward on Friday December 24, 2004 @01:02AM (#11174568)
      I agree totally. I used .NET at my previous Hedge Fund, and I use J2EE at the current one. It is night an day. Do you ever want to see a full stack trace (not just the couple of methods that the exception crossed before it was caught?), do you want to avoid .dll hell, do you want software that is efficient and has a collections API that wasn't designed by a 12 year old? If you answered "YES" to any of those questions, avoid .NET like plague.

      Since it's for a hospital, I assume that...

      1) It's server like, pushing around data and integrating with other systems.
      2) It really shouldn't crash.
      3) You'll probably have lots of home computers, terminals, etc.. as users. It might be hard to track them all down to get stuff upgraded, especially considering that doctors may not always have the time for you to screw with their computers.

      Seriously though, you just can't go wrong with J2EE. It'll run on anything, you can get pretty much any sort of appserver you want. You can get free appservers (JBoss), expensive ones (Websphere), or just embed your stuff in the database (Oracle) if that's what you think is appropriate. Java Web Start is a godsend for managing applications, and EJB will easily handle all your communications needs.

      I just can't stress this enough, .NET and C# is the best way to go if you want to use the Microsoft solution, but it has SEVERE CRIPPLING deficiencies. No coplete stack traces, nothing even approaching the scale or efficiency of something like JBoss, operator overloading that everyone loves to use (Ever see == throw a NullReferenceException?), the glories of COM (learn love Single Threaded Apartments), and half the examples are written in VB. I could just go on for days.

      This is, in fact the reason I quit my previous job. After trying to pound nails with a screwdriver for about a year (and getting roughly the progress you would expect from such an attempt), I threw in the towel and moved somewhere more sane. My life is much better now.

  • http://www.linuxmednews.com/

    Medical software is one area where we should all agree that closed source code has no place. After all it is not like a life support system, it IS a life support system. Closed source code for medical applications is like selling drinking water in a life boat. It's wrong.

    And while we are on the subject, can anyone explain why we let the government mandate via hippa the use of diagnostic codes that are not in the public domain. Thats right the AMA owns the diagnostic codes t

  • Java (Score:5, Interesting)

    by the eric conspiracy ( 20178 ) on Thursday December 23, 2004 @11:55PM (#11174223)
    The company I work for is in the process of porting all of it's VB (.Net predecessor) software over to Java. The reasons are pretty interesting.

    - Microsoft essentially obsoleted our entire company's code base when they introduced .Net, forcing a rewrite that will cost millions. Microsoft is infamous for churning its technology base, so they could easily do it again. Fool us once, we aren't going there again.

    - Java has been around for 10 years, with many fewer technology upheavals.

    - Java is multiplatform, much more so than .Net (Mono is not even close to be considered - one patent infringement lawsuit from MS and it is gome). Java gives us access to just about any platform we are likely to need to deploy to.

    - Scalability. .Net is famous for crappy performance on more than 2 cpus. Java runs great on big iron.

    - App servers - With MS there is one choice. With Java there are many vendors, with a vast range of product capabilities.

    - Development tools - Just as good, wider variety and often far less expensive per seat.

    - Maturity - best practices are fully understood, while .Net's use cases are not.

  • If you are a smallish shop used to some of the older technologies, I suspect you'll be annoyed by the overhead in both C# and Java. I would take a serious look at Python. Python can be run under the JVM, .NET CLR or native-it is also a nice, accessible language for a team of your size.
  • From what I've observed so far in the field, I don't think almost any hospital/medical office environments are running Mac OS X Server right now. (You tend to see it more at the research/lab level.)

    There are already a few packages for Mac OS X out there to run small dental, doctors' or chiropractic offices with - but you'll tend to see these running on several networked iMacs, in more of a "peer to peer" environment.

    If you *do* have concerns about your new product being compatible on OS X Server, I think
  • I use .NET when I want to develop the application faster. It is a lot easier to make web services on .NET than on Java. The bad part is that you are limiting yourserlf to MS servers. Of course, the database servers and everything else can be run on whatever else you like. The client can be in .NET, JAVA, a browser, it doesn't really matter.

    When I develop for portability I use JAVA. I can run it on any server that I like. Then again, how many times are you going to switch servers?

    Because of what I ment

  • Kaiser Permanente is a Java Shop... (Score:5, Informative)

    by cutecub ( 136606 ) on Friday December 24, 2004 @12:50AM (#11174503)
    Kaiser Permanente, for those who don't know, is really the first HMO. They serve all of California, Hawaii, Colorado, Georgia and a smattering of other regions around the country.

    I've been with the company for about 3 years, doing both Software development and system support. During that time, most of my development has been in Java. I have yet to see any .NET development.

    There may, in fact, be .NET development at Kaiser, but I haven't been able to find many references on the corporate intranet.

    I would summarize Kaiser's software development as follows:

    • Patient Records are stored in IBM DB2 running on IBM OS390 mainframes./li>
    • Minor or less-critical datastores often use Oracle.
    • Some legacy systems use Cache (Mumps) running on AIX
    • Major applications run on either a Mainframe or IBM AIX boxes, or a combination of the two.
    • Java is the language used for developing their Integration Broker, the crosspoint which links many of their newer medical systems.
    • Fat client-side applications are written in C++, or to a lesser extent, Java
    • Web applications are written in Java and hosted on IBM WebSphere
    • Perl plays a supporting role in UNIX environments, as it always seems to.
    • I have yet to see Microsoft used for any critical back-end component which could significanly impact patient care. Client software, yes. Back-end software, no.

    In the last few years, Kaiser has had an apiphany regarding in-house software development and now leans towards vended systems. But there is still a significant amount of in-house software development done to integrate these vended systems.

    Hope that's useful.

    -S

  • I would say J2ee due to portability, but I think for your purposes, J2ee is going to be too structured. Stay with me here for a sec.

    You don't know much about the vertical and your dev team's split. You're going to have a lot of design changes. In my experience, J2ee has a lot of problems handling design and code structure changes, while .Net in various flavors has an easier time because it allows for a looser design.

    But yeah, keep your resume dusted unless the company you're working for has deeeep pockets

  • web services are what's important (Score:3, Interesting)

    by amichalo ( 132545 ) on Friday December 24, 2004 @01:05AM (#11174581)
    I have just finished a project for small group physician practices all built OSS and 2005 I will be working on another project for the same market with .NET.

    As much as IO enjoy OSS and dislike the evil that is blah blah blah, I have to say .NET is a very good environment to get large, complex applications built in with limited resources. I had never programmed in it myself until two months ago and I must say it is not difficult at all to pick up as long as you understand OO programming (which any programmer does).

    So my take as far as the market itself is that the best thing to do is develop web services that can be consumed by the customer. That way, the platform you develop in does not matter. If you have to pick, then know that Microsoft is making huge strides in healthcare with transcriptions, digital medical records, iPaqs and Tablet PCs. I don't see a lot of OSS in the market.

    Best of luck.
  • I have heard MANY good things about Apple's WebObjects software, it's cross platform (OS X, Solaris and NT/2000/2003, maybe more...) and it's supposed to be a dream to develop for.

    If you assume that the client will not care about the back end, give it a look.

    The big problem you may have is any customer with an MS Enterprise Agreement. The unspoken rule with those things is that YOU WILL NOT run ANY technology that Microsoft does not make.

    I worked at a client that had an MS Enterprise agreement, and the
  • Bah. Use MUMPS [hardhats.org], like the US Veterans Administration. It has all the power of BASIC with the transparency of INTERCAL. Who could ask for more?
  • The nice thing about open-source software is that you don't have to spend precious time and money re-inventing the wheel---you could at least improve upon an already existing design. That said, at least check out GnuMed [gnumed.org]. It doesn't have the backend that you're looking for, but at least will give you ideas. It's a system developed by physicians. Won't you consider contributing to a open-source project? It'll make the world better---at least with a unified open-source system, patients will be better-off due t
  • You know what? It really doesn't matter which you choose.

    What does matter is the Sarbannes-Oxley and HPIAA acts, and think like as if your data was in there.

    Patient privacy is all important, and that's 100% about process and 0% about technology.

    Spend the time to create the system properly.

    Think about the entire lifecycle
    - architecture
    - design
    - testing
    - coding
    - SQA
    - Security / UAT / SIT
    - Deployment

    These things are important. Do not fall into the waterfall lifecycle methodology - it's simply too hard to
  • I don't think I've seen as many Anonymous Cowards pluging^h^h^h^h^h^h^h^h.. er.. suggesting thier products. :-)

  • I cannot give you an answer for your particular situation, but I can tell you my opinion, based on my real-world experience.

    I am the chief architect for a major application developed by the U.S. State Department [ndf.org], and used by foreign governments for the licensing of hazardous materials [trackernet.org].

    We use J2EE, and have been since 1999. JBoss [jboss.org] is our application server. We used to use Weblogic, and were technically happy with it, but JBoss does everything we need, and has licenses and costs more favorable for our e

  • The McKesson Horizon suit of products (clinical) all have a J2EE future. Right now availability is a top concern for those of us deploying clinical systems and evaluating vendors. A portable solution is important here because it allows the IS shop to determine which scalability/availability solution best fits their budget.

  • My experience... (Score:2, Informative)

    by PinchDuck ( 199974 )
    If you are creating fat clients, .NET is the way to go, most likely. If you want web based, J2EE has a lot of open-source compenents you can use to get your application networked via HL7
    HAPI is a java-based open source HL7 library:
    http://hl7api.sourceforge.net/ [sourceforge.net]
    JEngine can quickly route HL7 messages to & from your application:
    http://jengine.org/ [jengine.org]
    If your software is open source, or you can use open source components, OpenEMR can give you a leg up for clinical demographic and medical data management. It
  • development is having someone who knows HL7 inside and out. Do NOT think you can learn it as you develop, you can NOT. It fills 2 binders, each over 1000 pages. I had X12 experience in the mortgage and finiancial industries. When I went into medical I figured it would be someting I could opick upo as I went. Lets just say I'm glad they didn't make HL7 my top priority right away.

    As for your development platform it comes down to this: .new excludes more platforms the J2EE, however, most hospitals are tied in
  • Java isn't slow. Honest. And .NET is just as cross-platform capable as Java is. In fact, it even allows you to cross language barriers so code can be written in whatever language is best suited to the task. Technically, Java can do this too, but it isn't as well done or publicized...

  • I'm in this Industry (Score:3, Interesting)

    by jerdenn ( 86993 ) <jerdenn@dennany.org> on Friday December 24, 2004 @02:47AM (#11174985)
    Hmmm..

    This is an interesting question. I'm actually in this industry, and have been for the last half-decade. For an industry that seems to lag remarkably behind the times, I'd like to note the following:

    1. The major player in this field, McKesson (previously HBOC) seems enamored with Java. This, however, is only because the Healthcare IT field seems to be 5-15 years behind the current technology.

    2. Major players in this field (Particularly Eclipsys) have bet the farm on .NET, and by-and-large, this seems to have been a successful gamble, though not a smooth road. The Eclipsys flagship product, Sunrise XA, is written almost entirely in .NET. This product is a major player in the healthcare arena.

    3. Many hospitals have strict rules on what IT software is allowed. I will tell you that the following is ALWAYS allowed: Windows NT, Windows 2000, Windows 2003, SQL Server, Oracle.
    The following is SOMETIMES allowed: Sybase, Any "other" RDBMS, Windows XP, Linux, *nix, etc.

    With the combination of Windows and SQL Server, you can't go wrong. Don't believe me? Do your market research. Want more info? jerry@dennany.org.

  • Here's a health care industry perspective (Score:3, Informative)

    by Man_Holmes ( 519973 ) on Friday December 24, 2004 @03:27AM (#11175123)
    I am currently working on a project for a software company that sells to the health insurance industry.

    In developing this project I've had contact with a lot of the largest health insurance companies in our region.

    What I have found most of them have in common is a mixture of J2EE and ColdFusion, almost exclusively. It appears that dotNet hasn't made the inroads with the health care industry that they have with other corporate clients.

    Holmes

  • Beware of EJB's. Make it lightweight Java (Score:4, Insightful)

    by johnjaydk ( 584895 ) on Friday December 24, 2004 @07:39AM (#11175711)
    Personaly I prefer Java. BUT you need to be aware of a couple of dangers.

    First of all don't use EJB's unless you have to. If you don't need distributed transactions then stay away. You don't want heavy weight frameworks to drag you down. Read: Better, Faster, Lighter Java. http://www.oreilly.com/catalog/bfljava/ [oreilly.com] For a free introduction read: http://www.onjava.com/lpt/a/4744 [onjava.com]

    My personal advice is a stack made of:

    1. JSF for the webfront. Struts if you are a bit more conservative. http://struts.apache.org/ [apache.org]
    2. Spring for the business logic. http://www.springframework.org/ [springframework.org]
    3. Hibernate for persistence. http://www.hibernate.org/ [hibernate.org]
    If your need a thick client then use Swing instead of JSF. Then you can stick RMI in between two of the layers.

    Don't forget to have fun.

  • Java vs .NET (Score:4, Insightful)

    by Kell_pt ( 789485 ) on Friday December 24, 2004 @02:10PM (#11177288) Homepage
    I started reading the whole thread of replies, and I couldn't find a better comment than the one made by the first poster: "Java isn't slow, .NET is not insecure".

    A programmer worth its weight knows that each language has its niche, and for specific tasks there are enviroments that work best. Then there are those who believe the hype and form a concept of things without actually ever having a 1st hand impression. It's a bit like racism, applied to programming languages, and it has a common origin: ignorance. I hope this doesn't sound ecletic, but it probably could inspire flames, since people usually have a hard time admitting their ignorance. But the next time you feel like writing something about Java, .NET, C or C++, try to think wether you have solid facts and a really large experience to support it, or just your idea of how things are, read elsewhere from someone you don't really know.

    Also, the belief that a programmer can only be good in one language is ridiculous. Give a good programmer a month and he'll excel in whatever you throw at him in a given language. And what he doesn't know, he'll learn. Give him a project and a couple months and he'll know things inside out. Maybe he'll have a preferred language, but who's to say that won't change over time? Evolving oneself as a programmer sometimes involves changing paradigms.

    That said, I consider myself mainly a C programmer, then converted to C++. Nowadays I use C/C++ very little, for very specific things or for my private projects (involving OpenGL & C++). I've worked extensively with Java, Perl, PHP, Prolog and bit in a dozen others. I'm in the process of learning everything possible about Mono/C#, and I'm enjoying it.

    I don't really enjoy Java mainly because I find developing in it to be a real pain. When you have learned over 20 different languages, you value freedom of expression, and Java doesn't give you that - it locks you into a syntax that is archaic and not very flexible. I don't like the Sun Java team making choices for me, like not allowing operator overloading and not having propper syntactic support for modern OO concepts like properties. Maybe one day they'll understand the language syntax itself isn't important - just convenient - and will follow the road of Parrot or MSIDL (argh).

    I like .NET for the way it's architectured, but the freedom it gives you in development it takes away in vendor lockin. I initially saw Mono with lots of suspicion, mostly regarding its legal status and possible future implications. Then I spent some time reading about it and ended up dismissing those fears.

    I have recently gone through a process I consider similar to yours, and I don't envy you. It's a though choice. I recently spent almost two weeks studying the whole issue, experimenting with RAD systems for Java, Delphi, C++ and C#. In the end, I ended up adopting a solution based on LAMP2 (Linux, Apache2, PostgreSQL, Mono) - which should not be confused with LAMP (Linux, Apache, Mysql, PHP). Here's the reasons and thoughts:
    - We find C# to be quite more expressive as a language. Mono is in a state good enough for us to use it, which satisfies our needs for platform independance.
    - Java is not modern enough syntactically. It wasn't designed for some of the things it's used for nowadays, namedly GUIs, and that shows. Nowadays, having to write 'a.setLabel( a.getLabel() + "..." )' instead of 'a.label += "..."' looks stupid, and just shows what happens when people make decisions on your behalf based on their beliefs: on this I agree with Anders Hejlsberg [microsoft.com].
    - We prefer open source solutions whenever possible. We have many people with skills on PostgreSQL and its internals (we've had to extend it before).
    - Apache is rock solid.
    - Global input from the rest of the team.

    There were, of course, lots of small decisions related t

Slashdot Top Deals

He has not acquired a fortune; the fortune has acquired him. -- Bion

Close