通过

java.lang Vs primitive types (i.e. int vs java.lang.Integer) in J#

  • 项目

Here are a set of questions that one of our customers asked us recently. They were concerned that our library is not friendly to Java wrapper types (java.lang.Integer, java.lang.Character, java.lang.Boolean and so on). They asked us to explain.

Q> Why supporting primitive types as int, bool as well as their arrays is not enough in Java world? Is there anything in the picture that I am missing?

A> This is because traditional Java doesn’t have the concept of passing primitive types by reference (i.e. /** @ref */ in J#).
The only ways to pass primitive types by reference in traditional Java are:
1. Pass a 1x1 array or the primitive type
2. Pass a wrapper type (int is wrapped by java.lang.Integer, boolean by java.lang.Boolean and so on)

Q> It seems like this is just a boxing type why would be an issue not supporting those?

A> Traditional Java doesn’t have the notion of boxing either!
You cannot do the following in traditional Java:
int i = 0;
Object obj = (java.lang.Integer)i;

      But in J# you can do the following:
int i = 0;
Object obj = (System.Int32)i;

Q> It sounds like the existence of @ref makes the use of Integer and the same useful just for maintaining Java compatibility (if someone really needs that) otherwise using the primitive types should be enough.

A> Yes you are right except that @ref int makes use of System.Int32 and not java.lang.Integer.

Comments

  • Anonymous
    May 02, 2007
    Java does have autoboxing in the newer versions, so the point made in question 2 is moot. Furthermore, the absence of relevance of the difference between the memorylocation of an object and its value is a great boon in Java. There is only one simple rule when it comes to references in Java: If it's a primitive type, the 'value' of a variable is its actual value, and when the variable is typed as an object, it's value is a reference to that object. This does force you to wrap multi-typed returns in some object, but it removes a lot of headache when calling stuff, since returns can always be used in the form 'variable' = 'method()' and you don't have to worry about other variables being set by calling a method. It simply foces you to use good form.