Java 1.4.2에서 Java 5로 중간 규모 코드 기반을 마이그레이션하기위한 전략

Question

코드 기반 (~ 20K LOC)을 검토하고 1.4.2에서 5로 마이그레이션하는 방법을 결정하는 중입니다. 당연히, 그것은 밤새 프로젝트가 아니며 내가받은 제안은 Java 5에 대한 새로운 코드를 작성하고 이전 코드를 조각 식 방식으로 마이그레이션하는 것입니다. 또한 Java 5의 새로운 기능에 대한 전문 지식이 없습니다 (즉, 해당 기능을 알고 있지만 프로덕션 용도로 작성한 적이 없습니다).

내 질문 :

1. 자바 5의 기능은 무엇 일반적으로 생산 코드에 사용되는? (즉, 제네릭, 자동 권투 등) 모범 사례로 간주되지 않거나 피할 수있는 기능이 있습니까?

2. 이 크기의 코드 기반을 마이그레이션하는 데 사용할 수있는 최상의 리팩토링 전략은 무엇입니까? (즉, 클래스가 편집 될 때만 한 번에 하나씩 클래스를 변경합니다.) 목표 - 코드 기반의 위험을 줄입니다. 제한 - 리팩토링을 수행 할 리소스.

미리 감사드립니다.

업데이트 - 너무 늦었지만 결코 늦지 않는 것이 더 좋습니까? =)

많은 의견을 보내 주셔서 감사합니다. 소프트웨어 개발자의 삶에는 끝내기 위해 노력하고 항상 "긴급한"것 때문에 주위를 둘러 보지 않으려 고 노력하는 프로젝트가 항상있을 것입니다. 그것이 우리가 자바 6.

을 사용하지 않은 이유를했다 그래서 (그 당시) 자바 5의 사용과 관련하여

는, 내가 강한 것을 발견, 클라이언트의 생산 환경에서 요구 된 일을했다 열거 형 및 열거 형에 대한 입력은 기본 코드와 새 코드 모두에 가장 많이 적용되는 기능이었습니다. 리팩토링은 상당히 간단했지만 코드 이해도가 크게 향상되었으며 표준을 적용하기가 더 쉬워졌습니다. 내가 가장 어려웠던 것은 제네릭이었습니다. 제 생각에는 아직 이해할 기회가 아직 없었기 때문에 제네릭 적용이 적절한 이전 사례를 찾기가 어려웠습니다.

이 스레드에 기여한 사람과 늦은 후속 조치에 사과하신 모든 분들께 다시 한번 감사드립니다.

Answer 1

자바 5는 거의 완전하게 호환 일반적으로 자바 4. 당신이 자바 4 코드에서 새로운 enum 키워드의 용도로 이름을 변경하는 것입니다 해야 메이크업을 마이그레이션 할 수있는 유일한 변화입니다.

잠재적 인 호환성 문제의 전체 목록은 여기에 나열됩니다 :

http://java.sun.com/j2se/1.5.0/compatibility.html

내가 연습에 실행 한 유일한 다른 하나는 JAXP 구현의 변화와 관련되어있다. 이 경우 단순히 클래스 경로에서 xerces.jar을 제거해야합니다.

리팩토링에 관한 한, 컬렉션 클래스를 새로운 강력한 형식의 제네릭 버전을 사용하고 불필요한 캐스팅을 제거하도록 마이그레이션하는 것이 좋습니다. 그러나 다른 포스터가 지적했듯이 제네릭 컬렉션을 변경하면 세로 조각으로 작업하는 것이 가장 효과적입니다. 그렇지 않으면 일반 형식을 비 제네릭 형식과 호환되도록 코드에 형 변환을 추가해야합니다.

코드를 마이그레이션 할 때 사용하는 또 다른 기능은 @Override 주석입니다. 코드를 리펙토링 할 때 상속 문제를 잡는 데 도움이됩니다.

http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Override.html

새로운 동시성 라이브러리

는 코드 스레딩을 사용하는 경우 매우 유용합니다. 예를 들어 자생 스레드 풀을 ThreadPoolExecutor으로 바꿀 수 있습니다.

http://java.sun.com/j2se/1.5.0/docs/relnotes/features.html#concurrency

나는 확실히 당신이 정상 유지 보수시 변경으로 코드를 업데이트하는 방법을 걸릴 것이다. 호환성 문제 외에도, 다른 이유로 코드를 변경하지 않는 한 새로운 Java 5 기능을 사용해야 할 강력한 이유가 있다고 생각하지 않습니다.

Answer 2

제네릭의 "바이러스 성"특성과 관련된 한 가지 실제 문제가 있습니다. 아키텍처의 특정 레이어에 이들 레이어를 추가하기 시작하면 일반적으로 아래의 레이어에 소개하기를 원합니다. & 제네릭을 도입하는 것이 전체 "수직"에서 가장 잘 수행되는 것으로 나타났습니다. 그러나 당신은 모든을 즉시 할 필요가 없습니다.

Answer 3

1.4에서 5로 전환 할 때 작동하지 않는 항목 (확실하지는 않은 항목)을 마이그레이션하려는 경우 술에 대한 항목을 마이그레이션하는 데 조심해야합니다. 당신이이 길을한다면

, 몇 가지 질문 :

당신은 포괄적 인 테스트 범위를 가지고 있습니까? 그렇지 않다면 마이그레이션 할 코드에 대한 단위 테스트를 작성해야합니다.

코드베이스에서 널리 사용되는 구성 요소가 있습니까?그렇다면 API (예 : 제네릭 등 사용)로 마이그레이션 할 수 있습니다.

Java 5에서 널리 사용되는 용어와 관련하여 제네릭은 중요하며 인생을 훨씬 쉽게 만듭니다. autoboxing이 표시되지 않습니다 too 또는 enums (모두 상대적입니다). Varargs 거의 절대. 어노테이션은 프레임 워크에 유용하지만 필자는 이것을 소비합니다. 나는 나 자신을 구현 한 적이 없다고 생각한다.

Answer 4

이것은 어떤 코드가 영향을 받고 그 코드가 얼마나 중요한지에 따라 달라지기 때문에 정말 어려운 질문입니다.

마이그레이션이 중요하지 않은 사업 일 경우 우선 Java 최신 버전 인 Java 5로 업그레이드하십시오. Java 6은 1 년 반 동안 만 사용되었습니다. 성숙하다. Java 5 (imho)를 선택하지 않아도됩니다.

둘째, 모든 소프트웨어 프로젝트와 마찬가지로 가능한 한 빨리 제품에 뭔가를 넣는 것이 목표입니다. 따라서 시스템의 일부를 식별해야합니다. 작은 쪽이 좋을수록 비현실적 일수록 좋습니다.

Java 6에서 응용 프로그램을 시작하고 중단되는 부분을 확인해보십시오. 예상보다 나쁠 수도 있습니다. 훨씬 더 좋을 수도 있습니다.

당신이 알고 있어야 할 다른 것은 그것의 소리에 의해 당신은 애플 리케이션에 jar/libraries가 사용되지 않을 것이기 때문입니다. 일부는 1.4.2 이상의 Java 와도 호환되지 않을 수 있습니다. 이 모든 것을 최신 버전으로 업그레이드하는 것이 좋습니다.

이것은 더 많은 물건을 깨뜨리는 것을 의미 할 것입니다.하지만 오래된/더 이상 사용되지 않는 API를 사용하면 길을 막 으면서 다른 문제가 발생합니다.

업그레이드가 광범위한 영향을 미칠 수있는 경우에는 예외가 있습니다. 축 1 - 축 2가 떠오른다. 그 상황은 더 신중하게 생각해야합니다.

사용 된 기능은 ... 모두 거의 같습니다. 나는 머리 꼭대기에서 피해야 할 어떤 것도 생각할 수 없다.

또한 프로젝트의 크기를 알아 냈습니다. ~ 20K LOC. 실제로는 아주 작습니다 (예 : 지난 3 개월 동안 해당 크기에 대한 앱을 직접 작성했습니다).

마지막으로, 이것은 또한 쉽게 깨는 것을 찾을 수있는 방법에 달려 있습니다. 좋은 단위 테스트 커버리지가 있다면 큰 것입니다. 그것은 꽤 드문 일입니다. 앱을 실행하고 문제를 안정적으로 찾을 수 있다면 너무 나쁘지 않습니다.

문제가되는 상황은 시나리오를 테스트하기가 어려우며 문제를 즉시 발견하지 못할 수 있습니다. 그것은 더 많은주의를 요구합니다.

Answer 5

20 (비평가) kloc은 빅뱅이있는 제네릭을 삽입 할 수있을만큼 작아야합니다. 분명히 코드가 Java SE 5에서 먼저 실행되도록 컴파일해야합니다. 제네릭에 대한 상대적으로 쉬운 점은 의미를 변경하는 것이 거의 없다는 것입니다. 암시 적 케이스로 인해 과부하가 바뀔 수 있습니다. Iterator<char[]> iter; ... System.out.println(iter.next());은 내 머리 꼭대기에서 나쁜 예입니다.

제네릭을 추가하는 경우 코드의 개념적 문제가 강조됩니다. 예를 들어, Map 하나를 분리 된 키 세트가있는 두 개의 맵으로 사용하십시오. TreeMap은 단일 클래스가 두 개의 고유 모드 (Comparator<T> 또는 Comparable<T> 사용)를 갖는 Java 라이브러리의 예제입니다.

향상된 기능 및 자동 권투와 같은 기능은 매우 로컬이며 단편적으로 추가 할 수 있습니다. 열거 형은 더 희귀하며 실제로 어떻게 사용할 것인지 생각할 수도 있습니다.

Answer 6

나는이 잘못된 방향으로 가고 있다고 생각합니다. 현재의 모든 코드를 Java 1.5로 업데이트 할 계획이 아니어야하며, 모든 현재 코드가 1.4.2에서와 똑같이 실행되도록하고 향후 작성된 모든 코드가 1.5에서 올바르게 작동하도록 계획해야합니다 .

다양한 크기의 코드 기반과 같은 몇 가지 전환 과정을 거쳤습니다. 목표는 항상 우리가 1.5 톤을 쉽게 끼워 넣고 그것을 통해 테스트를 실행할 수 있도록 우리가 단위 테스트 톤을 가지고 있는지 확인하는 것이 었습니다. 실제로 약 10 가지 문제가 발생했습니다. 대부분 문제를 지원하지 않거나 다르게 지원하는 정규 표현식 라이브러리와 관련이 있습니다.

모든 새로운 코드를 1.5로 작성하십시오. 어떤 이유로 든 이전 클래스를 변경하면 잠시 시간을내어 제네릭을 구현하지만 모든 것을 리팩터링 할 필요는 없습니다. 테스트를 제대로하지 않으면 저에게 위험합니다.