Java 7 컴파일 된 코드를 Java 8로 업그레이드하면 어떤 이점이 있습니까?

Java 7을 사용하여 작성된 오래된 응용 프로그램이 있습니다. Java 8 JRE에서 제대로 실행됩니다. Java 8 기능을 사용하기 위해 코드를 다시 작성할 계획은 없습니다. 컴파일 된 코드를 최신 Java 8 JDK로 업그레이드하면 기술적 인 이점이 있습니까?

분명히하기 위해 코드는 현재 Java 7로 컴파일되어 있으며 최신 Java 8 JRE로 이미 실행 중입니다. Java 8 런타임 개선의 이점이 이미 있습니다. 이 질문은 버전 8로 컴파일하고 Java 8 컴파일 된 바이트 코드로 실행하여 이점을 얻을 수 있는지 여부입니다.

또한 개발자 생산성과 같은 비 기술적 이점에 대해서는 걱정하지 않습니다. 나는 이것이 중요하지만이 질문의 요점은 아니라고 생각합니다. 개발 팀이없는 프로덕션 코드를 요구합니다. 순전히 유지 관리 모드입니다.

질문을 올바르게 이해하면 javacJava 8에서 생성 된 바이트 코드 가 Java 7보다 "더 나은"지 여부를 알고 싶습니다 .

대답은 아마 아닐 것입니다. 컴파일러의 버그를 지속적으로 수정하고 때로는 더 효율적인 바이트 코드로 이어집니다. 그러나 내가 볼 수있는 한 Java 8에 대한 수정 사항으로 인해 속도가 크게 향상되지는 않습니다. 변경 로그 에는 버전간에 2 가지 주요 변경 사항 만 나열됩니다.

오라클 웹 사이트는 끔찍하며 javac버전간에 관련된 버그 수정 목록을 얻을 수없는 것 같지만 OpenJDK의 철저하지는 않습니다 . 내가 찾을 수있는 대부분은 오류를 수정하는 것입니다. 따라서 Java 8로 업데이트 javac하면 JLS 를 더 정확하게 따르기 때문에 더 이상 컴파일되지 않을 가능성 이 있으며 바이트 코드에 대한 "개선"이 거의 없습니다.

주요 이점은 Java 8에 Java 7이 공개적으로 업데이트되지 않는 최신 버그 수정이 있다는 것입니다.

또한 Java 8 JVM에서 코드를 실행하려는 경우 Java 버전이 하나만 설치되어있을 수도 있습니다.

Java 8이 더 빠를 수 있으며 G1과 같은 새로운 기능을 더 잘 지원합니다. 그러나 유스 케이스의 경우 속도가 느려질 수 있으므로 테스트하는 것이 유일한 방법입니다.

컴파일 된 코드를 최신 Java 8 JDK로 업그레이드하면 기술적 인 이점이 있습니까?

Java 8 컴파일러에서 Java 7 코드를 다시 컴파일 할 때 어떤 이점이 있는지 묻는다면 그 대답이 있습니다. 거의 아무것도.

유일한 미묘한 차이점은 Java API에 약간의 차이가 있다는 것입니다. 따라서 Java 8 컴파일러가 Java 7에서 발견 할 수있는 미묘한 차이점이있을 수 있습니다

다른 사소한 차이점은 파일 시작시의 마법 번호, 아마도 상수 풀의 순서입니다. 바이트 코드는 기본적으로 동일 invokedynamic합니다. 람다에 대한 추가 지원조차도 Java 7에 존재했지만 그렇게 사용되지 않았습니다.

인식 을 만들어 도움을 줄 수 있습니다.

Java8로 전환하면 javac에서 추가 경고가 표시 될 수 있습니다. 예 : Java8에서는 형식 유추 가 크게 향상되었습니다. 따라서 현재 코드베이스에서 @SuppressWarnings 주석이 필요하지 않을 수 있습니다 (이러한 주석이 더 이상 필요하지 않으면 컴파일러가 경고합니다).

따라서 오늘날 코드베이스를 수정하지 않더라도 Java8로 전환하면 그러한 정보를 알 수 있습니다. 지식을 늘리면 정보에 입각 한 결정을 내리는 데 도움이 될 수 있습니다.

반면에 :

• Java8이 Java7 코드 컴파일을 거부 한 (드문) 상황에 대한 몇 가지 질문이 있습니다. 따라서 Java8로 전환하면 이러한 종류의 문제가 발생할 위험이 최소화됩니다.
• 그리고 오늘 코드 기반을 건드리지 않으려는 경우에도 나중에 마음이 바뀔 가능성이 있습니다. 그런 다음주의를 기울이지 않으면 Java8 기능을 이용할 수 있습니다. 어떤 수 "필드 업데이트"를 복잡하게; 당신은 지금 가지고있는 두 개의 유지하기 위해 소스 코드의 버전을!
• 그런 다음 : java7 jre를 사용하여 제품을 실행하는 고객이있는 경우; 당신이 그들에게 제공하는 바이너리 픽스에 대해 정말로 조심해야한다. 우리는 그러한 설정을 가지고 있습니다. 실수로 단일 Java8 컴파일 클래스를 Java7 기반 테스트 시스템에 배치했기 때문에 시간이 두 번 이상 낭비되었습니다. 개발자 및 테스트 / 고객 설정이 모두 Java7 인 경우에는 간단하게 발생할 수 없습니다.

간단히 말해 : 몇 가지 미묘한 장점과 특정 위험 (위험의 중요성이 주로 전체 설정에 달려 있음)이 있습니다.

나는 적어도 이러한 사실을 위해 할 것입니다 .

1) HashMap 내부 (jdk-8에서는 더 빠름)

2) 수정 된 버그 많은 수 당신이 실제로 아무것도하지 않고 빠르고 더 나은 코드를 만들 것 (런타임 최적화를위한 투명).

3) G1 가비지 콜렉터

편집하다

기술적 인 관점에서 이것은 Ahead of Time Compilation과 관련이 있거나 코드를 더 분석하여 컴파일러가 개선 할 수있는 것과 비슷합니다 . 내가 아는 한 그러한 것은 Java 8 컴파일러에서 수행되지 않습니다.

개발자의 관점에서 볼 때 많은 것이 있습니다. 생산성 향상이 가장 중요합니다.

편집 2

두 번째 쿼리와 일치하는 두 가지 점만 알고 있습니다.

– 매개 변수

메소드 매개 변수 이름을 보존합니다.

-프로필

더 작은 설치 공간을 위해 컴팩트 프로파일 옵션 이라고합니다 .

응용 프로그램을 다시 컴파일 해야하는 다른 이유가 없다면 허용 된 답변에 명시된 것처럼 큰 차이가 없을 것입니다.

그러나 한 번만 다시 컴파일해야하는 경우 다음을 고려하십시오.

• 애플리케이션 소스 코드는 Java 7과 호환되며 대부분 8 과도 호환됩니다.
• 코드가 Java 8로 컴파일되지 않는 경우 Java 7 소스 호환 모드 ( -source 7javac 사용) 에서 Java 8 컴파일러로 컴파일되지 않을 것입니다 .
• 개발자와 CI는 가능한 한 프로덕션 환경에 가깝도록 Java 8 런타임에 대해 단위 및 통합 테스트를 실행해야합니다. 개발자는 응용 프로그램을 로컬로 실행할 때 동일한 Java 8 런타임에서 응용 프로그램을 실행해야합니다.
• 동일한 버전으로 모든 것을 수행하는 것보다 JDK 7로 컴파일하고 JRE 8 (동일한 빌드 프로세스 또는 동일한 IDE에서)로 실행하는 것이 더 어렵습니다.
• JDK 8로 컴파일하고 대상 런타임이 Java 8 -source 7인 -source 8경우 대신 사용 하면 이점이 없습니다 .
• 를 사용 -source 8하면 개발자가 컴파일 및 런타임 모두에 Java 8 이상을 사용하고 있음을 보장 할 수 있습니다 (강제로 -target 8).

결론적으로, 필요하지 않으면 다시 컴파일하지 마십시오. 그러나 처음에는 코드 변경으로 인해 다시 컴파일해야하고 Java 8로 전환해야합니다. 환경 불일치로 인해 버그가 발생할 위험을 감수하지 말고 적절한 이유없이 개발자를 제한하지 마십시오.