Non Strict Variables
 

Hello

In c++ (used sparingly), I borrow a part of Justin J. Meza's Lolcode compiler code so I can use Non-Strict variable typing. It is a struct abuser, but it works.

How can I get the equivalent in Java?

(ignoring the FUNKSHUNZ and BUKKITS, of course)

Re: Non Strict Variables
 

By design, Java doesn't really support untyped/non-strict variables. The closest you can come with "plain old Java" is something like this:
'Object' works fine as a generic container, but you'll have to typecast before calling any functions.

If you're writing for the cRIO that's probably about all you can do without any extra libraries due to the lack of reflection support. But for desktop Java (version 1.5 and up) you can pretty happily use Groovy, Jython, or any of the other languages that run natively on the JVM (JavaScript, BeanShell, JRuby, etc).

For the cRIO, though, you could likely use an old version of Groovy (or any other sufficiently old JVM-based scripting language) to build for JDK1.3. Languages this old are precompiled into standard bytecode and shouldn't have problems running on older versions of the JVM.

Even so, there might be a better way to accomplish things than with untyped variables, depending on what you're trying to do.

Re: Non Strict Variables
 

You can approximate weak typing in Java by creating a class or interface that encompasses your entire domain of types of interest. For example, see the J2SE Number class. At the highest level, Object does this (except for built-in types like int, double, etc.)

In general, though, if weak typing is a requirement, Java is probably not the right tool for the job.

Re: Non Strict Variables
 

I don't see anything here that couldn't be translated pretty much directly to Java:

• The various data types become classes: structs become new classes, double, int, etc become Double, Integer...
• In the value class, the void* becomes Object, the enum type becomes Class, the value* becomes an object reference to the parent instance of the same class.
• Casts, methods, etc stay almost the way they are.
• Mallocs become new Whatever, frees go away.

This would look very odd in Java, and one suspects the problem being solved, whatever it is, could be addressed in a more idiomatic way (interfaces, as mentioned, come to mind), but unless I'm missing something the code could be ported almost as is.