Fog Creek Software
Discussion Board

VC++ envy

For some time I have had an ambition to write an 'application'. An .exe that someone can run and it does stuff. In my mind, this is 'real' programming! Coming from a server side background I never had a need for VB ,VC++ or Delphi. I've learned Perl, ASP, PHP and even some JSP. But then I read an article on the IBM DeveloperWorks site ( and I had an idea. It seems that one can write an application in Java and then compile it for the target platform. Ok, so now one looses the write once run anywhere thing, but frankly I don't care! If it turns out that I can use my Java knowledge gained through JSPs and the like, and turn it into an app that anyone can download and run on their machine, then WOW! I've always felt that I needed to learn VC++ (or Borland etc.)  to actually realise this ambition, but maybe now this isn't the case.
I'd love to know if anyone on this learned list has any experience of using Java native compilers. For me, at the end of the day it boils down to not having to learn yet another language.

Eagerly anticipating your responses ...

Wednesday, March 6, 2002

Hi TP,
As I understand it you already know Java, don't you?

What do you think about just writing normal java programs. They will be also runnable as stand-alone client application. The only think your audience needs is the java runtime.

Or have I missed the reason why you would not like to go this route?

Hope that helps

Wednesday, March 6, 2002

I'm afraid I don't quite understand your motivation for compiling Java applications, either.

However, we did do experiments with Java->Native compilers a few years ago and were underwhelmed.  At the time, we were trying to address Java's memory and performance issues (but mostly the memory - what a pig).  The Win32 compiler we tried (I've forgotten the name) worked, but didn't really address our problems.  The runtime overhead is there whether or not it's byte code or machine code that's executing.

If you just want to write stand alone applications for fun, just stick with Java.  Each platform's SDK provides tools or samples on how to bundle the java classes into a standalone, double-clickable application.

If you want to write commercial grade client software, then you'll need to do some more research.  I haven't stayed current with Java's performance.

Good luck,

Jay Zipursky
Wednesday, March 6, 2002

I got a lot of helpful info about using Delphi for easily writing a Win9x app.

The thread is:

David Fischer
Thursday, March 7, 2002

On the desktop you have the same sort of library problems you have on the server, but they are worse.  THat is why it is often tempting to write a huge program, staitcally compile in all the dependencies and deploy it that way.  Yes, it will be huge, but you don't go through DLL hell.  We won't talk about c runtimes or any of that....

In java, you have a similar issue.  Yiou need to make sure the target machine has , at a minimum the Java Version compatible with what you are using.  Most MS boxes will have that braindead 1.8 version (I think) and most Linux Boxes don't have anything installed by default.  So if you want to make sure your destop app runs correctly on those machines, you must install a Java Runtime Environmnet.  The Star Office Install does this, and is probably the most successful Java Desktop app.

In C++, you have a similar probalem.  For Windows, you can use MSVC++ and statically compile in the MFC code and you will get a Huge application.  I mean really big.  If you don't you have to make sure that the right version of MFC.dll is installed.  Similar Issues with the COM Componenets.  For Linux, you have a choice of Qt and KDE style programming, GTK--, Or going to a C API GTK+, GLUT etc.  Again, you must make sure the library is installed.

TCL/TK, PERL/TK, Python, Visual Basic, on down the line have the same problem.  Some are cross platform, others aren't.  Some are more likely to be installed than others.

This is why the Web has been successful.  It is a braindead, simple lowest common denominator pain in the ass to work with UI that is more likely to be installed on the clients machine than any other.  HTML is a lousy user interface,But I know that I can get code to be displayable on all machines everywhere.

All that being said, go with Swing and Java.  Use Java Web start to install, and give you users a link where to find it.  Yes, swing is slow, but it will get the job done.  And with JWS you'll be able to deploy fairly easily.

BTW C++ is the language of choice for complex desktop programming (Graphics rendering) and most of the scripting languages (VB, PERL/ Python etc) are useful for Rapid prototyping.  Java runs a good middle ground between them.

Hope this helps.


Thursday, March 7, 2002

Delphi doesn't require runtime dll's per se

Friday, March 8, 2002

Anyone telling you to write an app in Swing for distribution over the internet probably has not written code that anyone actually uses. 

KISS.  In your real world, people don't need 1 hour supporting API downloads to run your app.  Swing apps run like shit, to get to the point.  Slow and clunky. 

Look into the distribution requirements of a VB app.  New builds of windows already have the VB runtime (monopoly!)    If that's not realistic, then maybe VC++ is your choice if it has less supporting code to install. 

Funny, in this case, it's not about the language, but about the "real world" hurdle of DISTRIBUTING it !

Sunday, March 10, 2002

>Anyone telling you to write an app in Swing for
>distribution over the internet probably has not written
>code that anyone actually uses.

This is completely untrue.  I can think of more than a dozen well known examples of shipping Swing apps, along with a few we've developed ourselves.

The JRE adds 7 megs to the install.  After it's been installed, deployment is much easier, particularly with Java Web Start.

As for Swing behavior & performance, have you tried JDK 1.4?  My apps load faster than most Windows programs.  Everything's snappier.  Best of all, the architecture of Swing is leaps and bounds above most other frameworks, primarly because it uses design patterns effectively.

I know my words here will have little effect on those already biased, but for those of you on the fence, find out for yourself before listening to the nay-saying.

Timothy Falconer
Wednesday, March 13, 2002

I, too, would avoid using GCJ or other Java -> native compilers. Just write to a particular JRE and see what happens. Optimizing Java code is not completely futile; you can get high performance out of it. Slow Java performance is sometimes more dependent on your algorithms and program design than on your compiler, just as it is in other languages.

Re: Swing performance.

I regularly see three common Swing problems:

1. Excess class loading. A partial solution is to avoid hard linking in your program: use encapsulation and Java's reflection system to load class as they are needed, not before.

2. Excess event listener code. Obviously, the code behind every ActionListener or other listener should be as small and as fast as possible. If it could take more than a few hundred milliseconds, split off a thread and inform the user of the thread's progress. If the task can be done in the background, invisible to the user, do so.

3. Slow redraw speed. This is usually the fault of over-ambitious UI programming, with an excessive number of layers, layout managers, components and images. In my experience, Java 1.3 is quite fast at pumping pixels to the screen; I regularly see >60 fps in my Swing games. If, however, a Java coder does not investigate all the complexities of buffering, overdraw, and layout like they would have to on other platforms, they will get slow performance.


[N.B. If you are thinking of Forte/NetBeans, ignore everything I just said.]

Michael Buttrey
Wednesday, March 13, 2002

*  Recent Topics

*  Fog Creek Home