Eclipse 3.0과 3.1 사이의 비호환성

플러그인에 영향을 주는 Eclipse 3.0 및 3.1 간의 비호환성 방식으로 Eclipse가 변경되었습니다. 다음 항목에서는 변경된 영역에 대해 설명하고 3.0 플러그인을 3.1로 이주하는 방법에 대한 지시사항을 제공합니다. 3.1에서 3.0 플러그인을 실행하는 중 문제가 발생하는 경우 다음 정보를 참조하십시오.

  1. 플러그인 환경 설정
  2. IPath 제한조건 변경사항
  3. 확장 레지스트리
  4. 코드 포맷터 옵션
  5. AntCorePreferences의 API 접기 변경사항
  6. JFace Policy 클래스의 API 접기 변경사항
  7. 널(null) 기본 Perspective를 허용하는 API 접기 변경사항
  8. IViewLayout의 API 접기 변경사항
  9. IVMInstall의 API 접기 변경사항
  10. SelectionEnabler.SelectionClass는 패키지가 표시되도록 함
  11. ContributionItem.getParent()는 널(null)을 리턴할 수 있음
  12. IPropertySource 및 IPropertySource2에서 isPropertySet(boolean)의 변경사항
  13. org.eclipse.ui.commands 확장점에서 삭제된 handlerSubmission 요소
  14. 최종화된 TeamUI의 최종이 아닌 정적 API 필드 GLOBAL_IGNORES_CHANGED
  15. FillLayout를 사용하는 ClassCastException
  16. 처리된 상위 요소로 위지트 작성

1. 플러그인 환경 설정

영향을 받는 대상: Plugin#initializeDefaultPreferences를 대체하여 기본 플러그인 환경 설정 값을 초기화하거나 환경 설정 변경 리스너를 사용하는 플러그인.

설명: Eclipse 3.1에서 org.eclipse.jface.preference.IPreferenceStore 오브젝트는 org.eclipse.ui.plugin.AbstractUIPlugin#getPreferenceStore에서 얻고 org.eclipse.core.runtime 플러그인이 제공하는 새 3.0 Eclipse 환경 설정 프레임워크의 최상위에서 활성화되도록 이주되었습니다.

필요한 조치: 결과적으로 환경 설정 API를 사용하는 클라이언트는 다음과 같은 두 가지 문제를 확인해야 합니다.

  1. 환경 설정 변경 이벤트에 포함된 오브젝트 유형이 확실하지 않습니다. 이벤트의 이전 값과 새 값이 모두 널(null), String 또는 입력된 오브젝트일 수 있습니다. 따라서 올바른 클라이언트가 되려면 환경 설정 변경 리스너는 가능한 세 가지 상황을 모두 처리할 수 있어야 합니다.
  2. 플러그인이 org.eclipse.ui.plugin.AbstractUIPlugin#initializeDefaultPreferences를 사용하고 있으면 org.eclipse.ui.workbench 플러그인에서 이 종속성을 제거할 경우 필요한 플러그인 목록에 org.eclipse.core.runtime.compatibility 플러그인을 포함해야 합니다.

자세한 정보는 환경 설정 저장 문서를 참조하십시오.

2. IPath 제한조건 변경사항

해당 사항: IPath 오브젝트를 작성, 조작 또는 저장하는 플러그인.

설명: Eclipse 3.0의 IPath에는 내부 운영 체제의 제한조건보다 제한적인 경로의 세그먼트에 대한 많은 제한조건이 있었습니다. 제한조건은 다음과 같습니다.

플랫폼의 데이터 위치(작업공간)가 이러한 제한조건이 없는 파일 시스템에 위치할 경우 Eclipse 3.1에서 이러한 제한조건은 제거되었습니다.

필수 조치: 확장된 경로 범위에 적절한 처리를 사용하기 위해 플러그인 내의 모든 PathIPath 사용은 아래에 설명된 대로 검토 및 갱신되어야 합니다. 수정되지 않은 대부분의 플러그인은 3.0에서 유효하다고 간주되는 모든 경로에서 3.0과 동일하게 계속 작동합니다. 그러나 사전 설명된 이러한 변경사항이 적용되지 않으면 해당 플러그인은 3.0에서는 유효하지 않지만 3.1에서는 유효하다고 간주되는 경로가 관련된 경우에는 실패할 수 있습니다.

다른 플랫폼에서 읽을 수 있는 형식으로 경로의 문자열 표현을 저장한 플러그인은 새 Path.fromPortableString 팩토리 메소드로 이주되어야 합니다. 이 메소드는 플랫폼과 관계없는 형식의 IPath 인스턴스를 만듭니다. 이 경로 문자열 표현은 IPath.toPortableString 메소드를 사용하여 작성할 수 있습니다. 영향을 받은 메타데이터 파일의 예제에는 Eclipse 작업공간 프로젝트(.project, .classpath 등) 내부에 저장되어 있는 파일과 환경 설정 저장(org.eclipse.core.runtime.preferences.IPreferencesService)에 저장된 모든 경로가 포함됩니다.

참고: fromPortableString은 Eclipse 3.0 IPath.toString 메소드를 사용하여 작성된 모든 경로 문자열을 제대로 읽지만 Eclipse 3.1 toString 메소드를 사용하여 작성된 것은 읽지 못합니다. 따라서 toPortableString을 사용하여 경로를 쓰고 fromPortableString을 사용하여 경로를 읽기 시작하는 것을 제외하고 대부분의 경우에는 기존 메타데이터 파일 형식을 변경하면 안됩니다.

':' 및 '\'가 모든 플랫폼에서 특별한 의미를 가진다는 가정 하에 하드 코딩된 문자열 리터럴에서 경로를 작성한 플러그인은 이주해야 합니다. 가장 쉬운 솔루션은 문자열 경로 리터럴을 모든 플랫폼에서 지원되는 서브세트로 제한하는 것입니다(콜론 및 백슬래시 제외). Path.toPortableString에서 작성된 이동 가능 경로 문자열을 사용하면 경로 리터럴이 유효 Unix 경로의 전체 세트를 지원할 수 있습니다. 이 형식은 첫 번째 단일 콜론(':')을 장치 분리자로, 슬래시('/')를 세그먼트 분리자로, 이중 콜론("::")을 리터럴 콜론 문자로 해석합니다. 예를 들어 코드 new Path("c:/temp")는 이제 Unix 플랫폼에서 두 세그먼트의 상대 경로를 작성합니다. 마찬가지로 new Path("a\\b")는 Unix 플랫폼에서 단일 세그먼트의 경로를 작성하고 Windows에서 두 세그먼트의 경로를 작성합니다.

':' 및 '\'가 모든 플랫폼에서 특별한 의미를 가진다는 가정 하에 IPath.append(String) 메소드를 사용하여 경로를 구성하는 플러그인은 코드를 갱신해야 합니다. Eclipse 3.1에서 이 메소드는 운영 체제 관련 장치 및 세그먼트 분리문자를 사용하여 제공된 경로 문자열을 해석합니다. 예를 들어 Unix 플랫폼에서 append("a\\b")를 호출하면 단일 세그먼트를 추가하지만 Windows에서는 두 세그먼트를 계속 추가합니다.

플랫폼이 읽고 해석한 데이터 파일은 모든 플랫폼에서 더 이상 ':' 및 '\'를 특수 문자로 처리하지 않습니다. 여러 플랫폼에서 읽을 수 있는 데이터 파일에 저장된 모든 경로는 이식 가능한 양식이어야 합니다. 예를 들어, 아이콘 파일 경로나 plugin.xml에 있는 기타 경로는 경로 세그먼트 분리자로 '/'만 사용해야 합니다.

3. 확장 레지스트리

해당 사항: Eclipse 플랫폼의 플러그인 또는 확장 레지스트리에서 IExtensionPoint, IExtensionIConfigurationElement 오브젝트를 조작하거나 유지하는 플러그인.

설명: 3.0 이전에는 확장 레지스트리(이전 플러그인 레지스트리)에서 얻은 모든 오브젝트가 계속 올바른 오브젝트였습니다. Eclipse 3.0에서는 Eclipse를 다시 시작할 필요 없이 동적으로 플러그인을 추가 또는 제거할 수 있도록 변경되었습니다. 다시 시작하지 않고 플러그인이 제거되면 확장 레지스트리의 플러그인 항목이 유효하지 않게 됩니다. 이는 삭제된 플러그인의 확장 레지스트리 항목에서 이전에 얻은 오브젝트에 연결된 다른 플러그인이 올바르지 않은 오브젝트를 보유한 채 남게 됨을 의미합니다. 클라이언트는 IRegistryChangeEvent를 청취해야 힌트를 얻을 수 있습니다. 이 문제는 Eclipse 3.0 이후로 존재했지만 Eclipse를 다시 시작하지 않고 플러그인이 제거되는 경우는 극히 드물었기 때문에 실제로 거의 발생하지 않습니다.

3.1에서는 이 문제가 다음과 같이 해결되었습니다.

필수 조치: 플러그인이 동적 인식(즉, 작동 중인 플러그인 추가 또는 제거를 처리할 수 있음)되도록 하려면 일부 다른 플러그인에서 얻은 IExtensionPoint, IExtensionIConfigurationElement 오브젝트를 처리하는 코드는 IRegistryChangeEvent가 확인된 예외인 것처럼 이 오브젝트를 발견하도록 변경되어야 합니다. 예외(isValid() 사전 확인 제외)를 발견하는 것이 동시 스레드(거의 확실히 동시 발생함)에 의해 플러그인이 제거되는 경우를 처리하는 유일하게 확실한 방법입니다.

4. 코드 포맷터 옵션

해당 사항: Java 코드 포맷터 옵션에 프로그래밍 방식으로 액세스하는 플러그인.

설명: Eclipse 3.0에서 코드 포맷터 옵션 org.eclipse.jdt.core.formatter.DefaultCodeFormatterConstants#FORMATTER_TAB_CHAR의 값은 TAB 또는 SPACE만 될 수 있습니다. 스펙에서는 값 유형이 나중 릴리스에서 증가할 수 있는 열거임을 명시적으로 언급하지 않았습니다. Eclipse 3.1에서는 세 번째 가능한 값인 MIXED가 버그 73104를 해결하기 위해 추가되었습니다. 스펙은 이 새 값을 포함하고 나중에 더 많은 값을 추가할 수 있도록 변경되었습니다.

필수 조치: 이 코드 포맷터 옵션을 프로그래밍 방식으로 읽거나 설정하는 클라이언트는 클라이언트의 코드를 확인하여 새로운 세 번째 값을 반영하고 코드에 예기치 않은 옵션 값이 발생할 경우 완전히 실패하는 강력한 방식으로 코드가 작성되었는지 확인해야 합니다.

5. AntCorePreferences의 API 접기 변경사항

해당 사항: org.eclipse.ant.core.AntCorePreferences를 서브클래스화 또는 인스턴스화하는 플러그인.

설정: Eclipse 3.0에서 org.eclipse.ant.core.AntCorePreferences 클래스에는 클라이언트가 인스턴스화 또는 서브클래스화될 수 없음이 표시되어 있지 않습니다. Eclipse 3.1에서는 클래스에 서브클래스화 또는 인스턴스화되도록 의도되지 않음을 표시하여 이 문제를 해결했습니다.

필수 조치: org.eclipse.ant.core.AntCorePreferences의 인스턴스를 프로그래밍 방식으로 작성한 클라이언트는 클라이언트의 코드를 이주하여 org.eclipse.ant.core.AntCorePlugin.getPreferences()를 통해 환경 설정을 검색해야 합니다. 임의의 서브클래스는 서브클래스 org.eclipse.ant.core.AntCorePreferences에 대해 더 이상 재정의되지 않아야 합니다.

6. JFace Policy 클래스의 API 접기 변경사항

해당 사항: Workbench에서 설정된 JFace 로그를 재정의하는 RCP 응용프로그램.

설명: Eclipse 3.0에서 Workbench는 Workbench의 로그를 로그로 설정하여 Workbench 플러그인의 로그를 직접 org.eclipse.jface.util.Policy.setLog(ILog)에 전달하는 방식으로 JFace 오류를 로깅하는 데 사용합니다. 3.1에서는 Eclipse 런타임 외부에서 SWT 및 JFace를 사용하여 독립형 응용프로그램을 사용 가능하도록 하기 위해 ILog에 대한 종속성이 JFace에서 제거되었습니다. JFace의 필요를 충족하는 새 인터페이스 ILogger가 도입되었습니다. Workbench는 ILog Workbench를 줄 바꾸기하는 ILogger를 제공하도록 변경되었습니다. 추가 세부사항은 버그 88608을 참조하십시오.

필수 조치: 대부분의 RCP 응용프로그램은 Workbench가 설정한 로그를 재정의할 필요가 없어야 하지만 이전에 Policy.setLog(ILog)를 호출한 경우에는 대신 ILogger를 전달하도록 변경되어야 합니다.

7. 널(null) 기본 Perspective를 허용하는 API 접기 변경사항

해당 사항: 널(null)이 아닌 기본 Perspective를 필요로 하는 RCP 응용프로그램.

설명: RCP 응용프로그램이 Perspective를 열지 않고 빈 창을 사용하여 시작할 수 있도록 하기 위해(추가 처리 71150) WorkbenchAdvisor.getInitialWindowPerspectiveId()IPerspectiveRegistry.getDefaultPerspective()가 널(null)을 리턴할 수 있도록 변경되었습니다. IDE에는 항상 기본 Perspective가 있으므로 IPerspectiveRegistry.getDefaultPerspective()는 널(null)을 리턴하지 않습니다. 마찬가지로 기존 RCP가 이전에 WorkbenchAdvisor.getInitialWindowPerspectiveId()에서 널(null)이 아닌 값을 리턴한 경우 IPerspectiveRegistry.getDefaultPerspective()는 계속 널(null)이 아닌 값을 리턴합니다.

필수 조치: 클라이언트에 필요한 조치가 없습니다.

8. IViewLayout의 API 접기 변경사항

해당 사항: org.eclipse.ui.IViewLayout를 구현한 플러그인.

설명: Eclipse 3.0에서 org.eclipse.ui.IViewLayout 클래스에는 클라이언트가 구현하지 않을 것임이 표시되어 있지 않습니다. Eclipse 3.1에서는 클래스에 클라이언트가 구현하도록 의도되지 않음을 표시하여 이 문제를 해결했습니다.

필수 조치: 모든 구현 클래스는 더 이상 org.eclipse.ui.IViewLayout를 구현하도록 재정의될 필요가 없습니다.

9. IVMInstall의 API 접기 변경사항

해당 사항: org.eclipse.jdt.launching.IVMInstall을 구현하는 플러그인.

설명: Eclipse 3.0에서 org.eclipse.jdt.launching.IVMInstall 클래스에는 클라이언트가 구현하지 않을 것임이 표시되어 있지 않습니다. Eclipse 3.1에서는 클래스에 클라이언트가 직접 구현하도록 의도되지 않음을 표시하여 이 문제를 해결했습니다. 2진 호환성을 유지하기 위해, 클라이언트가 직접 인터페이스를 구현할 수 있도록 허용하지만, 클라이언트는 대신 org.eclipse.jdt.launching.AbstractVMInstall을 서브클래스화해야 합니다. IVMInstall을 구현하는 클라이언트는 이제 AbstractVMInstall이 구현하는 새로운 선택적 인터페이스인 org.eclipse.jdt.launching.IVMInstall2도 구현해야 합니다. 클라이언트는 새 인터페이스인 IVMInstall2를 구현하여 버그 73493에 명시된 문제점을 방지해야 합니다. 권장되는 이주는 AbstractVMInstall을 서브클래스화하는 것입니다.

필수 조치: 아직 org.eclipse.jdt.launching.AbstractVMInstall을 서브클래스화하지 않은 모든 구현 클래스는 org.eclipse.jdt.launching.AbstractVMInstall을 서브클래스화하도록 개정해야 합니다.

10. SelectionEnabler.SelectionClass는 패키지가 표시되도록 함

해당 사항: org.eclipse.ui.SelectionEnabler.SelectionClass를 사용하는 플러그인.

설명: Eclipse 3.0에서 중첩된 구현 클래스 org.eclipse.ui.SelectionEnabler.SelectionClass는 public이었고 사용에 대한 제한이 없었습니다. Eclipse 3.1에서는 클래스에 패키지를 표시하도록 하여 이 문제를 해결했습니다.

필수 조치: org.eclipse.ui.SelectionEnabler.SelectionClass를 확장하거나 인스턴스를 작성하는 클래스는 더 이상 이 클래스를 참조하지 않도록 개정해야 합니다.

11. ContributionItem.getParent()는 널(null)을 리턴할 수 있음

해당 사항: org.eclipse.jface.action.ContributionItem의 서브클래스에서 getParent()를 호출하는 플러그인.

설명: Eclipse 3.0에서 org.eclipse.jface.action.ContributionItem.getParent() 메소드는 널(null)을 리턴할 수 없도록 지정하지 않았습니다. Eclipse 3.1에서는 Javadoc을 사용하여 이 메소드가 널(null)을 반환할 수 있는 경우를 명시하여 이 문제를 해결했습니다. 추가 세부사항은 버그 92777을 참조하십시오.

필수 조치: ContributionItem.getParent()를 호출하는 코드가 널(null) 결과를 처리할 수 있는지 확인해야 합니다.

12. IPropertySource 및 IPropertySource2에서 isPropertySet(boolean)의 변경사항

해당 사항: org.eclipse.ui.views.properties.IPropertySource 또는 IPropertySource2를 구현하는 플러그인.

설명: Eclipse 3.0에서는 org.eclipse.ui.views.properties.IPropertySource.isPropertySet(boolean) 메소드의 스펙이 잘못 변경되어 지정된 특성에 의미 있는 기본값이 없는 경우 true를 리턴하도록 지정했습니다. 이전 버전에서는 이 경우 false를 리턴하도록 지정했습니다. 특성 소스가 IPropertySource를 구현하고 IPropertySource2를 구현하지 않는 경우에는 해당 구현이 이전과 같이 작동하지만 이것은 의도되지 않은 중단 API 변경이었습니다. 3.1에서는 IPropertySource.isPropertySet(boolean)를 다시 이전 스펙(이 경우 false를 리턴해야 하는)으로 되돌리고 IPropertySource2.isPropertySet(boolean)가 이를 재정의하여 이 경우 true를 리턴하도록 지정함으로써 이 문제를 해결했습니다. 추가 세부사항은 버그 21756을 참조하십시오.

필수 조치: 일부 특성에 의미 있는 기본값이 없는 IPropertySource 또는 IPropertySource2를 구현하는 모든 클래스를 확인하여 isPropertySource(boolean)에 대해 적절한 값을 반환하는지 확인해야 합니다. 클라이언트에서는 특성 보기의 기본값 복원 단추가 특성 소스에 대해 제대로 작동하는지 확인해야 합니다.

13. org.eclipse.ui.commands 확장점에서 삭제된 handlerSubmission 요소

영향을 받는 대상: org.eclipse.ui.commands 확장점 Eclipse 3.0에 도입된 실험용 handlerSubmission 요소를 사용한 플러그인.

설명: Eclipse 3.0에서, 실험용 요소가 org.eclipse.ui.commands 확장점에 도입되었습니다. 이 요소는 XML을 통해 핸들러를 등록하기 위한 방법으로 사용되었습니다. 이로 인해, 더 뛰어난 메커니즘인 org.eclipse.ui.handlers 확장점이 도입되었습니다. 요소가 실험용 요소로 표시되었으므로, 이제는 제거되었습니다.

필요한 조치: handlerSubmission 요소를 정의하는 플러그인은 org.eclipse.ui.commands 확장점으로 이주해야 합니다.

14. 최종화된 TeamUI의 최종이 아닌 정적 API 필드 GLOBAL_IGNORES_CHANGED

영향을 받는 대상 TeamUI의 GLOBAL_IGNORES_CHANGED 필드를 설정하고 있었던 플러그인.

설명: Eclipse 3.0에서는 GLOBAL_IGNORES_CHANGED 필드가 TeamUI 클래스에 추가되었습니다. 이 필드는 팀 플러그인이 조작한 글로벌 무시 목록이 변경되었음을 표시하기 위해 특성 변경 이벤트에 사용되는 상수입니다. 이 필드는 3.0에서 최종으로 표시되지 않았지만 최종이어야 합니다. 3.1에서는 최종화되었습니다.

필요한 조치: 위의 필드를 설정하고 있었던 플러그인은 더 이상 이 필드를 설정할 수 없습니다.

15. FillLayout을 사용하는 ClassCastException

영향을 받는 대상: FillLayout을 잘못 사용하는 플러그인.

설명: Eclipse 3.0에서는 FillLayout과 연관되는 레이아웃 데이터가 없었으므로 응용프로그램이 FillLayout이 관리했던 하위 요소에 레이아웃 데이터를 지정한 경우 이는 무시되었습니다. Eclipse 3.1에서는 크기 조정 성능을 개선하기 위해 크기 정보를 캐시할 수 있는 지원이 FillLayout에 추가되었습니다. 캐시된 데이터는 FillLayout이 관리하는 각 하위 요소와 연관되는 FillData 오브젝트에 저장됩니다. 응용프로그램이 레이아웃 데이터를 하위 요소에 잘못 지정한 경우, 상위 요소에서 computeSize를 호출할 때 ClassCastException이 발생합니다.

필요한 조치: FillLayout에서 레이아웃 데이터가 지정된 하위 요소를 찾고 레이아웃 데이터 지정을 중지하십시오.

16. 처리된 상위 요소로 위지트 작성 중 IllegalArgumentException 발생

영향을 받는 대상: 위지트 작성 중 예외를 발견하는 플러그인.

설명: Eclipse 3.0에서, 처리된 상위 요소로 위지트(widget)가 작성된 경우 예외는 발생하지 않고 나중에 위지트 코드가 실패하거나 "위지트가 처리됨" 텍스트와 함께 SWTException이 발생했습니다. Eclipse 3.1에서는 처리된 상위 요소로 위지트가 작성될 경우, 생성자가 "인수가 올바르지 않음" 텍스트와 함께 IllegalArgumentException을 발생합니다.

필요한 조치: 위지트를 작성할 때 SWTException을 처리하는 코드가 IllegalArgumentException도 처리해야 합니다.