Fog Creek Software
Discussion Board




Portability: rougue meme or virus?

A recent threat on this board inquired about a cross platform UI library. In the end the original poster came out and said the cross platform part really was not that important. I have encountered similar phenomena in a few projects in recent years: "Portable" is on the requirements list, but when you ask it turns out nobody really cares since the app is not going to ever leave platform X, DBMS Y etc. (in other cases the requirement was genuine, but I am interested in the pathological cases here)

Now it is not as if "portable" comes for free. You dumb down to a least common set of features, have to do extensive testing, add in abstractions for non -unifiable behaviors etc. etc.

In some case it turns out there is a hidden agenda by (someone in) the IT team:
-e.g. they would really like to use Java, even though there is no justifiable reason but if they can sneak in "portable" ...
Or one of the influential devs on the team is an avid /. enthusiast and sees it as a religious cause to transition the entire company to Linux/MySQL no matter what.
In other cases it really turned out to be pure ignorance and more of a fashion statement.

Have you ever encountered this? What where the causes in your cases?

Just me (Sir to you)
Saturday, September 20, 2003

I forgot to add:

Another cause I encountered was that what was asked for was portability, where what was really meant was interoperability.

Just me (Sir to you)
Saturday, September 20, 2003

I don't know how US companies think about this, because I don't live in the US, but I have a feeling that they view Java code as something precious which doesn't degrade so much over time (when compared with C or Perl code, for example).

Java gives them a sense of stability, of a rock-solid platform commited to also running their code in the future, without having to do any changes.


As for the IT department wanting to program in Java, give me a break.

Yes, if you come from the C and C++ world, Java seems an improvement.

If you come from the Delphi world, Java seems poor and slow to develop with.


I never understood why Delphi isn't more successful.

I guess it's because Borland didn't know how to market it properly.

In contrast, the marketers at Sun are simply the Masters of Hype in this industry. Somehow, they generated one of the biggest hype explosions in IT.

Jake
Saturday, September 20, 2003

Just one opinion:

"Portability" is a code-word which translates to Java.

Developers want to code in what they perceive as the latest'n'greatest language/system, and need to come up with as many different and seemingly valid justifications to support their choice.

Management often falls for the latest industry buzzwords and hype.

Portability may be an issue if you have to support a variety of different platforms (Linux, Windows, MaxOS,  PDA's), but consider where Java is most prevalent these days: in server-side programming with JSP and possibly EJB (and other J2EE components). Where are the portability considerations here? Are you going to be switching between server platforms with a degree of regularity which justifies coding for portability?

Java is also making inroads into cell phones and other such devices. Are you going to deploy apps to cell phones?

There are valid reasons to consider Java (it is a productive environment, there is a lot of support for it, much in the open software world), but portability is probably far down the list.

You and your co-workers need to consider the whole range of possibilites here, incuding the possibility of re-using some, or most, of your existing codebase in COBOL.

I don't want to come across as pro-Microsoft, but the .NET environment does seem to allow for the re-use of existing code, namely in the form of COBOL for .NET (from Fujitsu, if I recall correctly). If it is at all likely or desirable to re-use the existing code, then this approach makes a lot of sense.

No single approach is the silver bullet. Each has pros and cons. Examples:

Java:

pro: lots of high quality support for enterprise applications

pro: not tied to a single vendor (you have a choice of J2EE app servers)

con: there are definite and real performance issues. If not coded carefully, Java can definitely be slower than other platforms (Delphi.... and others). Need more evidence: just look at the number of books with titles like "Java Pitfalls", "Java Performance Optimization". Its not a trivial consideration.

con: J2EE and EJBs are not silver bullets. There is a lot of debate going on about the different flavors of EJB (container managed persistence vs bean managed persistence), and the situations where each should be used.

.NET:

pro: MS has picked the good points of Java, improved on the bad points, and (arguably) come up with a winner.

pro: .NET was designed with multi-language and legacy code re-use in mind.

con: it is (at present) limited to a single platform. Is this an issue for you?

con: it is a proprietary system.

General consideration:

I don't mean to be condescending, but do any of you have experience in object-oriented programming? If not, then the jump to Java (or C#) is going to be fraught with peril, as well as taking a considerable amount of time, as developers get up to speed on OOP.

Before jumping into one world or the other, it is definitely worth while to do some experimentation.

Try some J2EE development using a couple of simple real-world scenarios;

Try to convert some existing COBOL to .NET.

Make your decision from a basis of knowledge and not from hope.

AnMFCAndJavaProgrammer
Saturday, September 20, 2003

Sometimes portability as a requirement is simply a matter of controlling for uncertainty in the future.  Maybe you're an all platform XYZ shop now, but if you're spending a lot of money on building in-house software applications you'd like to protect that investment from too many changes that are beyond your control.  This is especially true if you've been burned before by a vendor that left you stuck on an end-of-life platform without an upgrade path or one that squeezed you dry with extortion-like pricing after you were locked in.  Portability is then simply a code word meaning, "We want a life raft to get off this boat if it starts sinking."

Matt Latourette
Saturday, September 20, 2003

I've seen cases where "portability" came up as a desired feature (if not a requirement) specifically for the kind of reasons Matt mentions. Companies -- not just technology companies -- often are rightly wary of being locked into single suppliers for any kind of crucial component. Imagine if you're GM and there's only one factory in the world that can make a special bolt you need to put your car together ... now you're at the mercy of that supplier.

Now, for a server-side application, there are so many different and costly-to-implement dimensions to portability (OS, database, etc.) that in many case I'd argue that worrying about portability up front is a mistake. As XP folks like to see, YAGNI (You Aren't Gonna Need It). And if you do, deal with it when the need arises.

That said, I wouldn't be surprised to hear people are using "portability" as a code word for "Java". Java seems to fascinate people in a way I've never quite understood, and I'm not clear whether it's because they think the technology/language/runtime/platform/whatever is so great, or because they think it's safe (in the sense of "nobody ever got fired for buying IBM / using Java"), or because there are lots of Java jobs so building one's Java skills is a good career move. Personally I find Java and C# to be somewhat tedious to code in, but perhaps that's because my brain is wired in a way that works better with dynamically typed languages. Or maybe it's because I generally work on smaller projects that don't require coordination between hundreds of developers, where I suppose some of the integration issues would be much different.

John C.
Saturday, September 20, 2003

I just love unportable software, especially Windows-Only software.

Why? I see Linux desktop systems deployed everywhere around me (I live in germany, and the whole public sector seems to be switching over - most recently 9 of the biggest cities of Rheinland-Pfalz and about 12 thousand desktop systems of the police of Niedersachsen). Of course, they all use lots of custom apps, mostly windows-only, like Access-frontends, VB apps etc. They all have to be ported. I know a bit about porting from Windows to Unix. People hire me for that. I win.

The original developers either are happy that they don't have to deal with that kind of stuff themselves, or they are angry at me because they want to stay a MS-only shop, but would lose an inportant customer if they wouldn't allow me to do my job. Of course, some are really against porting, and enforce it, that are the jobs I never even learn about. Tough shit.

Most german "switchers" go with SuSE, being the number one Linux distributor in germany by far (although the Niedersachsen police uses Red Hat, for example), and they are generally OK to work with. They don't have the capacity for doing everything themselves, and are generally not experts when it comes to stuff like OpenOffice and especially Gnome, which seems to be winning against KDE in the corporate area (being the choice of Red Hat, Novell, Sun etc., while SuSE has traditionally being a KDE supporter), and they know and accept that. It's a good time to be a freelancer with a Unix background in Germany.

motta
Saturday, September 20, 2003

"Imagine if you're GM and there's only one factory in the world that can make a special bolt you need to put your car together ... now you're at the mercy of that supplier"

Bad analogy. Languages don't need resupply or maintenance. Buy VS.Net today and even if MS goes Chapter 11 tomorrow you can write C# code until you die.

Philo

Philo
Saturday, September 20, 2003

We have to remember that portable software has been around for many years.

I seem to recall working in Apple ][ Pascal, in the early 1980's (too many years ago, I must be getting old). Apple Pascal was written for the UCSD p system; theoretically, binary code from apps written on the Apple could be run on any other p system. Why didn't that platform take off? Surely there was more computer diversity back then than now, more reasons for portable software to exist.

What about standard C, written for the *nix systems. Is that portable? We've all heard stories about sofware written on one flavor only needing to be re-compiled on the other flavors. It sure doesn't fit the pattern implied by the UCSD p system, and its descendant, Java.

<GROSS-GENERALIZATION>
Major platform changes, such as the switchover from DOS to Windows required at least a substantial rewrite (but at least some of the old code could be reused...).

Switching from *nix to Windows or vice versa will require a substantial rewrite, perhaps a complete rewrite.

If you have to do this kind of work, there's probably no choice.
</GROSS-GENERALIZATION>


But, if you're not faced with that degree of change, if you're staying on the same platform, and you have perfectly functional existing code, why on earth throw all of it away and rewrite in a new language? Why not go with a system that at least allows for the possibility of re-using some of the existing code?

AnMFCAndJavaProgrammer
Saturday, September 20, 2003

AnMFCAndJavaProgrammer:

Take a look at Wine and Cygwin.

They allow porting Unix->Windows (Cygwin) and Windows->Unix (Wine library) with relative ease. The result will probably not be as fast or well integrated as a "native" port, but they both let you get to a usable, working port within hours or days.

Ori Berger
Saturday, September 20, 2003

I think it's a very narrow definition of "portable" that can be used interchangeably with "use Java".  Until recently, my company used the same codebase to develop both a windows service and a Netware NLM (I'll let you guess which one we no longer support).  By definition, all of our code was portable.  And it wasn't hard.  Anything that we couldn't portably do in C was put behind a thin abstraction (sometimes as thin as a #define).  We never branched out to include another platform, but I don't think "porting" to, e.g. Linux, would have required more than a few man months.

Of course, this is all server-side, where it tends to be easier.  The OP sounded more like a client-side GUI issue, where 90% of what you want to do is outside the scope of ANSI C.  But then it's just a matter of choosing an appropriate strategy.  And Java isn't the only game in town.  In fact, I was under the impression that it was faring poorly as a desktop application platform, and that it was doing much better in the server app space, where ironically its portability advantages are slimmer.

Brian
Saturday, September 20, 2003

Just one slight disagreement with Philo here (rare that). Saying that you could write C# until you died even if something wiped MS from the face of the planet, seems to ignore the fact that the runtime you code against wouldn't change, but the systems would. In the next couple of years we're going to be seeing the 32/64bit split, and we've already of course been through the 16/32bit split, so any runtime which is not fairly continually updated, will be extinct in the nearish future. Yes mainframes are still running, but not as many as there were...

Andrew Cherry
Saturday, September 20, 2003

I also must respectfully disagree with Philo ... if MS goes under  and I've coded my whole app around Windows, or Exchange, or SQL server, or Outlook, or etc, etc, I'm in trouble.  New bugs in those apps won't get patched, security holes won't get fixed, etc, etc.  But if I've coded abstractly around an OS, or a mail server, or a database, or a mail app, etc, etc, I just lose one platform.

Now MS going under isn't likely to happen any time soon, but they might increase the price on one of the above components, or decide to stop supporting it for whatever reason.  Also not that likely, but possible...

Michael Kale
Sunday, September 21, 2003

You also have to consider that you'll never get another license to the software you're using ever again if the company dies.

You might be able to use Visuale Studio .NET until you die, but what if a big project comes up that requires hiring of more programmers? What are they going to use? With Microsoft gone, nobody is selling Visual Studio anymore, so you're in a spot of bother ...

Of course, the chances of Microsoft dying in the lifespan of the average project is very small. A more likely alternative is that they change product direction and no longer sell or support the product you need.

For most projects it's not going to be an issue, but if you have a system you expect to be around for the long haul, you really have to take portability into account. Chances are we wont be all be running Windows XP on 32-bit x86 machines forever.

Sum Dum Gai
Sunday, September 21, 2003

If MS die, and you need more Microsoft Visual Studio Dot Net licences, then you are stuffed. But it's easy to solve, because with MS gone you don't need more licences. Just install the program on several computers anyway.

I hear there exist places where they are getting in practice by doing this already :-|

Tom
Sunday, September 21, 2003

"Take a look at Wine and Cygwin."

This is an extremely good point. These are products which allow for complete (at least I assume so...) re-use of an existing code base on a platform which is entirely different from the original one. No rewrite required.


''I think it's a very narrow definition of "portable" that can be used interchangeably with "use Java". ''

My point here is that in the context of the discussion, the term portable was meant to directly imply that the only workable solution was Java; hence portable == Java. It is a narrow definition, but then the original context was also narrow.

Some other respondents indicate that a .NET solution becomes problematic if Microsoft goes out of business. With Microsoft gone, then the future of Windows is uncertain. Such a huge market, perhaps another company would jump to take up where MS left off? Or, perhaps Windows goes open source and achieves immortality that way?

I don't see the use of such speculations. MS is still going strong. True, they are facing stiff competition from Linux and Java, but its a considerable leap to go from "under competitive pressure" to "on death's doorstep".

<crystal-ball-mode>
Its more likely that the successor to Java/.NET will come along before Microsoft disappears off the face of the earth.

C++ had about 15 years in the limelight (late 80's to present) before being supplanted by Java.

Java is now in the limelight, so in about 15 years can we expect to see something else come along?
</crystal-ball-mode>

Of course, just because C++ is no longer the language-du-jour, does not mean that it is instantly useless. Significant amounts of code still exist, and need to be maintained and extended (heck, I just started work on a new MFC project, and, yes, it also involves a Java component).

AnMFCAndJavaProgrammer
Sunday, September 21, 2003

Microsft might go out of business and leave you in a lurch. But if you are doing a risk analysis that  comprehensive, don't forget to include the far more likely risk of your backup tapes all getting hit by a meteor or your development offices falling into the ocean.

Dennis Atkins
Sunday, September 21, 2003

"I don't see the use of such speculations. MS is still going strong. True, they are facing stiff competition from Linux and Java, but its a considerable leap to go from "under competitive pressure" to "on death's doorstep"."

That's really not the point.  Microsoft doesn't have to go bankrupt in order for portability to be an issue.  If they abandon the particular product your software is built on before the useful lifetime of your software has ended, then you're in trouble if you didn't include portability concerns in the design.  You can only "write C# code until you die" if the C# product remains supported.  As soon as a product is end-of-life, you're in a race against time to get your software off it.  Inevitable hardware upgrades and OS upgrades force your hand.  You cannot live in the past, so it's best if you choose development tools that you believe will be supported for the lifetime of the software you build and design your software to mitigate the risk of changes in APIs.

Matt Latourette
Sunday, September 21, 2003

If your objective is to fight the "portability == Java" meme, note that if somebody argues for Java on the basis of portability, you can do this:

1. Lead them into insisting that portability is the most important factor for choosing the language

2. Once they're committed to this position, say that in that case, we should use the most portable language available, Python (or whatever more-portable language you prefer), because it runs on all JVM platforms, plus platforms where the JVM won't.

3. Enjoy watching them squirm.  :)

Phillip J. Eby
Sunday, September 21, 2003

"That's really not the point.  Microsoft doesn't have to go bankrupt in order for portability to be an issue.  If they abandon the particular product your software is built on before the useful lifetime of your software has ended, then you're in trouble if you didn't include portability concerns in the design."

I'm trying really hard to come up with a platform that MS has prematurely abandoned (I don't consider the 16-bit products to be abandoned -- they were superceded after a prolonged migration period).

The only thing that comes to mind is VB6/VB.NET, where some developers had raised concerns about the number and magnitude of differences between the versions.

As far as I can tell (can someone find counter-examples? I'm stumped), MS has provided a clear path forward. With the advent of .NET, Microsoft still provides support for MFC.

It should be possible to use all those existing API's: ODBC, DAO (anybody using that one?), MAPI, etc.

Microsoft even provides for the ability to access these API's where .NET does not provide coverage.

How about the Sun-Microsoft rift? Did Microsoft abandon J++ users?

Do we consider different Office file formats under the topic of portability? Hmm, could be a point.

Portability is clearly an issue if you want to use MS products across platforms. But, if you are tied to Windows, this is not an issue. Is it wise to be tied to Windows? Thats another topic.

AnMFCAndJavaProgrammer
Sunday, September 21, 2003

Our main product is Java based. We consider portability a nice selling point, becuase it gives our customers freedom to deploy on their preferred platform.

Eg.,
- Do you have a Windows network? Run it on Win 2k.
- Are you short of cash? Run it on Linux.
- Do you want the best reliability, and have lots of cash to burn? Run it on a Sun box.

It also allows us developers freedom in our machines. I have a Powerbook and a dell box, another guy runs Linux, and the rest of our coders are on Windows. Most of our clients are on Sun boxes.

Rhys Keepence
Monday, September 22, 2003

Which is exactly one of the points I have mentioned. Some dev. or dev. team wants to use his pet system. There is no way this can benefit the organization, no rational case can be found, but hey, if they can plant the "portability" meme, he gets to develop on his Mac.

I am also not buying the "Let's do it just in case Oracle/Microsoft/IBM goes out of business or abandons us" argument. That just seems like a "let's cut of both our legs since otherwise one day we migth hurt our little toe" kind of thing.

Just me (Sir to you)
Monday, September 22, 2003

But Just me, the reverse is also true, that some people *cough* don't want to develop portable s/ware because they don't want to do Java or whatever and want to stay with c++ (or whatever).


Monday, September 22, 2003

The point is that where there is a clear need for portability, i.e. the demonstrated requirement to support multiple platforms, then building for portability is essential, and Java is probably a very good tool for achieving that end.

However, the problem comes about when the need for portability is not clearly demonstrated, and developers specify "portability" to bolster their case for using Java. Things get worse when the desire to re-code in Java overcomes the considerable advantage of being able to reuse significant amounts of existing (dare I say) legacy code. Thats usually when problems start. It did for us, and hopefully we can recover...

If you are Borland or IntelliJ (two makers of cross-platform Java IDEs), then there is a lot to be gained in portability. If you have to support a single platform, and there is no credible indication of that changing, then where is the portability issue? Surely if the need to switch platforms arises, there will be other, equally as large (perhaps larger) issues surrounding the conversion. Non-portable code will only be your first major concern.

All I'm saying is that if you're adopting Java for the sake of portabilty, then for your sake, I would hope that the need for portability is real, and not just a pseudo-justification for choosing one path over another.

If the choice is for portability, and you need to support a substantial GUI, then be prepared for the "write-once-test-everywhere" consequences, as well as the potential for a considerable amount of performance tuning when you realize that Swing doesn't perform to quite the same level as the native GUI.

AnMFCAndJavaProgrammer
Monday, September 22, 2003

The interesting thing about portability is that when people claim to want to port to whatever, they really often mean that they want to run under Windows and either Mac or Unix.

In the "portable" project I worked on at one point, they spent a large amount of effort to do a combo Java + native C++ witches brew evil codebase.  I speculated that in the time it took them to build all of that, they could have ported everything over to windows in less time and had far less trouble debugging everything.

Flamebait Sr.
Monday, September 22, 2003

"I'm trying really hard to come up with a platform that MS has prematurely abandoned (I don't consider the 16-bit products to be abandoned -- they were superceded after a prolonged migration period)."

What constitutes prematurely abandoned is in the eye of the beholder.  If you're building large, complex systems then it's a very reasonable thing to consider the platform lifecycles in your choice of development tools.  At the extreme end of this, you have NASA still using 386s because they've invested so much money and effort to validate the hardware.  Then there are companies such as GE and AGFA that have software products that are classified as FDA approved medical devices that are running on top of WinNT 4.0.  You can bet that they either have some specially negotiated agreement with Microsoft for support of NT beyond it's regular lifecycle or else they're spending a lot of money and effort right now to migrate those systems before NT support ends.

As an interesting sidenote, the new GE Medical Systems products that I've seen are running on top of GE's own flavor of Linux.  I'm betting that at least part of the reason for using Linux was to have greater control over the product's lifecycle.  It was easier to go at least partially into the OS development biz than to be chained to the development cycle of an OS vendor.

In my own organization, we're still working on migrating our homegrown information system off of APT and XView (both are already end-of-life development tools).

Matt Latourette
Monday, September 22, 2003

Borland have just written a C++ IDE in... Java.

Walter Rumsby
Monday, September 22, 2003

"Borland have just written a C++ IDE in... Java."

And if its anything like JBuilder, the IDE will start to groan and strain under the weight of Swing...

The IDE is nice enough from a feature point of view. It has most of the features I've come to expect from an IDE (comparing against Microsoft Visual Studio).

The problem is that the UI exhibits some "latency" (I can't think of a better term); there are frequent pauses in responsiveness, which tend to interrupt the thought process. Then, of course, there are the garbage collection cycles, where the GUI goes away for upwards of 5 seconds.

Maybe I'm just being picky, but these issues were not present in the native code versions of JBuilder. Lest I be accused of being overly anti-Java, the same issues are present in Visual Studio .NET.

I guess, maybe, managed code in any form needs to evolve before it will be a universal replacement for native code?

AnMFCAndJavaProgrammer
Tuesday, September 23, 2003

"I'm trying really hard to come up with a platform that MS has prematurely abandoned"

Microsoft Pascal IIRC. They also dropped Microsoft Fortran but they sold that product to DEC and offered a migration path to DEC Visual Fortran rather than simply abandoning it.

Chris Nahr
Wednesday, September 24, 2003

Java is actually more portable than .NET, UI-development-wise. In addition, Java has support for much more languages which interest me than .NET (Jython, SISC).

aaa
Wednesday, September 24, 2003

"Java is actually more portable than .NET, UI-development-wise."


I agree with you, but that isn't the point.

By avoiding the use of native GUI components (i.e. list boxes, etc.), and using Java2D to draw the equivalents, Swing achieves a high degree of platform independence.

Remember that one of the purposes for doing this was so that web-based apps, ones that use applets, could be deployed to any Java supported platform, and not have to worry about what the underlying OS was.

The problem is that this approach is not very efficient for so-called rich "thick client" GUI apps. An app which uses the underlying OS windowing components/widgets will outperform the app which has to use interpreted bytecode to draw the equivalents. If the app in question is only ever deployed to a single platform, where is the benefit of the platform independence here?

For what its worth, MS adopted a similar approach for ActiveX controls; you could create a "windowless" control, where the UI features were drawn as opposed to depending on a native UI component. Of course, the drawing was performed with native code....

Sun has made repeated acknowledgements of (real or perceived) Swing performance issues, and has promised to do something(s) in the future. But, inasmuch as the main focus of Java these days is in server-side programming, perhaps it will be a long wait?

AnMFCAndJavaProgrammer
Thursday, September 25, 2003

*  Recent Topics

*  Fog Creek Home