# Thursday, 10 April 2003
« Value Types & Reference Arguments | Main | More value type feedback »
More on value types

David Jeske commented on the previous entry

Can ValueType local variables be treated as ValueTypes instead of pointers to ValueTypes? If this were the case, then av[1] could be the pointer to the interior of the valuetype array, and av[1].foo = 42; would work correctly. This would also make the IL for using local ValueType variables most similar to how it would turn out if it had been C#.

The boxing/unboxing would only occur when coercing/converting from a local variable of a ValueType to a ReferenceType (i.e. Object foo = v; )

Remember that I'm working with a standard Java compiler. All the value type support is in the byte code to CIL compiler, because of this I wanted to stay as close to the Java semantics as possible, to prevent problems caused by Java compiler differences (there really isn't any guarantee that local variables in the source end up as local variables in the byte code). Also, the current design a lot easier to implement ;-)

Having said that, treating locals as value types still wouldn't allow av[1].foo = 42; to work. This would require the aaload instruction to return a pointer to the array element, in itself this isn't hard but the introduction of pointers would complicate the type system greatly.

Ultimately, the reason I added this (limited) value type support, is to enable me to write more "native" Java methods in Java. I haven't checked in these changes and I'm still not sure that doing so would be a good idea. Without Java compiler support it will always be a hack.

Thursday, 10 April 2003 12:26:21 (W. Europe Daylight Time, UTC+02:00)  #    Comments [1]
Thursday, 10 April 2003 16:55:52 (W. Europe Daylight Time, UTC+02:00)
I definitely think these changes should be included.

As I understand it, without them it is impossible to use C# structs, enums and other value types in Java code at all, and also impossible to call methods which require ref or out parameters.

To me this scenario is very disappointing - the dream of IKVM, for me, was to see Java as a first-class .NET language while still remaining "true java". Eliminating support for value types and reference arguments clashes with the first of these goals; requiring a hacked compiler violates the second.

I'd even go so far as to ask whether it would be possible to actually *write* a "struct" in java, along the lines of the following:

public class JavaStruct extends system.ValueType {
int structMember;

Presumably it would be possible for ikvm to detect classes that inherit from ValueType and compile them as structs rather than classes...

To summarize, not only do I think this is cool functionality (even if the implementation *is* a little bit of a hack) I think it's extremely important functionality and I'd like to see further fine-tuning of the "hack" and further enhancements to the functionality, rather than leaving it out entirely.

The reason I didn't comment earlier, though, is that I don't really have any right to comment, as I don't actually use IKVM at all (although I may in the future to save my co-developers from downloading the JRE to run a single java program). I'm only commenting now to provide at least some positive feedback on the idea of checking it in, so that you don't throw it out on the basis that nobody thinks it's valuable (although of course I fully respect your right to throw it out for any other reason).

Home page

I apologize for the lameness of this, but the comment spam was driving me nuts. In order to be able to post a comment, you need to answer a simple question. Hopefully this question is easy enough not to annoy serious commenters, but hard enough to keep the spammers away.

Anti-Spam Question: What method on java.lang.System returns an object's original hashcode (i.e. the one that would be returned by java.lang.Object.hashCode() if it wasn't overridden)? (case is significant)

Comment (HTML not allowed)  

Live Comment Preview