Now we have decorator classes ReverseArray, RotateArray, SliceArray, ConcatArray for reverse, rotate, slice, concat.

it looks neat and elegant.

But, it presents another problem.
Suppose I have a loop in my code that'll do reverse, rotate, slice, concat repeatedly.
for calls to reverse 100 times, the Array object will be
ReverseArray
   ReverseArray
     ReverseArray
       ...
                           ReverseArray
                               arr

For arr.slice(1, 100).slice(2, 10), the result Array object will be
SliceArray [1, 100]
   SliceArray [2, 10]
       arr
for arr.rotate(2).reverse().roate(2), the result will be
RotateArray 
    ReverseArray
       RotateArray
         arr
But, for the first case, we all know it's equivalent to arr itself.
For the second case, we all know it's equivalent to arr.slice(3, 10)
For the third case, we all know it's equivalent to arr.reverse()

Similar consideration applies to Concat. 

How can we avoid some kind of stupidity?

For reverse/ReverseArray, this is easy. You just return a straight array in the reverse method of the ReverseArray, since the reverse of a reverse is straight. This will eliminate the overhead of get/set method, but cannot avoid generating a lot of garbage objects.
For the rest, I'm not sure, it depends on whether two successive operations can be simplified into one. If yes, then it's easy like the ReverseArray. Otherwise we'll need some serious consideration, since introducing new Arrays that embed two successive operations is a lot of work, and their reverse/slice/etc methods will need to be optimized too.
Anyway, the general idea is that the reverse/slice/etc methods of the ReverseArray/SliceArray/etc classes represent two successive operations, and you should optimize accordingly.

the problem is: it's a very specified case, how about 
a.reverse().rotate().slice(x, y)...many steps in between..rotate() ?

BTW, virtual functions are faster than if-else if the numbers are large ( as switch are faster than if-else with lots of conditions).

我的构想是：每个RotateArray、ReverseArray都在内部保留一个State对象，在State内部封装下标变换逻辑；每次调用，将其内部State压入一个队列排队，如连续出现两次相同的状态，则移除；最后，使用Command模式来执行（依次调用队列中剩下State的下标变换逻辑）。
因没有时间实现，写出想法，不知是否可行，请多指教。

i.c.
My mean is that we cann't get the nead info from the java expression:
  arr.slice(1, 100).rotate(2).slice(2, 10).rotate(2);
Will u keep the status after calling each mothed?

If you can't express reverse+rotate in another single operation, then a class like RevRotateArray MAY have its place, but I'm not sure if this is a good idea, please see 2nd paragraph in my post. 

As I said, if two operations can be simplified into one, like reverse+reverse=identity, then it's trivial, something like ReverseArray.reverse() = IdentityArray can solve it. If not, then I don't have a clear idea what to do, just some observations. For example, if we introduce RevRotateArray, then its reverse method can be optimized, since reverse+rotate+reverse=rotate, and we just need RevRotateArray.reverse() = RotateArray.

我总觉得引入太多的新对象不是太好的解决办法，但这个问题确实很棘手。
期待一个大家都满意的解决方案！

lazy evaluation doesnt means no evaluation. 
let's say :
array a[n]; // n>m
array b= a.reverse().slice(m).reverse().rotate()......

can you give me a answer what b[0] is in a generic way?

btw, lazy evaluation can be removed by reorder the sequence of execution. take a look at those functional languages and you will know java are lightyears behind in this area.

呵呵，谢谢指点，我也知道反射效率极低，有时也是不得已而为之，我一般在两种情况下用反射：
1、如JDBC必须用Class.forName()来实例化一个不确定的类一样，我封装了一些东西，必须如此施为。
2、长篇累牍的if else是破坏代码清晰和可维护性一个大敌，我只能牺牲性能，来取得维护的方便。
毕竟，OO的精神首先强调的不是性能，而是清晰可维护。对于目前的B/S应用而言，Server端消耗的一小段时间片，对于窄带时代漫长的传输消耗来说，是微不足道的。：）
个人意见，还望赐教