Slashdot Mirror
Moving a Development Team from C++ to Java?
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."
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."
Send the IT director on a one way trip to Basra
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.
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
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.
I still have more fans than freaks. WTF is wrong with you people?
Why switch to Java? That really IS a damn good question.
I pretend to know more than I really do by mooching off google and wikipedia.
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.
would you want to do a silly thing like that? Is C++ resticting you from doing something theat java will allow you to? From this idiots point of view you gain no advantage from switching platforms(languages, etc.) you just accrue profit for an offshore company.
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.
Javascript + Nintendo DSi = DSiCade
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.
Joseph Bacanskas [|] --- I use Smalltalk. My amp goes to eleven.
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.
Trust the Computer. The Computer is your friend.
Give the team a lobotomy. That'll do it!
Buckle your ROFL belt, we're in for some LOLs.
Your best solution, if you can find people with enough sway would be looking into getting your IT Exec fired. Really.
[quote]The real question is: what do we gain from moving to Java?[/quote]
About a gig of memory use.
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.
- 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.
- 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.
That puts a whole new spin on "eating your own dog food".
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).
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.
Conformity is the jailer of freedom and enemy of growth. -JFK
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-user functionality but do NOT try to replicate it. Re-write from the ground up and throw away all the mistakes that have been made.
It's simple: I demand prosecution for torture.
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 from JoelOnSoftware.
People have varying opinions on his work, but in this situation, if you can't answer his objects you should not rewrite.
This sounds like one of those no-win situations. You'd be crazy to rewrite all your stuff in Java, from scratch. If you have no choice, resign and go work somewhere less insane.
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.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
Here are some tips for things you'll likely run into:
- Use Lazy Loading and Background Class Loaders to hide the slow class load times from your user. First impressions count!
- Use A Splash Screen (eg. launch4j) if a GUI app
- Expect to set minimum hardware requirements for your customers.
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.
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.
Anything is possible, except skiing through revolving doors.
You've got some abstraction between interface and app logic and database, presumably? Choose a meta-language (Java, .Net) that will let you talk multiple languages (I'd suggest C# and Managed C++ via .Net/Mono).
This way you can reuse and marginalise the other language over time.
Basically we're all asking you to apply evolution, rather than revolution.
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.
For every complex problem there is an answer that is clear, simple, and wrong. -- H L Mencken
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
http://tinyurl.com/ru625
http://tinyurl.com/mrdgo
http://tinyurl.com/ounbe
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++.
"Things you should never do, Part 1": http://www.joelonsoftware.com/articles/fog00000000 69.html
Subject: Moving a Development Team from C++ to Java?
Body: No.
http://developers.slashdot.org/article.pl?sid=03/0 2/09/1347215&mode=flat&tid=108 Sun doesn't even like Java.
;-)
I agree with the other posters who think this is a bone headed move. Polish your resume indeed. Don't wait, leave as quickly as you can get another job.
If, for some reason, I were desperate enough to want to re-write working code, I would consider a language that provides some real advantage. I like Python for most things because it is fast to write. It is also easy to produce nearly self-documenting code. That isn't what your boss asked for though; so just leave now and beat the rush.
If this hair brained scheme works and the company still exists a year from now, post another article so the rest of us can eat crow.
...That doesn't justify moving from your existing platform to Java. It sounds to me like the problems are your in your management and process, not your platform. If you can at least implement improvements in your process (tighter testing, then re-factoring) you could spend your time improving your existing codebase instead of trying to move all of that logic to a new paltform.
As for the off-shoring, if your management thinks it is a good idea, it's time to find a new manager. They have to be looking at it as a purely cost-saving solution and are not considering the hidden costs of trying to work with people half way around the world. Many companies are discovering that off-shoring is too expensive to do half-way; you either farm to whole project out to India, or you do it all in-house and add contractors as needed. Anything else can easily get to be more hassle than it is worth.
For comparison, I have been working almost exclusively with Java for most of it's life, and have really enjoyed using Spring and Hibernate, which both add a lot to the Java platform. That said, I can't think of any reason why I would have faith in a decision to abandon one platform for another after six years in the name of efficiency. That is the kind of decision that could only come out of poorly-informed management.
If I were you, I'd start looking for a new manager or a new job.
I would agree too, rewriting everything in Java just means wasted time programming, wasted time debugging, and wasted time testing. Now, for me at least, the best solution is to do all future development in some managed, garbage collected language and use your existing C++ code from inside that language.
While directly using JNI or the Python C API is possible, the SWIG Project reads C++ headers and generates the neccissary code to use that from Java, Python, or many other languages. It works on Windows and UNIX. While it isn't 100% magic, it is about 92% magic with just a little bit of extra directives and stuff you need to tell SWIG about. For a huge project, the automation SWIG provides really makes it possible to use a huge C++ library from inside Java or Python (or Ruby, etc).
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/). 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/) 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/, wyoFiler http://freshmeat.net/projects/wyoeditor/) 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
See http://wyoguide.sf.net/papers/Cross-platform.html
if you're going to change languages, move to
python or ruby
Technically, the best solution for this kind of migration could be moving the code to managed C++: you keep your working code, the managed environment may find bugs you didn't know about, and you can do new development and rearchitecting in a more productive language. A big practical problem with that is that the only mainstream managed C++ solution comes from Microsoft and you may not want to be tied to Microsoft platforms (I don't).
But that's probably the only generic advice one can give you. Beyond that, deciding whether Java or anything else is the right choice depends on too many factors.
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.
There you are, staring at me again.
This seems like some sort of panic reaction: "IT problems, let's hire a third party, they'll know what to do." Looks like they lost fate and had an "Out with the old, in with the new" feeling.
Frankly I don't see why switching to a different language and rewriting everything would be faster and more economical than rewriting parts, finetuning and sticking to the same language. Especially considering the fact that that language is C++, would it have been brainfuck, well that would be another story.
Just my thoughts
In Soviet Russia elephant rides you!
Don't you just hate it when people reply to your signature?
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.
I need more information to offer much more advice than this but one of the many things that Java is pretty good at is calling native code. So if I were you I would start by writing a bunch of wrappers onto your existing C++ libraries and start doing new development in Java. As you need to add/modify functions you can port that portion of your library to Java and so on. Its a nice language and pretty easy to pick up from a C++ background. Get hold of a copy of Thinking in Java by Bruce Eckel as a starter tutorial and look out for a new addition of Effective Java by Josh Bloch.
The big plus point you'll get from Java whatever you are doing are:
1) Decent refactoring support in all the major IDE's makes it a lot easier to avoid your current problem in future. Check out Jetbrasins IDEA for a start.
2) Garbage Collection easy memory management.
3) Threads a real joy when writing multithreading apps. The implementation is minimal and elegant. The simple way that methods can be protected from concurrent update, the equally simple semaphore and critical cod mechanisms, the very easy way of creating a rendezvous between two threads, all combine to make this a good language feature.
4) Exception Handling. Main thing here is the finally block in Java. Every try block can have a 'finally' clause. Any time such a block is exited, regardless of the reason for that exit (e.g. execution could proceed out of the block, or an exception could pass through it) the code in the finally clause is executed. Checked exceptions are more controversial but I like them and think they tend to lead to more robust code. At least they force you to consider error handling as you go.
5) Amazing collections of open source libraries Jakarta common is a good place to start.
6) Huge vendor support.
7) Seriously cross platform. All my Java code is developed on Windows machines but runs on Linux, AIX, Z/OS etc. I haven't had a problem moving from one to the other in years.
Having said all of this no tool is ever going to fix poor practice so you might want to think about why your code base ended up being (by the sounds of it) such a mess in the first place.
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++, but it can be easier when your language handles it for you. You also lose all the complex template-foo you can do in C++, which you can either decide is an advantage or disadvantage
Combination - fun iPhone puzzling
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.
Slashdot social media options: AIM, ICQ, Yahoo, Jabber and Mobile Text. Why no MySpace?
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 wants the product when you're half-done in a few years.
My advice: start looking for another employer. Maybe after you've taken all the Java training and certifications...
Oh, I can't help quoting you because everything that you said rings true
As others have suggested, be VERY suspicious if it isn't an incremental switchover. I have a feeling that won't happen for you, and the offshore company is going to enjoy your company's money a lot.
When it all goes wrong, please do a little write up of the events and submit it to The Daily WTF.
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.
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.
Stupid job ads, weird spam, occasional insight at
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.
--
Mad science! Robots! Underwear! Cute girls! Full comic online! http://www.girlgeniusonline.com/
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.
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.
--- These are not words: wierd, genious, rediculous
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.
"Avoid employing unlucky people - throw half of the pile of CVs in the bin without reading them." -- David Brent
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*.
http://www.joelonsoftware.com/articles/fog00000000 69.html
Food for thought--you have 6+ years experience in writing C++ apps. This means you know the framework and hopefully the ins and outs and the gotchas of the original system. What if instead of a ground up rewrite you did the following:
1) Start with a port of the application from unmanaged C++ into managed C++
2) ID the areas that are particullar "smelly"
Be especially aware of the areas that you had to implement yourself, are smelly and could be replaced by an existing library (e.g. message passing from one machine to another gets redone using the System.Messaging namespace (MSMQ)
3) ID the areas that have to stay unmanaged (performance reasons or perhaps something written in asm?) and migrate them into separate libraries...
Down the road this might have a better payoff--generally these sorts of projects (if set up correctly) can be language neutral (and yes I've worked in a shop where the project was a composition of VB.Net, C#, managed C++, and unmanaged C++ and C). You need to move something onto a 'nix platform? There is mono...
You have a one off winform application that you want to generate, you need it in a week, and it needs to use your existing infrastructure? I think you get the point where I'm going here....
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.).
"Avoid employing unlucky people - throw half of the pile of CVs in the bin without reading them." -- David Brent
... if they have to switch to anything, they should be switching to .NET. They're a microsoft shop.
"Avoid employing unlucky people - throw half of the pile of CVs in the bin without reading them." -- David Brent
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 development in C++ with shims to access them from Java rather than re-engineering everything.
Beyond that though, without an answer to that first question it's hard to analyze things any deeper.
--- I wish I could hear the soundtrack to my life. That way I'd know when to duck.
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 allocate a team of current employees to work with the new guy. New guy brings employees up to speed on java and tools and team brings new guy up to speed with existing codebase. Have the java team rewrite a good chunk of code, then throw it away... be brutal. Write it again, with the team up to speed, then move onto other pieces. Management usually hate funding R&D, but they have no choice if they want results. Choose what to tackle gingerly... something tough and important but not mission critical. After the first pass, sit back and breakdown what needs to be re-implemented and re-architect with hindsight, if possible. For working standalone code/services, think of a corba (ick), jni or some other c++ - java compatability layer. If I, as a solo developer, were to decide to move the last 6 years of my code to another language, I wouldn't do it. Too much work... sure, I'd learn a bunch, but it'd take be years to get to the point where I am now. That being said, my current codebase is java in eclipse, and any stale code is as easy as possible to refactor. The tools are great, but if you're not careful, you'll just make a broken c++ codebase become a broken java codebase. The prerequisite to good code is experience, and there's only one long, hard way to get that.
Question for the original poster: Are you referring to getting your software in line with 21CFR Part 11 regulations? I don't see how switching languages is going to help you validate your software any quicker.
If you do move to Java, though, everything I've read indicates that implementing automated unit tests in JUnit would be a very, very good idea. That way, your unit tests can serve as documentation that certain aspects of the system are validated without making a poor human run those tests.
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 someone else mentioned, refactoring when you can is a good idea, and eclipse will help you a lot with that.
And, best of all, Eclipse is FREE! That's the best price your management could ask for. There's also a couple of books about Eclipse which might be worth investigating to get started.
Good luck, I've encountered a few systems that were FDA approved, and I can tell you that it's a pain in the butt to write code for it if you don't have unit testing. Go with JUnit and part of your pain will be alleviated, and paradoxically, writing that much more code will make you more productive as you'll spend less time debugging (the bugs will become evident as soon as the code is written!).
Cheers
---- I am certain of only one thing : I know nothing else.
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 exception that it is very fast.. so is more usefull for applications that require speed. I know your familiar w/ C++ but bear w/ me...
IME, Java is slightly faster to develop than C++. It's garbage collection helps reduce memory leaks, and it's typeing is safer, which will reduce _some_ bugs for you. IMO it doesn't offer enough to do a complete migration away from C++. I see a lot of places do this and I think it's often a mistake. If you were starting from scratch, Java may be worth it. With 6 years of C++ and several C++ experts in the group. I say stick to what you do best unless you find something that can dramatically improve productivity.
What you really need to look for to make this dramatic difference is a framework, regardless of what language it uses. If you are doing web software, something like Ruby on Rails will work wonders for you. This isn't the only framework though.. there are a many for all types of applications. There are things like SAS for data processing and QT for cross-platform widgets. If there aren't any frameworks to give you a head start, than you may need to roll your own or try to migrate your existing codebase into a working framewok. This will obviously take a lot of time and resources.. but there's no getting around that. At least it will get you on a good footing for the future.
Also... try and convince your management that sending a pile of code overseas is not going to make it come back as a higher quality product. Usually the effect is the opposite.
I was working on migration of one big c++ project to java.My problem was that i did'n know the c++ syntax but was familiar with java.That project has lasted for whole year(5 developers on project). My bigest problem at the start was understunding c++ pointers.
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 effects. Worse yet it doesn't instill the culture that software engineering really should include continuous refactoring as part of the development process ifo order to keep the hedges trimmed. So inevetably as time goes on that clean new design will accumulate cruft. Unlike some pundants state, source code does rust.
Switching from C++ to Java may marginally improve programmer productivity because memory management is easier in Java, but it seems I bet that it will take about 3 years before you reach the level of expertise needed to start seeing that benefit.
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 another language would be insanity. But I'm betting its not. I'm betting the bulk of the codebase is the simple stuff that you have to build from the ground up in C++. You mentioned Hibernate, so there's probably ORM code somewhere in there, or DB code at least. You might have some amount of file IO code or event managing code or logging code or any of a hundred other tasks that people writing in C++ have to reinvent everytime they write an app.
This is one of the critical differences between C++ and Java. C++ doesn't have a giant common language runtime for doing network stuff and DB stuff and logging. It certainly doesn't have a vast array of open source third party libraries designed to do all the things you have to do for so many applications, like write logging and serialization API's.
So it comes down to how much code you need to port and how much code do you get to throw away. 'get' is the word here because every time you can junk a piece of functionality and use a mature open source third party library instead, that's more time you get to have to fix bugs in your domain specific code. I've been a C++ developer a lot longer than I've been a Java developer, like by an order of magnitude, and while I still love C++, I wouldn't write an application in it unless I had a very good reason to. Some reasons were if it was a client app being distributed to a large homogenous Win32 userbase, where ensuring the VM was present or had the right version becomes more of a problem than its worth. If the VM footprint was larger than warranted by the application, like for instance if I'm writing a version of 'grep'. If I'm writing a 3D graphics intensive application like a game. Mostly this is all stuff on the client side. If I'm writing server side code, finding a reason not to write in Java becomes harder and harder. Maybe some would argue that PHP or Ruby On Rails is going to be better, but certainly not if you're dealing with a group of people with existing C++ knowledge.
You're biggest problem will be learning when NOT to write code. The temptation will be there to go ahead and write that XML parser, just because it so engrained. But you have to learn to use features in the language and the library.
I could go on quite a bit, but you get the idea. If you have any questions give me a ping, I'll be happy to answer them.
Jherico
What can the average user can do to ensure his security? "Nothing, you're screwed"
I agree with a lot of posts here with regards to polishing your resume.
I don't know the nature of your application or which field your employer is in so I can't make a good comment on your situation.
Your development staff is quite small 5 (FTEs) so a rewrite will be very difficult to do and maintain your existing app at the same time.
Unfortunately, I get this sinking feeling in my stomach when I read that your IT director is looking at an offshore to assist in the migration to Java.
Does this mean that you're going to be offshored someday? Or does it mean that he does recognizes the high costs of the rewrite?
It's silly to think that just rewriting your existing application in another language is going to solve all your problems instantly.
If you're going to rewrite, atleast keep it in house and retain your intellectual property within the company and keep your staff up to date with its own software products.
What I believe might happen is that the rewrite will be assisted by this offshore company by people who don't understand the business concepts as well as your staff does and it may end up being a buggier mess than the original.
Better to hire some experienced Java programmers with a strong C++ background to help with this rewrite.
Goodluck.
"If a show of teeth is not enough, bite
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 doesn't offer is much improvement in development speed over C++. Simple tasks often take ridiculous amounts of code, offsetting the gains of automatic memory management.
So... in this case Java is really solving problems that are being introduced by adding offshore developers. So the real question is whether offshore developers are the solution to your problems. I'm guessing they're not.
GCHQ Quantum Insert installed. If only our tongues were made of glass, how much more careful we would be when we speak
And is it on the "shortable" list?
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 getting rid of it will not make your problems go away. The language is not the problem.
Exactly, there's a balance. Speaking of Windows, note that Windows was rewritten from scratch, when Dave Cutler from DEC was hired to write NT. Now certainly there are some vestiges of DOS, and OS/2, and it's a huge codebase, but it's not Windows 95/98/Me, that is clear.
Joel's article seems to be the defacto standard against rewriting software, but funnily enough, I think he's been proven completely wrong, in hindsight, by the very example he used to prove his point. Think of Mozilla? Mozilla originally started from the Netscape codebase, but they got a lot of flack from folks like Joel for rewriting it. Now it seems IE is the patchy codebase you describe Windows to be.
Although a bit tangential, Ogre 3D has a C++ API. In order to create a Java API, the Ogre4j developers have been working on an automatic bridge to create C++ handles for Java programs specifically from Ogre 3D's C++ API, using JNI and some other stuff: http://www.ogre4j.org/phpBB2/viewtopic.php?t=25 You can use this to package all of your previous code into an API that your new java code references. Granted, this assumes that the new code you will be developing either doesn't need to change much of the existing code (i.e., it will mostly be enhancements, rather than changing existing, already written code). If you do need to change how some of the previous code works, you could handle it by wrapping some structures with Java classes, but the more you have to do this, the more development time you will lose. Doing a straight rewrite from C++ to Java will take between 50% to 75% of the time that it took you to write it in the first place, and this is a possible alternative to get it up off the ground with a chance. After this is done, you can slowly convert sections of the C++ code that do frequently change. It is possible, it can be done, but it heavily depends on how much rewriting you plan on doing to your already existing C++ code.
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...cool" phase where it effectively maps single tables to single model objects and even does a few more complex things than that, you'll start running into obscure bugs and start pulling your hair out trying to a) figure out why the @#$% it is generating certain SQL (usually a hard process) and b) figure out how to get it to generate reasonable SQL (nearly impossible). If you have anything more complicated than simple table mapping and maybe a couple of joins, avoid Hibernate like the plague.
2) Conversely, you'll be quite happy with Spring. Aside from some wierdness in SpringMVC, almost all of Spring enables you to do whatever you want. Provided you've planned ahead so that you're spring config files don't get out of hand (this should be fairly easy considering that you've already built your app once...you should be able to get a fairly close estimate of all your beans up front, so make sure you break it down into spring beans config files that have between 10 and 30 beans apiece (numbers to be a secondary concern to grouping like functionality), and you'll be fine.
3) If you have any need for single sign-on or complex authorization schemes, you'll probably have run into the pain that is Acegi and have navigated its complex array of implementable interfaces to the point where it is working well for you. Relax, and feel good that you've gotten it working and there aren't likely to be any holes in it that need fixing. To be clear, I'm not demeaning Acegi...it's a great product. It's just that the interface is quite confusing and has documentation that is, to be kind, only for advanced users.
4) You will (I hope) have a large battery of unit tests for all your code. Spring's IoC capabilities ensure that you'll almost always be able to test each piece of your code in isolation. Use this to your advantage. Write tests until you believe you've covered everything, then write some more. Use code coverate tools like Emma, Cobertura or Clover and make sure that you've tested everything (well...you can probably leave getters and setters untested).
All this will leave you far more agile than you are now. You'll be able to make changes quickly since you can re-run all of your tests to ensure that you haven't broken anything. You'll have developed a great appreciation for interfaces and what programming towards them can allow you to accomplish when it comes to pluggability of components.
But will you be better off than you would if you had continued on your current path? That isn't a question I can answer. I can't determine whether your employees would be able to adapt from a C++ environment to a Java environment. If you simply write C++ code in Java, your code base will still be ugly. I also can't answer whether it would be less effort to re-architect your product in C++ and bring with you the code that does work well. These are all questions you have to answer for yourself. Do not let management be sweet talked into dictating your technical path. There is no answer that is right all the time. Make your decision based on how painful development is now and how painful its likely to be given each path you're considering taking. Make your decision personally (or as a team, with your fellow developers), make it clear to management what your decision is and if they mandate any other path, start looking for a new employer.
A co-worker of mine is fond of the saying "There is no magic in programming" (though Spring sometimes comes pretty damn close). And it's true. A well-architected solution in almost any language will be better than a poorly architected solution. Spend your time and money on doing things right no matter which tools you choose.
"Don't blame me, I voted for Kodos!"
It is a move to outsource all 5 of your jobs.
Find a new job.
I am very small, utmostly microscopic.
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 time, and these have nothing to do with portability. There are also reasons why it will cost you a huge amount of time. Some say that it'll take years just to break even -- well, assuming you do break even, it's pure profit after that.
However, there really isn't enough information here to make an informed suggestion. Many are assuming you're writing web apps, but you don't even say what kind of application you're doing. Of those 6 or so years of development, how much of that code actually gets re-used these days -- are these old apps you must still support, or frameworks/libraries you have to use every day? Are they mostly stable (minus the bugs), or are they under constant development? Will you be doing anything to help clean up your process other than switching languages?
Anyway, you're in the best position possible to explain to your managers how much switching languages will cost, and whether there will really be an advantage. If you want Slashdot to do it for you in a meaningful way, you'll probably have to reveal more of who you are and what you do than your boss will allow.
Don't thank God, thank a doctor!
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?
Your team is good at C++. The offshore team is good at java. Why should your team adjust to the offshore team's skillset? Why not just hire a better offshore team? One that knows C++? Oh, and I'd be pissed that anything is being offshored to begin with. This means, of course, that your IT director think that you are a bunch of incompetents.
On the point of Java vs C++, If you know C++ you're going to be able to put together a better design than if you hop languages and try to figure things out as you go along. Some other comments have referred to getting a consultant onboard to help with your architecture/high-level design. If you're going to go the Java route, this is something that will reduce the risk of having to redesign/re-write what you're re-writing now two years from know when you've learned enough to realize that you didn't do it right the first time around.
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.
-I like my women like I like my tea: green-
This way, you don't make a possibly insane transition based on "some Indian guys in India"'s idea (How well do they know your team, code, and history?), and your FTEs get hands on experience with Java. If there are advantages, they will become apparent to you and your fellows and you are the people that need to see and utilize those advantages.
What I remember most from transitioning away from C++ was that I could develop things faster because they syntax was simpler and code contained fewer errors because of the lack of pointers and need for handling garbage collection. Another potential advantage of Java is that it is the "bandwagon" at the moment and therefore many eyes (e.g. products) are out there to make necessary business tasks easier in Java.
The real value of Java that the 3rd party is alluding to is in the interoperability of Java with other components (you listed a few). If you are using some middleware or other software that meets an important business requirement that you have and that middleware plays nicer with Java, then you might have real value there. But even if that were the case, you could always use JNI or something like that to wrapper the quality pieces that you have written in C++ or whatever.
Anyway. Bottom line is you and your fellow FTEs need to have direct experience with the advantages and disadvantages, and the best way to get that is to selectively migrate (refactor, redesign, replace, etc.) the more troublesome components with Java code and see if that is better (faster to develop, fewer bugs, etc.) than what you could do in C++.
Yes! There are tools for both TDD and Refactoring for C++. For that matter, there are TDD frameworks for embedded C code too. However, the refactoring tools for Java are ahead of the support for C++. If you actually make use of them, they can improve your productivity. Switching languages because of some blind belief that programmers using a particular language are more productive is a waste of time. Switching to take advantage of tools and libraries that are better than the ones available for your old language can help you.
For the record, I've used C++ for years. I still use C for embedded code. I love Perl. I've used a bunch of other languages as well. I learned Java several years ago because it was the language of choice for examples in the early work on refactoring. Design Patterns were about raising the level of abstraction on chunks of code. Refactoring is about raising the level of abstraction on changes to code.
The net will not be what we demand, but what we make it. Build it well.
The choice of language really has nothing to do with FDA approval, or at least not much. I have been through an FDA approval of a software driven device from the ground up. What matters is your development process, not your implementation language. It seems that no one in your organization really understands what they are doing vis a vis FDA approval. Rewriting the code in java may or may or may not be helpful to your end goal but it is not the real issue. Dump the offshore consultants, who probably know nothing of the FDA approval process, and hire some consultants who do. You need people who understand the process and who understand the development of safety critical software.
It sounds like upper management is leaning on your IT director to produce something and he's waving his arms around like a maniac.
It's not a pretty situation. Some needs to calm him down and talk some sense into him.
As has been state elsewhere, suddenly switching to Java will buy the company nothing but lost time, heartache (or more heartache if he and or the comany are already under pressure), and money going to off shore services, potentilaly for a long time. It will acomplish absolutely nothing positive in less than about 2 years.
The guy needs to sit down and work out a serious budget before he drags the company under. Alternatively, you go over his head and explain to his boss that the guy has just gone over board and is going to drive the company into the mud. Explain the bad news and pray that you get his job (or not) after they fire him.
The dude didn't ask, "Should we switch to Java?" It may well be a bad decision, but it's not his to make.
I've never seen a project move from C++ to Java ever succeed. I've seen plenty of disasters. If you want any chance at success, leave behind everything that is C++ and consider this a new project from the ground up. Even then, you chances of success are moot because I've also never seen a successful Java project.
You know, it entirely depends on your product you're producing. If you're rewriting the Java EE API to get things done in C++ you're definitely gaining a lot from Java. If your needs do not overlap well with the proven Java technologies out there then chances are C++ and Java are about the same.
It's all about the APIs. Are you doing stuff that screams J2EE? If so, maybe the vast majority of your code is obsolete and replacable with superior open source libraries. Or are you rewriting your VB fat client into a swing app? In which case you're probably just wasting your time.
And just a remark, why does a 5 person team have an IT head? Isn't he just your manager? If your boss didn't extend the courtesy of asking for your opinion to solve this apparently severe problem I would consider that a rotten work environment. But conversely it sounds like your "C++ experts" may not be as expert as it sounds if they could not immediately recognize from experience the folly of switching languages so late in the game.
The above poster's comment is probably the most important in this thread. Unit testing is helpful no matter what you do or where or in what language. Some frameworks and tools make it easier than others. But an approach that involves a lot of rigorous unit tests is going to make your development go much faster and more surely. It's a good idea no matter what tools you use.
In fact, regardless of whether or not you make the ill-advised leap from C++ to Java, a rigorous set of unit tests of your system will help you. You should write them even if you're just going to be re-architecting your existing C++ code.
As for changing programming languages...
I despise Java. I think booting a whole OS just to run a program is silly. I think the fact that people invent all kinds of new ways to make sure they can start new Java things from an existing VM so they don't have to boot the OS (otherwise known as a VM) again in order to run a new program is amusing and telling. Java is a 'joiner' virus technology that encourages you to do everything in Java and makes it really hard not to.
I was a big Java fan when it first came out. Experience has taught me how icky it is.
People tell you Java is more productive because you don't have pointer problems or the complex and arcane syntax of C++. These claims are vastly overblown. In truth, the language is nearly as verbose as COBOL, and for as little reason. It lacks the expressive power of C++, Python, Ruby, Lisp or Perl, and that will lead to you writing a lot of stupid vaguely repetitive code for no purpose than to provide thunking layers in the rather incapable and inexpressive type system. The only thing Java got right was packages, and Python and Perl (and possibly Ruby) do them just as well.
Need a Python, C++, Unix, Linux develop
Not even drugs! I bet that is a new one to you. If anyone claims their product is FDA approved (software or otherwise) that is false advertising and illegal.
My immediate and knee-jerk solution to your problem is DON'T switch to Java. I forget who I stole the quote from, but:
"Saying Java is nice because it works on all OS's is like saying that anal sex is nice because it works on all genders."
Maybe it's just my bias, but it seems like all Java developers are stuck in a rut, churning out applications that look like a ten year old HTML form, and feel like a Cobol terminal. I don't know if it's because of the libraries they use, or that they don't drink enough Pepsi, but something is just WRONG.
One thing I whole-heartedly recommend is to look into functional languages, if you can afford the performance hit. When it comes to large business-intelligence applications, functional will help you write safer, more concise code, keeping your attention focused on the actual program logic rather than the implementation details. Something like "Clean" or OCaml comes to mind. If you're really uptight, you could write the backend with functional code, then a thin interface in some conventional language, or even a RAD tool like VB.Net or Delphi. Just stay the hell away from Java, for everyone's sake.
-Billco, Fnarg.com
The real question is: what do we gain from moving to Java? ... lets say 25%.
If roughly 30% of the time you spend writing C++ code is fiddeling with memory management, then you probably can save those 30%, or more precisely, a great part of it
Additionally, will one language or another really help us to get FDA approval?
I assume this is similar to a kind of CMM level 2 or CMM level 3 certification. Certainly not! First of all, the language you use has nothing to do with the qualitiy of your code. Second: the language you use has not much to do with the amount of time you need to meet/implement requirements.
We have always used C++ [...] and we have more than 6 years of code, applications and libraries developed. and our existing architecture is difficult to manage for a group of our relatively small size (5 FTEs)
So you have roughly 30 man years code.
To replace all this with Java, might be how much faster? 100%? Lets assume you can indeed achieve an 100% speed up by just switching to Java. Then you still need 3 years to redevelop all that code. That does not count bug fixes, new features or anything.
Bottom line:
Your problem is lack of architecture, you likely never aimed for maintaneability, enhanceablility etc. Probably you even have a deep lack of test cases. You should look in building "components" today that is called SOA, this concerns architecture.
Try to look into test driven development, design for testability is also a design for maintainability. The design afflicts architecture, the tests and the way how you manage it afflicts the process.
Probably read about SCRUM (basic concepts are learnable in 2 hours), this also is about how to come from requirements to implementations, easy, fast, reliable. This affects your software process as well.
After all when you want a certification, its a certification of your abilities -> and that is your process. And not your code.
Regards,
angel'o'sphere
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
I don't know what you guys are doing, and I'm not an expert, but from what I know so far Java and such languages are good if you have to work with a large number of cheap, mediocre developers. If, on the other hand, you're a small group of competent, experienced professionals then you may as well use a language that's better suited for a small group of competent, experienced professionals that would give you the additional advantages of fast development and more maintainable code. FDA sounds like you're doing something of perhaps medical relevance, maybe interacting with medical devices or such, have you considered a language like forth? Forth has a good niche for such technical uses. I don't know what you need, but my point is that if you're going to make a language switch then at least switch to something that would make a difference, not Java.
I was hired to work for 6 months in France in C++ in a big system in the gorgeous Cote D'Azur. I went there and I was finished with all my bugs and features in 3 months, since I already had 7 years of experience in C++.
My coworkers had been working in the system for 8 years, extending and perfecting it, and already it was a huge system.
When I arrived management decided to give a try to reimplement the system in Java and maintain the system in C++, so that they could offer both systems to their clients. We had 6 month to reimplement the system in Java and I was ROTFL because it couldn't possibly be done, my coworkers stared at me in disbelief. (Or mistrust?)
In the Cote D'Azur people work 35 hours a week and they are so laid back... After the 6 months, the system was working, with a few notorious subtle bugs, but working! From that moment I never programmed in C++ anymore, since I realized most companies would switch, and those companies that decided not to switch or to switch late, would disappear.
Java is ready to create database engines, device drivers, application servers and whole operating systems.
I work for a company who produces software for medical devices, who shall remain nameless. To answer your specific question, the FDA could care less what language you're using. They care that you have a well-defined process for developing that software, that you have documented the heck out of that process and how you are following it, that you have properly validated that the software does what you say it does, and that it is safe and reliable. They aren't much for specifics, for example requiring a CMM level or whatever.
Exactly what they're going to want from you will depend a lot on things you haven't shared here, like what this software is being used for. Software that is part of therapy delivery (radiation treatment machines) is different from software that is used in diagnosis (blood sugar meter), which is different from software that is used in say, billing and medical records, which is different from software that is used in the process of developing other medical devices. I'm going to guess that you're in one of those last two categories.
If the current state of things is as bad as you seem to imply, starting from scratch with a new architecture may be a good idea, but that doesn't necessarily mean you need to switch languages. I'm going to agree with others here that it is either a) a bad idea or b) an excuse to outsource the whole thing and that you should polish up your resume. What your company really needs is an expert in the FDA approval process and what you need to do to meet their needs, not any generic software consulting firm who's just trying to get your business for themselves.
Oddly enough, that also explains how all the English Bible translations came about.
I was the lead developer on a team that converted from VB to Java. For us, it made sense, as we wanted to web-enable our app and VB's web support at that time (VB5, back around the turn of the century) was too simplistic for us. It was a big challenge, and lots of hassle, but we got it done and it's been a pretty successful app in its space.
I can think of several reasons why your IT manager wants to make this change, and none of them are good. For us, it made send to make the move to the OOP Web world, because that's where we wanted to take our software. I really don't see the upside moving from C++ to Java. It sounds like offshore Java developers are cheaper, and that's the big incentive.
Just junk food for thought...
Problem: I have a C++ buggy software and I want to move it to a bug free language
So: No such thing as a bug free language.
My Opinion, before attempting something risky, do a risk analysis with some grounds, forget guesswork it will only make matters worse.
New Problem: I have a C++ buggy software and I want to make it bug free
Step one: - Rearquitect from scratch thinking in C++
Step one.point.five: - Rearquitect from scratch thinking in Java
Step two: - Take a snapshot of the current arquitecture and its problems
Step three: - Merger the arquitechtures taking the best of the current and new ones
Step four: - Evaluate which merger is most likely to solve the existing problems and manage to grow
Step five: Do the changes in cycles and steps, and if neccesary switch language, use learned lessons from the old code.
Step six: Evaluate, next change
Step seven: Incremental delivery = incremental phase off the old sw
Java is not platform independent. Java is ridiculously hard on system resources. Java is a security liability.
When the JRE changes your applications will stop working. Your clients will scream bloody murder. (not to mention the FDA)
The JRE cannot be validated under 21 CFR part 11 regulations, C++ code can. The FDA will approve of applications written in C++ much more easily than those written in the terribly unreliable java. (...client installs a new JRE and your application is automatically no longer validated...)
Java is pure evil.
C++ is standard for a reason. I have C applications that are over ten years old that still run on multiple platforms. Show me a java application that can do that.
I think your IT director will soon find himself out of a job. He should tell the school that he freshly graduated from to get off that java train before the inevitable wreck occurs.
Please excuse the shameless piece of self-promotion that follows. One of the really cool things about Java is RetroVue - a "bidirectional debugger" that allows the programmer to step their program backwards, or rewind to any point in the program's execution history. We've just released UndoDB - a bidirectional debugger for C/C++ (and other compiled languages). Suddenly those horrible C/C++ bugs aren't so daunting :-)
No no no...
Java != JavaScript
It's not Perl, Python, or Ruby either... so SWIG does not apply here. SWIG is for binding C++ code to interpreted *scripting* languages.
SWIG is nice for cranking out some quick tools, but no way should you consider it an alternative to a ground-up re-write.
HA heeee hahhaa
I don't think so.
If your IT director is clueless enough to make a move like this without (obviously) asking advice from his developers first, the handwriting is on the wall: your company has had it, and their form of suicide includes expending their remaining funds on consultants. Start looking for a new job TODAY. By all means collect a paycheck while you're looking (you can also acquire some Java experience to sell to the next company) but don't ride the sinking ship too long. It's depressing.
Python might work ok, but for C++ developers on Windows, C# would work much better. It's a more productive language than C++ and it allows you much more easily intergrate existing C++ code than Java and probably Python. I personally prefer Java, but C# is so similar and it's easier to call existing C++ code on Windows. If you don't portable code, I think C# is the definate answer.
Although, if you go with Java, you can still interface with existing C++ code, so you don't have to rewrite everything.
:-]
Java fast development is marketing. You can achieve the same results in C++ undoubtely.
Although, as someone up hinted, Python would be cool. Python integration with C++ is great.
And better, is trendy.
I intend to live forever. So far, so good.
You wrote there that your IT manager decided to convert everything to Java to speed up development times, so, why don't you ask him how he thinks this is going to happen? What are the advantages and tools that Java (i'm sure it does) has that makes it better than C++ to speed up develepment? Does this sound like something you would ask your boss? I really think so.
Building for a shallow grave Must be something else we say Somehow to defend this place
The question is, is the system radically misdesigned, or has it just accumulated some cruft? If it's radically misdesigned because the requirements have changed so many times over the years, then a ground-up redesign, with the benefit of reams of documentation of what the real requirements and specifications are *might* be a good idea.
But if the system just happens to use some older technologies or has code that appears messy or spaghetti-ish, then I would strongly suggest refactoring over rewriting. If the capabilities of the current system are limited in some way, make sure you understand exactly in which way and why they are limited so you don't waste time rebuilding only to find that those limitations are fundamental to some combination of business requirements, rather than incidental to the engineering decisions.
If the scope and breadth of what a system is supposed to do has changed drastically and you can demonstrably prove to a room full of developers that the architecture is to blame for your current problems, then the bad design/architecture flag could legitimately be thrown. Understand that you will be throwing away the baby with the bathwater when you rewrite. And don't try rewriting using tools your team isn't familiar with - that's just asking for disaster.
I have been in one situation where a poorly specified system was replaced about 85-90% with a ground-up rewritten system (we reused a few components), where the original took a team of 10 people over 2 years to write and the replacement was done in 2 months by 2 people. This was accomplished because the original system was supposed to do everything for everybody and turned into a totally flexible architecture and infrastructure for enterprise apps in Java and basically became a slow bloated mess. The replacement just stuck to a well-defined set of requirements and did its job well, and was between 20 and 50 times faster than the original.
However, I have also seen situations where an otherwise good, working system that was complex and underdocumented (but where the complexity was necessary) was thrown away for political reasons, and we ended up wasting 3 months rebuilding the system from scratch ("porting" it from C++ to Java with a JNI/C++ core). The new system worked well, and was somewhat more flexible, but since the original system had been revised to reflect dozens of additional rules of business logic and corner cases that were never documented anywhere, replicating it all to the actual needs of this customer would have been a prohibitively complicated process.
I think it's a good idea to switch from C++ to Java (or C#) if:
.NET route.
/george
if you are getting bogged down in memory leaks,
if stepping through smart pointers makes debugging complicated,
if you have 20-minute compile times
if some trivial functionality (say, de-serialization of XML, or web service calls)
requires pages of C++ code
If you go ahead and start switching, try to do the following:
A) keep as much of existing C++ code, and call into via JNI,
B) use jazillian http://jazillian.com/ to translate existing code to Java,
C) use my web site http://code2code.net/ to translate to C# or VB, if you want the
Good luck, switching will be an enormous project!