Moving a Development Team from C++ to Java? 204
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."
Here's an idea (Score:2, Funny)
Re:Here's an idea (Score:2)
Logic check (Score:5, Insightful)
Re:Logic check (Score:5, Interesting)
Switching suddenly to Java, though, is a bad idea if you don't already have the expertise.
Re:Logic check (Score:5, Informative)
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.
Re:Logic check (Score:2)
You need to review more. SWIG defines its own C-like IDL. It's not terribly good, but neither does it require the concept of interfaces or a repository of the same. It's an FFI generator, not an ORB My only beef with swig is that the FFI it actually generates is kind of grotesque (it depends on the language I suppose). But it sure is easy.
CORBA is a god damned monstrosity. I had a big paragraph explaini
c++ == java (Score:2)
Re:Logic check (Score:2, Insightful)
Why not find some consultants who like C++?
Re:Logic check (Score:2)
Resume (Score:5, Insightful)
In either case my advice to you is the same: Polish up your resume.
-Peter
Re:Resume (Score:3, Informative)
Re:Resume (Score:5, Insightful)
1) consulting company hires a lot of junior/intermediate coders for his company that only learned Java or C#. C++ skills and experience avoided in favor of knowing the latest
2) an expensive consultant comes in to analyze an imperfect system
3) this person makes all kinds of suggestions, says nice things about management, says "use lots of UML"
4) says his devs are really good C++
5) brings in his coders to help fix bugs, charges lots of money for diagrams never used
6) consultant coders fail at fixing bugs, claim that code base is too fubar'ed to maintain
7) convince management to "port" code to Java/C#.
8) consultant coders soon have more knowledge of the system than the old devs because knowledge isn't shared properly (no more UML)
9) management becomes too afraid to let go consultant coders because they know more about the system than the devs (despite costing atleast twice as much)
I can't count how many times I've seen this because the city I used to live in had atleast 2 massive consulting companies that made this their business model. I imagine it's even worse when it goes off shore to India because all the knowledge is looked away in peoples' minds thousands of miles away. Such a huge mistake for management to lose all they paid for for nothing.
Oz
Re:Resume (Score:3, Informative)
p.s. An hour ago as I was walking to lunch, I overheard one of upper management on his cell phone saying, "they're all ol
Don't (Score:5, Insightful)
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.
Re:Don't (Score:2)
You'll still lose initial productivity from learning the new language, but it won't cost a complete code library if that library doesn't exist. And if the next product happens to be similar enough to a previous one that you could rework the old one easily, you could still use C++ on it, since the developers are experienced in both.
Re:Don't (Score:2)
Socket s=new Socket(IP_ADDRESS, PORT);
File I/O is simply
FileInput(Output)St
Re:Don't (Score:2)
No, because if you were ...
As for java, what I've found (from talking to c/c++ developers)
... you would know if you had talked to C programmers or C++ programmers. They are not the same. Good C is as dissimilar to good C++ as good Java code is.
Re:Don't (Score:2)
Re:Don't (Score:4, Insightful)
Actually, he said that it's *not* "working" per se. He already stated that it's difficult to manage, and (I presume) full of bugs. This is a common issue for companies, especially if the original developers didn't fully understand the dynamics of the concept when they first coded it. (I believe the military saying is, "No plan survives contact with the enemy.")
In those cases it can make a lot of sense to do a ground up redesign and rewrite. You can still use the original code as a reference, as well as grab useful code snippets. But the key is to shake out all the cruft that has built up in the system. Without this sort of step, your development staff will simply need to grow and grow. Before you know it, you'll have 200+ programmers, and your company will look like SAP's development floor.
As for moving to Java, that's difficult to say without knowing their specific problem. If they, for example, have their own Web Application Framework, they might save huge amounts of development time and money by moving to a more standard platform. If there's nothing they can pare down, then they're probably wasting their time. It's hard to say without knowing more.
Re:Don't (Score:2, Insightful)
Re:Don't (Score:2)
Not true - some will be fixes for fixes that were poorly implemented (perhaps in a rush to hit a deadline, then forgotten about), some of the cruft will be for features that are no longer used (or perhaps even available, if other parts of the app no longer use the code at all), and so on.
Re:Don't (Score:2, Insightful)
>You have working code in C++.
Actually, he said that it's *not* "working" per se.
It's working a hell of a lot better than the java code that hasn't been written yet.
Re:Don't (Score:2, Insightful)
No, it doesn't. While you're doing the rewrite, you have no product to sell, unless you maintain the old version in parallel. After the redesign phase, you'll find that the new version is buggy and incomplete, after all it's a new programm. When it is finally ready for premiere, you'll find that meanwhile the competition has driven you out of the market and that you developed a bad case of second system effect. The new syst
Re:Don't (Score:2)
Re:Don't (Score:2)
Re:Don't (Score:5, Insightful)
There are two kinds of Software Development Processes: 1) Manager centric and 2) Developer centric.
All the stuff we do at our company for Sarbanes-Oxley is classic Manager Centric SDP. It's about tracking the track every inch of code, who changed what, who had business authorization to put it in. Developers loose productivity over this, it's tedious, it doesn't improve quality, it doesn't prevent errors, but it does keep the auditors happy which does keep management happy.
The SDP's that benefits developers are things like Agile Programming. Among the cornerstones of Agile are Test Driven Development and frequent iterations. These are the processes that focus on preventing bugs in the first place.
I once worked for A Company [slashdot.org] that wanted all of #1 and none of #2. They got what the deserved. You need a measure of both with a dash of flexibility.
Software development processes have almost nothing to do with the choice of language. That said, it's been my observation that there are lots of really smart people working on Java to improve the development process. Eclipse is amazing with code completion, on-the-fly error tracking and refactoring. JUnit (comes with eclipse) is a benchmark Test Driven Development system. If you must switch languages, invest in the training to make those tools productive!
Hypothetical question: (Score:2)
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*.
Re:Don't (Score:2)
Those two sentences are polor opposites. The second one is correct, the first one is bunk. It's completely rediculous to say "never rewrite working code" -- by this logic all apps last forever regardless of operations cost and opportunity cost. In this world, all apps would still be Cobol and Fortran.
To the original question -- yes you can rewrite your app. There are three ways to do it
A) code the whole thing from scratch in p
What is your current application environment? (Score:2, Insightful)
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.
Re:What is your current application environment? (Score:3, Informative)
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.
Re:What is your current application environment? (Score:5, Informative)
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".
Re:What is your current application environment? (Score:2)
With a large C++ code base, you're much better off looking at languages like Ruby and Python that have simple and stable C/C++ interfaces. Don't be fooled by the fact that Java has JNI. It's not easy to use, and will usually mak
Re:What is your current application environment? (Score:2)
Dude... if we all had the capability to tell all our bad managers to jump off a bridge and replace them with good managers, most of us would probably be writing code instead of bitching on slashdot!
General Thoughts (Score:5, Insightful)
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.
Don't re-write anything! (Score:3, Insightful)
Re-writing your codebase is *usually* a one-way trip to bankruptcy. If forced to change languages, always dicey, you might want to try the following:
1. Mine the code so you have documented interfaces
2. Create wrappers where neccessary to facilitate access by *new* code
3. Write new functionality/apps in the new language
4. As your apps force change of the wrapped-code, evaluate the cost-effectiveness of a re-write of that piece only
And, most-importantly, use Test-Driven Development; you must mitigate the huge risk that your management has mandated.
Good Luck, you have your work cut-out for you.
Thanks!!
Joseph Bacanskas [|]
--- I use Smalltalk. My amp goes to eleven.
A bit tangential (Score:5, Insightful)
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.
Re:A bit tangential (Score:2)
I would recommend buying six copies of "Working Effectively with Legacy Code", by Michael Fe [amazon.com]
lobotomy (Score:3, Funny)
your best solution (Score:2)
Your best solution, if you can find people with enough sway would be looking into getting your IT Exec fired. Really.
Oh my. (Score:5, Insightful)
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.
Re:Oh my. (Score:2)
Exactly what I was going to suggest. Throwing everything out is just complete insanity. If he can't talk them into fixing their
Re:Oh my. (Score:4, Interesting)
Let me be the lone voice to call bullshit. Story poster is obviously inexperienced and trying to be diplomatic (if for no other reason than pride). What we have here is almost certainly a big steaming pile of crap.
Their development has slowed to the point where they are going to ditch the whole thing. It's too late to save this code. Putting a nice interface on it will just exacerbate the problem because anything you try to do will either expose the underlying crap and bugs (ie mfc,
Just take a look at Windows for an example of what happens when you try to incrementally evolve something like this: 6 years with basically no innovation because updating anything is so slow and difficult. Meanwhile both Apple and Linux have made leaps and bounds, Apple by ditching their massive investment in OS 9 and Linux by shunning backwards compatibility. Linux doesn't have binary kernel drivers because mapping better stuff to old mistakes is even harder than keeping a zillion drivers up-to-date. I'm always getting "kernel too old" messages trying to make binaries that run everywhere. It sucks, but imho it's a huge reason why Linux is advancing instead of stagnating. The only reason Microsoft is still around is because of lock-in; if poster's company doesn't have a lock on the market and given their codebase they will fail if taking the incremental approach.
I think it's painfully obvious that whatever it is they are doing (I'm guessing some database + COBRA junk) is something that shouldn't be written in C++ in the first place. For example, poster does not mention performance at all. C++ *can* be a lot faster than Java at some things and is a pretty good choice for those (action games for instance), but if you are not even slightly concerned about it then that's a pretty big tell that using C++ for it is a huge mistake. Ideally they would write most of their code in Python or Ruby or similar, but it sounds like this could be out because of client issues. So Java or C# is probably the only realistic language to code in.
Re:Oh my. (Score:2)
With respect, you've mistaken "incremental" for "maintaining backwards compatibility at all costs". They're not the same at all, and I'd never suggest trying to maintain any sort of backwards compatibility in this context.
Your post makes complete sense if you make that substitution.
I routinely make increme
Re:Oh my. (Score:2)
Process != Language (Score:5, Insightful)
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).
Re:Process != Language (Score:2)
Re:Process != Language (Score:2)
These processes are all about mega-reams of documentation, proof that you've done all kinds of analysis, and audits of all of your process.
Thank you for saying this... (Score:2)
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.
Update the resume (Score:2)
Unfortunately, you're solving the wrong problem (Score:2)
If you are asking this question on Slashdot (Score:2)
Also: "Things You Should Never Do, Part I" (Score:2)
People have varying opinions on his work, but in this situation, if you can't answer his objects you should not rewrite.
Re:Also: "Things You Should Never Do, Part I" (Score:2)
Agreed; but what should you do instead?
A good answer can be found here [slashdot.org] and particularly here [slashdot.org]: rewrite it a bit at a time, adding unit tests as you write or rewrite code. Like the "rewrite from scratch" plan, you'll spend a lot of time working on functionality you already have. Unlike that plan, you'll h
Re:Also: "Things You Should Never Do, Part I" (Score:2)
How are you validating? (Score:5, Informative)
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:How are you validating? (Score:2)
There's a problem with this: some Java code (including Sun's JVM class libraries) throws excep
Comment removed (Score:3, Interesting)
Just because you fail to understand it (Score:2, Interesting)
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.).
Re:Take it from a Java guy new to J2EE (Score:2, Funny)
You mean something like, say... Spring and Hibernate? What a good idea! Why didn't he think of that??
Why change? (Score:3, Interesting)
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.
business cost of finding more developers (Score:3, Insightful)
Finding employees.
Not because of "oh, I'm too good for C++" jerks. Just the simple fact that most recent development has been in Java, not C++. (C is also increasingly hard to find.) That's important when you're looking to expand your staff or replace departures -- it's harder to find people who are current in C++, and harder still to find good people who stayed with C++ instead of migrating to Java.
Same thing with using standard packages like Spring and Hibernate. They may not be the best technology, but they're almost always good enough and you can find good people who know how to use them.
As for outsourcing... huge mistake with a project this small. Besides the nightmare of managing a small team in a distant timezone, development teams this small need a lot of soft skills specific to the deployed environment. You could get around that with a rock solid spec, but I doubt that's the case here.
Which "C++"? (Score:3, Insightful)
Microsoft likes to present a lot of its own extensions as "C++" features. In particular, they like to present C++/CLI (a.k.a "CLI++") keywords as "C++" keywords.
And then there are the managed extensions. (But even Microsoft has deprecated those in favor of CLI++.)
Going back even further, there's MSVC 6. Lots of people still use it, but it's just too old for anyone to expect it to be close to Standard compliance.
What compilers do you work with? Do you set compiler options to disable extensions and run in a "strict" standard-conforming mode? Do you use more than one compiler?
Do you make judicious use of the STL? Do you use any part of Boost? (If not, you should seriously consider taking some time to learn about these best-of-breed libraries that are available *for free* and for which support is available from multiple consulting firms.)
Did you give up trying either of those libraries before trying out STLFilt? (If so, go play with it. You'll probably want to give generic programming a second try.)
Have you and your team read any of the *good* C++ books? E.g.:
http://tinyurl.com/puhjb [tinyurl.com]
http://tinyurl.com/ru625 [tinyurl.com]
http://tinyurl.com/mrdgo [tinyurl.com]
http://tinyurl.com/ounbe [tinyurl.com]
Have you invested in static analysis tools? (E.g., PC-Lint, etc.)
Most of the C++ programmers who cut their teeth on Windows learned a watered-down version of the language by way of the Microsoft libraries (e.g., MFC, which should *not* be mistaken for a model of modern C++ interface design). If that describes most of the people on your team, you should seriously consider migrating from "kinda-C++" to Standard C++.
Re:Which "C++"? (Score:2)
Re:Which "C++"? (Score:2)
where
x ? : y
is equivalent to
x ? x : y
Handy, yes. Standard, no.
I think Joel says it best... (Score:5, Interesting)
Re:I think Joel says it best... (Score:2)
I heartily agree with an earlier poster who suggested SWIG. Keep the C++ codebase and maybe refactor the bits that really need it but do all new development in a scripting language like Python or Ruby, using SWIG to wrap the existi
Framework is the way to go (Score:3, Interesting)
In case your future environment has to produce binary applications you are IMHO best of if you switch to the wxWidgets framework (http://www.wxwidgets.org/ [wxwidgets.org]). Since you already have C++ knowledge and wxWidgets is quite easy for Windows developer it shouldn't be a big problem to become familiar. I'm quite sure with wxWidgets you are equally efficient as with any Java framework but don't have the disavantages of Java.
You can use wxWidgets regardless of any platform consideration, if you just want to stick to Windows or to Linux or whatever, it doesn't matter. But if you also follow the guidelines of wyoGuide (http://wyoguide.sf.net/ [sf.net]) you can move your code anytime to another supported platform and just release it. As long as you just use the features of wxWidgets there's no need to recode anything on other platforms ever.
If you want to see how well this approach works try out my samples (wyoEditor http://freshmeat.net/projects/wyoeditor/ [freshmeat.net], wyoFiler http://freshmeat.net/projects/wyoeditor/ [freshmeat.net]) or look into Audacity. Or look out for the commercial application Xara. There's probably no alternatives for cross-platform development as if you do single-platform development as with wxWidgets/wyoGuide. And keep in mind, no Java disadvantages.
O. Wyss
Re:Framework is the way to go (Score:2)
Re:Framework is the way to go (Score:2)
I guess you evaluated both toolkits but you have written real code only with QT. In my case I evaluated both and I have written real code only with wxWidgets, so take my bias into account.
I agree that MFC message maps are ugly, but they are not obligatory, in fact I use none of them in my new wxCode. I have code like this in the constructors (or wherever is
Experienced or not? That's the question. (Score:2)
Re:Experienced or not? That's the question. (Score:2)
If so, they haven't adapted to new C++ practices, and there's no way they'll adapt to Java. They'll write terrible Java and be miserable.
If not, then they'll adapt to Java pretty quickly. Some of their C++ techniques won't be possible in Java, but they'll figure out the strengths of Java in a few months and start writing good Java code.
Oddly enough, the more modern C++ elements you see in your code
Bad idea (Score:2)
You hit the nail on the head here. In fact you'd probably be worse off since you've mostly got to learn Java etc first, and a management willing to throw six years of code down the tube is probably not going to give you time to do silly things like learning new languages. You'd be better off rewriting sections
A couple of advices (Score:3, Informative)
- 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:A couple of advices (Score:2)
Allow a year (Score:2)
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++,
What a great solution (Score:2)
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.
Been there, done that... (Score:2)
A complete waste. Tens of thousands of man-hours and millions later, only miniscule parts were rewritten, albeit without the possibility to interoperate with the legacy code.
Just like it sounds from you, this is a internally triggered initiative, not something that came from sales or marketing. Chances are noone want
Have you learned from your mistakes ... (Score:3, Interesting)
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.
Been there done that (Score:3, Interesting)
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.
Re:Been there done that (Score:2)
Funny you mentioned CORBA, we used it extensively in the C++ version.
For what it's worth, another word of wisdom. Our product had a critical application install and monitoring GUI console that was written initially by Windows people a
stay on target! (Score:4, Insightful)
Main sticking points (since it's been years since I've last used Java, someone will probably have to correct this):
* lack of templates
* lack of double inheritence
* everything is a pointer (both good and bad)
* you have to be aware of garbage collector for optimizations
* more verbose: both libraries are verbose in nature, and syntax can be a bit more verbose
I think most issues people have with C++ can be solved with the right library. Want garbage collection, use a garbage collection library. Or use the STL (check out boost too!), which has just about all the container classes you could possibly want or need. Roguewave has also always provided a good amount of commercial quality C++ libraries. And don't forget QT. Way way way better than any interface provided by Java. I'm not a big fan of Swing (or AWT) at all.
If you want to talk in terms of productivity, one method of sticking with C++ (although it sounds maybe the decision was made already) is to use a hybrid (come on, everyone else is doing it!). I use the boost::python library a whole lot (though there is SWIG, Weave and Pyrex as well). All my optimized code stays in C++, and everything else is in Python. I know Python isn't the fastest language in the world, but I don't have to worry about that. If I need to read in a configuration file, write a quick XML parser, etc. -- easily done in Python.
Python is far from a perfect language -- I get bitten by the whitespace issue quite a bit (yes, if you stick with one editor it's fine, but you might always have that luxary, and some editors insist on using tabs). It is definitely one of the more complete interpreted languages with a huge amount of libraries written for it. Also boost::python, like all template library will slow your compile down by a lot. On the other hand, you compile your code less, since most of your work is in Python. And Python takes 1 day to learn.
Dear god, no. (Score:3, Interesting)
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.
Re:Dear god, no. (Score:2)
Ask your offshore development outfit how many C++ developers they have. And how many Java developers. I'll happily bet you $100 that they have at most a couple of C++ devs, and that this is the reason for their "recommendation". Given that they won't have the expertise on hand to understand the logic of your existing system what are the odds they'll do a good job of the rewrite?
Re:Dear god, no. (Score:2)
I've seen stuff like this before. Poorly architected system gets rewritten in another programming language. This is a no-fault, blameless way of throwing out the old, useless system and replacing it with something that is, hopefully, better.
If you claim that the old system is too crufty for a reasonable maintenance cycle, then someone might get their feelings hurt and strive to defend the old code. A language change is more politically acceptible because C++ can't defend itself from being bashed.
The [transitionchoices.com]
Changing focus? (Score:2)
If so, then a change in architecture is probably warranted as you can take advantage of tool sets geared towards this new development environment. However, this doesn't mean you should throw the baby out with the bath water. Java works well as an intermediate/coordination layer and you could leave large portions of your legacy deve
It'd be a ton of work. (Score:2)
using old code to write new one (Score:2)
However, I would recommend using Eclipse with the CDT plugin to import all your existing code, and then using that to write the same code using java and at that point, use JUnit for unit testing. That will tremendously help you.
Eclipse is a great tool for java (dunno much about using it with C/C++), and JUnit is now critical in any of the code I write that is beyond 150 lines, it just makes things a lot clearer.
Also, as someo
Not Java.. but maybe something else or new C++ (Score:2)
Incremental Refactoring (Score:2)
Switching languages won't help long-term. While a rewrite to a different language is one way to gain the refactoring you are after, it comes with a lot of undesirable side e
Why maybe you should do this (Score:2)
See, if the bulk of that 6 year old codebase is fine tuned code for simulating some physical process or something similarly domain specific, then throwing it away and converting it to anothe
An attempt at balance (Score:2)
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
The language is not the problem (Score:2)
screw the project (Score:2)
Some advice from a Java/Spring/Hibernate shop... (Score:2)
1) You will be cursing the day you ever accepted Hibernate into your development environment. After the initial "ooh...
It isn't a migration (Score:2)
Find a new job.
This is rediculous (Score:3, Insightful)
Question is a troll? (Score:2)
Now, I'm not saying that's a bad thing. Mostly, I agree with the responses, but I have to wonder if there's another side to this, such as: Did the consultants really say nothing more than "Java is a magic bullet"? There are legitimate reasons why Java may save you tim
Re:Java (Score:2, Insightful)
Re:Do it incrementally. (Score:2)
{
class Finally {
~Finally() {
}
} foo;
try {
} catch {
}
}
Re:FDA? (Score:2)
I decided that, and understood what the term "dog food" really meant when reading this:
I Have a Feeling We're Not In Emerald City Anymore [pipeline.com] by Henry G. Baker.