Well, guys, this talk gets really captivating. So i decided to take a
part in it, though know that i'd regret it.
I'll just drop down a couple of further explanations. But, please, don't
beat me up if i would write smth wrong. Everyone has the right for
mistake. And the truth is that no matter how experienced the person is
he/she can be mistaken sometimes. If you had only heard local tranlation
of English movies (from English to Russian) which are broadcasted around
the _whole_ country!!!, you would have definitely understood what i'm
talking here about. Just let help each other, let share our knowledge.
That's why every interest group is usually created and that's why you
are reading this message right now. Abusing is useless and stupid. Try
to think about other people not as simply email addresses, but as real
PEOPLE, PERSONS who live in some country, in some city. So, back to the
point.
--------------START EXAMPLE---------------
1 public TCBSplinePathInterpolator(Alpha alpha, TCBKeyFrame keys[]) {
2
3 (stuff deleted)
4 // Make space for a leading and trailing key frame in addition to
5 // the keys passed in
6 keyFrames = new TCBKeyFrame[keysLength+2];
7 keyFrames[0] = new TCBKeyFrame();
8 keyFrames[0] = keys[0];
9 for (int i = 1; i < keysLength+1; i++) {
11 keyFrames[i] = new TCBKeyFrame();
12 keyFrames[i] = keys[i-1];
13 }
14 keyFrames[keysLength+1] = new TCBKeyFrame();
15 keyFrames[keysLength+1] = keys[keysLength-1];
---------------END EXAMPLE------------------
When u create keyFrames array in line 6, its elements are not
intialized. That is keyFrames[i] == null is true for any element of the
array. If u would try to access this not initialized element you'll get
NullPointerException. Now, correct me if i'm wrong, but as far as i know
array elements store only _references_ to the objects, not the instances
themselves. So, in order to initialize the elelement one should have
_any_ reference to the same object type. 'new TCBKeyFrame()' in line 7
returns _reference_ to TCBKeyFrame object which was initilized by
default empty constructor. keys[i] also has reference to _another_
TCBKeyFrame object. So, _both_ line 7 and line 8 are grammatically
correct, but they do the same job. The only difference is that line 7
operation takes much more time to compare with the one in line 8 and
that the element would hold reference to different objects (that is to
different places in memory)
A note: the basic mistake in Java (and C as well) language is checking
equality of two objects by means of == sign. The point is that in case
of objects (Object1 == Object2) is true _ONLY_ in case earlier in the
code there was an assignment Object1 = Object2. If u create Object1 and
Object2 independently (that is via
'Object Object1 = new Object() and
Object Object2 = new Object(), for instance),
then (Object1 == Object2) is always false (unless the assignment i
talked about is present somewhere in the code), while
Object1.equals(Object2) is always true unless you haven't changed some
fields of these objects since the moment of creation. Remember, that
'==' compares pointers, memory addresses, if you want, of the objects.
So, obviously two objects created as independent instances via 'new'
operator couldn't take up the same memory addresses and thus the result
of '==' comparision is always false for them.
It looks like the guy who wrote that code thought that he/she should
declare that element would be of TCBKeyFrame type by means of 'new'
operator and only after that it is possible to assign other references
to this array element. Or possibly he/she did believe that he/she makes
_real_ copies of the objects that would take up another memory
addresses.
It is interesting that in the cource of discussion neither has said how
to modify the code. I wonder why. I bet there is a number of people who
want to know it. So i'd dare to propose my variant (just comment out
some lines)
--------------START MODIFIED EXAMPLE---------------
1 public TCBSplinePathInterpolator(Alpha alpha, TCBKeyFrame keys[]) {
2
3 (stuff deleted)
4 // Make space for a leading and trailing key frame in addition to
5 // the keys passed in
6 keyFrames = new TCBKeyFrame[keysLength+2];
// 7 keyFrames[0] = new
TCBKeyFrame();
// 8 keyFrames[0] =
keys[0];
9 for (int i = 1; i < keysLength+1; i++) {
// 11 keyFrames[i] =
new TCBKeyFrame();
12 keyFrames[i] = keys[i-1];
13 }
// 14
keyFrames[keysLength+1] = new TCBKeyFrame();
15 keyFrames[keysLength+1] = keys[keysLength-1];
---------------END MODIFIED EXAMPLE------------------
Note1: keyFrames[keysLenght+1] (the last element of keyFrames array) is
the same as keysFrames[keysLenght] (the second element from the end).
That is (keysFrames[keysLenght+1] == keysFrames[keysLenght]) IS true.
Note2: the arrays we get here (keysFrames) is actually the same we get
in original example. Commented lines change absolutely nothing except
for the loss of productivity and speed.
No _objects_ are actually being copied in this example. Only
_references_ do. Which means that that if keysFrames[i] object would be
modified in this function, so would keys[i-1], and thus keys2[i-1]
object of the class/function which called this TCBSplinePathInterpolator
constructor would be also changed. So Java3D team guys do not follow the
tradition of copying the objects. To do the actual copy function the
following should have been written instead:
keysFrames[i] = (TCBKeyFrame)(keys[i-1].clone());
Hope this has cleared something out. Remember, that everyone can
mistake. So, just don't get mad. Explain the mistake, so that no one
would ever do it again. It's so simple. Thanks for your attention.
Comments are always welcomed.
vladimir
Justin Couch wrote:
>
> Just in case anyone who is reading this is wondering what the hell these
> guys are talking about, I'll highlight it very simply:
>
> > keyFrames[0] = new TCBKeyFrame();
> > keyFrames[0] = keys[0];
>
> Note that the keyFrames[0] object is being assigned twice in two lines.
> The first line creates a new instance of the object. The second line
> throws away that newly created instance and replaces it with a
> _reference_ to the object from the incoming array. The just created
> object in the first line has never been used so we are dealing with a
> big performance hit of creating a new object and then having it
> immediately garbage collected. This is not isolated to one case in the
> j3d utils package either.
>
> Now, back to Andrew's original point about source etc. Over the years of
> working with Java I have serious doubts about the competance of many of
> the core Java team. It's either they are just really bad at programming
> or they have management breathing so far down their necks to get the
> next new set of functionality out the door that they don't have time to
> do anything other than kludgy coding. Another potential problem is that
> nobody seems to be in charge of an entire architecture. My favourite
> topic of Java's image loading is a classic example of this where nobody
> seems to know what anybody else is doing. On one hand there is this
> perfect system called URL content handlers then we have the toolkit code
> and finally the rendering code, all of which need to take separate
> copies of the data blowing memory usage out of the water. This goes back
> to even little things like naming conventions - Point3d vs Transform3D
> for example - and this done by people working on the same project!
> Freely available source that we could modify unhindered would solve many
> of these problems. Peer review is a wonderful thing for dealing with
> getting bugs ironed out.
>
> --
> Justin Couch Author, Java Hacker
> Snr Software Engineer [EMAIL PROTECTED]
> ADI Ltd, Systems Group http://www.vlc.com.au/~justin/
> Java3D FAQ: http://tintoy.ncsa.uiuc.edu/~srp/java3d/faq.html
> -------------------------------------------------------------------
> "Look through the lens, and the light breaks down into many lights.
> Turn it or move it, and a new set of arrangements appears... is it
> a single light or many lights, lights that one must know how to
> distinguish, recognise and appreciate? Is it one light with many
> frames or one frame for many lights?" -Subcomandante Marcos
> -------------------------------------------------------------------
>
> ===========================================================================
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
> of the message "signoff JAVA3D-INTEREST". For general help, send email to
> [EMAIL PROTECTED] and include in the body of the message "help".
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff JAVA3D-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
