JavaTM Platform
Standard Ed. 6

java.util
클래스 ServiceLoader<S>

java.lang.Object 
  상위를 확장 java.util.ServiceLoader<S>
형태 파라미터:
S - 이 로더에 의해 로드 되는 서비스의 형태
모든 구현된 인터페이스:
Iterable <S>


public final class ServiceLoader<S>
extends Object
implements Iterable <S>

간단한 서비스 프로바이더 로드 기구입니다.

「서비스」란, 기존의 인터페이스 및 클래스 (일반적으로은 추상 클래스)세트입니다. 「서비스 프로바이더」란, 특정의 서비스의 구현입니다. 일반적으로, 프로바이더의 클래스에 의해, 서비스 자체에 정의되고 있는 클래스의 인터페이스와 서브 클래스가 구현됩니다. 서비스 프로바이더를 Java 플랫폼의 구현에 인스톨 할 때는, 확장 기능의 형식, 즉, 확장 기능의 일반적으로의 디렉토리에 배치되는 jar 파일의 형식에서 행해집니다. 프로바이더를 이용 가능하게 하려면 , 어플리케이션의 클래스 패스에 추가하는지, 플랫폼 고유의 방법을 사용합니다.

서비스는 로드 목적을 위해서(때문에), 단일의 형태, 즉 단일의 인터페이스 또는 추상 클래스로서 표현됩니다. (구상 클래스도 사용할 수 있습니다만, 그것은 추천할 수 없습니다. ) 특정의 서비스의 프로바이더에는, 그 「서비스 타입」을 프로바이더에 고유의 데이터나 코드로 확장한, 1 개(살) 이상의 구상 클래스가 포함되어 있습니다. 일반적으로, 「프로바이더 클래스」에는, 프로바이더 자체가 모두 포함될 것은 없습니다. 요구시에 실제의 프로바이더를 작성할 수 있는 코드와 함께, 프로바이더가 특정의 요구를 채울 수가 있을지 어떨지를 식별하기 위해서 필요한 정보로 구성되는 프록시가 되어 있습니다. 프로바이더 클래스의 내용은, 개별의 서비스에 크게 의존합니다. 1 개의 클래스 또는 인터페이스로 프로바이더 클래스를 통합할 수 없습니다. 이 때문에, 이러한 형태는 여기에서는 정의되고 있지 않습니다. 이 기능이 강제하는 유일한 요구는, 프로바이더 클래스에는, 로드안에 인스턴스를 생성할 수 있도록(듯이), 인수를 취하지 않는 생성자 이 존재하지 않으면 안 되는, 이라고 하는 것입니다.

서비스 프로바이더는, 자원 디렉토리 META-INF/services 에 「프로바이더 구성 파일」을 배치하는 것에 의해 식별됩니다. 이 파일의 이름은, 서비스의 형태의 완전 수식바이너리명이 됩니다. 이 파일에는, 구상 프로바이더 클래스의 완전 수식 바이너리명이 1 행에 1 개씩 기술됩니다. 각각의 이름을 둘러싸는 공백 문자와 탭 문자, 및 공백행은 무시됩니다. 코멘트 문자는 '#' ('\u0023',NUMBER SIGN)입니다. 줄머리에 코멘트 문자가 삽입되고 있는 경우, 그 행의 모든 문자는 무시됩니다. 파일은 UTF-8 로 encode 되고 있을 필요가 있습니다.

특정의 구상 프로바이더 클래스가 복수의 구성 파일내, 또는 같은 구성 파일내에서 반복해 지정되고 있는 경우, 중복 한 지정은 무시됩니다. 특정의 프로바이더를 지정한 구성 파일을, 프로바이더 자체와 같은 JAR 파일 (또는 그 외의 배포 단위) 내에 포함할 필요는 없습니다. 이 프로바이더에는, 구성 파일의 검색시에 최초로 조회된 클래스 로더로부터 액세스 할 수 없으면 안됩니다. 그 클래스 로더는, 파일이 실제로 로드 되었을 때의 클래스 로더와 동일하다라고는 한정되지 않는 것에 주의해 주세요.

프로바이더의 검색과 인스턴스화는, 지연적으로, 즉 On Demand로 행해집니다. 서비스 로더는, 이전에 로드 된 프로바이더의 캐쉬를 유지 관리합니다. iterator 메소드가 불려 갈 때마다, 반복자가 1 개 돌려주어집니다. 이 반복자는 우선, 캐쉬의 모든 요소를 인스턴스화 된 차례로 생성해, 다음에, 남아 모든 프로바이더를 지연적으로 검색해 인스턴스화해, 각 프로바이더를 순서에 캐쉬에 추가합니다. reload 메소드를 사용하면, 캐쉬를 클리어 할 수 있습니다.

서비스 로더는 항상, 호출원의 시큐리티 문맥내에서 실행됩니다. 신뢰할 수 있는 시스템 코드는 일반적으로, 이 클래스내의 메소드나 그러한 메소드로부터 반환되는 반복자의 메소드를, 특권 첨부의 시큐리티 문맥내로부터 호출해야 합니다.

이 클래스의 인스턴스는, 복수의 thread로 병행해 사용할 수 없습니다.

특히 지정되어 있지 않은 한, 이 클래스내의 메소드에 null 인수를 건네주면(자),NullPointerException 가 throw 됩니다.

있는 프로토콜용의 일련의 엔코더/디코더 페어를 표현하기 위해서 설계된 서비스 타입 com.example.CodecSet 가 있다고 합니다. 이 경우, 그것은 다음의 2 개의 추상 메소드를 포함한 추상 클래스입니다.

 public abstract Encoder getEncoder(String encodingName);
 public abstract Decoder getDecoder(String encodingName);
각 메소드는 적절한 객체를 돌려줍니다. 다만, 프로바이더가 지정된 인코딩을 지원하지 않는 경우는 null 를 돌려줍니다. 일반적으로의 프로바이더에서는, 복수의 인코딩이 지원되고 있습니다.

com.example.impl.StandardCodecsCodecSet 서비스의 구현의 1 개인 경우, 그 JAR 파일에는 다음의 이름의 파일도 포함되어 있습니다.

 META-INF/services/com.example.CodecSet

이 파일에는, 다음의 행이 포함됩니다.

 com.example.impl.StandardCodecs    # Standard codecs

CodecSet 클래스는, 초기화시에 단일의 서비스 인스턴스를 작성 및 보존합니다.

 private static ServiceLoader<CodecSet> codecSetLoader
     = ServiceLoader.load(CodecSet.class);

지정된 인코딩명에 대응하는 엔코더를 검색하기 위해서, 그것은 static 팩토리 메소드를 정의합니다. 이 메소드는, 기존으로 사용 가능한 프로바이더에 대해서 반복 처리를 실행해, 적절한 엔코더가 발견되었는지 프로바이더의 유효기간이 끊어졌을 경우에게만 리턴 합니다.

 public static Encoder getEncoder(String encodingName) {
     for (CodecSet cp : codecSetLoader) {
         Encoder enc = cp.getEncoder(encodingName);
         if (enc ! = null)
             return enc;
     }
     return null;
 }

getDecoder 메소드도 이와 같이 정의됩니다.

사용상의 주의점 프로바이더의 로드에 사용되는 클래스 로더의 클래스 패스에 원격 네트워크 URL 가 포함되어 있는 경우, 프로바이더 구성 파일의 검색중에 그러한 URL 가 간접 참조됩니다.

이 활동은 정상적입니다만, 그 경우, Web 서버의 로그내에 불가해한 엔트리가 작성될 가능성이 있습니다. 다만, Web 서버가 올바르게 구성되어 있지 않은 경우에는, 이 활동에 의해 프로바이더 로드 알고리즘이 의사적으로 실패할 가능성이 있습니다.

요구된 자원이 존재하지 않는 경우, Web 서버는 HTTP 404 (Not Found) 응답을 돌려주어야 합니다. 그런데 , Web 서버 속에는, 그러한 경우에 HTTP 200 (OK) 응답과 유용한 HTML 에러 페이지를 돌려주도록(듯이), 잘못해 구성되어 있는 것도 있습니다. 그 경우, 이 클래스가 그 HTML 페이지를 프로바이더 구성 파일로서 해석하려고 한 시점에서,ServiceConfigurationError 가 throw 됩니다. 이 문제의 최선의 해결책은, 잘못해 구성된 Web 서버가 올바른 응답 코드 (HTTP 404)와 HTML 에러 페이지를 돌려주도록(듯이), 수정하는 것입니다.

도입된 버젼:
1.6

메소드의 개요
 Iterator <S > iterator ()
          이 로더의 서비스의 사용 가능한 프로바이더를, 지연적으로 로드합니다.
static
<S> ServiceLoader <S>
load (Class <S> service)
          지정된 서비스 타입의 새로운 서비스 로더를, 현재의 thread의 문맥 클래스 로더 를 사용해 작성합니다.
static
<S> ServiceLoader <S>
load (Class <S> service, ClassLoader  loader)
          지정된 서비스 타입과 클래스 로더에 대응하는 새로운 서비스 로더를 작성합니다.
static
<S> ServiceLoader <S>
loadInstalled (Class <S> service)
          지정된 서비스 타입의 새로운 서비스 로더를, 확장 클래스 로더를 사용해 작성합니다.
 void reload ()
          이 로더의 프로바이더 캐쉬를 클리어 해, 모든 프로바이더가 재로드 되도록(듯이) 합니다.
 String toString ()
          이 서비스를 기술한 캐릭터 라인을 돌려줍니다.
 
클래스 java.lang. Object 로부터 상속된 메소드
clone , equals , finalize , getClass , hashCode , notify , notifyAll , wait , wait , wait
 

메소드의 상세

reload

public void reload()
이 로더의 프로바이더 캐쉬를 클리어 해, 모든 프로바이더가 재로드 되도록(듯이) 합니다.

이 메소드가 불려 가면(자),iterator 메소드의 후속의 호출은, 작성된지 얼마 안된 로더가 실시하는 것 멈춘 구 같이 프로바이더를 처음부터 지연적으로 검색 및 인스턴스화합니다.

이 메소드는, 실행중의 Java 가상 머신내에 새로운 프로바이더를 인스톨 할 수 있는 것 같은 상황으로 사용하기 위한의 것입니다.


iterator

public Iterator <S > iterator()
이 로더의 서비스의 사용 가능한 프로바이더를, 지연적으로 로드합니다.

이 메소드로부터 반환되는 반복자는 우선, 프로바이더 캐쉬의 모든 요소를 인스턴스화 된 차례로 생성합니다. 다음에, 반복자는 남아 모든 프로바이더를 지연적으로 로드해 인스턴스화해, 각 프로바이더를 순서에 캐쉬에 추가합니다.

지연성을 실현하기 위해서(때문에), 사용 가능한 프로바이더 구성 파일을 해석해, 프로바이더를 인스턴스화한다고 하는 실제의 작업은, 반복자 자체에 의해 행해집니다. 따라서, 그 hasNextnext 메소드는, 프로바이더 구성 파일이 지정된 형식에 위반하고 있는 경우, 검색 및 인스턴스화할 수 없는 프로바이더 클래스가 프로바이더 구성 파일내로 지정되고 있었을 경우, 클래스를 인스턴스화한 결과를 서비스 타입에 대입할 수 없는 경우, 또는 다음의 프로바이더를 검색 및 인스턴스화할 때에 그 외의 모든 종류의 예외나 에러가 throw 되었을 경우에,ServiceConfigurationError 를 throw 할 가능성이 있습니다. 서비스 반복자를 사용하는 경우에, 완강한 코드를 기술하기 위해서 필요한 (일)것은,ServiceConfigurationError 를 캐치 하는 것 뿐입니다.

그러한 에러가 throw 되었을 경우, 반복자의 후속의 호출은 최선의 노력을 다해, 다음에 사용 가능한 프로바이더를 검색 및 인스턴스화하려고 합니다만, 일반적으로, 그러한 복구는 반드시 성공한다고는인가 선.

설계상의 주의점 이러한 경우에 에러를 throw 하는 것은, 극단적으로 보일지도 모릅니다. 이러한 동작이 되어 있는 이유는, 부정한 프로바이더 구성 파일은 부정한 클래스 파일과 같이, Java 가상 머신의 구성 방법이나 사용 방법에 관한 심각한 문제를 나타내고 있는 것에 있습니다. 이 때문에, 복구하려고 하거나 한층 더 나쁜 것에 아무 통지도 없게 실패하거나 하는 것보다도, 에러를 throw 하는 것을 추천합니다.

이 메소드로부터 반환되는 반복자는, 삭제를 지원하지 않습니다. 그 remove 메소드를 호출하면(자),UnsupportedOperationException 가 throw 됩니다.

정의:
인터페이스 Iterable <S > 내의 iterator
반환값:
이 로더의 서비스의 프로바이더를 지연적으로 로드하는 반복자

load

public static <S> ServiceLoader <S> load(Class <S> service,
                                        ClassLoader  loader)
지정된 서비스 타입과 클래스 로더에 대응하는 새로운 서비스 로더를 작성합니다.

파라미터:
service - 서비스를 나타내는 인터페이스 또는 추상 클래스
loader - 프로바이더 구성 파일과 프로바이더 클래스의 로드에 사용하는 클래스 로더. 시스템 클래스 로더 (그것이 실패했을 경우는 bootstrap 클래스 로더)를 사용하는 경우는 null
반환값:
새로운 서비스 로더

load

public static <S> ServiceLoader <S> load(Class <S> service)
지정된 서비스 타입의 새로운 서비스 로더를, 현재의 thread의 문맥 클래스 로더 를 사용해 작성합니다.

이 메소드를 다음의 형식에서 호출하면(자), 상기의 동작을 합니다.

 ServiceLoader.load(service)
이것은, 다음과 같이 지정하는 것과 같습니다.
 ServiceLoader.load(service,
                    Thread.currentThread(). getContextClassLoader())

파라미터:
service - 서비스를 나타내는 인터페이스 또는 추상 클래스
반환값:
새로운 서비스 로더

loadInstalled

public static <S> ServiceLoader <S> loadInstalled(Class <S> service)
지정된 서비스 타입의 새로운 서비스 로더를, 확장 클래스 로더를 사용해 작성합니다.

이 편리한 메소드는 단순하게, 확장 클래스 로더를 검색해 (이것을 extClassLoader 로 한다), 다음의 값을 돌려줍니다.

 ServiceLoader.load(service, extClassLoader)

확장 클래스 로더가 발견되지 않는 경우는 시스템 클래스 로더가 사용되어 시스템 클래스 로더가 존재하지 않는 경우는 bootstrap 클래스 로더가 사용됩니다.

이 메소드는, 인스톨 끝난 프로바이더만이 필요한 경우에 사용하기 위한의 것입니다. 결과적으로 얻을 수 있는 서비스는, 현재의 Java 가상 머신에 인스톨 되고 있는 프로바이더만을 검색 및 로드합니다. 어플리케이션의 클래스 패스상의 프로바이더는 무시됩니다.

파라미터:
service - 서비스를 나타내는 인터페이스 또는 추상 클래스
반환값:
새로운 서비스 로더

toString

public String  toString()
이 서비스를 기술한 캐릭터 라인을 돌려줍니다.

오버라이드(override):
클래스 Object 내의 toString
반환값:
설명문자열

JavaTM Platform
Standard Ed. 6

버그의 보고와 기능의 요청
한층 더 자세한 API 레퍼런스 및 개발자 문서에 대해서는,Java SE 개발자용 문서를 참조해 주세요. 개발자전용의 상세한 해설, 개념의 개요, 용어의 정의, 버그의 회피책, 및 코드 실례가 포함되어 있습니다.

Copyright 2006 Sun Microsystems, Inc. All rights reserved. Use is subject to license terms . Documentation Redistribution Policy 도 참조해 주세요.