Re: Delphi, .NET and Linux
- From: "Paul Nichols [TeamB]" <paul@xxxxxxxx>
- Date: Tue, 19 Jun 2007 22:50:00 -0400
Alexandros Karypidis wrote:
Hi all,
I have been assigned the task of evaluating and choosing a RAD tool for the software house I work for. I'm half-way through evaluating PowerBuilder 11 and am about to take on Delphi.
One major concern for us is that our clients are very keen on having the software run on Linux.
If you want the easiest way to do XPlatform, then Java is your choice. You can, of course, write XPlatform apps with other toolsets, but you might as well forget RAD and change it to could be BAD!!
Other toolsets like GTK+ widgetsets, WxWindows will work, but configurations on multiple platforms is painful. Plus, since these widgetsets are not native, you will find stability may be a problem.
Java uses the underlying native calls for whatever system you are targeting. You are writing to the VM, not the widgetset. Give you an example; slots and signals are not the same as Windows loopback listeners and Windows events. The concepts are similar but the implementation is not. Therefore, the widgetsets have to do some trade off. Stability on Windows and Linux with GTK+ or WxWindow apps I have tried (I like to use for instance, GIMP on both Windows and Linux) my reveal that the app runs great on Linux, but will eventually hang and lock on Windows (try GIMP, use it extwnsively, and see what I mean. Gimp is actually one of the best native XPlatform apps I have tried, using X based widgetsets, BTW).
Java, on the other hand, uses a agnostic approach to the underlying OS. It isolates you from the normal way the OS or X layer would be called, by creating their own way of implementation and calling the underlying OS native APIs through the runtime environment layer.
Admittedly, Swing has had traditionally had problems as well with rendering, but the newer versions are much better. Follow the tutorials on threading events and it is not bad at all. My summary on native verses Java and NET can be summarized as follows:
Native:
(1) Native can be faster and will render more closely to precisely to the OS GDI layer employed to the OS/System you are deploying to.
However, this may be limited to only when you are using some widgetset that is preferred for the GDI layer you are coding to: (ie) Windows APIs or abstraction layer that calls the APIs directly, like VCL, or like GTK+ on XWindows based systems, such as Linux, Solaris, Mac OS.
(2) There is usually a load time and run time advantages associated with natively compiled binaries.
This is what should be expected, in most cases. No interpretation and no need to compile on the fly (JIT or VM).
(3) Those who have no experience with a VM/JITed based system like Java, may be more at home with a native toolset that they are used to.
(4) Intensive Graphical programs can see much better performance.
The more math and/or GUI intensive, the greater difference you will experience between native and non native applications.
Downside to native X Platform:
(1) Deployment can be difficult:
If the widgetsets are not native to the platform, you have to install the widgetsets on each platform where the widgetsets are not native.
This may sound standard and expected fare, but you also have to ensure that all dependency files (.so, .dll) are also supplied with the install. This can be both arduous and problematic.
If you are new to this, I would make a suggestion. Try and find an open source application simular to size and operation of your application.
Download just the source, not the binary to mimic your experience. Now create build or make files for each platform and try to deploy to machines clean. You will quickly see what I mean.
(2) You may have to have a separate compile for each and every platform deployed to.
This may not be OS dependent only, but can also be Hardware specific.
For instance you may have to deploy to Linux on x86, X64, SPARC, or Power PC. The same is true with MAC (x86/64, Power PC). Hardware drivers for Video and sound can also affect run time effectiveness ad using modems, etc. can also provide problems on multi-platform widgetsets and installs.
(3) It is not uncommon to be required to have separate code bases for each platform you are installing to.
This is true even if you are using native widgetsets. Not all are rendered the same between OS calls.
Java Advantages
(1) You write to a single widgetset, namely Swing.
Your code does not change, period. OS and hardware concerns are basically irrelevant. The proper jre is your only concern (Windows jre for Windows, Linux for x86/x64 for Linux, or for MAC, usually jre is pre-installed. Swing usually calls native APIs, when possible.
(2) You do not need to have separate code bases, nor even compile for each platform.
Compile it once, run practically anywhere the jre is available (that includes just about all OSes and hardware. If you want to deploy to handheld or PDAs, make sure that the device supports the full jre or you will have to cut your application down to j2me APIs compatibility).
(3) You do not need to package dependency files
The only exception is if you attempt to use native code calls without using the default Swing calls. Installing or using an installed JRE and a single jar file is all you need to deploy. Dependencies are included in either the jre or the jar file deployed itself.
(4) You have the option of a install from installer, download, or use Java Web Start.
You do not even need separate installers for even large apps. Many complete IDEs can install from a zip file or for many applications, a single jar file.
The Web Start option means that you can provide a downloadable, updatable GUI client that means deploy on the server, auto update to any client on the network. Version control is a part of the Web Start protocol. (For instance I deploy version 1. Every user using Web Start gets Version 1 on start up. Version 2 comes out, you deploy to a centralized server. Every user with version 1 will automatically be updated to version 2 if they are on the network where the server version is installed. This can be LAN or WAN based, like the Internet. No need to download and install, the update is automatic.)
Downsides to Java:
(1) Speed not as fast as native
Startup is usually slower and when deploying to CPU and memory strapped machines, this issue can become more pronounced.
(2) Not as easy to code as RAD environments like Delphi, VB.
There is going to be a learning curve. However, Layout Managers, which use to be problematic for people coming from a RAD tool like Delphi, VB is much better now thanks to new Layout Managers like Maltisse, which makes GUI more RAD like these other tools. There is still a learning curve, especially with Listener events.
(3) You have to code to your VM with the least common denominator.
While VMS are usually backward compatible, they are not forward compatible. For instance, if you t 1.5 anarget Java 1.5 and above, 1.4 runtimes will not work. You have to code for the least common denominator of the VM you expect to be existing on the client machine, or which is available for the clients. On MAC this is restricted to no greater than 1.5 at this time.
NET:
Advantages:
(1) You can use Delphi IDE
Nuff said!
(2) Like Java, theoretically, you should be using abstract calls to the underlying OS, instead you will be coding to the VM, not to the underlying OS.
VL.NET is an exception, with Delphi.
(3) No need to install a non native widgetset.
Should be contained in the NET runtime environment.
(4) Deployment is much simpler than native and native widgetsets.
Just the NET runtimes and assemblies are required to be deployed.
Downsides:
(1) NET is not fully implemented on platforms other than those owned and controlled by Microsoft
While it is possible to deploy a NET application using Microsoft NET and Mono or GNU NET, there is not always a true one to one API consistency using these two frameworks.
(2) Testing time increases:
Due to inconsistencies in the APIs between the proprietary and open source Versions.
(3) You may have to provide multiple code bases.
See 1 and 2 above for the reason why.
(4) Newer NET versions are not supported outside the Microsoft world.
Net 2.0 is not complete on non MS platforms and 3.0 is no where near ready for release. 1.1 is your best shot here.
(5) App behavior between MS and Open Source APIs even when the same, may not function the same.
You cannot take for granted that a call on the MS NET platform will perform identical on the Open Source NET platform.
(6) NET performance will be less than native.
Close, equal, or sometimes a little faster or slower compared to Java speed.
(7) NET installation for runtime modules, are much larger than Java's jre.
Check the runtime sizes for each platform. Java is usually around 13-14 meg. NET runtimes can be 50-100 meg.
This is the best I can do at a true honest non biased
Hope it helps.
P.S. The other option is Wine. Wine is improving and your native Windows app could run on it, especially if you can provide missing Dlls. However, any system needed Windows dlls not supplied in the default Wine install may require or violate the MS Windows license.
My personal experience with Wine is iffy.
Wine versioning is very important here! Make sure all wine builds are the same, on each OS you are deploying to.
Wine is still a beta product and most Linux OS versions and Distros have different Wine versions installed (Same is true with Solaris). You will need to do a lot of testing for a wide distribution. If you can control the installed environment, could work well for you.
.
- Follow-Ups:
- Re: Delphi, .NET and Linux
- From: GrandmasterB
- Re: Delphi, .NET and Linux
- From: Frank J
- Re: Delphi, .NET and Linux
- References:
- Delphi, .NET and Linux
- From: Alexandros Karypidis
- Delphi, .NET and Linux
- Prev by Date: Re: Downgrading to D7
- Next by Date: Re: Delphi and C++Builder
- Previous by thread: Re: Delphi, .NET and Linux
- Next by thread: Re: Delphi, .NET and Linux
- Index(es):
Relevant Pages
|
|
