Java variable parameter list
The code copy is as follows:
class A {}
Since all classes are inherited from Object, you can use the Object array as a parameter:
public class parameter { static void printArray(Object[] args){ for(Object obj : args){ System.out.print(obj + " "); } System.out.println(); } public static void main(String[] args){ printArray(new Object[] { new Integer(47), new Float(3.14), new Double(11.11) }); printArray(new Object[]{"one", "two", "there"}); printArray(new Object[]{new A(), new A(), new A()}); }} For Java SE5 versions after adding features, you can write this:
public class parameter { public static void printArray(Object... args){ for(Object obj : args){ System.out.print(obj + " "); } System.out.println(); } public static void main(String[] args){ printArray(new Integer(47), new Float(3.14), new Double(11.11)); printArray(47, 3.14F, 11.11); printArray("one", "two", "three"); printArray(new A(), new A(), new A()); printArray((Object[]) new Integer[]{1, 2, 3, 4}); printArray(); }} You can use Object to think of the parameter list:
public class VarargType{ static void f(Character... args){ System.out.print(args.getClass()); System.out.println(" length " + args.length); } static void g(int... args){ System.out.print(args.getClass()); System.out.println(" length " + args.length); } public static void main(String[] args){ f('a'); f(); g(1); g(); System.out.println(" int [] " + new int[0].getClass()); }}This is a feature introduced in Java 5. If the number of parameters a method wants to receive is uncertain, then this feature can come in handy.
For example, where IO operations are involved, you basically need to close at least two streams: input and output. I like to encapsulate the stream closing operation into the following method, so that multiple streams can be closed in just one call.
public static void closeSilent(Closeable... closeables) { for (Closeable closeable : closeables) { if (closeable != null) { try { closeable.close(); } catch (IOException ignored) { } } }}This is the only place I think this feature is suitable for use, with the following features:
These parameters have the same type;
The number of parameters is uncertain, each is optional;
The uses of these parameters are the same, for example, the above are all executed closing.
The Java variable-length parameter list can only be placed at the end of the method parameter list.
Implementation of Java variable-length parameter list
The implementation of Java variable-length parameter list is passed through the compiler to encapsulate these parameters into an array.
For example, the signature of the above method is actually: closeSilent(Closeable[] closeables) void.
Step on a pit
There is a method that is called by A and B in two places. In September, a parameter needs to be added to A. When my mind was crazy, I decided to use a variable-length parameter list. I felt that there was no need to change it to B, so the pit was buried.
Recently, we have asked B to add two new parameters here, so we continue to add parameters to the method's parameter list. The types of these parameters are different, so the variable-length parameter list is declared as Object type.
The first pit is that when taking elements with variable-length parameters in this method, it does not take into account that some parameters are not passed, and the array is offside exception is directly destroyed. I immediately felt that the variable-length parameter list was not good, so I didn’t need it, and changed it to a regular fixed-form parameter passing.
After the modification, it is fine to test it in the test environment. After replacing several classes in the production environment, the result is an error. The method cannot be found. It depends on the method signature, but it is an array, and it has not been replaced. Judging from the source code, the call location does not need to be changed, so I didn't expect to replace it; since the test environment is fully packaged, there will be no problems.
The signature of the method is determined at the time of compilation. The source code level does not seem to require modification, but does not mean that the compiled class does not need to be replaced.
In fact, I have heard before that in this case of irregular packages, after changing a constant value in the source code, only the class file that defines the constant is replaced, and no recompiling and replacing all class files that reference this constant is possible, resulting in inexplicable problems. It is essentially the same problem as the method signature.