

Groovy Array: it just keeps going...and going... - rbxbx
http://svn.codehaus.org/groovy/trunk/groovy/groovy-core/src/main/org/codehaus/groovy/runtime/ArrayUtil.java

======
jff
I just went to post that... can anybody explain to me what exactly is going
on? I'm not familiar with Groovy, and I try to forget Java when I can, but
this just plain doesn't make any sense.

~~~
akronim
They're aiming for compatibility with Java 1.4, which doesn't have varargs. In
java 1.5 you could just write

    
    
      public static Object[] createArray(Object... args) {
        return args;
      }

~~~
zmmmmm
I remember discovering this and deciding to eliminate it as part of an effort
to compress the groovy jar file a bit more (long story, but basically I was
running some Groovy in an applet, every byte counts).

I thought I'd found a jackpot and that killing this class would surely
eliminate a nice chunk of byte code. To my amazement it makes almost no
difference. With pack200 the redundancy of all these methods is totally
stripped out. It took me an hour or so of work and I think it made less than
200 bytes difference in the end.

------
briancarper
There are some similar horrors in the source code for Clojure.
[https://github.com/clojure/clojure/blob/master/src/jvm/cloju...](https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/IFn.java)

Java is a harsh mistress. This is why dynamic languages on the JVM are nice,
so I never have to write code like this myself.

~~~
Psyonic
I can't be sure, but in the Clojure case it appears to be done for performance
reasons. The final definition of invoke uses varargs for everything after 20,
so it's not an issue of compatibility.

------
tomn
This is what _comments_ were made for!

I'm sure it's legitimate, but you'd have to be insane to look at that code and
not question why it exists.

~~~
code_duck
One could also say you'd have to be sophomoric to assume the person who put if
there didn't do so for a good reason.

~~~
tomn
As I said, I'm sure that it's legitimate, but it's definitely not good code,
and I'd rather not have it lurking in my codebase for years on end. If you
don't know the original motivation behind writing something like that, you
can't really remove it for fear of the original bug cropping up again without
you noticing.

(I guess, then this is also what test cases are for...)

------
Groxx
I'm curious: Why don't people just use `new Object[]{arg1, arg2...}` ?

It's one letter longer than `createArray(arg1, arg1...)`, doesn't require you
to include that chunk of code, is _infinite_ in length, and allows you to
statically-type it in your type of choice. Heck, it's _the same code_ , just
removing a layer of indirection.

edit: noticed it's one character longer, not the same length. Maybe that's
why?

~~~
chrisbroadfoot
This isn't regular code. This is code for the groovy runtime.

~~~
Groxx
So, why don't the Groovy runtime programmers just write `new Object[]{arg1,
arg2...}` ?

~~~
tedunangst
I suspect this is code meant to be called by generated bytecode, and
generating the bytecode to call said function is easier than generating the
bytecode to make a new object[]?

~~~
wlievens
It's been a while since I generated JVM bytecode (oh my, five years), but I
don't recall there being array initializer instructions. In other words, the
new Object[] {...} statement probably translates to a whole bunch of array-
write operations on the caller side whereas with a method call you just push
them all on the stack and invoke the utility method.

------
chrisbroadfoot
It's probably generated. Here's a one-liner in Groovy to generate the class
body:

    
    
       (0..249).each { println "public static Object[] createArray(${(0..it).collect{'Object arg'+it}.join(', ')}) {\n\treturn new Object[]{\n\t\t${(0..it).collect{'arg'+it}.join(', ')}};\n}\n" }
    

Sorry it's not the most readable thing ;)

------
xiongchiamiov
Can't you use variadic function parameters?

    
    
        public static Object[] createArray(Object... args) {
            return args;
        }
    

I haven't done any Java in a while, so I'm just piecing this together from
StackOverflow examples (with compiling, of course).

~~~
Psyonic
Since Java 1.5, yes. Perhaps it's an issue of backwards compatibility.

------
emehrkay
I need to instantiate an array with 251 members. Guess I'm out of luck

------
robinduckett
And this is why I like dynamic languages.

~~~
brazzy
Groovy _is_ a dynamic language. This is what it has to do behind the curtains,
and even then only for backwards compatibility.

Your own favorite dynamic language is most likely doing worse things deep
inside the runtime code where you can't see it.

------
powertower
This is a good example of how projects turn out that are outsourced and get
billed by a lines-of-code metric.

(just as an example ... I'm aware that this is not the case here)

~~~
wlievens
If it's not a case here, how could this be a _good example_? This is an
example of generating code to work around a limitation. You can approve or
disapprove of the whole situation, but it does have technical merit.

