Slashdot Mirror
Portable Coding and Cross-Platform Libraries?
Bradee-oh! queries: "My brother and I were just commissioned to develop a large energy management system for a few big college campuses in the area. It will be written in C/C++. We know that in 6 months, when a preliminary test system will be installed, it will be running on NT/2000 servers. The software will be tested on NT for up to 12 months and a final version will run on NT a year after that. We also know that around that time, it will shift to *nix servers, and we're expected to account for that in development. The question is, what sorts of cross platform libraries will make this as painless as possible? I've never made it a point to code for 2 platforms at once in any language other that Java. Aside from the GUI, which we've already agreed to use QT 3.0 for, we specifically are looking for cross-platform libraries for multi-threading, serial port I/O, and network I/O."
"Ideal libraries would be open source and free, though those aren't as important as tested/stable/reliable. What are your recommendations? Anyone have experience writing for multiple platforms at once with threading, serial I/O, and network I/O all in mind? The ideal scenario would be to recompile on the new platform without changing a line of code - will this type of portability be possible?"
From www.imatix.com (The makers of the Xitami webserver).
SFL is a great library for doing portable low-level stuff such as network etc..
The GNU Compiler (gcc/g++) runs on so many platforms so it should solve a lot of portability issues. CommonC++ is a GNU library for threading and I also believe it can handle network IO.
Now, I always heard that NT is supposedly Posix compliant so it might not be terribly difficult...
int func(int a);
func((b += 3, b));
ACE is an open-source framework that provides many components and patterns for developing high-performance, distributed real-time and embedded systems. ACE provides powerful, yet efficient abstractions for sockets, demultiplexing loops, threads, synchronization primitives.
I've never tested this framework but it seems very good. I know several companies which use it and which are happy with it.
Do you have a compelling reason not to use Java in this case ? It would seem to provide everything you require.
Even just writing portable C++ code can be tricky, especially if one of the target platforms is Microsoft.
QT covers the multi-threading and network stuff so you're down to just serial port stuff aren't you. If you use QT properly then you should be fairly ok.
Your choice of Qt is a good start, but be sure to use GCC, all open source libs that exist on both sides, and adhere as closely to the ANSI standard as you can. If you do the footwork now and gather the libs and other files needed now for both sides AND keep cross compiling on both platforms as you go.
Dont think you can make it under NT and then 2 years later that it will compile on *Nix magically, you need to test every step of the way.
Oh and be sure you have the libs that are identical for both platforms and freeze them before you start. nothing kills a cross platform project faster then changing libs and finding later that the libs you built for on platform X are no-longer compatable with platformY's libs.
Do not look at laser with remaining good eye.
wxWindows (http://www.wxWindows.org) supports quite a few platforms, is open-source, has been developing since 1992, and might be probably exactly what you're looking for.
I realise that the STL isn't on the same level of cross-platform libraries that you were referring to, but it does aleviate some problems - and it's damn efficient too. Stream's, the way the STL uses them, can be quite an effective way of abstracting I/O.
The biggest two problems we had was threading, and serial I/O. Threading, thanks to NT's posix libraries, wasn't that much of a pain - but we did need to write our own thread interface classes, one NT specific and one unix specific. Serial I/O was a little more tricky, but both came down to the same basic approach of treating the serial ports as files.
I think the conclusion we came to was that it was a good idea to highlight the major differences first, and create your own wrapper classes around the OS specific methods. This way your main program is platform independant, and porting is kept to the wrapper classes.
And of course, if you use the Cygwin environment, you shouldn't have any problems at all porting to another GCC platform.
Only one warning: watch out for tricky C++ template uses, not all compilers support all features (e.g. Visual C++ lacks partial template specialisation amongst other useful features).
Check Netscape Portable Runtime, (just one of the many projects that are part of Mozilla. This library provide cross-platform threading, IPC, network/file IO, and dynamic linking, among other things.
would be a good place to start for the threading and networking parts. from what i've seen, it looks like a well engeneered package (and you'll have a hard time finding a better tested library :-).
http://apr.apache.org/
Acts@core.mailboks.com Acrux@core.mailboks.com Adam@core.mailboks.com Adar@core.mailboks.com Ada@core.mailboks.com
Well if you are using qt for GUI why not use the
qt 3.0 network tools.
se the doc for qt 3.0 http://doc.trolltech.com/3.0/
I know that there is no IO mod but g++ have som you can use!
What rimes on recursion What rimes on recursion What rimes on recursion What rimes on recursion
You need SourcePro from Rogue Wave, formerly Threads.h++ etc. It provides a high level, easy to use C++ API for cross platform application development. Even if you're not going cross platform, the Rogue Wave stuff is excellent, provides loads of useful classes for threading, database access, network protocol handling and more.
My guess (and what my impression was reading the post) is that the submitter has to use NT, presumably because whatever systems it has to run on currently run NT.
Just be glad its not the other way around and they're not migrating from Unix to NT.
Perl - $Just @when->$you ${thought} s/yn/tax/ &couldn\'t %get $worse;
Writing cross platform GUI applications is hard. Writing cross platform GUI applications with multithreading and network stuff is very hard, but most of all hard to get right.
Hard = difficult = long = costly.
The question is, is the cost worth it? This application, from what you're telling us, is going to run on a few dozen computers at most. It's not a general purpose app, there is no added value in providing cross platform support.
Why switch platforms in the end? It doesn't make any sense.
But to answer your question, if Windows is really a transitional system, I would just develop on *nix, and run it on Windows with Cygwin. Might be even simpler to use XFree/Cygwin.
Why not write the whole thing in Delphi, which is -apparently- source-code compatible with Kylix. All you need to do then is recompile...
If an experiment works, something has gone wrong.
I'm not sure what you mean by "Energy Management System", but if the interface isn't heavily interactive, I'd go with a browser front-end. If you can, use Mozilla and XUL. It allows you to build really nice interfaces easily.
Browser-based apps aren't going to replace everything. Highly interactive things like word-processors, spreadsheets, etc. aren't suitable for browsers, but if the interface is form-based I think it's the way to go.
The obvious advantage in your case is that the interface code is painlessly cross-platform. You still have to worry about lower level stuff, but that's much easier to do properly if you eliminate the GUI.
It is tempting, if the only tool you have is a hammer, to treat everything as if it were a nail. - Abraham Maslow
While cross-platform libraries will help, some things just work differently on different platforms, and you're unlikely to find a library covering everything so that all it takes is a rebuild to port.
As an alternative strategy, and one that's often easier in practice, I suggest you adopt the old programming rule of thumb: isolate anything platform specific in your code. If you're developing using C++, for example, define interfaces (probably via abstract base classes or in terms of templates) that represent the low-level functionality for serial comms, threading or whatever. Write all your higher level code in terms of those interfaces.
Then you just need to write the implementation behind them for each platform. This may be as simple as writing a few inline forwarding functions if your platform provides native APIs to do what you want. (Obviously I'm including any platform-specific or cross-platform libraries you have in the term "APIs", not just OS-provided functionality.) If, for any particular platform or library, there isn't a direct API to do what your interface requires, you can write a more complex routine in your implementation using the APIs that are available. It will still be isolated from the rest of your code, and nothing higher-level should need changing (or, hopefully, even rebuilding).
If you adopt this approach, the vast majority of your code will probably be 100% portable, because all it depends on is your own "middle level" APIs. Those can be implemented in whatever way is most convenient on a given platform, which might still include writing them in terms of a cross-platform library. The key thing is that most of your code isn't tied to anything platform-specific at all this way, and as such is immediately portable anywhere as long as your middle-level interfaces are sensible -- which they will be, of course, since you wrote them. ;-)
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
In addition, you can get security, high availabilty, and scaleability with far less effort and platform-dependence than a C/C++ solution.
Are you being forced to use C/C++ simply because of QT? Have you considered using QT in conjunction with Trolltech's QT AWT?
Crippled? Hmmm, I don't know if that is true. Java in itself is an elegant language which has some limitations due to trying to support such a wide range of platforms transparently. You have to know what you are doing, that is all...but that counts for any language.
Java code runs fast (really fast) in a lot of cases, mostly the only thing that "feels" slow is the GUI. You can really enhance responsiveness by including intelligent Threading. You can also avoid creating of throwaway objects, thus limiting Garbage collection.
For the GUI, just don't use Swing if you don't need to... AWT is enough for simple frontends, yes it is not perfect, but it is faster. I suppose it is even possible to write your own native implementation linking to, for example, QT libraries or W32 libraries. Not portable, lot of work, but speed ensure.
Some people tend to forget: using a vitual machine inherently takes some performance, but that is the price to pay for excellent multi-platform support. Note that it's still is better to do test on all the platforms you want to support, but the implementation is done once. Especially when using applications (not applets, because of browsers (non)support ), mult-platform Java applications tend to work astonishingly well in my experience.
Ahhh...the great dumpster continuum. Many a free computer will be found there. -- sowth (748135)
It seems to me that you're looking to prototype on the NT platform, and construct the production environment on Unix. Tcl/TK is a wonderful tool that promotes rapid application development, and multi-platform (nt,unix, mac, etc). Whether you're aware of it or not, all of the major industry players have been using Tcl/tk in their products, Oracle with oratclsh, IBM with wscp (their tcl/tk interface to websphere), Vignette with the tcl/tk interface. Also, considering that Ajuba has placed TclPro in the open-source community, you can DL the Unix & NT version's for free. The really nice features of TclPro, is that it contains the tclcompiler (to byte-compile your tcl/tk code), and the tclwrapper (to wrap your code into a binary executable). Most of Tcl/Tk's libraries are cross-platform, though there are specific's to both arena's, (i.e. IPC on Unix & Registry calls on NT).
I'd suggest you start with modeling the product in Tcl/TK on the NT platform, ensuring you don't reference any NT specifics. Once you're happy with the model. Copy the code to your Unix system, confirm it still runs, then compile it up into a binary executable for distribution. BTW, there's some nice GUI IDE tools available for Tcl/Tk, I'm rather fond of SpecTcl, a GUI for building graphical user interfaces, that will also produce java & html output.
Good Luck!
Threading - It has been my experience that since various operating systems handle threads differently, your thread behavior will be slightly different on each OS, however, the threading code will remain the same. This code should be portable with no problems as long as you do it in a standard (ANSI, ISO that is) kind of way. The only problems that may come up are timing issues, but these are easily solvable (like a day of labor for a real brain stinger), and rarely come up as long as you didn't do anything unorthodox.
Network - Again, as long as you don't do anything funky, and just use portable ansi/iso code, socket programming shouldn't pose a problem. Dont' go below port 1024 if your program won't run with root permissions, as many *nix's will only let root access those ports.
Serial - Ok, this could be a nightmare, find a good library.
I've worked on several projects using the Java platform, where the portability was one of the the major issue. ...
I could also tell you that the major part of these applications were in a banking environment, where reliability and security were, of course, vital.
It included Threading, I/O , GUI,
The problem with Java is quite offen not the language itself, but the programmers which are not able to understand the basic
O.O. principles, and to keep the logic as simple as possible.
Furthermore, Java performances have been really improved since the version 1.0
It is quirky, a pain in the rear, time consuming, but less so than other cross-platform libraries.
I've used it in projects that required common threading, interprocess communication, and a few other things across NT, Solaris, HP-UX, AIX, and Linux. I point out all of the UNIX-like platforms as seperate entities because they all have enough quirks that you can't expect any given library to work across the board.
Oh, and to everyone that has been promoting ideas like "just use gcc" or "just use straight c++", maybe you've never worked on a large scale, long term project, but gcc is not the best option for an app that needs to be highly optimized and writting everything in c++ from scratch is a waste of time (that's why we have libraries in the first place). I'm not flaming here, just pointing out that you need to look at the bigger picture.
"SWIG is a software development tool that connects programs written in C, C++, and Objective-C with a variety of high-level programming languages. SWIG is primarily used with common scripting languages such as Perl, Python, Tcl/Tk, Ruby, Guile and MzScheme."
You can write your code as portable C++ classes, and then use SWIG to automatically read in the header file, and write out all the glue code to plug your C++ classes (or C libraries) into the scripting language of your choice.
-Don
Take a look and feel free: http://www.PieMenu.com
And I still don't get why those people who insist on Java programming cannot see how screwed up Java is. Just look at any of the well-known Java projects (JUnit, the Jakarta stuff) and watch how insane programming in Java is. "We don't have method pointers, so we use the method name and reflection". "We do not have preprocessors or macros, so we cut&paste the code and modify each copy a little bit". "We are too lazy to write the long static method invocations, so we just inherit from the class that contains the methods that we need". "Lets make everything a bean, use reflection to access it and separate the code in 5 layers - ok, we write 10 times the code of a simple solution, but look how easy it is to do this change"... I admit that C++ is harder to learn, just because of its pure size, but it really pays off because it contains so many features that are really make your life easier without using all the ugly cludges that the Java guys must do (unfortunately I am one of them and do this 8hrs/d).
Good morning! Write your program as a XUL application! Say what? Yeah, that's XUL (pronounced zool) ...
The folks that earlier suggested NSPR are on the right track but they stopped short of taking advantage of the cross-platform GUI aspects of mozilla. Design you UI using XML - that's XUL.
Write modular components in C++ using XPCOM - a
cross platform variant of COM.
Compile and deploy to just about any platform that mozilla runs on - and *that* my friend is a lot!
The bulk of your app can be defined using a few
text files (XUL compatible XML tags with some Javascript). You might not even need to write *any* C++ code.
Besides the docs available directly on mozilla.org,
here's a link to some stuff I wrote:
http://www-106.ibm.com/developerworks/webservices/ library/co-xpcom/
Enjoy.
And this is all too common, I'm afraid. I once had to implement a massive, heavy-fines-for-errors project that needed to compare massive associative arrays in C instead of Perl. Why? Because the boss didn't like Perl.
The Independent: Reverend Spooner Arrested in Friar Tuck Incident - ISIHAC, Historical Headlines
Actually, no, but he DOES already have the answer.
QT 3.0 supplies everything he needs for platform independent sockets, threads as well as the gui. Serial port access is easy enough on both platforms to do yourself.
My only suggestion is to have a spare linux box with a cron job that checks out the latest sources from cvs, compiles, and emails you the error messages. Then he will be notified as soon as he checks in some sources that only compile on the lame VC++ compiler. I do that all the time and it is much easier to fix the portability problems as you go instead of in one big chunk at the end.
--jeff
ipv6 is my vpn
Correct, but there is another gotcha.
::operator new = memory corruption and crashes
The current cygwin g++ compiler is not compiled itself with the appropriate flags to generate thread safe RTTI and exception handling code.
threads + cygwin + g++ +
unless you use -fno-rtti -fno-exceptions
Yes, this sucks.
--jeff
ipv6 is my vpn
The key thing is that you must develop for at least three platforms from the start. My initial work was on Solaris, Linux, and VMS. This allows you to find (most of) the inconsistencies early and design around them before they get too embedded in the project to ever change.
You also need to identify what things are very likely to change across platforms (in my case it was threads, networking, and file I/O) and abstract those out from the start. Write wrapper functions and use them. Actually, I wish I had wrappered more of the output functions; as it is, the app's a little too dependent on ASCII. Given a few wrapper functions I could easily have supported EBCDIC and Unicode; now it'd be a bear to add that.
Stick with anything ANSI, and POSIX is good. C++ still hasn't finalized everywhere, not like ANSI C. If you write in ANSI C it works darn near everywhere. Windows doesn't do POSIX threads natively, but if you aren't doing anything really weird, wrapper functions can handle that. (All I needed was threads with default stack sizes, and mutexes.)
Not that all the Unixes are the same. AIX in particular has some non-standard silliness in its implementation of pthreads. A comment from my code:
A few #ifdefs can take care of things like that. But really, really, really: Port from the start!
For the GUI part of it, make a separate front-end app. Use something portable for that; a library or Java or whatever. Speed is hardly ever a problem for GUI front-ends. Just make it simple and reuse as much code as you can between platforms.
PHEM - party like it's 1997-2003!
This is a cross-platform C lib and networking runtime. It's production quality and free. See mozilla.org for more info.
Porting it to HP-UX was a headache; the STL's on the platforms differed in a multitude of subtle ways. AIX has been even harder (there may be something good about AIX, but I haven't run into it yet).
The STL seems to be about where C was when the ANSI spec first came out. It took several years before code was really portable...
PHEM - party like it's 1997-2003!
For portable CORBA and threading support, try omniORB (http://www.uk.research.att.com/omniORB/omniORB.ht ml). We use it for seamless portability between NT4.0 & Solaris components and its very effective.
-- Matthew - matthew.gream@pobox.com, http://matthewgream.net
There was a rumour that MS didn't want anyone to use the POSIX subsystem. It seemed to be there simply to get a tick against the "Does it comply with the POSIX standard?" checkbox on corporate/governmental buyers requirements list. Once the sale is made, the POSIX subsystem is of no further use.
We eventually ported to the WIN32 subsystem using a toolkit called NuTCracker. It sort-of worked, but we eventually ended up doing a native port by abstracting out all the OS sprecific stuff.
There are other options to be considered. There is UWIN - http://www.research.att.com/sw/tools/uwin/. There is also the CYGWIN stuff (which seems to include OpenGL) which you can get at http://sources.redhat.com/cygwin/ (you might also need the extra CYGIPC at http://www.neuro.gatech.edu/users/cwilson/cygutil
Why not just start out on Unix? I mean, think about what you are saying. Develop on NT, test on NT for 12 months, run on NT for 12 months...then switch to Unix. Why not drop the superfluous OS and go straight to Unix? If UI is an issue, build a portable UI (in Java or whatever) they can run wherever they want.
324006
SWIG looks like it'll be great when it's done.
However I recently downloaded the SWIG based OpenSSL Python bindings (mtcrypto) and on my first attempt the build failed because the SWIG syntax had changed between releases. I would advocate not using SWIG for anything important until it stabilises.
The SWIG homepage appears to back me up here: "
SWIG is currently in a state of redevelopment in which substantial parts of the system are being reimplemented. This work can be found in the SWIG1.3 series of releases. If you are concerned about stability or are a first-time user, you may want to download some variant of SWIG1.1 instead. Caveat--SWIG1.1 may not be compatible with recent releases of certain scripting languages such as Perl 5.6 and Guile."
Indeed.
And TAO that sits atop ACE, providing a real-time capable CORBA ORB atop it can't be beat either. Its use is less quirky than ACE and made possible a massively distributable financial and access control system that is in use at DFW International Airport and other locations. This system runs on both NT and Linux, with exception handling, etc. across both platforms working well.
I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas
The correct question: "why are our requirements so f***ed up?"
Seriously - there is absolutely no reason to develop on NT, test on NT, and deploy on Unix, and there are a number of good reasons not to follow that path. If you're going to deploy on Unix, you can develop the system on Unix using cheap hardware and more-or-less free Linux or *BSD development systems. You are setting yourself up for about twice as much work as you need to be - just develop the thing on Linux or *BSD to begin with, stick with standard Unix portability guidelines (there are a couple of good *nix portability guides out there from O'Reilly, although at the moment I can't remember the associated cover animals), and call it good. Don't add extra portability into the plan that doesn't really buy you anything.
I could understand if you foresee a future need to port back to Windows, but absent such a requirement at the present, I really think you want to plan the easiest development plan that's consistent with your current deployment requirements. Just ditch the whole NT thing entirely, or if it's a matter of "well, we already bought you these NT boxes to use", then reformat them and install Linux or *BSD on them. Even in the worst case, moving *nix code to Windows will be less painful than moving Windows code to *nix - Unix is designed for portability somewhat, Windows is specifically designed to make it harder to port applications to other platforms. That is not where you want to start out from.
Also, if you do have to do the Windows thing, don't test on NT, test on 2000. In the 2-year timeframe that you're aiming for, nobody's going to want to actually run on NT. So if Windows must be in the picture, then develop on 2000, test on 2000, and deploy on 2000. Again, save yourself from some headaches that aren't necessary.
Your right to not believe: Americans United for Separation of Church and
A lot of people have been suggesting Java, and just as many have been debunking it.
I know this is a C/C++/Perl/Java bigot crowd, so I'll keep this short.
What about Common Lisp or Smalltalk? Both are quite portable, and reasonably fast. Common Lisp can even be fully compiled to machine code. They both fill all of the other requirements.
Two notable implementations of CL are CMUCL (Free) and Allegro CL (free trial, commercial- but solid).
As far as Smalltalk, the notable implementations for your project are VisualWorks and IBM's VisualAge for Smalltalk. Couple summers ago I worked at a shop which was heavily into VA/ST, and it was a pretty awesome system. Core of their business, and we're talking about a pretty big insurance company.
Working toward a usable PDA environment in the spirit of Newton OS: Dynapad
Seriously. Most folks on here think Java sucks, but that's typically because they haven't actually *used* it. I think perl sucks, simply because I haven't used it and don't know it well enough to be efficient at it. That's all too common. But take a closer look at Java... It's cross platform, multithreaded, scaleable ('cept that pesky GC thing, which can be handled reasonably enough with intelligent coding), and does all the stuff you're looking to do.
I used to code exclusively in assembly, then C, then C++, and now Java. Trust me, Java is a stable alternative that will solve MANY of these cross platform issues for you, if not all.
As an example, I have written a datalogger for my car. I coded everything under Linux using vi. It's a Swing based app that's multithreaded and uses the serial port to communicate with the car's computer. I never gave a second thought to cross platform support. I just coded to the Java APIs.
One day, a friend of mine wanted to run the thing on his laptop...which had Windows 98 on it. Sure enough, I put the files onto his laptop and it ran perfectly. This was not modified in any way and didn't even get recompiled! I just put the jar files from my Linux box onto this Windows laptop and away it went. I told him this "should" work, and sure enough, it did.
As for scaleability, I have also helped design a VERY large scale middleware Java RMI server architecture for a VERY large shipping company (it's a public company...you know them...I'm positive you've used them). This handles all user-based load from their VERY large website. We're talking millions of transactions a day here, not thousands. With proper attention to garbage collection, multithreading, and a distributed architecture, this system runs without flaw, 24/7.
So Java works in real world examples, it really does. Plus, it promotes code reuse so well, that I can't imagine suggesting any other solution for your problem.
The way I see it you are going to be using either Java or a .net language. Microsoft's roadmap for .net includes a CLR that runs on Unix.
Pedro
----
The Insomniac Coder
If they're doing a lot of I/O device control directly with the app (Uh, this is an energy management system- which, by definition is going to be tickling things like Opto-22 panels, reading from sensors, etc...) then Java's only truely useful as a UI choice as they're going to have to come up with native interface code to drive the Opto-22 stuff.
They not only have to do network programming and serial comms, they have to deal with industrial I/O that may/may not have a serial interface. If it does all have serial interfaces, they're going to have to come up with APIs for those devices- which isn't always easy.
Java meets only part of the criteria- the ones they needed help with answers on. It doesn't magically meet the other criteria- what are they working with and what does the customer want. I suspect that Java doesn't make the grade here for some reason. I code in Java as well as C, C++, and Forth. I'd be using Forth or C/C++ for this sort of thing with maybe a CORBA driven UI coded in Java unless the customer requirements insisted on C/C++ for everything. Then I'd be using C/C++ because it's close enough to cross-platform to matter little if you pay close attention to your code. I know, I've been doing this sort of thing professionally for 7 years now.
I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas
Depends on how you use MI. There are certainly bad uses of MI, like you can misuse almost every feature. But there are also good ones, and he mentioned one of them: "interfaces with default implementations". They won't be more difficult to read than a UML diagram with regular interfaces, only with less duplicated code.
Just don't use VC++'s "features" such as many of the wizards. Don't use MFC for UI development- use something like Fltk, WX, etc. And, don't use COM/DCOM if at all possible, using CORBA or XPCOM when you need something like that.
I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas
Java has not much margin compared to C++. You have to code quite good Java.
Yes, the VM got faster. It is not the VM that is to blame all the time, expect for those occasions when native libs want to shovel data into the VM and back.
Trust on the garbage collection leads to memory bloat. The high level leads to the construction of deep nested objects that cost much time and memory to construct.
Not that it is different under C++, but people stick closer to the metal there.
Like you wrote, it depends largely if the developer is able to handle the tool.
Regards,
Marc
I find it amazing that programmers spend so much time looking for good libraries, but don't stop to think about their choice of language and spend the same amount of time looking for a good language to use.
Since it is going to a native UNIX environment, what about using Cygwin? Has anybody used this in a production environment which demands high-reliability?
For a GUI you could always use a web browser. I expect remote administration is probably a plus if it is going to eventually be running on a UNIX box... not that X doesn't provide similar functionality.
Of course the usual caution must apply that what the customer plans 1.5 years from now (i.e. going to UNIX) is not necessarily what they'll do... you could very well be stuck with Cygwin forever.
I didnt give a reason as i didnt think i would be questioned.
Its interpreted.. or rather run time compiled, call it what you will it will _never_ be as fast as c.
It requires a virtual machine, so it will always be more bloated than c.
As the "portability" that you and others in this thread mention, gcc is portable. if you want portable code dont make it closed source.
There are "feature-rich" libraries that can be linked to in c also.
Java's only good point is its easy to program in, its the modern day equivalent of basic, or visual basic. Once you become a more advanced programmer, the benefit of being easy to programming in is of reduced benefit.
Sun will never let java be really free.. they want to control it just as badly as any other large mega-corporation would, its just about money for them.
ABG is right, and you should isolate core functionality from data access and user interface - this is critical to portability and leads to evolution of strong, mature systems.
You will note that many business systems written in COBOL as "code monoliths" now require extremely expensive support in the form of CICS compatibility and cumbersome, user-unfriendly security layers. And their interfaces are still "green-screen" or, in many cases, have actually lost function and ease of use through poor GUI integration.
Meanwhile, many scientific systems written in a modular fashion live on despite having their underlying hardware replaced and their user interfaces re-written repeatedly. I'm sure there are systems that started on PDP-11s, are now running on Alpha VAXen, and are planning ports to linux clusters. Some will have been fitted with very pretty web interfaces.
Write your core modules, where the work is done, in ANSI C. Write your data access routines in the most portable language available on your preferred platform, and keep the code entirely distinct from the core functionality and user interface. If you're already invested in something like Rdb, Oracle, MySQL, whatever, then leverage the expertise and investment you already have but make sure your API is callable from C. Don't be afraid to use a fast, simple data store like Berkeley DB or plain old flat files - cheaper is better. But be sure to define a data access API in any case (such as Replace_Leaf_Record() and Create_New_Root(), for example) and keep the code cleanly separated into modules.
Provide a "raw text" interface, written in C, and keep that as the base functionality canon. Use it to test the GUI, which you can write in Java or C++ or Eiffel or whatever (I'd say use your favorite, since you'll get prettier results if you enjoy using the language). Make sure the API for the GUI is entirely documented in the core code itself so that it can be seamlessly replaced when the fabled post-GUI interface finally appears.
--Charlie
Its interpreted.. or rather run time compiled, call it what you will it will _never_ be as fast as c.
Just-in-time compilation is roughly equivalent to compiling, then executing; this is hardly an uncommon scenario with C programs, is it?
It requires a virtual machine, so it will always be more bloated than c.
Again, this is untrue. Java can easily be compiled to native code.
As the "portability" that you and others in this thread mention, gcc is portable. if you want portable code dont make it closed source.
Closed source is admittedly harded to port, but GCC isn't enough to provide a homogenous environment. E.g. GUI libraries vary a lot between e.g. Windows, Unix and Mac. These are highly cross-platform in Java.
There are "feature-rich" libraries that can be linked to in c also.
This part is quite true. However, the standard Java libraries are more feature-rich than the corresponding standard C libraries.
Java's only good point is its easy to program in, its the modern day equivalent of basic, or visual basic. Once you become a more advanced programmer, the benefit of being easy to programming in is of reduced benefit.
Ease of use is an advantage to experienced programmers, too (as anyone who's spent ages chasing memory leaks can attest)!
Sun will never let java be really free.. they want to control it just as badly as any other large mega-corporation would, its just about money for them.
Actually, considering the existence of third-party implementations like Kaffe, Sun probably can't close Java completely even if they want to!
ObjectSpace provides a good, cross platform STL implementation, with toolkits that build upon it. ObjectSpace's C++ Toolkits cover multithreading with mutexes, semaphores, reference counting, communication with streams, pipes, sockets and files. They also provide some useful tools in terms of time and regexp.
It's been a few years since I've used them, but I used them on solaris and hpux with both the proprietary compilers and gcc, and I know their headers had provisions for the MS compiler.
Sip has NO documentation, but it has the advantage that it's used for the Python Qt bindings. It's reasonably easy to use, though it really could do with some documentation.
Assuming you are writing in C++, which seems likely given that you are using Qt.
First, make sure you are using the STL. Others have pointed this out already and they are right. Second, Qt provides much of what you want. It is pretty good that way. Third, check out http://www.boost.org/ which has several other very useful libraries.
Oceania has always been at war with Eastasia.
Incidentally, I really like Qt, and it's great for commercial projects but as a Free library apps you really want to be cross-platform but can't afford to pay their Windows licensing fees for, I have become increasingly fond of wxWindows.
It has it's quirks, yes, but its greatest stregth IMHO is a very nice, well supported Python API. I swear it's at least 3-4 times faster to build a GUI in wxPython than in anything I've seen in C++, even using GUI RAD tools (which only get you so far before you start having to hack at source). Just my opinion, anyway.
...except maybe the serial IO. It certainly handles threading and network IO correctly, and serial IO isn't a hard thing to encapsulate and not much code to write twice (I don't know what the Win32 network interface looks like, so I can't comment much more about it).
Before looking into additional tools, look closer at what you're already using.
(On a personal note, btw, I don't use C++/Qt -- I prefer to use Python, which provides a sufficiently uniform interface for my needs, with its Gtk bindings, which are available on both the platforms you mention. Since these decisions are already made for your project, however, I'm not going to try to push them here).
You claim that the poster's claimns are utterly wrong. PROVE IT.
My own personal experience indicates that he's much, much closer to the truth than you'd like to admit.
I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas
But Qt 3.0 has fairly good cross-platform threading and networking libraries, in addition to its GUI stuff. See http://doc.trolltech.com/3.0/network.html for networking docs and http://doc.trolltech.com/3.0/threads.html for threading docs. Since you're already learning the "Qt way," you might as well use it for these features too.
--JRZ
Ever thought about that one, hm?
I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas
QT has a socket code, I think it has thread code, and much else. If you have already decidede to use QT as the GUI, I'd suggest using them for everything else. It should be cross platform compile okay.
Only 'flamers' flame!
I have used ACE and TAO (the ACE CORBA ORB) for a number of projects.
It works great and is incredibly portable. My only advice is to be sure to get familiar with the configuration of the entire package, like features and options and components before you settle on a given configuration for use in your project.
ACE+TAO are designed to run on a large number of platforms, and support C++ without exceptions, explicit STL template definition, and a number of other features which are really handy for some environments, but dont serve a default installation well.
Some of these options affect the way your code interacts with the library, and require you to write and/or compile your code accordingly. Obviously you do not want to get half way into a project and realize you need to change some configuration options, and then go back into your code and make the requisite changes to support these modified configurations. (This isnt a big deal, as everything is pretty well encapsulated, but it can cause headaches)
I'll give you a few examples of things that I ran across.
1. CORBA. I had used the TAO orb to compile IDL without native exceptions, producing stubs and skeletons that used a CORBA::Environment arguments in all methods to provide the hooks necessary to handle exceptions without using c++ exceptions. Later I switched to native c++ exceptions, and had to modify the function declarations and definitions to remove this now unnecessary CORBA::Environment argument.
2. I had built ACE with the 'no implicit templates' option, which required that all member templates be explicitly defined in the sources files where they were used for linking correctly. Later I switched to gcc 3.0.2 and started using implicit templates. I had to recompile ACE with this new configuration, and also modify my code to remove all of the explicit template definitions that I had added.
3. I had initially been building ACE + TAO with all components and features enabled. This led to very, very long compile times (I am talking 8+ hours on a dual PIII 550 w/ 512M of RAM!) It turns out a vast majority of the stuff being built I didnt need, like a number of the CoS services, the realtime CORBA stuff, and some of the ATM and other networking features. I was able to tweak a few settings in the configuration / build files and this cut my build times down to about an hour. This is a BIG time saver.
I work on a medium-sized (~50-100K LOC) cross platform commercial application.
:-( was very unhappy about Unix-like end-of-line sequences. We check out on each platform, and keep them in sync more or less "by hand" (carrying files or patches from one to the other).
The original developer (1.0 was Windows-only) wanted to use SourceSafe; it's a Windows-based source control system, but he'd heard there was also Unix support. I'd tried to use it on my previous project; true for small values of "support".
We use CVS, checking out onto Windows or onto Unix, hosted on Unix. It just plain works.
FYI, we could not find any way to check out one copy of the source on one platform and build on the other. Visual C++
P.S.: I have no personal experience with ACE but have also heard good things about it. Commercial support is available from Riverace, if that's an issue.
Stupid job ads, weird spam, occasional insight at
Java, as it currently is used, is likely to be a poor choice of a tool for this task.
An energy management system more often than not has to deal with industrial I/O systems such as an Opto-22 interface or a ModBus interface. This often requires system level coding resources Java doesn't provide in any way, shape, or form (because it's not part of it's model of how things should be). To claim that you can code those portions in C or C++ and interface them is silly- it's inserting needless complexity (in the form of having to support two differing languages and having to maintain interfaces suitable for JNI.) for no good reason. If you have to resort to using C or C++ for something, it's more often than not better to code the whole thing in one of those languages.
Coding the UI in Java is an arguable task. On the one hand, you've got the nice API designed for doing UI coding. On the other hand, you're back to adding needless complexities into the system in the form of multiple languages and RPC interfaces unless you're using CORBA between the UI and the energy management system engine. Again, you may be better off, based on my personal experience as a software engineer of 12+ years of experience in the industry as a whole, to code the thing entirely in the base language- it'd be simpler for the whole source tree.
And this doesn't even get into what the customer wants. If they want C/C++, then they get it.
I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas
And the code's collecting some 10-30K per day at a major international airport in parking and ground trans fees. Part of the system runs on NT (Not MY choice) and part of it runs on an embedded platform running Linux. Same codebase, some 200-500kloc of complext client-server code that compiles cleanly w/no warnings or errors on either GCC or VC++.
Its all in what you do/don't do coding-wise. And, I'd probably have a few horror stories to swap w/the people on comp.lang.c++.moderated over VC++ because I DO this sort of thing for a living and have done so for 6-7 years now.
I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas
I'll bet the customer knows about/knows C/C++ and understands that they can get systems (key word there...) programmers using that language.
Java isn't a great systems language- it's a great applications language and doesn't pretend to be anything more. You can do systems programming in an applications language, but the results are often less than stellar and a rough beast to maintain.
This is systems level programming and you need more than an applications tool to do the work right.
I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas
We use the same C++ foundation classes in ACE on WinNT, Win2k, Solaris, IRIX, HP-UX, and Linux. ACE is also supported on VxWorks, AIX, and a dozen other weird variants of *nix. It's a comprehensive real-time, networking, threading, and platform abstraction library. The stuff works great. Makes all platforms act the same. Takes a little work to get it compiled at first, though.
Expect to spend some time getting used to the toolkit, which ever one that winds up being. Every minute you spend initially studying example code, and learning the toolkit's way of approaching problems, is one less minute you will spend trying to beat their classes into doing something they weren't necessarily intended to do.
Unless you know what you're getting into up front, keep separate make strategies for Win and Unix. If you're feeling perky after a while, you may be able to migrate your windows build to the same makefiles as unix, but it'll take some work (and probably the cygwin toolset)
How's my programming? Call 1-800-DEV-NULL
The Mozilla "C++ portability guide" is long out-od-date, having been written in early 1998 before the C++ Standard was even official. The Mozilla document makes many uneducated assertions that would lead to poor programming practices.
Any article that suggest the use of macros over templates is clearly no written by anyone who has worked with C++ in the last couple of years.I've been writing, publishing and preaching portable C++ for more than a decade, and I have substantial code bases that compile and run, with MINIMAL conditional compilation, on multiple platforms (hardware and software). What the Mozilla document advocates isn't portable C++, because they threw out almost everything that *is* C++.
All about me
Some definitions:
Systems programming: Driving hardware with software and/or providing interfaces to system resource (i.e. Your OS itself). This includes industrial I/O stuff like you'd see with an energy management system. It's often timing critical with delays causing no end to problems with things working let alone working right.
Applications programming: Just about everything else.
Just because Java does a bang-up job of doing one, doesn't mean it works well for the other. For an energy management system, down to even the UI, the results must always be predictable and consistent for it to be of any use. For the UI, there's some slack for things like GC causing a second or so delay- and at seemingly random intervals. Java's a decent candidate for that. The flipside is that the controls underneath the UI don't want, don't need, can ill afford random delays like that because you could get into oscillations of operation that burn up any advantage you had by the management system in the first place.
I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas
Are you being simlpy forced to write code outside of Java because your employer/underwriter believes Java will be too slow for implementation, please remind them that the speed of Java applications with a good JVM and JITC can be as fast as C++ with well written code.
If that's their major concern, I would recommend building it in Java from the start.
Uhhh, Qt is still at version 2.3.0 for Windows.
That's funny, because I get paid to develop an app for Linux and Windows which uses Qt 3.0. AFAIK Trolltech hasn't released a free version of 3.0 for Windows yet (although they should soon), but the commercial Windows version was released at the same time the X11 version was.
In the 1980s, the speed and compactness you could get out of C was worth the extra coding time. But with today's hardware, languages are coming out of the woodwork that are much less efficient, but still successful. For example, a number of successful web sites have been written in PHP. Not as slow as ASP, but still a horribly slow language. Yet those sites are still successful, because the hardware can handle it. FWIW, my JVM-based implementation of BRL was 3-4x faster than PHP in a simple benchmark. (Incidentally, developers don't need to know C or Java to learn BRL. See the learnbrl.war demo/tutorial.)
As a whole, the CommonC++ design is pretty messy, relying on massive amounts of kludgy ifdefs and macros in the header files. I believe they are working on cleaning it up.
Other libraries I would consider:
ACE: threads, synchronization, sockets. ACE's design is not very object-oriented, but its probably the most extensively portability layer you will find.
IOLib, portable I/O (also includes identical ports for C and Objective-C).
ZThread for threads.
Nescape Portable Runtime (NSPR), a C library: sockets/IPC, threads, synchronization primitives, layered I/O, ADTs/algorithms, portable shared libraries, logging, etc.
Dinkumware did write the standard library implementation (including the STL stuff) supplied with VC++ 6. However, the version supplied was actually written before the C++ standard was finalised, and is considerably older than the compiler itself. This results in a number of annoying warnings during builds, and some equally annoying omissions (the auto_ptr implementation is seriously crippled, for example, because they don't have the templated constructor, since that wasn't in the spec pre-standard).
Dinkumware have, of course, revised and updated their library a lot since then. While they do advertise bug fixes (e.g., PJ Plauger himself is a regular on the C++ newsgroups and has posted the fix for getline), they are not just going to give away a whole new version of their library for free -- they've got to make their money somewhere! IMHO, Microsoft should have done the decent thing and shipped the bug fixes and major updates in one of the VC++ service packs, but that would have cost them money, so instead we have to wait for VS.NET, which includes a much improved C++ standard library implementation.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
I know that DJGPP is a mighty fine way of getting GNU stuff onto Windows systems and back for portability. Just avoid using any of the MS API's and the MSFC code.
I *think* that most of the programs developed for GNU environments will compile correctly with DJGPP.
They even include a Borland style IDE with DJGPP.
Codifex Maximus ~ In search of... a shorter sig.
The platform indendant standard does it. Altough windows is one of the few systems that doesn't complain it, you can get by using cygwin:
http://sources.redhat.com/cygwin/
(I know Windows NT got the POSIX Certifacte, but only because they implemented just enough to pass the preknown tests, that does by far not mean that it will function)
If you programm in the cygwin environment using exclusivly the cygwin library interface your code should run pretty well on all other POSIX platforms. (including linux, solaris, *bsd, etc.)
--
Karma 50, and all I got was this lousy T-Shirt.
Yes and yes. However, some caution is in order here.
It is a common misconception that the STL, templates and generic programming are synonymous, that one is only good with the others. This is not true. Generic programming is the concept, the programming style. C++ supports generic programming through its template facilities, but other languages (e.g., functional languages) manage perfectly well without a formal template mechanism. The STL is a very clever library based on generic programming principles, and the C++ standard library contains a large amount of material based on it, and unfortunately also commonly known as the "STL", though it is not entirely Stepanov's original idea. Also unfortunately, C++'s language facilities aren't quite up to making the most of it yet -- templates are a good start, but a couple of major omissions are still crippling for now. Hopefully the next revision of the C++ standard will incorporate things like in-place definition of anonymous functions, to fulfil the currently wasted potential of the standard algorithms.
Sadly, Sun's Java team seem to be amongst the uninformed here. The Java Generics proposal, which you can download via this link if you're interested, basically describes a heavily cut-down version of C++ templates. The usual Java approach has been adopted: take what is commonly used, quietly ignore anything else, add a little here and there but not much of substance. If memory serves, the more glaring omissions include numeric template parameters. Useful techniques from the C++ world such as traits and template metaprogramming appear to be hard or impossible to implement with the current Java generics proposals. As a result, Java's "generics" will probably be good for writing template containers -- itself a great improvement over the status quo -- but not very useful for much else.
It's a step in the right direction, certainly, but in spite of the hype, Java is still way behind the field on this one. The major functional programming languages are probably in the lead, and C++ is still the next most serious contender I know of by quite some distance.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
Insist that there be at least one production machine running Unix right now so that you can test the cross-platform capability. Do all your development on that machine.
If you start out this way doing it cross platform is not too much difficulty. You have to write every bit for both platforms at once. Otherwise you will have a porting nightmare later (this can also happen if you write for Unix and try to port to NT). Try to encapsulate the differences to as small a part as possible. Put the differences in header files, try to use macros or anything there so no ifdefs are needed in any of your source files.
I recommend using Qt and the cygwin header files (like libstd) on NT. Use the Unix versions of all calls. Try to avoid needing the cygwin libraries, though, they are slow.
Things like threads are not too much difficultly if you limit yourself to the common abilities of both systems. You don't want the weird features of pthreads (or Win32 threads) anyways. You can put a lot of macros in the header files so there is no time wasted. Linux supports recursive locks even though pthreads does not, it is a good idea to use these to match how Win32 works. Look in the linux pthread.h header file.
Absolutely do not release anything unless you have a working executable with identical behavior on both platforms.
Yes. One other gotcha with cygwin is that the cygwin DLL is licensed under the GPL - not the LGPL. So you can not distribute any closed source software that uses cygwin.
--jeff
ipv6 is my vpn
You've obviously not done a lot of systems programming or you've not tried to broaden your horizons. I've written code for systems that do things like drive Opto-22 I/O, etc. and they all are cross platform (Unix and NT) with minimal differences between the actual code bodies doing the work. If you have to do a lot of differing coding for the differing platforms, you're doing something wrong with your abstractions.
I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas
Why should Trolltech give their software away for free? How are they supposed to feed their families?
But to say "deficiencies" is to put it lightly.
:-Â )
It, for example, allows you to do evil things like modify variables labeled as "const" among other things. I had the damnedest time getting the contractors I was responsible for to get themselves out of THAT habit of Windows programming.
I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas
I get paid 100 an hour to design cross platform code. who would of thought I could of just asked /. to do my work for me.
He could of at least posted a list of places he's checked.
The Kruger Dunning explains most post on
The ideal scenario would be to recompile on the new platform without changing a line of code - will this type of portability be possible?
It certainly is possible, though you'll almost certainly want to have separate Makefiles for the two platforms. You also have to either use ifdefs, platform specific static libraries, or platform specific shared libraries/dlls.
My one suggestion is that you at the least compile on both platforms early and often. I say at the least, because you'd be better off doing at least some unit testing and QA on both platforms. You will run into problems if you don't, and you probably will run into problems even if you do. This is even true in java, trust me, I know from experience that some platforms are going to have bugs even if you do everything by the book. And other times you'll notice bugs in one platform that are bugs in the other platform, but just don't show up in your tests.
ok then your [sic] infringing on my copyright! Could you as [sic] me next time before STEALING my comments for your own?
I did read the revision history, and my statements still stand. The document is based on false assumptions, poor knowledge of C++, and an inattention to detail.
That given, I wonder why the Mozilla folk didn't simply stick to C and be done with it. Why use C++ at all if you won't use so many of its features?
All about me
And it is unlikely to be used in every situation- there's on-board, ethernet, and RS-485 multidrop based Opto-22. This doesn't even get into the varying embedded solutions from other suppliers that drive the passive module backplane for an Opto-22.
.so's project) to make a driver for the RS-485 multidrop B2 interface driver that we were using.
And, that's just Opto-22 stuff, there's all this other lovely stuff that needs driving. In most cases, they have a C or C++ API that snaps right in. For Perl, you had to build the module from that source- and you'd have to pretty much do that for every device you're trying to drive. For me and C++, I had to do very little (pretty much add it to my
And, not to question your choices, but Perl for a systems program (which is what you're describing) on a Naval vessel safety system? Man, you're more confident in Perl and your abilities in it than I would be.
I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas
Perl *is* C and it constitutes the most robust (secure against buffer attacks too) cross platform library you could ask for. You can also do all the things you need to do (and it will work even better on Unix so you can look forward to that). Networking, I/O, forking servers, it is all already done for you and tested in the CPAN (search.cpan.org). It will save you time and make the six month timeframe realistic for you (can't see it happening with C/C++ or Java frankly). It can do Qt, Tk and other GUI toolkits and can handle C and C++ like a charm. Unlike Java, which babysits you so you don't make mistakes, Perl's theme is "There's More Than One Way To Do It" (TMTOWTDI) which may be refreshing. You can still write everything in C/C++ but first get yourself a Perl architecture on top of it.
It is faster to program in Perl and you will be able to use C/C++ for the parts in which you need speed. You can even type C inline in you Perl program and it will compile it for you automatically.
You will be able to take advantage of lots of easy to find algorithms and can prototype a network-aware system extremely quickly. One event loop architecture for client apps called POE may be interesting for you.
To be fair, you could also do it in Java. Though I don't think it magically solves cross-platform issues, it costs more money, and there is a limited number of situations in which you really need to build a Java system. This system might be one of those however. It is usually a matter of what your team knows (although you get more power faster out of Perl). Then I expect you would skip Qt, and stop all the C/C++ work you are doing. If you have a Java team ready you might want to use Java then. Until the next version of Perl it is faster, though Perl usually uses precompiled C/C++ code for time-dependent things.
I am a Perl programmer and have managed Java e-commerce site development in the past (on WebLogic and Tomcat). It depends on the experience of your team as to whether you pick Perl or Java. If you want to build an animated client that talks to servers, or do large corporate multi-tier intranets, maybe Java is best. But I don't see you doing that in your time frame and I don't see it as being important to you. And of course you can make Perl-based clients, either encapsulated in an exe file or very thin and based on top of a local Perl installation.
You will probably be able to prototype the full functionality in straight Perl, optimizing later with into C/C++ on a per package (module) basis. So you need to first design yourself a clean, modular architecture of black boxes. I'd recommend doing use-case design to help discover all human-machine interaction and identify priorities; this will help you with risk management too and is applicable to any language.
You might even want to use CORBA or something similar so that these modules are providing networked services and can be changed to whatever language or system you like without fear. It seems likely that the most important thing to your client will be not the language but the ability to see a prototype, know it is extensible and scalable, and be able to get all the functionality (plus the feature creep functionality) for minimum cost.
Also Perl can run Java! And it can use commands like catch-throw and switch-case because Perl is an extensible, postmodern language that is getting very scarily powerful. In case you haven't noticed I'd recommend Perl in particular because of your timeframe, your leaning toward C/C++/Qt, and probably many other needs you will begin to appreciate such as glue to current systems, talking to devices, other information services, and so on. I have not been impressed with Java performance either engineering wise or in terms of cost, but if you have a trained team with plenty of time, lots of money, and a need for very high traffic transaction systems, Java and something like WebLogic is probably best. But you are not the phone company and I think the answer is obvious. Time to upgrade to Perl!
Some references are perl.com, perlmonks.org, and cpan.org. I think you will be pleasantly surprised. Just to reinforce the message, Java is still a totally valid option and probably most people will say Java, and something that is only Java and nothing else does have a beautiful elegance to it. I think though that you will probably save a lot of time and get tons more efficiencies from available code, being able to use different languages, being able to prototype more quickly, and being able to start *now* when it is still a reasonable amount of time instead of doing more technology surveys. You might want to post your question to both perlmonks.org and a Java site and see what people say, it might be interesting.