Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsWhite Papers
Discussion GroupsFirst AidDatabasesJavaBeansGUIJava 3DVirtual MachineCORBASecurityToolsGeneral
Java DirectoryOpen Source ProjectsSample Book ChaptersUser GroupsWeb Resources
Related Topics
Databases.NETMore Topics ...

Java Forum / General / July 2006

Tip: Looking for answers? Try searching our database.

a unusual codes

Thread view: 
jtl.zheng - 24 Jul 2006 05:01 GMT
the codes:
-------------------
     Object[] stuff = new Object[5];
     stuff[0] = "eggs";
     stuff[1] = new StringBuffer( "flour" );
     stuff[2] = 3.56;
     stuff[3] = 'c';
     stuff[4] = 123;
     stuff[0]="33";
     for( int i=0; i<stuff.length; i++ ) {
        System.out.println( stuff[i] );
     }
------------------
It seems odd.....

followings is what I guest. please tell me whether it's correct, thank
you very much

1:
what I think is because that the Object Class is any class's
superClass, so it can point to any type (right?), but in these codes it
only have Object Class's interface, not the interface which it point
to.
is it right?

2:
stuff[0]="eggs"

in this sentence,the JVM create a String object(right?), although it's
a String object and of course  it has all the String object's
interface, but what the reference(stuff[0]) can access is only the
Object Class's interface.not the String interfaces(just like
concat(),charAt()....)
is it right?

3:
stuff[0]="eggs"
System.out.println( stuff[0] );

and when print it,the print function call stuff[0]'s toString()
function,and this toString() is the String object's , not the Object
Class's
is it right?

thank you very much

JTL
Jean-Francois Briere - 24 Jul 2006 06:01 GMT
yes yes and yes
100% congratulations :-)
jtl.zheng - 24 Jul 2006 07:13 GMT
haha
thank you very much
: )
Mark Space - 24 Jul 2006 08:03 GMT
>       stuff[2] = 3.56;
>       stuff[3] = 'c';
>       stuff[4] = 123;

But these assignments can't work at all, can they?  These are
primitives, not objects, so they don't derive from Object.

stuff[2] = new Float(3.56);

Would be the correct syntax?  Or do primitives get promoted to objects
somehow?
AndrewMcDonagh - 24 Jul 2006 08:22 GMT
>>       stuff[2] = 3.56;
>>       stuff[3] = 'c';
[quoted text clipped - 7 lines]
> Would be the correct syntax?  Or do primitives get promoted to objects
> somehow?

You can have arrays of primitives.
jtl.zheng - 24 Jul 2006 08:24 GMT
>       stuff[2] = 3.56;
>       stuff[3] = 'c';
>       stuff[4] = 123;

it can be compiled in JBuilder
and it print:
----------------
33
flour
3.56
c
123
----------------

stuff[4]=123;
I think it is turn to "new Integer(123);" automatismly when in
compiling
I guest....
Bart Cremers - 24 Jul 2006 08:25 GMT
Mark Space schreef:

> >       stuff[2] = 3.56;
> >       stuff[3] = 'c';
[quoted text clipped - 7 lines]
> Would be the correct syntax?  Or do primitives get promoted to objects
> somehow?

Since Java 5 this is correct syntax. The auto-boxing feature will
actually compile this to:

   ...
   stuff[0] = "eggs";
   stuff[1] = new StringBuffer("flour");
   stuff[2] = Double.valueOf(3.56D);
   stuff[3] = Character.valueOf('c');
   stuff[4] = Integer.valueOf(123);
   stuff[0] = "33";
   ...

Regards,

Bart
jtl.zheng - 24 Jul 2006 08:30 GMT
so what I suppose is that any superClass's reference can point to its
any subClass
but what the reference can access is only the superClass's interface,
not the subClass's
and the method it called is exactly what the subClass has overrided.
is it right?
Bart Cremers - 24 Jul 2006 08:52 GMT
jtl.zheng schreef:

> so what I suppose is that any superClass's reference can point to its
> any subClass
> but what the reference can access is only the superClass's interface,
> not the subClass's
> and the method it called is exactly what the subClass has overrided.
> is it right?

An array of Object's can contain any Object. As every class in Java
extends Object, the array can contain every single instance of any
class.

Without casting you can only access the methods defined in Object,
that's correct, and if the method you're trying to call is overridden
by the subclass, the overridden method will be called.

Example:

String test = "a string";
Object o = test;

test.substring(5); // Correct
o.substring(5); // Incorrect
((String) o).substring(5); // Correct

The reason the second one is incorrect is that the compiler does not
know it actually is a String. In the third line you tell the compiler
to trust you (the programmer) and assume the object o references
actually is a String and cast it before executing the method.

regards,

Bart
Chris Uppal - 24 Jul 2006 08:36 GMT
> >       stuff[2] = 3.56;
> >       stuff[3] = 'c';
> >       stuff[4] = 123;
>
> But these assignments can't work at all, can they?  These are
> primitives, not objects, so they don't derive from Object.

You are correct, but...

> stuff[2] = new Float(3.56);
>
> Would be the correct syntax?  Or do primitives get promoted to objects
> somehow?

Yes, the compiler (since 1.5) automatically converts the original expression
into something similar to what you have.  It's called "autoboxing" and is a
bloody stupid idea.

The compiler actually generates code to call the static valueOf(<primitive>)
method rather than using an explicit constructor, which can in some cases make
use of cached lists of pre-allocated instances.  E.g. the line stuff[4] = 123
will generate a call to the (new in 1.5) method Integer.valueOf(int), which
(from the 1.5 code, not the spec) will in fact use the cache since 123 is in
the cached range [-128, 127].

   -- chris
Piotr Kobzda - 24 Jul 2006 09:01 GMT
>> Would be the correct syntax?  Or do primitives get promoted to objects
>> somehow?
>
> Yes, the compiler (since 1.5) automatically converts the original expression
> into something similar to what you have.  It's called "autoboxing" and is a
> bloody stupid idea.

What's stupid in that idea?  Can you argue please?

> The compiler actually generates code to call the static valueOf(<primitive>)
> method rather than using an explicit constructor, which can in some cases make
> use of cached lists of pre-allocated instances.  E.g. the line stuff[4] = 123
> will generate a call to the (new in 1.5) method Integer.valueOf(int), which
> (from the 1.5 code, not the spec) will in fact use the cache since 123 is in
> the cached range [-128, 127].

That's from spec (JLS 3rd ed.):

"5.1.7 Boxing Conversion

(...)

If the value p being boxed is true, false, a byte, a char in the range
\u0000 to \u007f, or an int or short number between -128 and 127, then
let r1 and r2 be the results of any two boxing conversions of p. It is
always the case that r1 == r2."

piotr
Bart Cremers - 24 Jul 2006 09:36 GMT
Piotr Kobzda schreef:

> >> Would be the correct syntax?  Or do primitives get promoted to objects
> >> somehow?
[quoted text clipped - 4 lines]
>
> What's stupid in that idea?  Can you argue please?

I'm not totally against autoboxing, but it should be used with great
care. Specially when used in conjunction with generics. Take following
code:

   List<Integer> carefull = new ArrayList<Integer>();

   carefull.add(1);
   carefull.add(43);
   carefull.add(227);

   carefull.remove(43);

   System.out.println(carefull.size());

This compiles fine and the output seems pretty straightforward, but
what you get is this:

   Exception in thread "main" java.lang.IndexOutOfBoundsException:
Index: 43, Size: 3

on the remove line.

Regards,

Bart
Chris Uppal - 25 Jul 2006 09:29 GMT
> > Yes, the compiler (since 1.5) automatically converts the original
> > expression into something similar to what you have.  It's called
> > "autoboxing" and is a bloody stupid idea.
>
> What's stupid in that idea?  Can you argue please?

The basic problem is that it makes it look as if one thing is happening, when
in fact something completely different is happening.  That is just bad language
design, for both beginners and experts.  /Especially/ when it doesn't add to
the expressive power of the language.

(Of course the /real/ problem here, is the use of non-object primitive types at
all -- at least as the "normal" way to express numeric values -- but that's a
different debate...)

It (autoboxing, or indeed any other sleight-of-hand[*] in the compiler) can
cause the unwary to introduce performance problems, or semantic problems,
without realising it.  E.g, some time ago, there was a person posting about
memory problems here -- it was only after some considerable amount of
speculation and debate that we realised he was holding around a million
"floats" in an ArrayList (or something like that).  Since he didn't realise
that his -- otherwise perfectly reasonable -- Java code wasn't doing what he
thought it did, he didn't initially mention how he was storing all those
values.  That only emerged later.

Autoboxing causes (yet more) ugly little glitches with generics too -- but I
can't remember exactly what and it's too hot to go searching ;-)

> That's from spec (JLS 3rd ed.):

Aha!  Thank you for the correction.

   -- chris

[*] "Sleight-of-hand" as in the shell-and-bean game, or its variants, where the
unwary punter is induced to bet, unwisely, that the bean is under the shell it
/seemed/ to be placed under....


Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2009 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.