릴리스 정보 JavaTM 2 SDK, Standard Edition 버전 1.3.1

목차

개요
Java 가상 머신
글꼴 속성
Solaris의 Xserver 버그
RMI
CORBA, RMI-IIOP 및 Java IDL
Java 2D^TM 기술
끌어서 놓기
액세스 기능
AWT 및 Swing
JDBC
보안
네트워킹
Java^TM Plug-in 구성 요소
현지화 정보
설명서
도구가 Solaris 2.6의 일본어 PCK 문자열을 변환할 수 없다
중국어 번체 글꼴 문제
Windows 2000 지원
Windows NT에 설치

Java 2 SDK, Standard Edition, 버전 1.3.1(J2SDK 1.3.1)은 이전 버전에서 확인된 버그 수정본이 들어 있는 유지 보수 릴리스입니다. 버그 수정본에 대한 자세한 내용은 다음을 참조하십시오.

본 릴리스에서 수정된 버그

또한, J2SDK 1.3.1에서는 다음과 같은 기능이 향상되었습니다.

• Java^TM Plug-in 향상
  이 릴리스에는 보다 융통성 있고, 사용 및 구성이 쉬우며, Netscape 6 브라우저의 새로운 Open JVM Interface 기능을 지원하는 여러 가지 새로운 기능을 갖춘 Java Plug-in 제품이 포함되어 있습니다. 자세한 내용은 New Java Plug-in Features를 참조하십시오. Java Plug-in에서 향상된 이러한 기능은 업데이트 릴리스 J2SDK 1.3.0_01에서 처음 도입되었습니다.

• Java 가상 머신의 오류 처리 기능
  J2SDK 1.3.1의 Java 가상 머신에는 원시 코드에서 충돌이 발생할 경우 화면에 디버그 정보를 표시하는 새로운 오류 처리 기법이 있습니다. 자세한 내용은 Error Handling in J2SDK 1.3.1을 참조하십시오.

• Java 2 SDK에 포함된 HTML 변환기
  Html 변환기는 이제 Java 2 SDK에 번들되었습니다. J2SDK 1.3.1 Beta 버전을 비롯한 이전 릴리스에서는 Html 변환기를 사용하기 위해 별도로 다운로드해야 했습니다.

Java Plug-in 제품 설명서는 Java Plug-in 웹 사이트에서 참조하십시오.

J2SDK 1.3.1에 대한 전체 설명서 세트를 다운로드할 수 있습니다. 새 온라인 설명서 Tuning Garbage Collection with the 1.3.1 Java Virtual Machine를 참조하십시오.

아래 노트에는 중요한 버그 수정 설명, 알려진 버그 및 해결 방법, 기타 팁 및 이 릴리스 사용을 위한 제안 사항을 비롯하여 J2SDK 1.3.1 사용자에게 흥미 있는 정보가 제공됩니다.

다음은 Java 가상 머신에 관한 내용입니다.

• Linux 플랫폼에서 I/O 작업을 위해 대기 중인 스레드는 I/O 작업에 관련된 파일이 닫히면 다시 작동하지 않습니다. 이 문제는 현재 버그 4344135로 추적 중입니다. 이 문제를 방지하려면 J2SE_PREEMPTCLOSE 환경 변수를 1로 설정하십시오.

  J2SE_PREEMPTCLOSE=1
  export J2SE_PREEMPTCLOSE
  

• 버그 4323062: 사용자가 로그아웃할 때 Java VM이 포함된 Windows NT Service가 중단됩니다.

  이 버그는 J2SDK 1.3.1에서 수정되었습니다. 이 수정본을 사용하려면 -Xrs 명령줄 옵션을 JVM에 전달해야 합니다. 이 수정본은 J2SDK 1.3 종료 후크 체계를 사용할 수 없도록 하고 sun.misc.Signal 클래스를 사용할 수 없도록 하기 때문에 추가 명령줄 인자가 필요합니다. 자세한 내용은 아래 Bug Parade에 있는 Evaluation의 마지막 절을 참조하십시오.

  http://developer.java.sun.com/developer/bugParade/bugs/4323062.html

• 다음과 유사한 오류 메시지가 나타나면서 프로그램이 종료된 후 JNI 버그로 인해 JVM이 충돌할 수 있습니다.

  Another exception has been detected while we were handling last error.
  Dumping information about last error:
  ERROR REPORT FILE = (N/A)
  PC                = 0x0x41621c7a
  SIGNAL            = 11
  FUNCTION NAME     = (N/A)
  LIBRARY NAME      = (N/A)
  Please check ERROR REPORT FILE for further information, if there is any.
  Good bye.
  

  이 문제는 이론적으로 Microsoft Windows 및 Solaris 플랫폼 모두에 발생할 수 있지만 대부분 Linux Red Hat 7.1 SMP에서 발생합니다.

  해결 방법 - 응용프로그램의 main 메소드의 마지막 부분에 명시적인 종료 호출을 다음과 같이 추가하십시오. Runtime.getRuntime().exit(0)

• Red Hat 7.1의 자동 마운트된 NFS 상에서 Java 플랫폼에 코드를 실행하면 Red Hat 의 dlopen()에서 자주 충돌할 수 있습니다. 이 문제는 명백히 NFS 자동 마운터로 인해 발생하며 mount -t nfs로 디렉토리를 명시적으로 마운트하면 이 문제가 없어집니다.

이 릴리스의 글꼴 속성에는 다음과 같은 문제가 있습니다.

• 6.1 이외의 Red Hat Linux 버전을 사용하면 font.properties 파일은 일부 Symbol/Dingbats 문자를 AWT 구성 요소에 제대로 나타내지 못합니다. 이 문제를 수정하려면 수정된 font.properties 파일로<JAVA_HOME>/jre/lib/ 디렉토리에 있는 파일을 교체합니다.

• 버그 4419794로 인해 글꼴 속성는 Solaris 8(Intel 구조)에 있는 UTF-8 로켈에 대해 경고 메시지를 표시합니다. Solaris 8의 UTF-8 로켈을 Intel 하드웨어에 사용해야 할 경우에는 이 문제를 수정한 Solaris 8 Update Release 4로 시스템을 업데이트해야 합니다.

Solaris Xserver 버그로 인해, Java 프로그래밍 언어로 작성된 응용프로그램이 글꼴을 참조할 때 시스템 충돌이 발생할 수 있습니다. 이 문제는 버그 4391019에 설명되어 있습니다. 이러한 문제를 해결하는 데 유용한 다음과 같은 Solaris 패치가 2001년 6월 중순경에 발표될 예정입니다.

Solaris 2.6 용: 105633-55 (Sparc) 106248-41 (Intel)
Solaris 7 용: 108376-24 (Sparc) 108377-22 (Intel)
Solaris 8 용: 108652-31 (Sparc) 108653-26 (Intel)

이러한 패치가 발표되었는지 확인하려면 SunSolve 웹 사이트를 방문하십시오.

다음은 이 릴리스의 원격 메소드 호출(RMI) 기능의 중요한 변경 사항입니다.

• 원격 호출을 수신하기 위한 "accept" java.net.SocketPermission 요구 사항
  액세스 제어 컨텍스트에 원격 java.net.InetAddress와 소켓 연결 포트에 대한 "accept" java.netSocketPermission이 없었지만 이전에 구현한 J2SDK의 버그로 인해 액세스 제어 컨텍스트에 제공된 액세스 제어 컨텍스트에서 원격 개체를 내보낸 다음 제공된 소켓 연결을 통해 해당 개체로 원격 호출을 수신할 수 있었습니다.

  이 버그가 수정되었습니다. 따라서 일부의 경우에 원격 개체를 내보내는 코드는 올바른 기능 수행을 위해 이전 구현에서 부여된 권한보다 더 많은 권한이 있어야 합니다.

  기본 보안 정책 파일 구문을 사용하여 그러한 사용 권한을 부여하는 방법의 예로, terrier.east.sun.com 호스트에서 소켓 연결을 승인하는 권한은 다음과 같은 권한 입력 항목(해당 코드 소스의 허가 입력 항목)으로 나타낼 수 있습니다.

  permission java.net.SocketPermission "terrier.east.sun.com", "accept";
  

  java.netSocketPermission 설명서에 설명되어 있듯이 호스트 사양은 와일드카드 "*"로 시작하므로 호스트에 대한 소켓 연결을 승인하는 권한은 제공된 허가 입력 항목에 다음과 같은 권한 입력 항목으로 나타낼 수 있습니다.

  permission java.net.SocketPermission "*", "accept";
  

• 내보내지 않은 원격 객체에 대해서는 가비지 컬렉션이 수행되지 않음
  이전 구현에서 RMI 런타임은 명시적으로 내보내지 않은 원격 개체라도 경우에 따라서는 참조했습니다. 이 버그는 수정되었기 때문에 RMI 런타임은 명시적으로 내보내지 않은 원격 객체를 참조하지 않습니다.

• ObjectOutputStream 교체 테이블 성능
  ObjectOutputStream 인스턴스는 이전 구현에서 선형 검색을 사용하여 교체된 객체(즉, ObjectOutputStream.replaceObject 호출로 반환되었거나 클래스 정의 writeReplace 메소드로 반환된 객체)를 기억했습니다. 따라서 해당 스트림에서 교체된 객체의 수가 클 경우, 각기 새로운 객체에 대한 검색 오버헤드의 비용이 컸습니다. 이 버그는 구현 시 객체 교체를 기억하는 데 보다 효율적인 알고리즘을 사용하도록 수정되었습니다. 객체 일련화 구현에 대한 이러한 수정은 RMI 인자와 반환값 마샬링 중에 객체 교체를 확장하는 이점이 있습니다.

다음은 이 릴리스의 CORBA, RMI-IIOP 및 Java IDL 기능에 대한 설명입니다.

• 다른 업체에서 제공하는 ORB와의 상호 운영성에 대해 테스트되지 않았기 때문에 Sun ORB가 기타 다른 ORB와 잘 작동할지의 여부에 대해서는 보증하지 않습니다.

• J2SDK 1.3.1 서버가 먼저 J2SDK 1.3 클라이언트와 연결한 다음 J2SDK 1.3.1 클라이언트가 writeObject 또는 readObject 메소드를 사용하는 Serializable 인스턴스로 보내려고 하면 MARSHAL 예외가 발생합니다. 마찬가지로, J2SDK 1.3.1 서버가 먼저 J2SDK 1.3.1 클라이언트와 연결한 다음 J2SDK 1.3 클라이언트가 같은 클래스 유형의 인스턴스를 보내려고 하면 MARSHAL 예외가 발생합니다. 이 문제는 현재 버그 4434140로 추적 중입니다.

  해결 방법 - writeUTF와 readUTF 대신 writeObject와 readObject를 사용하도록 Serializable 클래스를 변경합니다.

• J2SDK 1.3의 매핑된 writeUTF 및 readUTF는 wstrings 문자열이 아닌 CORBA 문자열을 호출합니다. 그러므로, 8비트보다 큰 문자로 된 문자열을 보내는 데 이러한 방법을 사용할 수 없었습니다. 이 문제는 J2SDK 1.3.1에서 해결되었지만, J2SDK 1.3과 통신할 경우 똑같은 제한이 적용됩니다. 이 문제는 현재 버그 4379597로 추적 중입니다.

  해결 방법 - writeUTF와 readUTF 대신 writeObject와 readObject를 사용합니다. 이 메소드 매개변수가 String이면 J2SDK 1.3뿐만 아니라 JDK 1.3.1은 이들을 CORBA wstring 호출에 매핑시킵니다.

• J2SDK 1.3.1에 포함된 Java ORB는 Java Serialialization Specification에서 지정한 대로 일련화 가능한 클래스에 대한 변경 사항을 지원하도록 수정되었습니다.

  이러한 지원 기능으로 인해, J2SDK 1.3.1과 다음 J2SDK 릴리스에서 이러한 클래스를 처리할 수 있습니다. 예를 들어, J2SDK 1.3.1에 포함된 클래스 V가 다음 J2SDK 릴리스에서 향상된 경우 J2SDK 1.3.1에서 실행되는 응용프로그램 클라이언트(클래스 V 송신/수신)는 다음 J2SDK 릴리스에서 실행되는 서버(클래스 V 수신/송신)와 상호 운영이 가능하며, 역으로도 가능합니다.

  그러나, 이전 릴리스 J2SDK 1.3.0에는 클래스 향상을 막는 버그가 있습니다.(예를 들면, Java Developer Connection^SM 웹 사이트에 있는 버그 보고서 4365188을 참조하십시오.)그러므로, J2SDK 1.3.1에서 향상된 클래스를 J2SDK 1.3으로 송신하려고 하면 상호 운용성 문제가 생깁니다.

• OMG IDL에서 코드를 작성할 때는 모듈 이름과 같은 인터페이스 이름을 사용하지 마십시오. 모듈 이름과 같은 인터페이스 이름을 사용하면 다른 업체의 도구로 컴파일할 때 불일치 결과가 발생할 수 있으므로 코드 이식성에 문제가 생길 수 있습니다. 예를 들어, 같은 이름이 들어 있는 코드는 Sun Microsystems에서 Java 컴파일러를 사용하여 IDL로 컴파일하여 한 가지 결과를 얻을 수 있습니다. 다른 업체의 IDL로 Java 컴파일러에 컴파일된 같은 코드는 다른 결과를 생성할 수 있었습니다.

Java 2D^TM 라이브러리의 버그 4178909로 인해 응용프로그램을 8비트 모드에서 실행할 때 응용프로그램을 제대로 표시할 수 없습니다. 이 문제는 재부트 후에 또는 디스플레이 모드를 8비트 설정한 후에 응용프로그램을 처음 실행할 때만 영향을 줍니다.

DirectDraw와 관련된 버그도 있습니다. DirectDraw 문제가 발생하면 DirectDraw를 해제하십시오.

-Dsun.java2d.noddraw=true

일부 디스플레이 드라이버는 DirectDraw를 액세스하면 창을 비롯하여 모니터 이미지가 재동기화되거나 점프됩니다. 이러한 상황이 발생하면 제조업체의 웹 사이트에서 이 문제를 해결한 새로운 드라이버를 찾아보십시오.

Java 플랫폼은 16색 디스플레이를 지원하지 않습니다. 16색 디스플레이에 그래픽 그리기와 GUI 구성 요소 문제가 발생하면 색상 깊이를 256색 이상의 모드로 변경해 보십시오.

다음 기능은 구현되어 작동하지만 완전히 테스트되지 않았으며 이 릴리스에서 지원되지 않습니다.

• 끌어서 놓기는 다음을 전환합니다.
  • 플랫폼 원시 데이터 유형 또는 사용자 정의 데이터 유형
  • 동일한 JVM 내에 있는 고유한 ClassLoader 인스턴스에 의해 로드된 임의 클래스 인스턴스*
  • JVM(또는 ClassLoaders) 간에 일련화된 Java 객체
• JVM 간에 RMI java.rmi.Remote 부속 인터페이스 링크

AWT와 Swing 구성 요소에는 Java Accessibility API를 구현하고 구성 요소에 적합한 액세스 지원 기능을 제공하는 내부 클래스가 있습니다. 그러나, 다음과 같은 AWT 클래스를 지원하는 액세스 기능은 이 릴리스에서 완전히 구현되지 않았습니다.

java.awt.TextComponent
java.awt.Menu
java.awt.MenuItem
java.awt.List

모든 구성 요소를 지원하는 전체 액세스 기능은 Java 2 플랫폼의 다음 릴리스에서 구현됩니다.

다음 설명은 이 릴리스의 AWT와 Swing 기능에 대한 것입니다.

• 정적 메소드 Toolkit.getDefaultToolkit을 호출하는 프로그램은 종료되지 않으며 명령 프롬프트를 반환합니다. 이 문제는 현재 버그 보고서 4030718과 4403762로 추적 중이며, J2SDK 1.4.0 Beta 버전에서 수정될 것입니다.

  해결 방법 - 응용프로그램이 종료되려면 System.exit()를 호출합니다.

• 새로운 Component.getListeners() 메소드가 PropertyChangeListeners를 반환하지 못합니다. addPropertyChangeListener()로 Listener를 추가한 경우

  myComponent.getListeners(PropertyChangeListener.class)
  

  위 명령줄은 빈 배열을 반환합니다.

• 버그 4199374는 JWindow 객체와 함께 주요 관리 문제에 대한 것입니다. 특히, 이 버그는 Component.requestFocus()가 JWindow의 구성 요소에 초점을 둘 수 없게 합니다. 이 버그는 업데이트 릴리스 J2SDK 1.2.2_05와 J2SDK 1.3.0_02에서 수정되었습니다. 그러나, J2SDK 1.3.1에서는 수정되지 않았습니다.

Windows NT에서 JDBC 2.0 브리지는 ODBC 2.x 및 ODBC 3.x 드라이버 관리자와 드라이버를 지원합니다. JDBC 2.0 브리지는 ODBC 3.x 드라이버 관리자 ODBC 2.x 및 3.x 드라이버로 테스트되었습니다.

Merant는 JDBC 2.0 브리지를 버전 3.5 이상의 Merant DataDirect ODBC 드라이버와 함께 사용할 것을 권장합니다.

다음은 이 릴리스의 보안 관련 문제입니다.

jarsigner 유틸리티는 코드 서명 인증서가 자체 서명되지 않으면 Netscape SignTool 1.3에 의해 파일이 서명되었는지 확인할 수 있습니다. 주: 공식적인 Netscape 코드 서명 인증서를 VeriSign^TM에서 구할 수 있습니다. 그러한 인증서는 VeriSign에서 발급하며, 자체 서명되지 않습니다.

Netscape SignTool 1.3은 코드 서명 인증서가 자체 서명되지 않으면 서명 파일에 인증서를 두지 않으며, 이 서명 파일에 서명자의 인증서가 없으면 jarsigner는 서명된 JAR 파일을 확인할 수 없습니다.주: SignTool 1.3에서 생성한 코드 서명 인증서는 단지 테스트용이며 자체 서명되었습니다. 코드 서명 인증서가 자체 서명된 테스트 인증서이면 Netscape SignTool 1.3에서 JAR 파일을 서명했는지를 jarsigner에서 확인할 수 없다는 것은 이미 알려진 문제입니다.

Java 2 SDK에서는 실제 ClassLoader 인스턴스가 응용프로그램 클래스를 로드했습니다. 그러므로, 응용프로그램 클래스에서 설치된 확장을 사용할 수 있으며, 사용자가 지정한 응용프로그램 클래스 경로를 부트스트랩 경로에서 구분할 수 있습니다. -Xbootclasspath 옵션을 사용하여 부트스트랩 클래스 경로를 무시할 수 있습니다.

그러나, 이는 응용프로그램 클래스가 Java 2 SDK에서 더 이상 기본적으로 모든 사용 권한을 부여받지 않는다는 뜻이기도 합니다. 대신, 이들 응용프로그램 클래스는 시스템의 구성된 보안 정책을 기반으로 사용 권한이 부여됩니다. 이 경우 1.0/1.1의 원래 보안 모델을 기반으로 하여 해당 보안 코드를 기록한 일부 응용프로그램이 예외를 발생하게 하여 Java 2 SDK에서 시작할 수 없게 합니다. 해결 방법은 Java 응용프로그램 시동기의 참조 페이지에 설명된 oldjava 응용 프로그램 시동기로 이러한 응용프로그램을 시작하는 것입니다.

다음은 보안 정책 및 서명과 관련된 문제를 요약한 것입니다.

• Java 2 플랫폼에 사용된 기본 보안 정책은 Java 보안 속성 파일 jre/lib/security/java.security에 있는 policy.provider 속성으로 구현했습니다. 기본이 아닌 보안 정책 구현을 지정할 경우 기본이 아닌 새로운 보안 속성 클래스 파일을 부트스트랩에 두어야 합니다. -Xbootclasspath 명령줄 옵션을 사용하여 이 작업을 수행할 수 있습니다. 이 옵션에 대한 자세한 내용은 Java 응용프로그램 시동기 참조 페이지를 참조하십시오. 이렇게 하면 정책 파일을 부트스트랩 클래스 로더에서 로드하게 됩니다. 새로운 기본 정책 파일을 클래스 경로나 확장과 같은 다른 위치에 두면 이 정책이 선택되지 않으며 sun.security.provider.PolicyFile에 제공된 기본 정책이 대신 사용됩니다.

• Java 2 SDK 버전 1.2.2부터 새로운 클래스 로드 체계를 사용합니다. 새로운 클래스 로더에서 Jar 파일의 패키지에 있는 클래스 파일이 서명되면 동일한 패키지에 있는 모든 클래스 파일은 같은 서명자가 서명해야 합니다. 일부 패키지 클래스는 서명되고 일부 패키지 클래스는 서명되지 않았거나 다른 서명자가 서명한 Jar 파일을 더 이상 사용할 수 없습니다. Jar 파일에는 여전히 서명되지 않은 패키지가 들어 있습니다. 그러나, 패키지에 서명된 클래스가 있으면 이 패키지의 모든 클래스 파일을 동일한 서명자가 서명해야 합니다. 이 조건을 만족하지 않는 기존의 Jar 파일은 이 버전의 Java 2 플랫폼과 함께 사용할 수 없습니다.

keytool 도구는 개행(줄 바꿈)으로 끝나는 파일에서만 Base64-코드화된 인증서를 가져오거나 인쇄할 수 있습니다. 끝에 줄 바꿈이 없는 인증서 파일을 가져오거나 인쇄하려고 하면 "Unsupported encoding" CertificateException이나 "Failed to parse input" 또는 "Input not an X.509 certificate"와 같은 keytool 오류 메시지가 나타납니다.

이러한 메시지가 나타나거나 예외가 발생했다면 파일 끝에 줄 바꿈이 없기 때문입니다. 이러한 문제가 발생하는 한 가지 이유는 인증 기관에서 응답(인증서 서명 요청에 대한 응답)한 인증서의 끝에 줄 바꿈이 없기 때문입니다.

UNIX에서 다음과 같은 명령을 실행하여 파일의 끝에 줄 바꿈을 지정할 것인지의 여부를 결정할 수 있습니다.

    od -xc <certificate_name>

여기서, <certificate_name>은 인증서가 들어 있는 파일 이름입니다. 예를 들어, 파일 이름이 mycert이면 이 명령은 다음과 같습니다.

    od -xc mycert

출력된 결과의 맨 끝에 "\n"(인용 부호 제외)이 있으면 줄 끝에 이미 줄 바꿈이 있는 것입니다. \n이 없는 경우에는 추가하십시오.

인증서 파일의 끝에 줄 바꿈이 있는지의 여부를 모를 경우에는 다음 단락마다 자동 줄바꿈을 추가한 다음 -import 또는 -printcert 명령을 다시 시도하십시오.이 명령이 작동하면 문제는 줄 바꿈이 빠진 것입니다. 여전히 오류가 발생하면 인증서에 다른 문제가 있는 것입니다.

줄 바꿈을 Base64-코드화된 인증서 파일에 추가하려면 텍스트 편집기에서 이 파일을 열고, 커서를 파일 맨 끝에 둔 다음, 줄 바꿈을 추가합니다(또는 줄 바꿈을 캐리지 리턴함). 예를 들면, 키보드에 있는 Enter 키를 누릅니다.

네트워킹

이 릴리스에는 네트워킹 API에 다음과 같은 알려진 버그와 제한이 있습니다.

• Windows 2000의 경우, 데이터그램 응용프로그램에 소켓이 닫혀 있다는 메시지와 함께 예상치 못한 SocketException이 발생할 수 있습니다. 이 문제는 원격 응용프로그램을 사용할 수 없을 경우 Windows 2000의 새로운 작동에 대한 것입니다. 해결 방법은 DatagramSocket을 닫고 다시 만드는 것입니다. 이 문제는 현재 버그 4361783으로 추적 중입니다.

• J2SDK 1.3.0에 HTTP/1.1 클라이언트 구현이 도입되었습니다. Apache와 같은 웹 서버는 코드화된 응답을 분할하여 HTTP 1.1 클라이언트에 반환하지만, J2SDK 1.3.0과 1.3.1의 분할 인코딩 처리 방식은 이 서버에서 분할된 응답을 스트림하지 않습니다. 이는 실제로 java.net.URLConnection.getInputStream과 같은 메소드가 서버의 응답이 완료될 때까지 반환되지 않는다는 뜻입니다. 이 문제는 버그 4333920에 설명되어 있습니다.
  해결 방법: Apache의 경우 해결 방법은 httpd.conf 파일에 다음 명령줄을 지정하는 것입니다.

  BrowserMatch "Java1\.3\..[0-1]" downgrade-1.0
  

• HTML 4.0 사양에는 URI(Uniform Resource Identifier)의 비 ASCII 문자는 하나 이상의 UTF-8바이트로 코드화하는 것이 좋습니다. 대부분의 기존 CGI 스크립트는 문서를 수신한 암호화로부터 바이트를 사용하여 비 ASCII 문자를 처리합니다. 그러나, 클래스 URLEncoder와 URLDecoder는 URI의 비 ASCII 문자를 처리하는 이러한 메소드 중 어떤 메소드도 지원하지 않습니다. 대신, 이러한 클래스는 기존 플랫폼의 기본 암호화에 정의된 대로 1바이트 이상을 문자로 대체합니다. 이 문제가 버그 4257115입니다.

• 클라이언트의 HttpURLConnection.getResponseCode 메소드를 호출하면 Win98 또는 WinNT 서버에서 보낸 HTTP 헤더 필드에 추가 CR이 있을 경우 가상 머신이 충돌하게 됩니다. 이 문제가 버그 4258697입니다.
  해결 방법: HTTP 1.0 응답을 보내도록 http 서버를 구성하여 스택 오버플로가 발생하지 않도록 할 수 있습니다. Apache의 경우 httpd.conf에 다음을 지정하면 됩니다.

  BrowserMatch "Java1\.3\..[0-1]" downgrade-1.0
  

사용하는 응용프로그램에서 네트워킹 클래스를 사용할 경우 Winsock 1.1에서 안정적으로 실행되지 않을 수도 있습니다.사용하는 네트워킹 응용프로그램에서 Winsock 1.1이 포함된 Windows 95를 지원해야 할 경우 응용프로그램 사용자가 Winsock 2.0을 갖도록 해야 합니다. Windows NT 4.0, Windows 2000, Windows ME 및 Windows 98에는 Winsock 2.0이 포함되어 있습니다. 다음 주소에서 Winsock 2.0을 다운로드할 수 있습니다.

http://www.microsoft.com/windows95/downloads/contents/wuadmintools/s_wunetworkingtools/w95sockets2/

다음 URL에는 Winsock 2.0 구성 요소가 Windows 95 플랫폼에 설치되어 있는지의 여부를 결정하는 방법에 대한 정보가 들어 있습니다.

http://support.microsoft.com/support/kb/articles/Q177/7/19.asp

이름 조회가 실패할 경우 Winsock을 업데이트하지 않으면 InetAddress.getByName이 kernel32.dll에서 충돌할 수 있습니다. 이 버그에 대한 자세한 내용은 Microsoft 웹 사이트를 참조하십시오.

http://support.microsoft.com/support/kb/articles/Q176/3/54.ASP

Java^TM Plug-in 구성 요소

다음은 이 릴리스의 Java Plug-in 구성 요소에 대한 것입니다.

• Linux 플랫폼에서는 웹 브라우저에서 한 애플릿에 대해 여러 개의 복사본을 인쇄할 수 없습니다. 한 번 인쇄한 다음에는 브라우저를 닫고 다시 시작해야 합니다. 이 문제는 현재 버그 번호 4450194로 추적 중입니다.

• Java Plug-in 구성 요소에 확장을 설치할 때 사용자에게 경고 메시지를 표시하는 경고 대화 상자가 나타납니다. 사용자가 "Deny" 단추를 눌러도 동일한 확장 설치를 승인 도는 거부할 것인지 묻는 경고 대화 상자가 다시 나타납니다. 이 버그는 다음 릴리스에서 수정될 것입니다.

• 1.3.0_01에는 인증서 CA 저장소를 사용하도록 변경된 서명 확인이 Microsoft Internet Explorer와 함께 제공되는 저장소 대신 Sun Java runtime environment와 함께 제공됩니다. 이는 인증서 저장소를 Internet Explorer에서 사용하면 Netscape 웹 브라우저에서 실행하는 에플릿에 대해서는 작동하지 않기 때문에 변경되었습니다. 버전 1.3.1에 추가로 도입된 오류 처리 코드는 확인할 수 없는 서명을 처리합니다. 버그 보고서 4424604를 참조하십시오.

현지화 정보

이 릴리스의 국제 로켈 지원에 대한 일반 정보는 Localization Notes를 참조하십시오.

설명서

다음 설명은 이 릴리스의 설명서에 대한 것입니다.

• 버그4459595로 인해 이 릴리스에 대한 API 사양의 Serialized Form 페이지에는 개인 파일 및 패키지 클래스에 대한 끊어진 링크가 들어 있습니다.

• 새 온라인 설명서 Tuning Garbage Collection with the 1.3.1 Java Virtual Machine을 참조하십시오.

도구가 Solaris 2.6의 일본어 PCK 문자열을 변환할 수 없다

Solaris 2.6 ja_JP.PCK 로켈에서 java 명령 인수로 일본어 문자열을 사용하면 오류가 발생합니다. 이 문제를 해결하려면 89행 /usr/java/bin/.java_wrapper를 다음에서

exec $DEBUG_PROG "$prog" $opts "$@"

다음과 같이 변경하십시오.

exec $DEBUG_PROG $prog $opts $@

중국어 번체 글꼴 문제

중국어 번체 글꼴에 대한 다음과 같은 문제는 이 릴리스에 이미 알려진 것입니다.

• Microsoft Windows 95 for Traditional Chinese Version 2.0에는 Java 2 SDK의 글꼴 속성 파일에 지정된 중국어 번체 글꼴이 없습니다. 이 운영 체제에서 Java 2 SDK 또는 Java 2 Runtime Environment를 사용하면 "글꼴이 없습니다"라는 경고가 나타나며 텍스트가 제대로 나타나지 않습니다. 1996년 10월에 릴리스되었으며 지정된 글꼴이 포함되어 있는 새로운 Microsoft Windows 95 for Traditional Chinese Version 2.0 Second Release에는 이 문제가 나타나지 않습니다.

• Microsoft Windows 95의 중국어 번체 환경에서 중국어 문자는 Swing 구성 요소에 제대로 나타나지 않습니다. 이 문제에 대한 자세한 내용은 Java Developer Connection^SM 웹 사이트에 있는 버그 보고서 4431319를 참조하십시오.

영어 로켈의 경우, Java 2 SDK 버전 1.3.1이 Windows 2000 Professional, Windows 2000 Server, Window 2000 Advanced Server에서 지원됩니다. Windows 2000 의 DataCenter 버전은 지원되지 않습니다. 비 영어 로켈의 경우, Windows 2000의 Professional 버전만 지원됩니다. Windows 2000의 알려진 문제는 다음과 같습니다.

• Windows 2000 및 다중 모니터 지원 - 다중 모니터는 아직 Windows 2000 플랫폼에서 완전하게 작동하지 않습니다. 특히, 256색 모드는 모든 모니터가 256색 모드로 설정되어 있을 때 제대로 작동합니다. 16비트(또는 그 이상) 색상 모드를 사용하는 것이 좋습니다.

• Windows 2000에서 설치 중에 다음과 같은 오류 메시지가 나타나는 경우

     config.nt. The system file is not suitable for running MS-DOS 
     and Microsoft Windows Applications.
  

  이 메시지는 일부 Windows 2000 설치에 있는 %SystemRoot%\System32\COMMAND.COM 파일에 문제가 있음을 나타냅니다. 설치 관리자를 시작하려고 할 때 이러한 오류 메시지가 나타나면 아래 Microsoft 웹 사이트에서

  http://support.microsoft.com/support/kb/articles/Q142/2/71.asp

  문제 해결 방법에 대한 정보를 찾아보십시오.

• 프로세스 중단 - Microsoft Windows 2000 Professional, Server 및 Advanced Server 운영 체제에서 Ntdll의 교착 상태로 인해 응용프로그램이 중단될 수 있습니다. 예를 들면, 이 문제는 java.lang.Process 객체의 입력 및 출력 스트림을 사용하는 응용프로그램에서 발생할 수 있습니다. 수정 사항을 비롯하여 자세한 내용은 Microsoft 지원 서비스 웹 사이트를 참조하십시오.

  http://support.microsoft.com/support/kb/articles/Q271/1/82.ASP

Windows NT에 설치

Java Runtime Environment의 버전 1.3.1을 설치할 때 C:\Winnt\Downloaded Program Files\Java Runtime Environment 1.3.1의 ActiveX Control 파일이 "Damaged" 상태일 수 있습니다. 이것은 단지 표면적인 문제이며 "Damaged" 상태는 어떠한 상황에도 악영향을 주지는 않습니다.

그러나 이와 같은 Damaged 상태가 발생하는 것이 문제가 되는 상황이라면 해결 방법이 있습니다. "시작 -> 실행"을 누르고 "regedit"를 입력합니다. "레지스트리 편집기" 창에서 레지스트리 키 "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Code Store Database\Distribution Units\8AD9C840-044E-11D1-B3E9-00805F499D93\DownloadInformation"으로 이동합니다. INF 문자열을 두 번 누르고 "값 데이터" 아래에 반전된 문자열을 삭제합니다. ActiveX Control 파일의 상태가 "Installed"로 바뀝니다.

Copyright © 2001 Sun Microsystems, Inc. All Rights Reserved.