03-13-2013 04:11 AM - edited 03-13-2013 04:12 AM
Hi dfs,
you have to do that on your own ("manually")!
You have to understand what that JAVA code is doing. Then you can (or: have to) recreate that with LabVIEW...
All you asked for was the possibility of converting JAVA to G. You got an answer for exactly that question 😄
03-13-2013 05:24 AM - edited 03-13-2013 05:24 AM
I do not think, that he deserves such answer. Your are perfectly right in general, ofc.
You should better tell him, NO, you cannot.
Basicly any code developed in java uses support of its massive library base,that targets the oposite sector LabView does.
As is LabView good for measurement or control apps, java is great for office apps.
If the code is not anything idiotic, or mathlike, I would say it takes less effort to code the whole thing in LabView from scratch, not looking at whatsoever how the java code managed to do that.
Totally agree, that such question is disabled and sounds a bit like "Can my cat learn the skills of my dog"
03-14-2013 03:17 AM - edited 03-14-2013 03:19 AM
Theoretically it's possible to create a translation tool that could do that. Parsing Java (or any text) code is mostly an exercise in endurance, and creating LabVIEW code is possible with the scripting extension.
However practically I think it's a totally useless exercise to write such a tool. The sequential programming paradigma of Java or other text based languages doesn't lend itself well for translation into a parallel dataflow language such as LabVIEW. Besides as Bublina mentioned, Java draws from a lot of built in libraries that are not easily replaced by LabVIEW functions. Think about Hashlists and its childclasses for instance, which are used almost in every Java program. LabVIEW doesn't really have built in Hahslist functions although you can "abuse" the Variant Attributes for that.
Also any automated translation tool is bound to stumble over certain language constructs that clever programmers have devised to (often wrongly) hopefully squezze out another microsecond of performance, or simply for the coolness factor because they can. And the translated result will almost always look somewhat ugly to the native programmer and possibly very involved or even almost incomprehensible. Combine this with the need to verify, test, and test again the resulting code and almost certainly having to make modifications to it, and you end up with the conclusion that translating it by hand is in the end most likely much faster, delivers cleaner and much better maintainable code, and also will very likely result in better performance too. That leaves not a single incentive to write such a tool other than the "Look what I did!" factor.
There exist translation tools between Java, Basic and C# but especially in the case of Java and C# this is because C# was clearly developed with Java as a huge inspiration source. Microsoft didn't want and most likely couldn't have used Java for that, and also lifted a few limitation from Java but otherwise it is exactly the same paradigma as Java. Even the libraries are often very similar with sometimes only the Uppere/lowercase changed to the C# convention.
03-14-2013 10:30 AM
Which do you think will happen first? A "Universal-Any-Programming-Language-to-LabVIEW" translator, or Peace on Earth? It's a toss-up... 😉
03-14-2013 12:34 PM
I'll go for the peace on Earth.
03-14-2013 01:57 PM - edited 03-14-2013 01:57 PM
@billko wrote:
Which do you think will happen first? A "Universal-Any-Programming-Language-to-LabVIEW" translator, or Peace on Earth? It's a toss-up... 😉
A difficult question. The LabVIEW translater is at least theoretically possible! But I would think that world peace is generally much more helpfull!
03-14-2013 02:54 PM
I'll still stick to world peace.
Just to throw a spanner into the concept of a theoretically possible translator.
How would you port to LabVIEW code that would work in Java or C# that creates a class that implements two or more interfaces?
Does LabVIEW have interface implementation? Afaik it only has inheritance.....
Secondly how do you realize abstract classes in LabVIEW 😄
.... 😉 I still think world Peace is more important and probable and world peace is also theoretically possible 😄
03-14-2013 03:25 PM
Forget any attempt to port Java classes to LabVIEW classes. It won't be possible eventhough Java itself already supports only a subset of the OOP mechanismes that have been so far come up by languages like C++. But at the same time it is broadly accepted that the current C++ implementation is in many areas overkill, and some of its features are hard or almost impossible to understand and even more of them are hardly ever used.
LabVIEW's current OOP implementation is even more limited than Java's, so translating Java to LabVIEW based on classes is a complete no-go. That doesn't however mean that you could not convert the actual code of the object methods to LabVIEW VIs. Organizing them as loose VIs would however loose some of the advantages of the Java implementation, although functionally it could probably be made to work.
03-15-2013 11:07 PM
thank you for your reply