Is Labview a cross-platform language as what Java is?

[DianSong]

Dear NI experts:

Do you think Labview can be a solution of cross-platform language? The main reasons for this demand is:
1. Labview application can be kept when we change or upgrade the hardware/operation system. This feature becomes more important when we use Labview in products.
2. Labview can be used in user-customized hardware, which is a great business opportunity.
3. Though Java or .Net framework is good in cross-platform aspects, many NI users are hardware engineers and Labview is the only power source to enable them to utilize computer technologies without touching many software details.

My understanding is that Labview has the cross-platform capability in a high degree; the current status is:
1. In source code level: Labview has the cross-platform capability, with support of MAX and hardware drivers provided by NI
2. In the executable code level: Labview don't have the cross-platform capability. We need different run-time engine to support them in different environment.
3. Labview extends its capability in mobile devices with Labview PDA, (Windows CE devices is also supported as I know)
4. Labview extends its capability to meet real-time demands with Labview RT, in specified hardware

My proposal is to set a clear goal in supporting cross-platform capability with Labview:
1. In large, Labview application can be deployed in executable code level for all platform, and let the run-time engine and drivers to address the hardware's and operation system's differences
2. Can we develop a compact version of Labview as a framework(like J2ME)? In the compact version, we have
- a G language set
- a run-time engine (like Java's virtual machine) that can be port to customized hardware/operation system
- hardware drivers (like J2SE/J2ME APIs) that can abstract the hardware in a common interface
=> Does Labview have to support J2SE/J2ME? Does Labview have to support .Net framework? With the compact Labview, Labview is the third one people can choose to develop their system's software. This means a huge opportunity for NI business.

Labview is one of great works in the computer world. I think this will make it much greater.

Best regards
Diansong

[shoneill]

You're confusing executable code and interpreted code.

JAVA "programs" are interpreted as far as I know (I know it used to be, is it still?) which means that it's kind of half-way between source code and an "executable".

LabVIEW can be deployed as an executable, but ANY executable as long as it's not an interpreted language, will not be platform independent. There are many reasons why not, big-endian and little-endian differences being only one.

Deploying the LabVIEW runtime for different OS's is similar to installing the JAVA "runtime". The difference is just that JAVA is interpreted, LabVIEW isn't.

Of course you can load VIs (In source code form) without compiling them, thus retaining the benefits of both worlds, don't you think? All you need is a small loader VI for each platform and then the VIs should run providing you don't make any OS-dependent code calls.

Shane.

[becktho]

I can't see a problem. The portability of a LV executable is absolutely given, due to the fact that there are different runtimes.

If you create an executable, you can also create an installer. There you could include the runtime-engine and so make different install files. This you also have with other applications.

But there is also no problem to distribute an installer just for the executable and distribute the different runtimes.

If you use java you also have to install a runtime (as Shane already mentioned). And if the program is interpreted (yes Shane, Java is still interpreted) or a binary executable doesn't really matter in this case I would say.

Thomas

[Lycangeek]

Just a clarification on Java - it's both interpreted and compiled. The JVM starts off interpreting the byte code but then it generates machine code after bit (when depends on whether you are running client or server versions of the virtual machine) via a process known as "Just in Time" compile (JIT'ing). It's the only way to get any real performance out of Java.

As a complete side note, one of the things about .NET vs. Java is that .NET also JITs, but does so immediately. It never runs interpreted.

As to the "compact" idea - something to consider: The LV RTE is the minimal supported needed on a platform, and as shoneill pointed out, you can build your own platform specific "VI loader" EXE that uses the VI Server calls to load and run the user's VIs through whatever configuration system you want. This is kind of like Java where you actually run java.exe with a command line argument as to what Java class to run.