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:
  • Re:Resume (Score:3, Informative)

    by Vegemite (609048) on Wednesday May 17, 2006 @10:18PM (#15355681) Homepage
    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
  • by Anonymous Coward on Wednesday May 17, 2006 @10:21PM (#15355693)
    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".

  • 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.
  • 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.
  • 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.

  • Re:Resume (Score:3, Informative)

    by Arandir (19206) on Thursday May 18, 2006 @03:13PM (#15359886) Homepage Journal
    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 old school Unix people, they don't know how to use Windows tools." I have no idea if he was excusing or blaming us, but I suspect the latter.

Anyone can do any amount of work provided it isn't the work he is supposed to be doing at the moment. -- Robert Benchley

Working...