Java ArrayList 1.7

http://www.docjar.com/html/api/java/util/ArrayList.java.html


  374       /**
  375        * Returns the element at the specified position in this list.
  376        *
  377        * @param  index index of the element to return
  378        * @return the element at the specified position in this list
  379        * @throws IndexOutOfBoundsException {@inheritDoc}
  380        */
  381       public E get(int index) {
  382           rangeCheck(index);
  383  
  384           return elementData(index);
  385       }

 596       /**
  597        * Checks if the given index is in range.  If not, throws an appropriate
  598        * runtime exception.  This method does *not* check if the index is
  599        * negative: It is always used immediately prior to an array access,
  600        * which throws an ArrayIndexOutOfBoundsException if index is negative.
  601        */
  602       private void rangeCheck(int index) {
  603           if (index >= size)
  604               throw new IndexOutOfBoundsException(outOfBoundsMsg(index));
  605       }


What's the point of having a range check if it only checks if the index is >= to the size and not if it's < 0. This seems stupid and a waste of a method call.



  171       /**
  172        * Increases the capacity of this <tt>ArrayList</tt> instance, if
  173        * necessary, to ensure that it can hold at least the number of elements
  174        * specified by the minimum capacity argument.
  175        *
  176        * @param   minCapacity   the desired minimum capacity
  177        */
  178       public void ensureCapacity(int minCapacity) {
  179           if (minCapacity > 0)
  180               ensureCapacityInternal(minCapacity);
  181       }
  182  
  183       private void ensureCapacityInternal(int minCapacity) {
  184           modCount++;
  185           // overflow-conscious code
  186           if (minCapacity - elementData.length > 0)
  187               grow(minCapacity);
  188       }

ensureCapacity is never called, yet they have it in the class.


BLOAT

The only thing that disadvantages java over seeples and C, is the inability to specify manual memory allocation. You can use garbage collection in seeples and see if you leverage a library for it, and use strict conventions about pointers if it happens to be a copying collector. But this takes effort, and not many people do it, and it doesn't eliminate memory errors, since you can still do manual memory management on the side, and arbitrary things with pointers. So when one programs in see and seeples, they are much more likely to use stack allocation and malloc/free to meet their needs. In java, one is unable to explicitly specify usage of the stack or manual memory management, so it rests with an optimizing compiler to avoid the gc when possible. It isn't too difficult to detect when a value can be allocated on the stack in some cases, like


double length = new Vector(x, y, z).magnitude();

The result of new Vector(x, y, z) is never saved anywhere, so it is impossible for a reference to it to exist after the running function returns, or after that expression is done being evaluated for that matter.

Getting a compiler to detect ownership rules and institute manual memory management could be difficult to do in general. I'm not sure if people try to do this. This would require looking at the entire program as a whole, and using data flow analysis to examine where values can go. This would be difficult, but I'm sure it could be done for many simple usage cases. Detecting when reference counting would be sufficient is probably much easier, and would likely yield results that are just as good.