Fog Creek Software
Discussion Board

When to retire...

Where I am working we have a product in C++/Win32. We are possibly moving to Java, for a lot of reasons.

The argument that is coming up most is, what about the old version.

1. Who will support it ?
2. When will we migrate the users over to the new product ?
3. We dont want to add feature X to the old product and the new.
4. If we have two product teams, then what will the old team do when there is no support/ehancement requests ?

Personally, I find some of these cencerns a mute point. Especially #4, because with one product, you still have the same problem of keeping developers busy.

I am voting that we keep the old product and support and enhance it on a user pays basis and, that we develop a new product.

I dont see the need to migrate the users of the old product to the new one, as they are happy with the old.  I just see new users using the new product.

Have any of you faced this same challenge ?
What did you do about it ?
Did you position win in the end and, how ?

James Ladd
Wednesday, March 6, 2002

Moving a project from C++ to Java is like shooting yourself in the foot. You don't have to believe me but when sales of your software go down; remember my words :)

Wednesday, March 6, 2002


What do you do when you need to support java because the customers want your product on non-win32 paltforms ?

The code is not currently portable to any other platform.

I dont think sales will go down just because we changed to java.  If the new product is lacking the features of the old, then I would agree.

James Ladd
Wednesday, March 6, 2002

James, well then sure you'll have to port your app to Java but you should keep the vc++/win32 version to. Why? Because many people have had bad experiences with Java apps, others have heard rumors that it's slow, others don't like the somewhat different GUI interface.

Wednesday, March 6, 2002

James, I tend to agree with Roger, how about a C++ version on Unix.  (I assume that is the other platform)

Thursday, March 7, 2002

> What do you do when you need to support java because the customers want your product on non-win32 platforms ? The code is not currently portable to any other platform.

We might port it: easier and /safer/ than rewriting it; most of our code isn't GUI; refactor Win32 to make an OS-specific layer, then rewrite the layer when the rest is portable (or use some trustworthy cross-platform library to help, but see also ... my wariness of proprietary libraries isn't just that we can't fix bugs, but also if we need to pay for upgrades (usually OK) or per-end-user licenses (usually not OK) /and/ that the library might not be supported/sold some years from now).

One code base is enough for us, I resist developers even 'supporting' more than one version of it (the codebase) if that's avoidable... (I don't mind if the codebase contains many /components/ to support, if no copy-and-pasting from one component to another as been going on ... and rewriting in Java sounds to me like copy-and-paste: one bit of functionality implemented in two separate places).

To support dead-end products, we've sold source and all (and maybe even sales and tech support people, and certainly any sales channel contacts, but not developers) to some other ISV who wanted to make it their own. Otherwise, we just stopped developing and selling it, and then stopped supporting it too after a while.

I don't understand "how do you migrate users": if you don't know the users, let them migrate themselves if they want to continue their relationship with you; or if you know them, then negotiate with them.

> I am voting that we keep the old product and support and enhance it on a user pays basis and, that we develop a new product.

It depends on your product/customers/industry, neh; do you have any /single/ customers rich enough to support your development (if not, it's moot; if so, you're doing custom development anyway).

> Did you position win in the end and, how ?

There's an "end"? <g>

Are you sure your question is well-framed? You're talking about the Win32 version of your flagship product; I'm guessing you don't want to 'retire' it at all and you're wondering how to support it (your existing product) while developing new features (same product, different platform: here the new 'feature' is its running on a new platform). Rewriting in Java sounds like "forking a codebase" which some people deprecate.

Christopher Wells
Thursday, March 7, 2002

To James: Your email is not working. Can you please post your correct email ? Thanks a lot.

I think its just fine to redo an application in Java. If you are talking about UI, Swing has made some progress in the past (especially SDK 1.4).  And you can use InstallShield or any other product to distribute your application. No need to compile to a native version.

If you are doing server-side applications Java is very scalable because of different application servers.

Thursday, March 7, 2002

We facing similar problem. We will have to migrate from two-tier application to multi-tier application server-based system.

What we going to do is to evolve our system, not wrtite a new one. This is going to be an application with half modules working through old system, and half - through application server.

I'm not sure if we will be able to give this transitional app to users (I hope we will), but in any case we will try to keep all automated functional tests running all the time.

Any other solution will be a suicide. First, it will be a rewriting with all its "benefits", and in addition it will have "second system effect" - developers will try to put all that nice featured that we had no time to put into new system.

Roman Eremin
Thursday, March 7, 2002

i'm a java/swing developer, but i would advice you to _not_ port your product to java. or at least, don't plan to use the java version as your "future flagship product". in my experience the subjective user "feel" of java UI interfaces loses massively against the native windows experience. and this is not only because swing still looks ugly + is slower.

there are still lots of tiny flaws in the UI behavior. you can't press "alt" and use the cursor keys to skip through the application menu (you have to press e.g. alt-F[ile]). ComboBoxes require some work until they mimic the convenient windows behavior (input completion etc). and extending swing components might become a nightmare when you want to do things the swing developers did not foresee (which happens quite regularly. JTable comes to my mind) ...

of course the good thing about java is the cool + voluminous core API which simplifies quite some work, and it comes with sourcecode.

depending on your specific market, you could at least determine your customers' reactions to a change of the user interface. maybe by porting a small subset of core user controls and showing them to some clients?

Martin Dittus
Thursday, March 7, 2002

My experience is that Java is far from the "write once, run anywhere" paradigm, and closer to the "write once, debug everyhere" one - be prepared.

Consider doing a C++ port using some Win32 emulation layer (Wine, MainWin, and there are others) or a native port. If it relies on binary x86 code you can't recompile (e.g., ActiveX control) but the target platform is an x86 O/S (Linux/*BSD), this may still work - The CrossOver plugin solution allows ActiveX plugins to run inside Mozilla/Konqueror for example, and costs something like $20/copy - I guess that you'd have to have a few thousands of clients that are going to pay for a new version to make that uneconomical. If it's not an x86 architecture, you might consider SoftPC / Bochs style solutions that can run Win32 software by running Win32 itself on any machine/architecture. Not exceedingly fast, but an 400Mhz SparcStation CAN emulate an interactive NT4 station.

Ori Berger
Thursday, March 7, 2002

I am interested in the reasons you are going to move to Java.  We are currently facing the opposite problem, because of the limitations of Java we are considering moving our application to C++.

This is not a knock on Java, really it is knock on our ability to foresee where our product would be most usefull.  Basically we have implemented a proxy server and realize now that it would probably work better as a WinSock Service Provider, and a comprable UNIX component.  We were initially thinking JNI, but have ruled it out because of performance and stability.

So I would say, rethink the reasons why you want to go with Java.  What limitations does your application currently have that Java would provide.  Then look from the opposite side and think about what limitations Java would impose, and how it may effect your product's future.

Also, if you have a product developed in C++ then you most likely have proficient C++ programmers with domain knowledge of your application - are you going to be cutting them out of the loop (either directly or indirectly) by moving to Java?  In otherwords, unless a good core number are also proficient in Java you may be doomed to make the same mistakes over, just in a different language.

wyoming johnson
Thursday, March 7, 2002

I have recently been researching Mozilla's "Netscape Portable Runtime" (NSPR). It does a good job of abstracting OS and C library functions like threads, memory-mapped files, etc. It has been ported to over 20 platforms, including many Unixes, Mac OS 9, Windows 95-NT, and even Windows 3.1. You can't get much more cross-platform than that! ;-) The project is the foundation of Netscape's Mozilla platform and is actively maintained.

The code is open-source using the "Netscape Public License" (NPL), which allows you to use the NSPR code without requiring to open-source YOUR code (ala the GPL virus) but if you modify the NSPR source code, you must release THOSE code changes to the public.

Banana Fred
Thursday, March 7, 2002

wxWindows  ( ) is a free, open source C++ GUI (and a bit more) library. Using a package like that, you could just rewrite the UI layer and any non-portable app code instead of the whole thing. One unique feature of wxWindows is that it uses native widgets, so a Windows program written with wxWdinows actually looks and acts like a Windows program.

For an app where the GUI is important, I don't think I'd go with Swing.

Kevin Dangoor
Thursday, March 7, 2002

Thankyou all for replying. All very interesting responses.

I should have detailed the application a little more, as it doesnt have a GUI component, and if it does get one, it could be native.  The application is a server.

We do have a lot of C++ people, and the current application uses a _lot_ of COM and win32 stuff. Unfortunately, this hasnt been abstracted (ie: win32 stuff used directly) so porting is a hard task.  We had a look at using commercial porting tools like MainWIN and they did not support all of the features we make use of.

I personally dont see a problem with moving the C++ developers to Java.  There are so many problems the C++ prople get into that are just not possible in Java.  Yes there may be problems in the Java version, but carefully applied standards and QA should see that overcome.

Java provides a lot of API's that the new product could benefot from, and we wouldnt have to write them ourselves.

Obviously, if we could port the product then that what I would recommend. Im certainly not suggesting Java because it is new/latest/fad, but because there are many other benefits to it.

Lastly, the final word is not mine, but the Directors.

I thank you all for your comments.

ps- email is fixed.

James Ladd
Thursday, March 7, 2002

Not to parrot what Joel often says, but look at Netscape's history before considering a total code rewrite.

Netscape tried to "port" their browser from C++ to Java ("Navagator"). That failed due to performance and memory management problems, so (I heard) they ported the Java code BACK to C++ using macros to support Java-features in C++.

Netscape abandoned their 4.0 browser code to write Mozilla from scratch. In those 3-4 years, Netscape was in limbo with an abandoned old product and no new product. Microsoft ate their lunch. Even today, there is Netscape 6 sucks and Mozilla 1.0 is still MIA..

Unless it is truly impossible, I would consider a refactoring to hide your COM code behind plain-vanilla C++ interfaces. Then you could attempt to create non-COM implementations for those same C++ interfaces.

Of course, I do not know much about your project. Just some "armchair product management" here..  <;-)

Banana Fred
Thursday, March 7, 2002

Hmm... here's a fantasy of mine.  Imagine if all openly pro-Java and anti-Java folks spent an hour trying to disprove their respective positions.  People saying Swing is slow & looks bad, go find an app that disproves this.  People saying Java's good for cross-platform, find counter-examples. 

I've got experience on both sides of the fence. All I'll say is: don't believe a damned word anyone says, including me.

1. Find out for yourself
2. Don't form opinions too quickly
3. Stay open-minded & neutral

Why people get so worked up over languages & architectures has always been a mystery to me.  True professionals are always interested in the best tool for job.  We should all *want* Java and .NET to get better and better, because it gives us more choice.

Timothy Falconer
Wednesday, March 13, 2002

Hear hear Tim. Well said.

James Ladd
Friday, March 15, 2002

*  Recent Topics

*  Fog Creek Home