Why Java methods with varargs identified as transient?

Question

I was playing with Java Reflection API and observed that methods with variadic argument list become transient. Why is that and what does transient keyword mean in t

Answer 1

Sort of an answer can be found in the code of javassist AccessFlag

public static final int TRANSIENT = 0x0080;
public static final int VARARGS   = 0x0080;

It appears both have the same values. And since transient means nothing for methods, while varargs means nothing for fields, it is ok for them to be the same.

But it is not OK for the Modifier class not to take this into account. I'd file an issue about it. It needs a new constant - VARARGS and a new method - isVarargs(..). And the toString() method can be rewritten to include "transient/varargs".

Answer 2

The flag for a transient field has been overloaded in the context of a method to mean that the method is a vararg method.

Likewise, the flag for a volatile field has been overloaded in the context of a method to mean that the method is a bridge method.

See: http://java.sun.com/docs/books/vmspec/2nd-edition/ClassFileFormat-Java5.pdf

pages 118-122 (or 26-30 in the PDF file)

Update

Reading the source code for Modifier.java confirms the first sentence of this answer ("The flag for a transient field has been overloaded"). Here's the relevant source code:

// Bits not (yet) exposed in the public API either because they
// have different meanings for fields and methods and there is no
// way to distinguish between the two in this class, or because
// they are not Java programming language keywords
static final int BRIDGE    = 0x00000040;
static final int VARARGS   = 0x00000080;
static final int SYNTHETIC = 0x00001000;
static final int ANNOTATION  = 0x00002000;
static final int ENUM      = 0x00004000;
static final int MANDATED  = 0x00008000;

Answer 3

This looks like a bug in the implementation. I think that the root cause might be that the bit set in the .class file for transient fields is the same for varargs methods (see http://java.sun.com/docs/books/jvms/second_edition/ClassFileFormat-Java5.pdf, pages 122 and 119).