Class and array

[Eli Delventhal]

Actually, this just becomes slow casting under the hood. Templates in Java are kind of crap. If you're worried about performance, better to make a subclass of ArrayList that accepts only a certain type of class. Then you can deal with the type casting yourself and make it maximally efficient.

But FYI, here is something like what I was referring to:

1   2   3   4   5   6   7   8   9   10   11   12   13   14

public class MonkeyArrayList extends ArrayList {     public Monkey get(int i)     {         return (Monkey) super.get(i);     }     public void add(Monkey m)     {         super.add(m);     }     //etc. }

You honestly think this is faster?

I don't get it. Generics does exactly the same, except that is doesn't do the cast in the ArrayList, but at the callsite. What you do is moving the cast from the usual callsite into your own (newly created) callsite. For HotSpot it's exactly the same code, while your subclass even adds another level of indirection. I'm stumped.

Well you'll have half as many casts, because the setters don't also need a cast. Or maybe I'm wrong and generics don't do a cast at that point, but I thought they did.

But really in the end no I don't think this is worth worrying about if your reason for doing it is speed. I would argue that in some situations it has more clarity, and you avoid some of the other issues mentioned in that article (like you can have MonkeyArrayList.staticVar separate from ApeArrayList.staticVar, for example).

[princec]

Aye Eli is a little misled on the application of generics. Generics don't make things faster or slower; but they do provide an extra level of compiler checkery which can make some code neater. Some code not so neat. Roll on project Coin which will sort it out.

Generics are like salt: use sparingly but effectively.

<edit> Also, casts in the JVM are much more cunning than you think.

Cas

[Eli Delventhal]

Aye Eli is a little misled on the application of generics. Generics don't make things faster or slower; but they do provide an extra level of compiler checkery which can make some code neater. Some code not so neat. Roll on project Coin which will sort it out.

Generics are like salt: use sparingly but effectively.

Cas

I've got to stop arguing points that I don't even really follow myself.

Games published by our own members! Check 'em out!

[princec]

I used to do that Now I just moan about Java being shit because I can't use it on the BASTARD IPHONE. Grrr. etc.

Cas

[Captain Awesome]

I used to do that Now I just moan about Java being shit because I can't use it on the BASTARD IPHONE. Grrr. etc.

Cas

Moan on steve jobs instead for not supporting java lol.

[princec]

Jobsy doesn't actually mind Java at all. He's pretty good pals with Larry too. The problem was the legacy dealings Apple had with Sun. I have a feeling things might look a little rosier in the not too distant future.

Cas

[SimonH]

Just to satisfy my own curiosity I just did a quick test (1M add, get, remove) for generic and non-generic Vectors and found no appreciable time difference. Phew! I was hoping there wouldn't be!

[JL235]

Just dont bother! Stick to whats working for you and get something done before trying to optimize at this level. You wont get anywhere if you start this now. Trust me: "premature optimization is the root of all evil"

Okay, I will agree with this. Just stick with the Vector or whatever that you've got already.

But FYI, here is something like what I was referring to:

1   2   3   4   5   6   7   8   9   10   11   12   13   14

public class MonkeyArrayList extends ArrayList {     public Monkey get(int i)     {         return (Monkey) super.get(i);     }     public void add(Monkey m)     {         super.add(m);     }     //etc. }

I'm surprised others failed to pick up on this. 'public void add(Object value)' still exists, so your method fails to be a full replacement to Generics. Your method is only ever called if you know a Monkey is passed in at compile time as otherwise it'll bypass it and call the old add. For example...

1   2   3   4

MonkeyArrayList monkeys = new MonkeyArrayList();     monkeys.add( "a string" );     monkeys.add( 42 );     monkeys.add( new Monkey() );

The above is perfectly valid and successfully executes.

To be fair you will get an exception when calling 'get' due to the cast. But consider this: if a non-Monkey is in the list then the error must have occurred at the point where the non-Monkey is added to the list (it shouldn't have been added). Because the type error only occures when calling 'get' (on performing the cast) then you have moved the error away from where it has occured. The error is now more misleading as you'd expect everything inside of 'monkeys' to already be a Monkey.

Secondly you will also get an error when using an iterator or when using a foreach loop (I believe foreach loops are just iterators + syntax sugar). This is because the iterator calls 'get', but this is implementation specific! I could build a 'SpecialList' which returns an iterator which does not call 'get'. If the 'MonkeyArrayList' extends my 'SpecialList' then there should not be a runtime error when using iterators or foreach loops.

Generics does not suffer from these issues. Finally yours offers no compile time validation. Generics does.

[Eli Delventhal]

Very good point, I wrote this quickly without thinking. To take a real-world situation, have a look at BodyList from Phys2D. It isn't an ArrayList, it has an ArrayList. I honestly momentarily debated that with myself before typing the example, obviously I made the wrong choice. You definitely wouldn't want to subclass ArrayList, that would make no sense.

1   2   3   4   5   6   7   8   9   10   11   12   13   14   15   16   17   18   19   20   21   22   23   24   25   26   27   28   29   30   31   32   33   34   35   36   37   38   39   40   41   42   43   44   45   46   47   48   49   50   51   52   53   54   55   56   57   58   59   60   61   62   63   64   65   66   67   68   69   70   71   72   73   74   75   76   77   78   79   80   81   82   83   84   85   86   87   88   89   90   91   92   93   94   95   96   97   98   99   100   101   102   103   104   105   106   107   108   109   110   111   112   113   114   115   116   117   118   119   120   121   122   123   124   125   126   127   128   129   130   131   132   133   134   135   136   137   138   139   140   141   142   143   144   145   146   147   148   149   150   151

/*  * Phys2D - a 2D physics engine based on the work of Erin Catto. The  * original source remains:  *  * Copyright (c) 2006 Erin Catto http://www.gphysics.com  *  * This source is provided under the terms of the BSD License.  *  * Copyright (c) 2006, Phys2D  * All rights reserved.  *  * Redistribution and use in source and binary forms, with or  * without modification, are permitted provided that the following  * conditions are met:  *  *  * Redistributions of source code must retain the above  *    copyright notice, this list of conditions and the  *    following disclaimer.  *  * Redistributions in binary form must reproduce the above  *    copyright notice, this list of conditions and the following  *    disclaimer in the documentation and/or other materials provided  *    with the distribution.  *  * Neither the name of the Phys2D/New Dawn Software nor the names of  *    its contributors may be used to endorse or promote products  *    derived from this software without specific prior written permission.  *  * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND  * CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES,  * INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF  * MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE  * DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS  * BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY,  * OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,  * PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA,  * OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY  * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR  * TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT  * OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY  * OF SUCH DAMAGE.  */ package net.phys2d.raw; import java.util.ArrayList; /**  * A typed list of <code>Body</code>  *  * @author Kevin Glass  */ public class BodyList implements java.io.Serializable {    /** The elements in the list */    private ArrayList elements = new ArrayList();        /**     * Create an empty list     */    public BodyList() {          }        /**     * Create a new list containing the elements specified     *     * @param list The list of elements to add to the new list     */    BodyList(BodyList list) {       elements.addAll(list.elements);    }        /**     * Add a body to the list     *     * @param body The body to add     */    public void add(Body body) {       elements.add(body);    }        /**     * Get the number of elements in the list     *     * @return The number of the element in the list     */    public int size() {       return elements.size();    }        /**     * Remove a body from the list     *     * @param body The body to remove from the list     */    public void remove(Body body) {       elements.remove(body);    }        /**     * Get a body at a specific index     *     * @param i The index of the body to retrieve     * @return The body retrieved     */    public Body get(int i) {       return (Body) elements.get(i);    }        /**     * Clear all the elements out of the list     */    public void clear() {       elements.clear();    }        /**     * Check if this list contains the specified body     *     * @param body The body to look for     * @return True if this list contains the specified body     */    public boolean contains(Body body) {       return elements.contains(body);    }        /**     * Get a list of bodies containing all of the bodies in this     * list except those specified     *     * @param others The bodies that should be removed from the contents     * @return The list of bodies excluding those specified     */    public BodyList getContentsExcluding(BodyList others) {       BodyList list = new BodyList(this);       list.elements.removeAll(others.elements);             return list;    }        /**     * @see java.lang.Object#toString()     */    public String toString() {       String str = "[BodyList ";       for (int i=0;i<elements.size();i++) {          str += get(i)+",";       }       str += "]";             return str;    } }

[ReBirth]

Just dont bother! Stick to whats working for you and get something done before trying to optimize at this level. You wont get anywhere if you start this now. Trust me: "premature optimization is the root of all evil"

Thanks for the advice. Honestly I didn't bother this. My current small project is using ArrayList<Ball> (Ball is my own defined class) and it works well. I call get() every update() time so every Ball can draw themself and no lag.

I just want to know and take a glance about optimization for future need

Games published by our own members! Check 'em out!

[cylab]

I just want to know and take a glance about optimization for future need

Fair enough, but you should take a different approach:

- benchmark your code - maybe it's just fast enough
- profile your code to find bottlenecks (Use one of Netbeans, Yourkit, Visual VM, JProfiler etc.)

Use the result of the Profiler to

- replace components that are slow for your use case with fast ones - usually every component has strengths and weaknesses
- reduce "exponential" complexities (like nested loops)
- find another algorithm to do things that are slow (google is your friend:))

Usually performance problems exist on a completely different level than such micro-optimizations

[JL235]

Very good point, I wrote this quickly without thinking. To take a real-world situation, have a look at BodyList from Phys2D ...

Ah, through composure instead. Yeah, that works.

I actually used this method myself once in a library made. I also went further and wrapped an array instead of an ArrayList and then just resize it myself. There is a speed improvement, but the only real improvement you see if you also do this for primitive types.

However I added this to my own code a long time after writing it (not in the first case), I did need my library to run faster (you shouldn't optimize unless it's needed) and it's only seen internally. I'd maintain you should only ever optimize under those circumstances.

Considering that the original poster needed help on just how to use arrays; this kind of stuff is too advanced (and it's to early on in his code) to be suggesting.

[Eli Delventhal]

However I added this to my own code a long time after writing it (not in the first case), I did need my library to run faster (you shouldn't optimize unless it's needed) and it's only seen internally. I'd maintain you should only ever optimize under those circumstances.

I will agree with you. On JGO, I often get a little bit too academic about things. As I said above, I have never personally done this in any "actual" projects, because they are never my bottleneck.

[Riven]

I will agree with you. On JGO, I often get a little bit too academic about things.

I usually associate academic with fully thought through

Ask Kev his opinion of generics and you'll get much more fire and brimstone than from me. Personally I'm going to stop arguing now, since it's already been done many times before.

This is just condescending and ill informed.

[Eli Delventhal]

I will agree with you. On JGO, I often get a little bit too academic about things.

I usually associate academic with fully thought through

Ask Kev his opinion of generics and you'll get much more fire and brimstone than from me. Personally I'm going to stop arguing now, since it's already been done many times before.

This is just condescending and ill informed.

Hm... I was thinking academic more referring to talking over ideas and coming to a conclusion, but yes you're right in many cases I don't think an overly long time about what I'm saying. As for the condescension, it wasn't at all intended. And I don't think that was ill informed either. I just searched the forum for "generics" in posts by kevglass.

http://www.java-gaming.org/topics/type-compatibility-linkedlist/8132/msg/71311/view.html#msg71311

one of the benefits of not using generics, ick!

http://www.java-gaming.org/topics/please-vote-today/6441/msg/57663/view.html#msg57663

I don't like generics

http://www.java-gaming.org/topics/generics-good-or-bad/6164/msg/56424/view.html#msg56424

They're easy to misuse

http://www.java-gaming.org/topics/sun-s-crappy-generic-implementation/7180/msg/63294/view.html#msg63294

Just don't use generics. They're a move toward bad programming anyway

Now, I'm posting all this just to emphasize the impression I got from Kev, and not that I was trying to throw out wild opinions about what someone else thinks (which admittedly I am still doing to some extent). I will also be the first to point out that in many of the posts I quoted Kev's main point is not that generics themselves are bad, but that they allow programmers to do dumb things. So he doesn't like generics because of different reasons than I mentioned.

All that said, though, I am totally aware that I too often will evangelize a point I remember reading on this very forum, but I turn out to be mistaken. I get carried away with the interest of having a discussion. I will continue to try not to discuss something as an informed individual unless I do in fact know something about the subject from my own experiences. I will also point out that my skill as a software engineer has never lied in a deep knowledge of the compiler or the OS or anything like that as your knowledge is based in, Riven, but it is in making programs come together quickly and cleanly in an intelligent fashion. I usually only worry about the underlying mechanics of what I'm using if I need to know them. So, like I already said, I should probably stop giving advice about underlying mechanics and stick to giving advice about making games.

[JL235]

I usually only worry about the underlying mechanics of what I'm using if I need to know them. So, like I already said, I should probably stop giving advice about underlying mechanics and stick to giving advice about making games.

I (obiously) disagreed with bits, but I didn't think there was nothing wrong with your suggestion. You certainly shouldn't feel like you shouldn't make suggestion in an area.

[Eli Delventhal]

I usually only worry about the underlying mechanics of what I'm using if I need to know them. So, like I already said, I should probably stop giving advice about underlying mechanics and stick to giving advice about making games.

I (obiously) disagreed with bits, but I didn't think there was nothing wrong with your suggestion. You certainly shouldn't feel like you shouldn't make suggestion in an area.

Cool. I've just gotten burned one too many times for suggesting/saying something that wasn't completely correct.