8

현재 Java 컴파일러를 작성 중이며 15.12.2.7 절이 구현되었습니다. JLS7 (http://docs.oracle.com/javase/specs/jls/se7/html/jls-15.html#jls-15.12.2.7)의 가장 까다로운 섹션 중 하나 인 스펙이 어쨌든 명확하지 않거나 모호한 것처럼 보이기 때문에 여전히 한 가지 문제가 있습니다. 내 문제는 다음과 같습니다.자바 유형의 추론 방법

lcta (U) =? U의 상한이 Object이면, 그렇지 않으면? extends lub (U, Object)

U는 임의의 형식 표현식입니다. 형식 표현의 상한은 무엇입니까? 또한 lcta가 항상 와일드 카드 인 이유는 무엇입니까?

사양은

CandidateInvocation (G) = 협회 (인보이스 (G))을 정의한다.

예를 들어, Inv (G) = {List <String>} 인 경우, 즉 유일한 후보 호출은 단일 매개 변수화 된 유형입니다. 이제 규칙

협회 인해 (G < X1, ..., Xn에 >) = G < lcta (X1), ..., lcta (내지 Xn) >,

결과

목록 < lcta (문자열) 내 의견 >

, lcta는 간체해야 CandidateInvocation (G)는 협회 ({목록 < >이 문자열})로 정의된다 = return < 문자열 >이 유일한 호출 일 경우, < 문자열 >을 인수로 유추하는 것이 좋습니다. 그러나, lcta (U)의 정의는 그 결과가 어느 것인가를 나타냅니다. 또는? lub (...)를 확장하므로 항상 결과는 와일드 카드입니다. 이것은 이상하게 보입니다. 나는 여기서 무엇을 잘못 해석하고 있는가?

답변

1

내가 컴파일러-dev에 메일 링리스트에서 질문과 답변을받은 :

네, 사양은 여기에 잘못입니다. lcta (U)에 대한 규칙은 단순히 총 쓰레기입니다. :). 게다가 그들은 단일 인수에 대해 lcta (U)를 호출하지 말고 U를 사용하는 것이 더 낫다고 주장했다. (단일 인수 U의 최소 일반 형식 인수는 항상 U 자체 여야하기 때문이다.)

6

이것은 사양의 버그처럼 보입니다. lcta(U)의 절이 JSL3에 없습니다. JLS3의 lci(e1..en)에 대한 정의가 n=1 일 때 불완전하고 새로운 스펙이이를 수정하려고합니다. 그러나 당신이 생각한대로 수정 프로그램은 횡설수설 한 것처럼 보입니다.

Javac7은 lci({ List<String> })List<String>으로 계산하여 추가 된 절을 무시합니다.

이 문제는 사양 유지 관리자에게 제기해야합니다. 그들에게 연락하는 방법을 모르겠다. 당신은 openjdk 시도 할 수있다 compiler-dev 메일 링리스트; 그것에 지식이있는 사람들이 있습니다.

+0

저는 이제 lcta (U) = U를 구현하여 정상적으로 작동하는 것 같습니다. 이 구현이 놀라운 결과를 산출하는 경우를 발견하면보고 할 것입니다.그건 그렇고 : Object가 항상 U의 수퍼 클래스이므로 {U, Object}의 지워진 후보 MEC는 항상 U 또는 그 하위 클래스 중 하나를 산출해야하기 때문에 lub (U, Object)가 항상 U가 아닌가? 따라서,이 규칙은 실제로 완전하게 쓰레기입니다. 그것이 좋을지도 모르는 유일한 것은 변형입니다. Object를?로 확장합니다. 그러나 U는 유형 표현식이므로 와일드 카드를 포함 할 수 없으므로이 경우는 결코 발생하지 않을 수 있습니다 ... 정말 이상합니다. – gexicide

+0

메일 링리스트와 좋은 아이디어, 나는 그것을 거기에서 시험해 볼 것이다라고 생각한다 – gexicide

+0

나는 lub (U, Object) = Object – irreputable