Ordem em que a JVM chama métodos sobrecarregados de uma classe

Programação Java
#1

Estou precisando de uma ajuda para entender melhor a ordem em que a JVM chama os métodos sobrecarregados de uma classe, sendo que estes métodos possuem argumentos de tipo primitivo, de tipo Wrapper e var-args.

Fiz um código de teste, e vi que a JVM chama nessa ordem: Tipo primitivo ----> Classes Wrapper -----> Var-args. A ordem é essa mesma?

public class A {

	void go(int x) { 
		System.out.print("argumento de tipo primitivo int"); 
	}
	
	void go(long x) {
		System.out.println("argumento de tipo primitivo long");
	}
	
	void go(int... x) {
		System.out.println("argumento de tipo primitivo int com var-args");
	}
	
	void go(long... x) {
		System.out.println("argumento de tipo primitivo long com var-args");
	}
	
	void go(Integer x) {
		System.out.print("argumento de tipo Integer"); 
	}
	
	void go(Long x) {
		System.out.print("argumento de tipo Long"); 
	}
	
	void go(Integer... x) {
		System.out.print("argumento de tipo Integer com var-args"); 
	}
	
	void go(Long... x) {
		System.out.print("argumento de tipo Long com var-args"); 
	}
	 
	public static void main(String[] args) {
	
		A a = new A();
		a.go(10);
	}
}

Obs: Quando comentei os métodos void go(int x), void go(long x) e void go(Integer x) obtive o seguinte erro de compilação: The method go(int[]) is ambiguous for type A. Alguém pode me ajudar?

#2

A JVM prefere a ampliação do que o autoboxing ou varargs…

Daí vem a dúvida e se tiver dois metodos um que tem q fazer auto-boxing e outro q tem var-args,
a jvm vai escolher o auto-boxing, pois o var-args é muito abrangente ele aceita de 0 a muitos argumentos, então fik na lógica que quanto maior for a abrangência ele deve ficar por último, para não deixar os outros métodos inutilizáveis.

#3

Não me lembro de cabeça das regras, mas isso cai na SCJP. procura material sobre a certificação q lá tem a ordem. no livro da katty sierra, é no capitulo 3 se não me engano.

#4

é, realmente é muito estranho

a ambiguidade ocorre entre os métodos var-args que passam (int… x) e (Integer…x)
eu não sei o porque isso não é detectado antes, só quando a JVM tem somente os dois como opção que ocorre esse erro

espero que alguém saiba kkkkkkkk

#5