Red Hat Summit Red Hat Summit지원콘솔개발자평가판 시작연락처

이 콘텐츠는 선택한 언어로 제공되지 않습니다.

1.2. Conflicting Classes

Overview
링크 복사

One of the main aims of the OSGi class loading architecture is to avoid loading conflicting class definitions into the same bundle class space. This section explains how such conflicts can arise in practice.

Symbolic references
링크 복사

To explain the difficulties that can be caused by having multiple copies of a loaded class, we need the concept of a symbolic reference to a class or interface. A symbolic reference is a point in your code where a class name is used, except the actual definition of the class. For example, when a class name is used to specify a return type, a parameter type, or a variable type, the class name is a symbolic reference.
At run time, the JVM must resolve each symbolic reference by linking it to a specific instance of a loaded class. Symbolic references are resolved using the same class loader as the class in which they appear. For example, Example 1.1, “Symbolic Reference Used in a Class Cast” shows the definition of the TestHello class, which is loaded by the class loader, A.

Example 1.1. Symbolic Reference Used in a Class Cast

// Java
package org.bar;

// TestHello loaded by ClassLoader 'A'
public class TestHello {
    public void useHelloObj(Object hello) {
        org.foo.Hello h = (org.foo.Hello) hello;
        System.out.println(h.getGreeting());
    }
}
Copy to Clipboard Toggle word wrap
Important
Although the symbolic reference, org.foo.Hello, is initially loaded by class loader A, this does not imply that the symbolic references must be resolved to A/org.foo.Hello. If the initial class loader A decides to delegate to another class loader, B, the symbolic reference could be resolved to B/org.foo.Hello instead (so that B is the effective class loader). The delegation mechanism is crucial, because it enables an OSGi bundle to re-use existing loaded classes and avoid class space inconsistencies.

Class cast exceptions
링크 복사

When multiple class loaders are used in parallel (as happens in OSGi), there is a danger that a class could be loaded more than once. This is undesirable, because it almost inevitably causes class cast exceptions at run time.
For example, consider the TestHello class shown in Example 1.1, “Symbolic Reference Used in a Class Cast”, where the org.foo.Hello symbolic reference has been resolved to A/org.foo.Hello. If you also have a Hello object that is an instance of B/org.foo.Hello type, you will get a class cast exception when you pass this object to the TestHello.useHelloObj(Object) method. Specifically, in the line of code that performs the following cast: 
org.foo.Hello h = (org.foo.Hello) hello;
Copy to Clipboard Toggle word wrap
The org.foo.Hello symbolic reference has been resolved to the A/org.foo.Hello type, but the hello object is of B/org.foo.Hello type. Because the types do not match, you get the class cast exception.
맨 위로 이동
Red Hat logoGithubredditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다. 최신 업데이트를 확인하세요.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

Theme

© 2025 Red Hat