Yes, a T... is only a syntactic sugar for a T[].

JLS 8.4.1 Format parameters

The last formal parameter in a list is special; it may be a variable arity parameter, indicated by an elipsis following the type.

If the last formal parameter is a variable arity parameter of type T, it is considered to define a formal parameter of type T[]. The method is then a variable arity method. Otherwise, it is a fixed arity method. Invocations of a variable arity method may contain more actual argument expressions than formal parameters. All the actual argument expressions that do not correspond to the formal parameters preceding the variable arity parameter will be evaluated and the results stored into an array that will be passed to the method invocation.

Here's an example to illustrate:

public static String ezFormat(Object... args) {
    String format = new String(new char[args.length])
        .replace("\0", "[ %s ]");
    return String.format(format, args);
}
public static void main(String... args) {
    System.out.println(ezFormat("A", "B", "C"));
    // prints "[ A ][ B ][ C ]"
}

And yes, the above main method is valid, because again, String... is just String[]. Also, because arrays are covariant, a String[] is an Object[], so you can also call ezFormat(args) either way.

See also

• Java language guide/varargs

Varargs gotchas #1: passing null

How varargs are resolved is quite complicated, and sometimes it does things that may surprise you.

Consider this example:

static void count(Object... objs) {
    System.out.println(objs.length);
}

count(null, null, null); // prints "3"
count(null, null); // prints "2"
count(null); // throws java.lang.NullPointerException!!!

Due to how varargs are resolved, the last statement invokes with objs = null, which of course would cause NullPointerException with objs.length. If you want to give one null argument to a varargs parameter, you can do either of the following:

count(new Object[] { null }); // prints "1"
count((Object) null); // prints "1"

Related questions

The following is a sample of some of the questions people have asked when dealing with varargs:

• bug with varargs and overloading?
• How to work with varargs and reflection
• Most specific method with matches of both fixed/variable arity (varargs)

Vararg gotchas #2: adding extra arguments

As you've found out, the following doesn't "work":

    String[] myArgs = { "A", "B", "C" };
    System.out.println(ezFormat(myArgs, "Z"));
    // prints "[ [Ljava.lang.String;@13c5982 ][ Z ]"

Because of the way varargs work, ezFormat actually gets 2 arguments, the first being a String[], the second being a String. If you're passing an array to varargs, and you want its elements to be recognized as individual arguments, and you also need to add an extra argument, then you have no choice but to create another array that accommodates the extra element.

Here are some useful helper methods:

static <T> T[] append(T[] arr, T lastElement) {
    final int N = arr.length;
    arr = java.util.Arrays.copyOf(arr, N+1);
    arr[N] = lastElement;
    return arr;
}
static <T> T[] prepend(T[] arr, T firstElement) {
    final int N = arr.length;
    arr = java.util.Arrays.copyOf(arr, N+1);
    System.arraycopy(arr, 0, arr, 1, N);
    arr[0] = firstElement;
    return arr;
}

Now you can do the following:

    String[] myArgs = { "A", "B", "C" };
    System.out.println(ezFormat(append(myArgs, "Z")));
    // prints "[ A ][ B ][ C ][ Z ]"

    System.out.println(ezFormat(prepend(myArgs, "Z")));
    // prints "[ Z ][ A ][ B ][ C ]"

Varargs gotchas #3: passing an array of primitives

It doesn't "work":

    int[] myNumbers = { 1, 2, 3 };
    System.out.println(ezFormat(myNumbers));
    // prints "[ [I@13c5982 ]"

Varargs only works with reference types. Autoboxing does not apply to array of primitives. The following works:

    Integer[] myNumbers = { 1, 2, 3 };
    System.out.println(ezFormat(myNumbers));
    // prints "[ 1 ][ 2 ][ 3 ]"

Actually, because for compatibility reasons, the signature of a method, which is using varargs function(Object... args) is the equivalent of a method declared with an array function(Object[] args).

Therefore in order to pass and spread any collection to function which expects varargs, you need to transform it to the array:

import java.util.Arrays;
import java.util.stream.Stream;

public class MyClass {
  
  static void printMany(String ...elements) {
     Arrays.stream(elements).forEach(System.out::println);
  }
  
  public static void main(String[] args) {
    printMany("one", "two", "three");
    printMany(new String[]{"one", "two", "three"});
    printMany(Stream.of("one", "two", "three").toArray(String[]::new));
    printMany(Arrays.asList("foo", "bar", "baz").toArray(new String[3]));
  }
}

All these calls of printMany will print:

one

two

three

It's not exactly the same as spread operator, but in most cases, it's good enough.

Use

yourDataStructure.addAll(Arrays.asList(arrayOfObjects));

this makes use of the addAll() method with a Iterable<Some_Type> you mentioned in your question.

This is a typical example of an "X-Y Problem". Your original quest was to somehow group the 3 different parameters that you want to pass to a function. That's "problem X". Then you came up with the idea of using an array for this, but you were still unsure how to go about it, so you posted this question asking how to best use an array to achieve what you want. But that's "problem Y", not "problem X".

Using an array may and may not be the right way of solving "problem X". (Spoiler: it isn't.)

Honoring the principle of the least surprise, the best way of solving your problem "X" in my opinion is by declaring a new class, FloatRgba which encapsulates the four floats in individual float members: final float r; final float g; final float b; final float a;.

So, then your rgbToFloat() method does not have to return an unidentified array of float, instead it becomes a static factory method of FloatRgba:

public static FloatRgba fromIntRgb( int r, int g, int b ) 
{
    return new FloatRgba( r / 255f, g / 255f, b / 255f, 1.0f );
}

Finally, you introduce a utility function prepareRenderer which accepts a Renderer and a FloatRgba and invokes renderer.prepare(float, float, float, float) passing it the individual members of FloatRgba.

This way you keep everything clear, self-documenting, and strongly typed. Yes, it is a bit inconveniently verbose, but that's java for you.

You can do this with reflection, but it's probably more performant to use cached method handles that you initialize once, then reuse as many times as you need.

class SpreadInvoker {
    public static void draw1(int x, String y) {
        System.out.printf("draw1(%s, %s)%n", x, y);
    }

    public void draw2(int x, int y) {
        System.out.printf("draw2(%s, %s)%n", x, y);
    }

    static MethodHandle DRAW1;
    static MethodHandle DRAW2;

    public static void main(String[] args) throws Throwable {
        DRAW1 = MethodHandles.lookup()
                             .findStatic(
                                 SpreadInvoker.class,
                                 "draw1",
                                 MethodType.methodType(
                                     void.class,
                                     int.class,
                                     String.class
                                 )
                             )
                             .asSpreader(Object[].class, 2);

        DRAW2 = MethodHandles.lookup()
                             .findVirtual(
                                 SpreadInvoker.class,
                                 "draw2",
                                 MethodType.methodType(
                                     void.class,
                                     int.class,
                                     int.class
                                 )
                             ).asSpreader(Object[].class, 2);

        SpreadInvoker instance = new SpreadInvoker();

        final Object[] args1 = { 13, "twenty-six" };
        final Object[] args2 = { 13, 26 };

        DRAW1.invoke(args1);           // SpreadInvoker.draw1(13, "twenty-six")
        DRAW2.invoke(instance, args2); // instance.draw2(13, 26)
    }
}

Output:

draw1(13, twenty-six)
draw2(13, 26)

Note, however, that this is the sort of thing you'd do if you don't know what method you need to call at compile time. This sort of thing should almost never be necessary.