passing reference value??

public static void go(Long n){System.out.println("Long "); }
public static void go(Short n){System.out.println("Short "); }
public static void go(int n){System.out.println("int "); }

short y = 6; long z = 7;
go(y); go(z);

why would it output int Long??
instead of short long??
thank you

Find more posts tagged with

Comments

JDMurray

For questions on Java programming, you'll find a quicker response in the forums over at www.javaranch.com.

eMeS

poguy wrote: »

public static void go(Long n){System.out.println("Long "); }
public static void go(Short n){System.out.println("Short "); }
public static void go(int n){System.out.println("int "); }

short y = 6; long z = 7;
go(y); go(z);

why would it output int Long??
instead of short long??
thank you

short is implicitly understood as an integer

How this is interpreted can entirely depend on the platform where you compile the code.

I remember encountering this around 10 years ago in a piece of production code that was an applet used to monitor a number of mainframe CICS regions. We were trying everything we could do to conserve memory...the way Java handles this kind of defeated the point, if I am remembering all of this correctly.

Try this and see what happens (note, I haven't tried it):

short y = (short)6;

You might also trying make a short object instead of a primitive.

MS

danclarke

That's actually nice concise code for exploring the rules for widening and boxing. If you try something along these lines:

public static void go(Long n){System.out.println("Long "); }
public static void go(Short n){System.out.println("Short "); }
public static void go(Integer n){System.out.println("Integer "); }

short y = 6; long z = 7;
go(y); go(z);

then you should get the output: "Short Long" because it won't widen from short to int and then box to Integer.

eMeS

danclarke wrote: »

That's actually nice concise code for exploring the rules for widening and boxing. If you try something along these lines:

public static void go(Long n){System.out.println("Long "); }
public static void go(Short n){System.out.println("Short "); }
public static void go(Integer n){System.out.println("Integer "); }

short y = 6; long z = 7;
go(y); go(z);

then you should get the output: "Short Long" because it won't widen from short to int and then box to Integer.

Very nice! Honestly it took me a good minute or two to see the difference between his code and yours.

So if you always use the object form as the parameters it will behave as expected?

MS

danclarke

eMeS wrote: »

So if you always use the object form as the parameters it will behave as expected?

In this scenario, yes. There might be valid reasons why you want to treat "short" and "int" and "long" primitives the same, though - which you could achieve using:

public static void go(long n){System.out.println("long "); }
...
short y = 6; long z = 7;
go(y); go(z);

to give: "long long "

The relevant rules being demonstrated here are that widening beats boxing, and that you can't widen then box.

If the overloading of the function gives the choice between widening a "short" primitive to an "int" primitive, or boxing a "short" primitive to a "Short" wrapper, then the compiler will choose widening. However, you can't use:

public static void go(Long n){System.out.println("Long "); }
...

short y = 6;
go(y);

assuming that y will be widened to a "long" primitive, and then boxed into a "Long" wrapper.

And if that isn't clear - well it took me ages to wrap my head around it - if you'll pardon the pun.

eMeS

danclarke wrote: »

In this scenario, yes. There might be valid reasons why you want to treat "short" and "int" and "long" primitives the same, though - which you could achieve using:

public static void go(long n){System.out.println("long "); }
...
short y = 6; long z = 7;
go(y); go(z);

to give: "long long "

The relevant rules being demonstrated here are that widening beats boxing, and that you can't widen then box.

If the overloading of the function gives the choice between widening a "short" primitive to an "int" primitive, or boxing a "short" primitive to a "Short" wrapper, then the compiler will choose widening. However, you can't use:

public static void go(Long n){System.out.println("Long "); }
...

short y = 6;
go(y);

assuming that y will be widened to a "long" primitive, and then boxed into a "Long" wrapper.

And if that isn't clear - well it took me ages to wrap my head around it - if you'll pardon the pun.

This is probably one of the best explanations I've ever seen of this.

I literally remember spending the good part of a week or so troubleshooting a problem with a Java applet around 2000 and trying to figure out what could be done to stop a memory leak that kept causing the applet to crash after a few hours.

This was in the days of Java 1.2...when "Swing" was all the rage.

This particular applet was used to regularly monitor the status of 200+ mainframe CICS regions. The applet was run in a command center on multiple machines and it would socket connect to a server, also written in Java, that would send regular update messages which would change the display on the applet, and then raise an alert when a threshold was reached. Behind the scenes there was a Java application that was doing the work on logging onto the CICS regions and executing a transaction and returning the results.

Some of the results involved a number, and basically, I was trying to make that number theoretically consume less memory. Upon making many changes I kept ending up in this situation, where a short was always becoming an int no matter how we coded it.

I really don't remember what we ended up doing to fix the problem with the applet. Applets used to be a big deal, but now it seems I rarely hear mention of them. I could just be out of touch with this area...are Java applets still popular?

However, I do still have all of the code to the solution that I mentioned above....kind of interesting to take a look at it after all of these years. I'm told it was retired from production use in 2006, and was never really modified once it became stable sometime back in 2000...

MS