Java 8: mis primeros tropiezos

OK ya identifiqué el problema con slf4j. Realmente no es un problema con slf4j; no estoy seguro si esto era un defecto del compilador en Java 7, o simplemente hicieron más estricto el compilador en Java 8 o qué. Pero la causa del problema es que estoy pasando un solo argumento pero es genérico, es decir, tengo algo así:

Por qué lo tengo así? Pues porque antes de Java 5 lo tenía como   y tenía que hacer cast cada vez que lo llamaba de esta forma:

Pero con la nueva variante ya no es necesario el cast:

Pero al llamarlo directamente como argumento en los métodos de slf4j, efectivamente es ambiguo; podría ser Object, o podría ser Throwable. Ahora lo que no entiendo es, por qué el compilador de Java 7 no se quejaba de esto...

Mientras tanto ya registré el issue de Lombok.

Es la primera vez que liberan la versión para OSX al mismo tiempo.. super!

Tssssss, eso del SLF4J si está de terror. Osea que por ahora no hay mas que un mal workaround, seria definir explicitamente el  

O un utilisimo Monkey Patch

Con hacer un simple cast funciona también:   o incluso puedes hacer algo que no está muy padre pero funciona:   (con eso ya el compilador sabrá que quieres usar   y pues como nada más hay que hacer un reemplazo en el string, el null será ignorado).

Pero como ya dije antes, ahora que entiendo el error, lo que no entiendo es por qué no salía en Java 7 (ni 6 ni 5).

De hecho ya para mi ahorita es más grave lo de lombok que lo de slf4j (que realmente se puede generalizar pero se vuelve algo complejo de describir).

En Java 7 hay varios bugs relativos a la determinación del método más cercano (JLS sección 15.12). Seguramente los habrá en Java 8. Imagino que algunos se han arreglado. Pongo un ejemplo aun más sencillo que el de Enrique para ver que sucede lo contrario. Compílenlo con java 7 y con java 8, y ejecútenlo en el que compila

el problema en el segundo método (Character... args) para que llegue a compilar basta con pasarle una variable char o un Character  
- asi que me marcaria error cuando el paso es como secuencia de argumentos 1,'a' pero se supone que java hace la conversión a la matriz  
algún problema en el cast ??

Lo que se comenta son las diferencias en resolver el método más específico en las versiones diferentes de Java y los cambios que se realizan. para cada versión. ¿ya lo compilaste en Java 7 y en Java 8? Es bueno echarle un vistazo a 15.12.2.5. Choosing the Most Specific Method

tengo java 7 todavía pero mi comentario iva mas a los bugs de java 7 y si este problema llegue a catalogar como bug o es un comportamiento normal.
por ejemplo: 
pero esto no:  

Lo que comentas julgo no tiene que ver con la sobrecarga de métodos, ni tampoco es un bug. Lo que aplica en ese caso es el mecanismo de inboxing, el tratamiento de char como tipo aritmético y la promoción de tipos aritméticos. Las últimas dos están presentes en casi todos los lenguajes de programación y el inboxing funciona como debe ser: un Character "encajona" un char.

si ya se que no tiene que ver con la sobrecarga de métodos @bferro solo tome tu ejemplo y no me preocupe en cambiarle de nombre, y si un Character encajona un char asi como un Integer a un int , mi pregunta iva a la asignación que es valida de
Character ch=1; pero al invocar un método no pueda hacerse con método_imprime(1); donde el método sea  

Por supuesto que no puede hacerse. El mecanismo de inboxing es crear un objeto al vuelo que son instancias de las clases wrappers de los tipos, y lo hace con el constructor de esa clase  . Es importante entender la diferencia en la comprobación que hace el compilador referente a la posible pérdida de precisión cuando declara e inicializa una variable y cuando cuando comprueba esa posible pérdida de precisión en el momento que invoca una función pasando su argumento correspondiente.
El tipo char primitivo en Java es un caracter Uincode de 16 bits (2 bytes), con valores estrictamente positivos en el rango de  . En el momento que se declara una variable de tipo   y se inicializa con un literal entero, el compilador comprueba si no hay pérdida de precisión en la inicialización. Si hay pérdida rechaza tal incialización. Así,
 
es aceptado por el compilador, pero:
 
no es aceptado y marca un error. Recordemos que el tipo int ocupa 32 bits y es un tipo con signo.
La comprobación de posible pérdida de precisión es más estricta cuando se trata de pasar un argumento a una función. En ese caso el compilador atiende exclusivamente al tamaño del tipo de dato y no a su valor. Supongamos la siguiente función:
 
Al llamar a  , el compilador solamente comprueba que un valor de tipo int de 4 bytes no puede ser usado para inicializar un valor de tipo char. En esta comprobación no tiene en cuenta el valor preciso de int.
Por supuesto que si indicas una coerción (downcasting) explícita no habrá error:
 
compilará sin problemas.

-muy bien explicado @bferro la duda estaba relacionada en la forma como trabaja el compilador ya que asumia que en esos casos hacer el cast era innecesario. 
-pero ya veo que int es la elección predeterminada y no se pierde nada con hacer un metodo_para_shorts((short)1);
y sin ello no podrían hacerse métodos sobrecargados que reciban int y short por ejemplo ya que seria ambiguo invocándolos
metodoSobrecargado(1);

Por supuesto que se puede:
 

Java define notación para expresar el tipo de un literal entero (de tipo int), literales de tipo long, double, float, pero no define notación alguna para decir que un literal es de tipo short o tipo byte. La razón es que estos dos últimos tienen poco uso con respecto a los demás. Por esa razón, siempre será necesario realizar un casting cuando se desea una "democión" de un literal int, double, float o long a un literal de tipo byte, char o short.
Pero lo anterior no impide la sobrecarga de métodos.
 

digo que analizandolo bien si tiene sentido hacer la coerción y un int sea el predeterminado ya que de no ser asi invocando f1(1) , en un método sobrecargado habría problemas de ambigüedad   con eso queda mas claro como java trabaja con los tipos primitivos, en cuanto al tipo short tiene prácticamente poco uso como bien dices, tendrá ventajas significativas en comparación a int o doublé en determinados casos??? is more efficient to use short??, tal ves en otro post para no desviar el tema

Será que Bárbaro ya usa demasiado facebook? jejej

No entendí.

s/inboxing/autoboxing

es que siempre cuando me refiero a autobox, si lo meto siempre digo in box y cuando lo saco digo out box. Me hiciste reir.