Introduction to the Service Provider Interfaces--官方文档

地址:https://docs.oracle.com/javase/tutorial/sound/SPI-intro.html

What Are Services?

Services are units of sound-handling functionality that are automatically available when an application program makes use of an implementation of the Java Sound API. They consist of objects that do the work of reading, writing, mixing, processing, and converting audio and MIDI data. An implementation of the Java Sound API generally supplies a basic set of services, but mechanisms are also included in the API to support the development of new sound services by third-party developers (or by the vendor of the implementation itself). These new services can be "plugged into" an existing installed implementation to expand its functionality without requiring a new release. In the Java Sound API architecture, third-party services are integrated into the system in such a way that an application program‘s interface to them is the same as the interface to the "built-in" services. In some cases, application developers who use thejavax.sound.sampled and javax.sound.midi packages might not even be aware that they are employing third-party services.

Examples of potential third-party, sampled-audio services include:

  • Sound file readers and writers
  • Converters that translate between different audio data formats
  • New audio mixers and input/output devices, whether implemented purely in software, or in hardware with a software interface

Third-party MIDI services might consist of:

  • MIDI file readers and writers
  • Readers for various types of soundbank files (which are often specific to particular synthesizers)
  • MIDI-controlled sound synthesizers, sequencers, and I/O ports, whether implemented purely in software, or in hardware with a software interface

How Services Work

The javax.sound.sampled and javax.sound.midi packages provide functionality to application developers who wish to include sound services in their application programs. These packages are for consumers of sound services, providing interfaces to get information about, control, and access audio and MIDI services. In addition, the Java Sound API also supplies two packages that define abstract classes to be used by providers of sound services: the javax.sound.sampled.spi and javax.sound.midi.spi packages.

Developers of new sound services implement concrete subclasses of the appropriate classes in the SPI packages. These subclasses, along with any additional classes required to support the new service, are placed in a Java Archive (JAR) archive file with a description of the included service or services. When this JAR file is installed in the user‘s CLASSPATH, the runtime system automatically makes the new service available, extending the functionality of the Java platform‘s runtime system.

Once the new service is installed, it can be accessed just like any previously installed service. Consumers of services can get information about the new service, or obtain instances of the new service class itself, by invoking methods of the AudioSystem and MidiSystem classes (in the javax.sound.sampled and javax.sound.midi packages, respectively) to return information about the new services, or to return instances of new or existing service classes themselves. Application programs need not—and should not—reference the classes in the SPI packages (and their subclasses) directly to make use of the installed services.

For example, suppose a hypothetical service provider called Acme Software, Inc. is interested in supplying a package that allows application programs to read a new format of sound file (but one whose audio data is in a standard data format). The SPI class AudioFileReader can be subclassed into a class called, say, AcmeAudioFileReader. In the new subclass, Acme would supply implementations of all the methods defined in AudioFileReader; in this case there are only two methods (with argument variants), getAudioFileFormat andgetAudioInputStream. Then when an application program attempted to read a sound file that happened to be in Acme‘s file format, it would invoke methods of the AudioSystem class injavax.sound.sampled to access the file and information about it. The methods AudioSystem.getAudioInputStream and AudioSystem.getAudioFileFormat provide a standard API to read audio streams; with the AcmeAudioFileReader class installed, this interface is extended to support the new file type transparently. Application developers don‘t need direct access to the newly registered SPI classes: the AudioSystem object methods pass the query on to the installed AcmeAudioFileReader class.

What‘s the point of having these "factory" classes? Why not permit the application developer to get access directly to newly provided services? That is a possible approach, but having all management and instantiation of services pass through gatekeeper system objects shields the application developer from having to know anything about the identity of installed services. Application developers just use services of value to them, perhaps without even realizing it. At the same time this architecture permits service providers to effectively manage the available resources in their packages.

Often the use of new sound services is transparent to the application program. For example, imagine a situation where an application developer wants to read in a stream of audio from a file. Assuming that thePathName identifies an audio input file, the program does this:

    File theInFile = new File(thePathName);
    AudioInputStream theInStream = AudioSystem.getAudioInputStream(theInFile);

Behind the scenes, the AudioSystem determines what installed service can read the file and asks it to supply the audio data as an AudioInputStream object. The developer might not know or even care that the input audio file is in some new file format (such as Acme‘s), supported by installed third-party services. The program‘s first contact with the stream is through theAudioSystem object, and all its subsequent access to the stream and its properties are through the methods of AudioInputStream. Both of these are standard objects in thejavax.sound.sampled API; the special handling that the new file format may require is completely hidden.

How Providers Prepare New Services

Service providers supply their new services in specially formatted JAR files, which are to be installed in a directory on the user‘s system where the Java runtime will find them. JAR files are archive files, each containing sets of files that might be organized in hierarchical directory structures within the archive. Details about the preparation of the class files that go into these archives are discussed in the next few pages, which describe the specifics of the audio and MIDI SPI packages; here we‘ll just give an overview of the process of JAR file creation.

The JAR file for a new service or services should contain a class file for each service supported in the JAR file. Following the Java platform‘s convention, each class file has the name of the newly defined class, which is a concrete subclass of one of the abstract service provider classes. The JAR file also must include any supporting classes required by the new service implementation. So that the new service or services can be located by the runtime system‘s service provider mechanism, the JAR file must also contain special files (described below) that map the SPI class names to the new subclasses being defined.

To continue from our example above, say Acme Software, Inc. is distributing a package of new sampled-audio services. Let‘s suppose this package consists of two new services:

  • The AcmeAudioFileReader class, which was mentioned above, and which is a subclass of AudioFileReader
  • A subclass of AudioFileWriter called AcmeAudioFileWriter, which will write sound files in Acme‘s new format

Starting from an arbitrary directory—let‘s call it /devel—where we want to do the build, we create subdirectories and put the new class files in them, organized in such a manner as to give the desired pathname by which the new classes will be referenced:

    com/acme/AcmeAudioFileReader.class
    com/acme/AcmeAudioFileWriter.class

In addition, for each new SPI class being subclassed, we create a mapping file in a specially named directory META-INF/services. The name of the file is the name of the SPI class being subclassed, and the file contains the names of the new subclasses of that SPI abstract class.

We create the file

  META-INF/services/javax.sound.sampled.spi.AudioFileReader

which consists of

    # Providers of sound file-reading services
    # (a comment line begins with a pound sign)
    com.acme.AcmeAudioFileReader

and also the file

  META-INF/services/javax.sound.sampled.spi.AudioFileWriter

which consists of

    # Providers of sound file-writing services
    com.acme.AcmeAudioFileWriter

Now we run jar from any directory with the command line:

jar cvf acme.jar -C /devel .

The -C option causes jar to switch to the /devel directory, instead of using the directory in which the command is executed. The final period argument instructs jar to archive all the contents of that directory (namely, /devel), but not the directory itself.

This run will create the file acme.jar with the contents:

com/acme/AcmeAudioFileReader.class
com/acme/AcmeAudioFileWriter.class
META-INF/services/javax.sound.sampled.spi.AudioFileReader
META-INF/services/javax.sound.sampled.spi.AudioFileWriter
META-INF/Manifest.mf

The file Manifest.mf, which is generated by the jar utility itself, is a list of all the files contained in the archive.

How Users Install New Services

For end users (or system administrators) who wish to get access to a new service through their application programs, installation is simple. They place the provided JAR file in a directory in theirCLASSPATH. Upon execution, the Java runtime will find the referenced classes when needed.

It‘s not an error to install more than one provider for the same service. For example, two different service providers might supply support for reading the same type of sound file. In such a case, the system arbitrarily chooses one of the providers. Users who care which provider is chosen should install only the desired one.

时间: 2024-10-01 19:55:59

Introduction to the Service Provider Interfaces--官方文档的相关文章

Android官方文档之Introduction

写在前面的话:接触Android的时间也不短了,听了视频.看了书.敲了代码,写了博客,做了demo...但是想做出一款优秀的APP(哪怕是封装一个不错的功能)还有很长的路要走.于是前些日子我打算更加深入地往底层.往源代码方向研究Android--我就买了一本<Android群英传>拜读一下,在刚读到前言的时候,我发现作者推荐了阅读官方的Training和Guide,我才意识到,其实之前我接触到的各个渠道的Android知识,都是来自官方文档,与其更加深入地了解Android,不如把官方文档的内

官方文档备份指南一 Introduction to Backup and Recovery

1.备份分为:物理备份和逻辑备份 物理备份:备份数据文件  控制文件  归档日志文件 逻辑备份:EXP EXPDP备份等 物理备份为主,逻辑做补充 2.错误的类型 media failure :介质失败.磁盘不能读写 user error: 操作错误 application error:应用程序错误 3.备份的方式 RMAN                                :RMAN备份 User managed backup      :用户手工备份 4. 关于RMAN备份的一些

Android官方文档之Creating a Content Provider

写在前面的话:说两点.1.很荣幸自己的两篇文章< Android官方文档之App Components(Intents and Intent Filters)>.<Android官方文档之App Components(Common Intents)>被郭霖老师转载了,一方面说明我的博客内容得到了认可,另一方面也鞭策我继续写出质量更高的博文:2.最近在翻译官方文档,今天翻墙一看,发现页面改版了,而且居然默认显示了中文的文档(其实改版以前也有官方的中文文档,只是默认显示英文而已,另外中

Spring 4 官方文档学习 Spring与Java EE技术的集成

本部分覆盖了一下内容: Chapter 28, Remoting and web services using Spring -- 使用Spring进行远程和web服务 Chapter 29, Enterprise JavaBeans (EJB) integration -- EJB集成 Chapter 30, JMS (Java Message Service) -- JMS (Java 消息服务) Chapter 31, JMX Chapter 32, JCA CCI Chapter 33,

Google 官方文档解析之——Application Fundamentals

Android apps are written in the java programming language.The Android SDK tools compile your code-along with any data and resource file-into an APK:an Android package,which is an archive file with an .apk suffix.One APK file contains all the contents

Spring Cloud官方文档中文版-声明式Rest客户端:Feign

官方文档地址为:http://cloud.spring.io/spring-cloud-static/Dalston.SR2/#spring-cloud-feign 文中例子我做了一些测试在:http://git.oschina.net/dreamingodd/spring-cloud-preparation Declarative REST Client: Feign 声明式Rest客户端:Feign Feign is a declarative web service client. It

【苦读官方文档】2.Android应用程序基本原理概述

官方文档原文地址 应用程序原理 Android应用程序是通过Java编程语言来写.Android软件开发工具把你的代码和其它数据.资源文件一起编译.打包成一个APK文件,这个文档以.apk为后缀,保存了一个Android应用程序全部的内容.Android设备通过它来安装相应的应用. 一旦安装到设备上.每一个Android应用程序就执行在各自独立的安全沙盒中: Android系统是一个多用户的Linux系统.每一个应用都是一个用户. Android系统默认会给每一个应用分配一个唯一的用户ID(这个

hbase官方文档(转)

Apache HBase™ 参考指南  HBase 官方文档中文版 Copyright © 2012 Apache Software Foundation.保留所有权利. Apache Hadoop, Hadoop, MapReduce, HDFS, Zookeeper, HBase 及 HBase项目 logo 是Apache Software Foundation的商标. Revision History Revision 0.95-SNAPSHOT 2012-12-03T13:38 中文版

Android Google官方文档(cn)解析之——Intents and Intent filter

应用程序核心组件中的三个Activity,service,还有broadcast receiver都是通过一个叫做intent的消息激活的.Intent消息传送是在相同或不同的应用程序中的组件之间后运行时绑定的一个设施.Intent对象也就是它自己是一个数据结构,这个数据结构持有将要执行操作的抽象描述,或者在broadcast的情况下,是一个已经发生而将要宣布的描述.为传递intent到每个不同类型的组件有单独的机制: 一个Intent对象被传递到Context.startActivity()或

Spring 4 官方文档学习(五)核心技术之SpEL

1.介绍 SpEL支持在runtime 查询.操作对象图. 2.功能概览 英文 中文 Literal expressions 字面值表达式 Boolean and relational operators 布尔和关系操作符 Regular expressions  正则表达式 Class expressions 类表达式 Accessing properties, arrays, lists, maps 访问properties.arrays.lists.maps Method invocati