Forgot your password?
typodupeerror

Moving a Development Team from C++ to Java? 204

Posted by Cliff
from the language-defection dept.
Nicros asks: "I work for a company that is working toward an FDA approved software development process. We have always used C++ in a Windows environment, and we have more than 6 years of code, applications and libraries developed. Because of our long and convoluted software development history, our existing architecture is difficult to manage for a group of our relatively small size (5 FTEs), and development times are rather slow. Our IT director has made the decision that, to speed up development times, we need to re-architect all of our existing code, from C++ to Java." What would be the best way to go about handling such a migration? In a general sense, how would you go about moving a development team from one language to another?
"Our IT director has hired a 3rd party (offshore) company assist us with this migration, and they have recommended that we change from C++ to Java, Spring and Hibernate. We are all professional programmers here, so learning Java is not a problem for those of us who don't know it. The real question is: what do we gain from moving to Java? Or conversely: what do we lose by moving away from C++? Additionally, will one language or another really help us to get FDA approval?

I personally am a bit suspicious of this solution. I find it more likely that the problems we have would persist across languages or architectures (lack of time and resources leading to buggy code, lack of direction from marketing, and so on). However, having not gone through this process before, I would be interested to hear any thoughts, stories of similar experiences, or pros and cons."
This discussion has been archived. No new comments can be posted.

Moving a Development Team from C++ to Java?

Comments Filter:
  • Send the IT director on a one way trip to Basra
    • The IT Director is probably expecting an all-expense paid vacation to Hawaii if six-years of C++ code is successfully converted. Any long-term implications related to this project probably isn't being considered beyond the vacation package, and will probably be someone else's job after the IT Director is promoted to Vice President. Happens all the time.
  • Logic check (Score:5, Insightful)

    by greywar (640908) on Wednesday May 17, 2006 @09:59PM (#15355589) Journal
    OK so you all have years of experience in c++, 6 years of code, etc. Consultants who are familiar with jave recomend changing to java. And changing development languages and re-doing all of this will save you time? I just don't buy that, to me it sounds more like it will make those offshore consultants more money. You're going to spend the next couple years re-writing all of your old work, not getting things done.
    • Re:Logic check (Score:5, Interesting)

      by dhasenan (758719) on Wednesday May 17, 2006 @10:06PM (#15355625)
      Agreed. You might see benefits if you start using a language that interfaces well with C++, though--perhaps Python? That would allow you to keep your existing work and continue using C++ while exploring more platform-independent and possibly quicker systems for development.

      Switching suddenly to Java, though, is a bad idea if you don't already have the expertise.
      • Re:Logic check (Score:5, Informative)

        by commanderfoxtrot (115784) on Thursday May 18, 2006 @05:28AM (#15356032) Homepage
        This is probably a good place to mention SWIG [swig.org]: open source, mature - SWIG is an interface compiler that connects programs written in C and C++ with scripting languages such as Perl, Python, Ruby, and Tcl. It works by taking the declarations found in C/C++ header files and using them to generate the wrapper code that scripting languages need to access the underlying C/C++ code. In addition, SWIG provides a variety of customization features that let you tailor the wrapping process to suit your application.

        From the FAQ:
        Designed to work with existing C/C++ code. SWIG requires little, if any, modifications to existing code. For the most part, it encourages you to keep a clean separation between C/C++ and its scripting interface.

        I haven't used it myself, but it sounds like it could help. At least you might be able to re-use your C++ code from Java.

        I think it's lunacy to rewrite 6 years of code in a new language just for the sake of it.
      • It's difficult to imagine any language interoperating more freely with C++ than Java, using GCJ and the CNI native interface. You just pass objects back and forth freely between the environments, call native methods directly across the language boundaries, and rock 'til you drop.
    • Re:Logic check (Score:2, Insightful)

      by Threni (635302)
      > Consultants who are familiar with jave recomend changing to java.

      Why not find some consultants who like C++?
      • That's a great idea. If the attractions of Java are unit testing, error handling, and memory management, maybe it would be just as good to hire a C++ coach who can introduce unit testing, Boost smart pointers (or garbage collection, even), and exceptions and be a good-natured coding standards Nazi to make sure your guys use those wherever they're appropriate. Of course, this doesn't do any good if you're already writing excellent C++.
  • Resume (Score:5, Insightful)

    by pete-classic (75983) <hutnick@gmail.com> on Wednesday May 17, 2006 @10:02PM (#15355607) Homepage Journal
    Sounds to me like the best case is that some salesman has convinced your management that Java is a cure-all. The worst case is that your management has decided that this is the first step in off-shoring your job.

    In either case my advice to you is the same: Polish up your resume.

    -Peter
    • Re:Resume (Score:3, Informative)

      by Vegemite (609048)
      You are handing your entire code base to an off shore firm to port to java. You are supporting your C++ product while giving this outside firm your technical expertise on all your coding decisions. When this rewrite is done, what is the point of having your development team around? Get your affairs in order! - Veg
    • Re:Resume (Score:5, Insightful)

      by Ozwald (83516) on Thursday May 18, 2006 @11:47AM (#15357859)
      This is a common tactic by consulting companies. It always follows the same flow, never fail:

      1) consulting company hires a lot of junior/intermediate coders for his company that only learned Java or C#. C++ skills and experience avoided in favor of knowing the latest .NET/Java technologies.
      2) an expensive consultant comes in to analyze an imperfect system
      3) this person makes all kinds of suggestions, says nice things about management, says "use lots of UML"
      4) says his devs are really good C++
      5) brings in his coders to help fix bugs, charges lots of money for diagrams never used
      6) consultant coders fail at fixing bugs, claim that code base is too fubar'ed to maintain
      7) convince management to "port" code to Java/C#.
      8) consultant coders soon have more knowledge of the system than the old devs because knowledge isn't shared properly (no more UML)
      9) management becomes too afraid to let go consultant coders because they know more about the system than the devs (despite costing atleast twice as much)

      I can't count how many times I've seen this because the city I used to live in had atleast 2 massive consulting companies that made this their business model. I imagine it's even worse when it goes off shore to India because all the knowledge is looked away in peoples' minds thousands of miles away. Such a huge mistake for management to lose all they paid for for nothing.

      Oz
    • Re:Resume (Score:3, Informative)

      by Arandir (19206)
      My story is remarkable similar, even down to the FDA approval. Except that we were doing realtime embedded Unix in C/C++, and management wanted us to do realtime embedded Windows XP Pro in C#/.NET. It was decided (by non-engineers) that it would be easier to port over the Unix/C++ code to WinXP/C#, than to start from scratch. This was five years ago. We still don't have a new product out.

      p.s. An hour ago as I was walking to lunch, I overheard one of upper management on his cell phone saying, "they're all ol
  • Don't (Score:5, Insightful)

    by AuMatar (183847) on Wednesday May 17, 2006 @10:02PM (#15355611)
    You have working code in C++. Throwing out all that work will take years and millions of dollars. Even if Java doubled your productivity (it won't- you don't have experienced Java developers so it will greatly reduce your productivity) it would take over a decade to break even if you ever did.

    Never rewrite working code. Refactor, rewrite subsystems if absolutely necessary. Otherwise leave it as is and if you really want to experiment with Java, do it with new tools.
    • Of course, this doesn't apply if each application is relatively small and irreducible--you just use Java for the next product that's commissioned and go from there.

      You'll still lose initial productivity from learning the new language, but it won't cost a complete code library if that library doesn't exist. And if the next product happens to be similar enough to a previous one that you could rework the old one easily, you could still use C++ on it, since the developers are experienced in both.
      • I've been workign with java for abotu 7-8 years, and I'm not knowledgable in c++, but wouldn't JINI work for alot of the libraries? Or, shouldn't much of the code be cross-compilable? GUI code will not be, but wouldn't alot of the algorithms still be useful? As for java, what I've found (from talking to c/c++ developers) is that java handles so much of the nuts and bolts internally. For example, creating a socket is simply

        Socket s=new Socket(IP_ADDRESS, PORT);

        File I/O is simply

        FileInput(Output)St
        • I've been workign with java for abotu 7-8 years, and I'm not knowledgable in c++, [...]

          No, because if you were ...

          As for java, what I've found (from talking to c/c++ developers)

          ... you would know if you had talked to C programmers or C++ programmers. They are not the same. Good C is as dissimilar to good C++ as good Java code is.

        • If you're confusing JINI with JNI, then I have to question both your claim of experience in Java and your familiarity with C++.
    • Re:Don't (Score:4, Insightful)

      by AKAImBatman (238306) * <akaimbatman.gmail@com> on Wednesday May 17, 2006 @10:16PM (#15355675) Homepage Journal
      You have working code in C++.

      Actually, he said that it's *not* "working" per se. He already stated that it's difficult to manage, and (I presume) full of bugs. This is a common issue for companies, especially if the original developers didn't fully understand the dynamics of the concept when they first coded it. (I believe the military saying is, "No plan survives contact with the enemy.")

      In those cases it can make a lot of sense to do a ground up redesign and rewrite. You can still use the original code as a reference, as well as grab useful code snippets. But the key is to shake out all the cruft that has built up in the system. Without this sort of step, your development staff will simply need to grow and grow. Before you know it, you'll have 200+ programmers, and your company will look like SAP's development floor.

      As for moving to Java, that's difficult to say without knowing their specific problem. If they, for example, have their own Web Application Framework, they might save huge amounts of development time and money by moving to a more standard platform. If there's nothing they can pare down, then they're probably wasting their time. It's hard to say without knowing more.
      • Re:Don't (Score:2, Insightful)

        by foobarbaz (21227)
        > But the key is to shake out all the cruft that has built up in the system. Every little bit of cruft is a bugfix that you'll have to make again.
        • by Tim C (15259)
          Every little bit of cruft is a bugfix that you'll have to make again.

          Not true - some will be fixes for fixes that were poorly implemented (perhaps in a rush to hit a deadline, then forgotten about), some of the cruft will be for features that are no longer used (or perhaps even available, if other parts of the app no longer use the code at all), and so on.
      • Re:Don't (Score:2, Insightful)

        by Anonymous Coward

        >You have working code in C++.

        Actually, he said that it's *not* "working" per se.


        It's working a hell of a lot better than the java code that hasn't been written yet.
      • Re:Don't (Score:2, Insightful)

        by Anonymous Coward
        In those cases it can make a lot of sense to do a ground up redesign and rewrite.

        No, it doesn't. While you're doing the rewrite, you have no product to sell, unless you maintain the old version in parallel. After the redesign phase, you'll find that the new version is buggy and incomplete, after all it's a new programm. When it is finally ready for premiere, you'll find that meanwhile the competition has driven you out of the market and that you developed a bad case of second system effect. The new syst
        • I'm not sure he meant it the way you took it. I've more than once gotten really, really pissed off at a few thousand lines of code when I was trying to fix its Nth should-have-been-simple problem and just rebuilt it. It was never the whole ball of wax. If you already know what the code's supposed to be doing, you've got the very familiar and (mostly-)working bad example right in front of you, it's a neatly severable chunk and you're angry enough, it goes fast and the result is rock solid. That kind of t
      • So true. The problem here is not the programming language, it is the architecture. If his team just haphazardly switches to Java they'll just blow 5 more years and wind up in the same boat. What they should do is review the app and the customer's needs, re-evaluate the architecture and sub system, and firm up the requirements and tech documentation. Then start from scratch in the language of choice (although I would recommend sticking with C++ since that is where his team's strengths are). Grab code as need
    • Re:Don't (Score:5, Insightful)

      by Marillion (33728) <ericbardes@gmai[ ]om ['l.c' in gap]> on Wednesday May 17, 2006 @10:52PM (#15355827)
      Initially, I'm inclined to agree. Swapping out a language to fix problems isn't fixing the problem. It's like those companies that move all the boxes the org-chart every so often trying to solve the problems of their company - those boxes at the top. The problem is poor development processes.

      There are two kinds of Software Development Processes: 1) Manager centric and 2) Developer centric.

      All the stuff we do at our company for Sarbanes-Oxley is classic Manager Centric SDP. It's about tracking the track every inch of code, who changed what, who had business authorization to put it in. Developers loose productivity over this, it's tedious, it doesn't improve quality, it doesn't prevent errors, but it does keep the auditors happy which does keep management happy.

      The SDP's that benefits developers are things like Agile Programming. Among the cornerstones of Agile are Test Driven Development and frequent iterations. These are the processes that focus on preventing bugs in the first place.

      I once worked for A Company [slashdot.org] that wanted all of #1 and none of #2. They got what the deserved. You need a measure of both with a dash of flexibility.

      Software development processes have almost nothing to do with the choice of language. That said, it's been my observation that there are lots of really smart people working on Java to improve the development process. Eclipse is amazing with code completion, on-the-fly error tracking and refactoring. JUnit (comes with eclipse) is a benchmark Test Driven Development system. If you must switch languages, invest in the training to make those tools productive!

    • Never rewrite working code.

      What if:

      1. The "working code" is several kB of sparsely documented assembly for a completely different (and old) CPU.

      2. The people who wrote it have long since left the company.

      3. The "working code" was obviously designed, written and debugged over period of several years by several people, while you have six months to come up with a new working solution on your own ?

      Of course, no one would ever end up in a situation like this. Never ever *COUGH*irewrotethewholedamnthing*COUGH*.

    • by bwt (68845)
      Never rewrite working code. Refactor, rewrite subsystems if absolutely necessary.

      Those two sentences are polor opposites. The second one is correct, the first one is bunk. It's completely rediculous to say "never rewrite working code" -- by this logic all apps last forever regardless of operations cost and opportunity cost. In this world, all apps would still be Cobol and Fortran.

      To the original question -- yes you can rewrite your app. There are three ways to do it
      A) code the whole thing from scratch in p
  • Since you mention Spring, I'm guessing that you're writing web applications. If you're not, then you need to tell your manager to jump off a bridge, as he has no idea what he's talking about.

    If you ARE writing web applications, then I would guess that moving to spring and hibernate from a completely from scratch c++ framework will result in much shorter development times. Serverside is where Java really shines in both performance and in ease of development.

    Either way, we need more details.
    • by Anonymous Coward
      Please ignore the parent. Spring (http://www.springframework.org/ [springframework.org]) is not a web application framework.

      There are probably a lot of gains to be made by switching. If your people really are as good as you say then the language itself wont matter much and you are gaining a lot of libraries and knowledge from the massive amount of real development being done in java.
    • by Joseph Vigneau (514) * on Wednesday May 17, 2006 @10:33PM (#15355746)
      Since you mention Spring, I'm guessing that you're writing web applications. If you're not, then you need to tell your manager to jump off a bridge, as he has no idea what he's talking about.

      I disagree- containers like Spring are useful for all sorts of applications, not just web-based ones. Stitching components together via configuration files, combined with aspects and "inversion of control" makes it a lot easier to build maintainable and extensible applications. There's nothing in the core Spring framework that shoehorns you into writing web apps.

      That being said, the OP should probably stick with C++, unless there are much more compelling reasons than "the offshore consultants said to use Java, Spring, and Hibernate".

    • Java is a lot nicer than C++ on the server-side, but it has one huge drawback: it doesn't play nice with existing C++ code. It doesn't really play nice with anything else at all (except for scripting languages which run on the JVM, especially the ones that compile to Java byte-code).

      With a large C++ code base, you're much better off looking at languages like Ruby and Python that have simple and stable C/C++ interfaces. Don't be fooled by the fact that Java has JNI. It's not easy to use, and will usually mak
    • >> "If you're not, then you need to tell your manager to jump off a bridge, as he has no idea what he's talking about."

      Dude... if we all had the capability to tell all our bad managers to jump off a bridge and replace them with good managers, most of us would probably be writing code instead of bitching on slashdot! ;)
  • General Thoughts (Score:5, Insightful)

    by AKAImBatman (238306) * <akaimbatman.gmail@com> on Wednesday May 17, 2006 @10:08PM (#15355633) Homepage Journal
    In general, rearchitecting a system can be a good way to update it for your current needs. The key however is to architect, not simply recode the exact same design. You need to see what your needs are in a system and decide what it is that you could meet if you could just change the basic approach.

    In your specific case, however, I'm a bit concerned about the track your company has taken. My concerns are:

    1. You're going to have a separate company working on your codebase when they have no intimate knowledge of how it *should* work.

    2. No one in your team is an expert in Java. This is problematic because good Java code has a very different profile from good C++ code. (Mainly due to auto-optimizations and garbage collection.) Things that were good ideas in C++ may actually hurt you in Java.

    3. Your lack of knowledge in Java is going to guarantee that Java's features won't be put to full use in the design. Which means that you may end up short of your maintainability goals.

    4. Blindly accepting a framework is a recipe for disaster. Unless you clearly understand the framework you're working with, you will tend to try and fight it instead of working with it. This will result in a lot of unnecessary hacks.

    My best suggestion for your company is to get a Java architect on staff who's also familiar with C++. (It's okay if he's a consultant as long as he's planning to be on-site for the next year or so.) Postpone the project for a few months while he gets up to speed on what your system does and what it needs to do. Once he's up to speed, he can work with the staff to develop an architecture that will meet the needs of your company and your platform. Use the outzourcing company for busy-work ONLY. Make sure that the API specs are well defined before you send ANYTHING to them for coding.

    As for the FDA approval, rewriting isn't a magic wand. You need to ensure that their requirements are taken into account during the architectural design phase. Otherwise you may fail to meet the goals.

    I'm not sure if your boss will agree to getting a highly paid Java architect to join your team OR to postponing the project, but thats the best advice I can give you. I presume if you already knew the answer you'd be championing it instead of asking us.

    Good luck to you! I hope it works out.
  • by GoSmalltalk (42449) on Wednesday May 17, 2006 @10:08PM (#15355634)
    Hi:

    Re-writing your codebase is *usually* a one-way trip to bankruptcy. If forced to change languages, always dicey, you might want to try the following:
    1. Mine the code so you have documented interfaces
    2. Create wrappers where neccessary to facilitate access by *new* code
    3. Write new functionality/apps in the new language
    4. As your apps force change of the wrapped-code, evaluate the cost-effectiveness of a re-write of that piece only

    And, most-importantly, use Test-Driven Development; you must mitigate the huge risk that your management has mandated.

    Good Luck, you have your work cut-out for you.

    Thanks!!
    Joseph Bacanskas [|]
    --- I use Smalltalk. My amp goes to eleven.
  • A bit tangential (Score:5, Insightful)

    by JanneM (7445) on Wednesday May 17, 2006 @10:10PM (#15355641) Homepage
    A tangential comment: You say a large part of your problem is a convoluted, complex architecture that's been growing for some years. That happens - in fact, it's probably inevitable to some extent, whenever you have a codebase that needs to change as requirements and use-cases do.

    And to solve that problem, doing a redesign and rewrite (or a close analogue) is probably a good idea, no matter what language you'd be doing it in. You need to get rid of all cruft, strange corner cases and mismatches between the envisioned architecture and the reality. Look at any large, well established OSS project and you'll see that they've done that too, sometimes more than once. And if you're going to rebuild from the ground up, more or less, you might as well take advantage of the better tools that's become available as well. And from C++, any of the newer development languages - whether Java, C# or even Perl/Python/Ruby - would probably be a step up in development speed and maintainability.

    Of course, OSS projects are also a showcase for how wrong it can go. You do need ample time and resources to do it - a rush job will just make the new system as bad as the old one, but with all-new problems in addition to the old ones. You also need serious constraints. Without them you'll inevitably succumb to feature creep ("wouldn't it be nice if we could..."), which will kill the system just as surely as a crappy reimplementation would.

    For every OSS project out there who did a redesign and rewrite and came out stronger, faster and better for it, there is a project that started a redesign just to get rid of cruft, went off into the design neverland and never appeared again, suicided by the endless opportunities that rewrite gave them.

    I think the use of Java is beside the point. The opportunities and pitfalls lie with the redesign and reimplementation. The tools are just an implementation detail.
    • I agree. The problem is not the language but the process. The offshore company probably has a better designed and documented process (it is a huge selling point for many offshore industries), but your team has the experience. What you need is to implement a constant improvement process, either by transfering all your work to an offshore company (your bosses' solution), or create and refine that process in house.

      I would recommend buying six copies of "Working Effectively with Legacy Code", by Michael Fe [amazon.com]

  • lobotomy (Score:3, Funny)

    by Xtravar (725372) on Wednesday May 17, 2006 @10:13PM (#15355653) Homepage Journal
    Give the team a lobotomy. That'll do it!
  • Your best solution, if you can find people with enough sway would be looking into getting your IT Exec fired. Really.

  • Oh my. (Score:5, Insightful)

    by Jerf (17166) on Wednesday May 17, 2006 @10:15PM (#15355666) Journal
    Or conversely: what do we lose by moving away from C++?

    Six years of C++ development, and all the corresponding skill development.

    Even with the C++ to guide you, and assuming you had all the manpower to do the full conversion to Java that you had to write the C++ in the first place, you'll need at least a third of that time again to re-write the whole thing in Java, most likely. And that's being conservative; if you're good with C++ it's extremely likely to borderline-certain that you have used idioms that will translate poorly or effectively not translate at all into Java.

    That's a shitload of stuff to just throw away to be buzzword compliant.

    My suggestions would be to do one of two things.
    1. Research JNI and see if that would allow you to incrementally pull things over to Java as you need them, while leaving the rest C++. C++ is so wonderfully... ahh... I'll go with "powerful" that it's hard to tell how things will interact, but if you can pull things over incrementally, you can at least not toss everything all at once. Because that's a guaranteed recipe for disaster.
    2. Research your choice of Python or Ruby. My recommendation would be the former as it's more mature in a lot of little ways (and some big ones, like Unicode from what I hear). There are several technologies for using C++ objects in Python. I presume there are some in Ruby. Incrementally wrap pieces of your code in Python handlers as you need them, write Python or C++ as the situation warrents. There are other such languages to consider too; you'll have to evaluate them for your needs.
    The key word here is not Java or JNI or Ruby or Python; those are really incidental to my point. The key word is incremental. Incremental might succeed. Attempting Total Switchover is just writing a check to the consultants for no return this decade.

    And while you're incremental-ing and maybe wrapping, be sure to write unit tests if you haven't already got them. If you do manage to not toss out your entire code base, a good first step for any of this is to write unit tests on the parts of the code you're going to manhandle.
    • Research JNI and see if that would allow you to incrementally pull things over to Java as you need them, while leaving the rest C++. C++ is so wonderfully... ahh... I'll go with "powerful" that it's hard to tell how things will interact, but if you can pull things over incrementally, you can at least not toss everything all at once. Because that's a guaranteed recipe for disaster.

      Exactly what I was going to suggest. Throwing everything out is just complete insanity. If he can't talk them into fixing their

    • Re:Oh my. (Score:4, Interesting)

      by 0xABADC0DA (867955) on Thursday May 18, 2006 @12:23PM (#15358170)
      Six years of C++ development, and all the corresponding skill development. ... That's a shitload of stuff to just throw away to be buzzword compliant. ... The key word is incremental. Incremental might succeed.

      Let me be the lone voice to call bullshit. Story poster is obviously inexperienced and trying to be diplomatic (if for no other reason than pride). What we have here is almost certainly a big steaming pile of crap.

      Their development has slowed to the point where they are going to ditch the whole thing. It's too late to save this code. Putting a nice interface on it will just exacerbate the problem because anything you try to do will either expose the underlying crap and bugs (ie mfc, .net forms) or be as much work as a re-write.

      Just take a look at Windows for an example of what happens when you try to incrementally evolve something like this: 6 years with basically no innovation because updating anything is so slow and difficult. Meanwhile both Apple and Linux have made leaps and bounds, Apple by ditching their massive investment in OS 9 and Linux by shunning backwards compatibility. Linux doesn't have binary kernel drivers because mapping better stuff to old mistakes is even harder than keeping a zillion drivers up-to-date. I'm always getting "kernel too old" messages trying to make binaries that run everywhere. It sucks, but imho it's a huge reason why Linux is advancing instead of stagnating. The only reason Microsoft is still around is because of lock-in; if poster's company doesn't have a lock on the market and given their codebase they will fail if taking the incremental approach.

      I think it's painfully obvious that whatever it is they are doing (I'm guessing some database + COBRA junk) is something that shouldn't be written in C++ in the first place. For example, poster does not mention performance at all. C++ *can* be a lot faster than Java at some things and is a pretty good choice for those (action games for instance), but if you are not even slightly concerned about it then that's a pretty big tell that using C++ for it is a huge mistake. Ideally they would write most of their code in Python or Ruby or similar, but it sounds like this could be out because of client issues. So Java or C# is probably the only realistic language to code in.
      • by Jerf (17166)
        Just take a look at Windows for an example of what happens when you try to incrementally evolve something like this: 6 years with basically no innovation because updating anything is so slow and difficult.

        With respect, you've mistaken "incremental" for "maintaining backwards compatibility at all costs". They're not the same at all, and I'd never suggest trying to maintain any sort of backwards compatibility in this context.

        Your post makes complete sense if you make that substitution.

        I routinely make increme
      • This is so far the lone voice of truth in a herd of anti-Java zealots. The guy obviously asked this question to get reinforcement for his objections to the switch. I mean really? What other answer did he expect from /. ?
  • by bssteph (967858) * on Wednesday May 17, 2006 @10:16PM (#15355673) Homepage
    You say you're looking to achieve a "FDA approved software development process." And your IT director decided that Java is the magic bullet.

    This should be setting off some kind of warning in your head.

    A software development _process_ has little to do with implementation language. What you're looking for is a way to verify that you and the rest of your developers can rigorously apply software engineering principles in your organization and (reasonably) predict cost, development times, etc.

    You should have your developers reading the Capability Maturity Model, not books on Java. The government loves the CMM. I'd suspect a critical organization like the FDA would want CMM Level 5 (as hardcore in software engineering as you can get) out of your _organization_.

    That is, the process is people, not implementation language. Java being the green light is a load of malarkey (or at least, it should be).
    • The point here is that a different implementation language would better serve the needs of the desired process. If they're trying to move to an Agile model, which it sounds like they are, then Java using Spring and Hibernate will assist in that process. Spring especially is designed to make best practices more easily attainable. Following best practices makes the code more maintainable. IMO, maintainable code equates to fewer bugs & happier developers that can spend more time understanding the probl
      • Speaking as someone who does life critical software development, the LAST thing they are going to be able to use with FDA approval is an Agile process.

        These processes are all about mega-reams of documentation, proof that you've done all kinds of analysis, and audits of all of your process.
    • ...so I didn't have to. As a Java guy, I can say for certain that Java is NOT going to solve the OP's issues. They're just going to be trading a few million lines of bad C++ code for a few million lines of worse Java code.

      OP should read what you wrote on CMM. Anyhow, I doubt the FDA would require CMMI Level 5. Probably Level 3. But what do I know? Also, if the work is for the government, they probably shouldn't be offshoring it.

  • So you're overwhelmed by the C++ workload, so you're porting the whole kit and kaboodle to Java? Your management is either retarded or getting ready to offshore everything.

  • Moving from C++ to Java is irrelevant. The nut of the problem is your poor software engineering. Moving to Java will not magically solve that and your IT Director is an idiot for thinking it will. You probably already knew that so my pointing it out isn't all that helpful. If your existing C++ architecture is difficult to manage, your new Java architecture will also be difficult to manage. The best thing you can do is to throw everything away. Use your current code as a prototype to illustrate desired end-u
  • You and your manager are obviously not as experienced or capable as you think you are. You really think you are going to port 5 years of code to Java? What guarantee do you have that this off-shore outsourcing company isn't going to just bolt with your code? Who do you know that has worked with them. How did you come to work with them? You sound like you don't know your own requirements.
  • In addition to my other comment, be sure to read Things You Should Never Do, Part I [joelonsoftware.com] from JoelOnSoftware.

    People have varying opinions on his work, but in this situation, if you can't answer his objects you should not rewrite.
    • ... be sure to read Things You Should Never Do, Part I [joelonsoftware.com] from JoelOnSoftware.

      People have varying opinions on his work, but in this situation, if you can't answer his [objections] you should not rewrite.

      Agreed; but what should you do instead?

      A good answer can be found here [slashdot.org] and particularly here [slashdot.org]: rewrite it a bit at a time, adding unit tests as you write or rewrite code. Like the "rewrite from scratch" plan, you'll spend a lot of time working on functionality you already have. Unlike that plan, you'll h

    • This is interesting. It is a article from April 2000 criticizing netscape for rewriting their browser. I don't think that, with the benefit of hindsight, I can agree with his conclusion. I think he was very short sighted. Firefox is a very good browser and it would not exist if they hadn't done this. Had Netscape continued to code the original code base, their market share decline would have perhaps been a little slower, but it would have been more inevitable. As it stands, six years later, firefox has some
  • by bill_mcgonigle (4333) * on Wednesday May 17, 2006 @10:35PM (#15355749) Homepage Journal
    Before you go and hire a bunch of off-shore'ers you need to hire an on-shore FDA compliance expert who can walk you through developing a CFR 21 Part 11 compliant development process. The funny thing about the FDA process is it doesn't recommend best practices rather it forces you to make a plan and stick to it (and document that). They want a paper trail should anything go wrong more than anything else, so problems can be indentified and fixed. You ought to do a bang-up job as well, for your company's competitiveness, but that's optional.

    Expect to properly validate all your code with good test cases. This is probably a good thing for moving languages. Write a test case for the C++ code, validate that the C++ code works, implement the Java version, make sure the test case results are still the same. The JUnit tools might be helpful here, though I haven't used them personally.

    Java gives you some advantages to write more robust code, especially among collaborators. But you can thwart that by doing try { } catch (Exception e) {} instead of catching the real exceptions. That's a matter of coding practices - you ought to mandate people catch actual exceptions thrown and call them girly-men if they don't. If you mandate it in your process they have to follow it or you won't be compliant.

    I also find Bugzilla to be very helpful in an FDA-complaint process, using the VERIFIED status to mean 'validated'. CVS is really important, or probably Subversion today.

    Over all you'll probably feel like you've done a better job as a software developer by using a good FDA-compliant process because bean counters can't force you to cut corners, though good work can be tedious. Beware they don't fool you into working crazy hours to make up for the additional workload.
    • Java gives you some advantages to write more robust code, especially among collaborators. But you can thwart that by doing try { } catch (Exception e) {} instead of catching the real exceptions. That's a matter of coding practices - you ought to mandate people catch actual exceptions thrown and call them girly-men if they don't. If you mandate it in your process they have to follow it or you won't be compliant.

      There's a problem with this: some Java code (including Sun's JVM class libraries) throws excep

  • by MikeRT (947531) on Wednesday May 17, 2006 @10:36PM (#15355755) Homepage
    J2EE before things like EJB 3.0 is pure crap. Convoluted, difficult to grasp crap. Research the lightweight frameworks and give them a shot first. They're much more straight-forward and Javaesque than old J2EE. Java was supposed to be a simplified C++, but older J2EE actually made it quite complicated, and really unnecessarily so.

    I'm not trying to troll, as I actually like Java and think it's a solid language. I'm just not going to lie to you and say that the JCP people were sobre when writing up the older J2EE specs.
    • Just because you fail to understand it, doesn't mean it's crap. The following are not crap, and were never crap: JMS, JMX, JNDI, MDB, Session EJBs, CMT, JSP, JAAS, and many others.

      Really, the only part of J2EE that I can think of that was ever crap would have to be Entity EJBs (high overhead, high complexity, too expensive for simple DB access, too difficult to get complex queries to behave (BMP), required meaningless conversions due to nonserializability, etc., etc.).

    • Research the lightweight frameworks and give them a shot first.

      You mean something like, say... Spring and Hibernate? What a good idea! Why didn't he think of that??

  • Why change? (Score:3, Interesting)

    by Fred Nerk (128328) * on Wednesday May 17, 2006 @10:36PM (#15355756)
    My professional advice would be to stick with what you've got. If it's 6 years worth of C++ code, it's probably going to take roughly that amount of time to get to the same place with Java.

    It'll be slightly quicker because you already know what you have to duplicate, but more than likely you will go through the same bugs and teething problems that were already solved years ago all over again.

    If you get this offshore company to redevelop in Java, they are going to hand you a pile of code which you don't understand (because you're all used to C++), and don't have any stake in. Your developers are going to be less interested in fixing other people's bugs than their own (that's my experience anyway).

    I think you'd be better off spending the money to hire some local contractors to cut down your codebase. Keep the language and functionality the same, but any project which has grown over 6 years is going to have crud that can be removed or rewritten. Spend your time imroving what you've got rather than starting again.

    Also my experience of one offshore dev company was that they cut & pasted some open source (GPL) code, changed a few lines then tried to charge me for 3 months of development work.
  • by coyote-san (38515) on Wednesday May 17, 2006 @10:40PM (#15355772)
    Something overlooked in the trenches is that there's a very good business reason for switching from legacy C++ to solid Java (spring/struts/hibernate).

    Finding employees.

    Not because of "oh, I'm too good for C++" jerks. Just the simple fact that most recent development has been in Java, not C++. (C is also increasingly hard to find.) That's important when you're looking to expand your staff or replace departures -- it's harder to find people who are current in C++, and harder still to find good people who stayed with C++ instead of migrating to Java.

    Same thing with using standard packages like Spring and Hibernate. They may not be the best technology, but they're almost always good enough and you can find good people who know how to use them.

    As for outsourcing... huge mistake with a project this small. Besides the nightmare of managing a small team in a distant timezone, development teams this small need a lot of soft skills specific to the deployed environment. You could get around that with a rock solid spec, but I doubt that's the case here.

  • Which "C++"? (Score:3, Insightful)

    by neutralstone (121350) on Wednesday May 17, 2006 @10:46PM (#15355802)
    Are you talking about Standard C++ or Microsoft++? There's a considerable difference, especially in recent years.

    Microsoft likes to present a lot of its own extensions as "C++" features. In particular, they like to present C++/CLI (a.k.a "CLI++") keywords as "C++" keywords.

    And then there are the managed extensions. (But even Microsoft has deprecated those in favor of CLI++.)

    Going back even further, there's MSVC 6. Lots of people still use it, but it's just too old for anyone to expect it to be close to Standard compliance.

    What compilers do you work with? Do you set compiler options to disable extensions and run in a "strict" standard-conforming mode? Do you use more than one compiler?

    Do you make judicious use of the STL? Do you use any part of Boost? (If not, you should seriously consider taking some time to learn about these best-of-breed libraries that are available *for free* and for which support is available from multiple consulting firms.)

    Did you give up trying either of those libraries before trying out STLFilt? (If so, go play with it. You'll probably want to give generic programming a second try.)

    Have you and your team read any of the *good* C++ books? E.g.:

    http://tinyurl.com/puhjb [tinyurl.com]

    http://tinyurl.com/ru625 [tinyurl.com]

    http://tinyurl.com/mrdgo [tinyurl.com]

    http://tinyurl.com/ounbe [tinyurl.com]

    Have you invested in static analysis tools? (E.g., PC-Lint, etc.)

    Most of the C++ programmers who cut their teeth on Windows learned a watered-down version of the language by way of the Microsoft libraries (e.g., MFC, which should *not* be mistaken for a model of modern C++ interface design). If that describes most of the people on your team, you should seriously consider migrating from "kinda-C++" to Standard C++.
    • Hmm. I agree with you about C++/CLI [regdeveloper.co.uk], and I remember how bad standards compliance used to be in earlier versions of Visual C++, but more recent versions of Microsoft's C compiler (since Visual C++ 7) are amongst the most complete compilers as far as standards support goes (couldn't find an authoritative link - sorry). IIRC, MS even hired one of the STL guys to help them in this regard.
  • by danpat (119101) on Wednesday May 17, 2006 @10:47PM (#15355805) Homepage
    "Things you should never do, Part 1": http://www.joelonsoftware.com/articles/fog00000000 69.html [joelonsoftware.com]
    • I agree with Joel but I can't help thinking that his attitude taken to the extreme is precisely what's wrong with Windows: millions of lines of legacy hacks, bugfixes and two-page functions that nobody really understands anymore and that few can fix or audit for security problems.

      I heartily agree with an earlier poster who suggested SWIG. Keep the C++ codebase and maybe refactor the bits that really need it but do all new development in a scripting language like Python or Ruby, using SWIG to wrap the existi
  • by wysiwia (932559) on Thursday May 18, 2006 @05:10AM (#15355948) Homepage
    As others have already asked, what environment you currently use is critical for any development strategy. Simply switching from C++ to Java will gain you nothing, what counts is what better framework you want to use. Since you only mentioned Windows I guess you just use plain MFC but since you also mentioned Java I guess you need to divert to a cross-platform solution.

    In case your future environment has to produce binary applications you are IMHO best of if you switch to the wxWidgets framework (http://www.wxwidgets.org/ [wxwidgets.org]). Since you already have C++ knowledge and wxWidgets is quite easy for Windows developer it shouldn't be a big problem to become familiar. I'm quite sure with wxWidgets you are equally efficient as with any Java framework but don't have the disavantages of Java.

    You can use wxWidgets regardless of any platform consideration, if you just want to stick to Windows or to Linux or whatever, it doesn't matter. But if you also follow the guidelines of wyoGuide (http://wyoguide.sf.net/ [sf.net]) you can move your code anytime to another supported platform and just release it. As long as you just use the features of wxWidgets there's no need to recode anything on other platforms ever.

    If you want to see how well this approach works try out my samples (wyoEditor http://freshmeat.net/projects/wyoeditor/ [freshmeat.net], wyoFiler http://freshmeat.net/projects/wyoeditor/ [freshmeat.net]) or look into Audacity. Or look out for the commercial application Xara. There's probably no alternatives for cross-platform development as if you do single-platform development as with wxWidgets/wyoGuide. And keep in mind, no Java disadvantages.

    O. Wyss
    • Actually, to get as closer to Java as it gets with C++, Qt is quite a bit more helpful than wxWidgets - assuming you do not mind GPL. While wxWidgets claims to be a C++ framework, it uses a subset of C++ coming directly from the stone age - no templates, for example (this makes collections particularly annoying to work with), and MFC-like message maps for event handling. Qt is not really a "proper" C++ framework either (in a sense Boost is, for example), but it is not afraid to use many nicer C++ features w
      • I see no reason to be closer to Java, as I'm more productive in C++ (with wxWidgets) than in Java, in the kind of applications where you can use either.

        I guess you evaluated both toolkits but you have written real code only with QT. In my case I evaluated both and I have written real code only with wxWidgets, so take my bias into account.

        I agree that MFC message maps are ugly, but they are not obligatory, in fact I use none of them in my new wxCode. I have code like this in the constructors (or wherever is
  • If it's a highly experienced C++ team, they will be disgusted with Java. Expect team morale going low. But if they are quite inexperienced, Java will make their life easier, morale up.
    • I think a better question is, are the C++ coders writing the kind of C++ code that was typical ten years ago?

      If so, they haven't adapted to new C++ practices, and there's no way they'll adapt to Java. They'll write terrible Java and be miserable.

      If not, then they'll adapt to Java pretty quickly. Some of their C++ techniques won't be possible in Java, but they'll figure out the strengths of Java in a few months and start writing good Java code.

      Oddly enough, the more modern C++ elements you see in your code
  • FTFA:

    I find it more likely that the problems we have would persist across languages or architectures (lack of time and resources leading to buggy code, lack of direction from marketing, and so on).

    You hit the nail on the head here. In fact you'd probably be worse off since you've mostly got to learn Java etc first, and a management willing to throw six years of code down the tube is probably not going to give you time to do silly things like learning new languages. You'd be better off rewriting sections

  • A couple of advices (Score:3, Informative)

    by Aceticon (140883) on Thursday May 18, 2006 @06:26AM (#15356204)
    From somebody that DID do C & C++ and has been doing mostly Java for a number of years now:

    - Get an experienced Java Developer/Designer/Architect inhouse at least for preparing and doing the migration. Put that person in a team-lead/team-coach role or at the very least use him/her for high-level design and for code reviewings. No mater how good you guys are, when you move to a different language AND more importantly a new set of libraries and frameworks, if you do it on your own you're going to make all the mistakes a "new guy" does which means a lot of going back and forward as you figure out that your initial design doesn't quite work with Hibernate/Spring/J2EE/whatever.

    - Develop a couple of some small apps first, just to get some experience with the language itself - take a week or two doing it. Try and use the libraries/frameworks you wanna use in the main project - for example, if you wanna use Hibernate to access the database, do a small app that works with it.

    - If some of you guys are still using non-object oriented features from the C side of C++, you're going to have problems moving to Java. The simplest solution is using loads of static methods in an auxiliary class. DON'T! Generic auxiliary methods in Java are the exception, not the rule in most applications.

    - Beware of thread safety. Multi-threading is a built-in feature in the standard Java libraries, and when using some of the major frameworks (J2EE for example, both the web side and EJBs) or having to deal with asynchronous events from multiple external entities (for example the server-side of a multiple-user client-server app) it is almost guarante that some of your methods WILL BE called by multiple threads simultaneously. If you make auxiliary methods at the class level (or worse, in a generic class), beware of them keeping state - in a multi-threaded environment there is no guarantee that said methods will be called in any given order, even if the your code looks like it will never do otherwise. The only way to control multi-threaded access to resources that have state is to either not share them (ie put the auxiliary methods in an object or encapsulate state in an object that gets passed to the methods) or carefully using synchronized blocks and methods (very few people know how to do the last one properly). Fortunatly, good OO encapsulation avoids most problems with multithreding.

  • Based on one sample of personal experience, I would say you should allow about 1 year to convert all your code to Java, get it back to the state it is now, and work through the hundreds of minor bugs that are certain to crop up. That is I think one of the most important things to consider. Do not underestimate how long the conversion will take.

    By moving to Java, the main things you gain are garbage collection, and generally much better memory protection. Yes I know in theory you can do these things in C++,
  • So the solution to the problem of resource shortage is to spend a lot of resources rewriting code.

    On another topic: I have professional experience with both Java and C++. Not a lot; about two fulltime years each. The thing is; Java has a lot of theoretical benefits and will theoretically run at about the same speed. Perhaps in 10 years it will, but right now I can see no technical reasons to prefer Java. The real reason is, presumably, an outsourcing one.
  • Apart from the C++ part, a former employer of mine did this back in, oh... 2000 or so. Numerous projects were started to move the monolitic behemoth of a product to a componentized Java version.

    A complete waste. Tens of thousands of man-hours and millions later, only miniscule parts were rewritten, albeit without the possibility to interoperate with the legacy code.

    Just like it sounds from you, this is a internally triggered initiative, not something that came from sales or marketing. Chances are noone want
  • by Lumpish Scholar (17107) on Thursday May 18, 2006 @08:10AM (#15356506) Homepage Journal
    ... only to do even worse this time?

    Seriously, that trick (pretty much) never works. I remember one project where six developers in a row said, "This code is unmaintainable, it needs to be rewritten from scratch." Think about it: it was rewritten from scratch five times, and each time, the result was still so bad that the next maintainer gave up on it.

    Here are some questions for the IT director's boss: When has this director done something like before? How successful was it the previous time(s)? What mistakes were made in those cases that you can learn from this time around? What mistakes were made in the development of your current system that you can learn from this time around?

    (Are you risking your job by going over the IT director's head? News flash: your job is already at risk.)

    You guys are about to be squeezed seven ways from Sunday.
    • The IT director is counting on offshore outsourcing to replace the system; it's probably planned as a one-way trip, and (if successful) likely to go that way even if that's not the plan. (The director's job is as likely to be relocated as yours is.)
    • The offshore guys are calling the technology shots, for their convenience, not your benefit.
    • Worst of all, the director has given up on maintaining the software; if someone can't manage maintenance, they probably can't manage a major greenfield development project, either.

    You're probably psyched about getting to learn new technology. Well, get psyched about this: odds are, the project will fail, the IT director will be fired, his or her successor may be even worse, and you guys will not be fired, but instead will still be left trying to clean up the mess you currently have.

    Fight it; you have nothing to lose but a job that's about to get a lot worse.
  • Been there done that (Score:3, Interesting)

    by SysKoll (48967) on Thursday May 18, 2006 @08:50AM (#15356645)
    I used to work in the Software Group of a large (large!) company that had developed its flagship application server mostly in C++, starting from the late 90s. We had a huge bugginess and productivity problem. The bug fixes were coming too slow and we had persistent quality issues. Furthermore, we could not port our C++ code to the umpteen platforms that marketing wanted to target.

    In 2000, we made the decision to move to Java. Moving to Java was painful at first. We managed to introduce new Java code while reusing the old C++ parts for a while, but we finally rewrote everything in Java. The Eclipse IDE boosted our productivity considerably, and the product is very successful. So I guess it makes sense.

  • stay on target! (Score:4, Insightful)

    by abes (82351) on Thursday May 18, 2006 @09:33AM (#15356860) Homepage
    Well, to agree with just about everyone else here, for the whole team to learn Java, get used it its quirks, etc. is going to take a good amount of time. One thing that it does sound like, is that there is a library issue -- your current library is unmaintainable, and perhaps the ones Java provides takes care of that. Maybe that can cover for the time it takes to learn Java (since it's based on C++, it's not so difficult, but at least last time I checked, it lacks many features that you'll have gotten used to in C++).

    Main sticking points (since it's been years since I've last used Java, someone will probably have to correct this):
    * lack of templates
    * lack of double inheritence
    * everything is a pointer (both good and bad)
    * you have to be aware of garbage collector for optimizations
    * more verbose: both libraries are verbose in nature, and syntax can be a bit more verbose

    I think most issues people have with C++ can be solved with the right library. Want garbage collection, use a garbage collection library. Or use the STL (check out boost too!), which has just about all the container classes you could possibly want or need. Roguewave has also always provided a good amount of commercial quality C++ libraries. And don't forget QT. Way way way better than any interface provided by Java. I'm not a big fan of Swing (or AWT) at all.

    If you want to talk in terms of productivity, one method of sticking with C++ (although it sounds maybe the decision was made already) is to use a hybrid (come on, everyone else is doing it!). I use the boost::python library a whole lot (though there is SWIG, Weave and Pyrex as well). All my optimized code stays in C++, and everything else is in Python. I know Python isn't the fastest language in the world, but I don't have to worry about that. If I need to read in a configuration file, write a quick XML parser, etc. -- easily done in Python.

    Python is far from a perfect language -- I get bitten by the whitespace issue quite a bit (yes, if you stick with one editor it's fine, but you might always have that luxary, and some editors insist on using tabs). It is definitely one of the more complete interpreted languages with a huge amount of libraries written for it. Also boost::python, like all template library will slow your compile down by a lot. On the other hand, you compile your code less, since most of your work is in Python. And Python takes 1 day to learn.
  • Dear god, no. (Score:3, Interesting)

    by MythMoth (73648) on Thursday May 18, 2006 @09:46AM (#15356943) Homepage
    I'm a full time Java consultant who used to be a full time C++ consultant. I like the Spring framework, and I've written a book on Hibernate. And I think this idea is just insane.

    Take your existing system and build upon it incrementally. If it is full of bugs, replace the buggy components incrementally. If you can't figure out how to maintain it in this incremental manner, I guarantee that the big-bang solution is going to be a total disaster anyway.

    And this is all setting aside my reservations about the wisdom of outsourcing a project like yours.

    Good luck. You are going to need a lot of it.
    • PS...

      Ask your offshore development outfit how many C++ developers they have. And how many Java developers. I'll happily bet you $100 that they have at most a couple of C++ devs, and that this is the reason for their "recommendation". Given that they won't have the expertise on hand to understand the logic of your existing system what are the odds they'll do a good job of the rewrite?
    • I've seen stuff like this before. Poorly architected system gets rewritten in another programming language. This is a no-fault, blameless way of throwing out the old, useless system and replacing it with something that is, hopefully, better.

      If you claim that the old system is too crufty for a reasonable maintenance cycle, then someone might get their feelings hurt and strive to defend the old code. A language change is more politically acceptible because C++ can't defend itself from being bashed.

      The [transitionchoices.com]

  • A move to Java, Spring, and Hibernate would point towards a change in focus to web-based applications. Are you going from Windows-based C++ applications to web-based solutions?

    If so, then a change in architecture is probably warranted as you can take advantage of tool sets geared towards this new development environment. However, this doesn't mean you should throw the baby out with the bath water. Java works well as an intermediate/coordination layer and you could leave large portions of your legacy deve
  • Some excellent suggestions so far. Let me first say I love working in java and there are no better tools out there, but, I'd think hard about the migration. It's going to take alot of time, much more than you or they might expect, and alot of foresight, situation analysis and learning before progress is seen. Double the estimate, then double again, in my experience. If the code is really rotten, a migration might make sense. A plan of attack might be: Get atleast one dedicated, experienced java head and
  • I'm assuming you're probably asking about a migration tool? I haven't heard of one.
    However, I would recommend using Eclipse with the CDT plugin to import all your existing code, and then using that to write the same code using java and at that point, use JUnit for unit testing. That will tremendously help you.
    Eclipse is a great tool for java (dunno much about using it with C/C++), and JUnit is now critical in any of the code I write that is beyond 150 lines, it just makes things a lot clearer.
    Also, as someo
  • The offshore guys love Java. They love Java because American IT directors love Java and give them a ton of money to develop in Java. That doesn't necessarily mean Java is always the answer.. Java is a one-size-fits-all language. It's known to be good at a lot of things but not necessarily great at any one thing. C++ is the speed-optimized object oriented language. It's fast, and maintains most benefits of OOP. It's also very flexible and sort of a one-size-fits-all language as well, with the exceptio
  • If you have architectural problems with a C++ application that are affecting programmer productivity, it seems to me that the answer is to fix those problems through a refactoring process. This process can be controlled so it is relatively non-invasive and low impact. Not as sexy and harder to sell to management, but it is the way to go.

    Switching languages won't help long-term. While a rewrite to a different language is one way to gain the refactoring you are after, it comes with a lot of undesirable side e
  • I see a lot of people replying that whoever is suggesting you do this is on crack, and that you shoudln't throw away working code so that you can go to Java. They might be right. They also might be on crack themselves. It all depends on what your software does and how much of it you're going to be able to throw away.

    See, if the bulk of that 6 year old codebase is fine tuned code for simulating some physical process or something similarly domain specific, then throwing it away and converting it to anothe

  • A lot of C++ fans here, I see. I offer the perspective of someone who's written C++ and written Java, but who doesn't particularly like either of them.

    What Java offers over C++ is robustness. It's designed so that a RAIJP (Redundant Array of Inexpensive/Interchangeable Java Programmers) can write code without creating a ton of memory leaks, null pointers and security exposures. From automatic memory management to mandatory exception handling, most of its features are designed to support that goal.

    What Java
  • If you have specific problems, fix them. If you have lots of legacy cruft that is not necessary, then trim it. If your code/revision management system is poor, then upgrade it and/or develop new procedures. If your code is hard to understand then perhaps you need to re-architect it and/or document it. Throwing away all the code and all the experience you have accumulated is the biggest mistake you can make. If your problems do not directly relate to issues inherent in the language or its libraries then get
  • You should view this as an opportunity to get free training in java from your employer, which you can list on your resume in about 6 months, which is about when your job will be offshored after the IT dept implodes.
  • I'm not going to comment on whether you should switch from C++ to Java...almost every other post in this thread has addressed that issue and only your team can really make the decision on whether your code is broken enough to need an architectural fix or not. What I will do is give you an idea of what your life will be like 2 years from now if you adopt the suggestions of the consultants.

    1) You will be cursing the day you ever accepted Hibernate into your development environment. After the initial "ooh...
  • It is a move to outsource all 5 of your jobs.

    Find a new job.
  • This is rediculous (Score:3, Insightful)

    by GorillaTest (742268) on Thursday May 18, 2006 @02:32PM (#15359555)
    Why do people always need to pick a dramatic solution? Just take some time out to refactor your code. That will be a lot cheaper and more effective than going through this exercise your IT chief has planned. I've gotta ask why are you putting up with this headache to begin with. Go somewhere where they unit test so refactoring is practical, and where the big chiefs are not allowed to read "Development for Dummies"
  • I mean that in the nicest possible way -- I believe the original question is structured to generate exactly the kind of response that we're seeing now -- don't do it. I believe this is merely an attempt to produce something to show the PHB.

    Now, I'm not saying that's a bad thing. Mostly, I agree with the responses, but I have to wonder if there's another side to this, such as: Did the consultants really say nothing more than "Java is a magic bullet"? There are legitimate reasons why Java may save you tim

10 to the 12th power microphones = 1 Megaphone

Working...