Estoy presentando un cambio de JNA que tiene en las versiones anteriores definido un conjunto de constantes como int
tipo, en concreto:
int VER_EQUAL = 1;
int VER_GREATER = 2;
int VER_GREATER_EQUAL = 3;
... etc...
(Ya que se definen en una interface
que son automáticamente static
y final
.)
Estas constantes se utilizan como Condition
argumento en el VerSetConditionMask función, que requiere un BYTE
argumento, asignada en JNA a Java byte
.
Para utilizar los existentes int
constantes en esa función sería de mí (y otros usuarios) a requerir explícitamente encasillado ellos, así que quiero cambiar estos valores constantes en la biblioteca para ser byte
, por ejemplo,
byte VER_EQUAL = 1;
byte VER_GREATER = 2;
byte VER_GREATER_EQUAL = 3;
... etc...
No creo que la compatibilidad de este cambio se rompe hacia atrás, ya que cualquier código que utiliza estas constantes se debe esperar que actualmente al menos una int
, y felizmente ampliar el byte
sin queja. He escrito un montón de código de prueba de convencerme de esto. Soy consciente de que el cambio de Object
tipos (como Integer
a Byte
) no funcionaría, pero yo creo que esto está muy bien para las primitivas. Sin embargo, a pesar de una hora buscando en la web para su confirmación, quedo de los más pequeños poco convencido.
Es este cambio compatible con versiones anteriores? O estoy equivocado y no es un caso en el que esto podría romper el código existente basándose en la int
primitiva?
Tal vez sea obvio. Pero tal vez no. Si un tercer usuario de la parte fue a buscar los int
valores y los almacena localmente en Integer
objetos, cambiando la int
que byte
va a causar un error de tiempo de compilación allí:
interface IntToByteWithInt
{
int VER_EQUAL = 1;
int VER_GREATER = 2;
int VER_GREATER_EQUAL = 3;
}
interface IntToByteWithByte
{
byte VER_EQUAL = 1;
byte VER_GREATER = 2;
byte VER_GREATER_EQUAL = 3;
}
public class IntToByte
{
public static void main(String[] args)
{
Integer a = IntToByteWithInt.VER_EQUAL;
// Type mismatch: cannot convert from byte to Integer
Integer b = IntToByteWithByte.VER_EQUAL;
}
}
Más allá de eso, creo que uno debe al menos mención de reflexión para la integridad.
También consideré el operador ternario ( https://docs.oracle.com/javase/specs/jls/se8/html/jls-15.html#jls-15.25.2 ) como candidato caliente, pero no alcancé a causa un error con que uno.