JDK-4105244 : RFE: Input Method Framework should handle Java input methods
  • Type: Enhancement
  • Component: client-libs
  • Sub-Component: java.awt:i18n
  • Affected Version: 1.1.5,1.2.0
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • OS:
    generic,solaris_2.5,windows_95,windows_nt generic,solaris_2.5,windows_95,windows_nt
  • CPU: generic,x86
  • Submitted: 1998-01-20
  • Updated: 1999-07-07
  • Resolved: 1999-07-07
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
1.3.0 betaFixed
Related Reports
Duplicate :  
Duplicate :  
Duplicate :  
Description

Name: joT67522			Date: 01/20/98



The background is, I plan
to write an input method for Java as there are forbidding difficulties in
refitting Windows NT (my system) with Asian input methods, however this project is
stalled until a framework for input methods is provided.

The Input Method Framework provided in JDK 1.2 depends on the native
input methods of the host platform. In this respect Java relies exclusively on
the specific native system: If the host has no input method, Java cannot use an
input method. Java is supposed to be plattform independant and international ; It
is not in this respect.

Let me add a short explanation of the technical terms: Input methods or input
method editors (IME) are software components that interpret user operations such
as typing keys, speaking, or writing using a pen device to generate text input for
applications. The most common input methods are the ones that let users type text 
in Chinese, Japanese, or Korean, languages that use thousands of different characters, 
on a regular-sized keyboard. The Input Method Framework in JDK 1.2 defines
classes and interfaces that enable all text editing components to receive text
through input methods. However, in JDK 1.2, only the native input methods of
the host platform are supported. No Java-based input methods can be added.

An API extension that will allow for input methods written in Java to be plugged
in is essential for platform independence. That even JDK 1.2 won't have this
feature runs counter to Java's promised universality and internationality, as it
appears that this enhacement won't be done any time soon.

How about at least publishing an Early Access beta?

At the moment, Java's internationalization looks like a ladder with the last spokes 
missing. This missing feature quashes Java's system independancy whenever 
Chinese, Japanese or Korean are used.

As a note: There are several companies and individual programmers waiting to
write Java input methods, yet those projects are severely hampered or even stalled
by the missing support for Java based input methods. Java could provide the solution
for most internationalization worries (Just try to refit a Western Windows system
with a good Japanese and/or Chinese input method, it appears impossible).


(Review ID: 23256)
======================================================================

Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: kestrel FIXED IN: kestrel-beta INTEGRATED IN: kestrel-beta
14-06-2004

SUGGESTED FIX Java Feature Request: Input Method Engine SPI Problem The Java 2 platform provides an input method framework that lets applications interact with input methods to provide text input mechanisms that go beyond simple typing on the keyboard. In version 1.2, however this framework only works with host input methods and server-based input methods using IIIMP. There have been numerous requests to add support for input methods implemented in the Java programming language that can be plugged into any Java runtime. Input methods for East Asian languages on other platforms are commonly sold as separate retail software products. RFE 4105244 - Input Method Framework should handle Java input methods Requestors Norbert Lindenberg, Masayoshi Okutsu, Fujitsu, Justsystem, IBM, Omron, Matsushita, Solaris Software, Consumer and Embedded, Sun China, and others Proposed API and feature changes Provide an input method engine SPI (service provider interface) that enables the development of input method engines in the Java programming language that can be used with any Java runtime environment. A draft specification is available at http://javaweb.eng/~norbert/ime.latest/guide/ime/index.html. Here's a summary: In package java.awt.im or in a new package java.awt.im.spi (TBD), add interfaces InputMethod, InputMethodDescriptor, InputMethodContext. In class java.awt.Toolkit, add a method mapInputMethodHighlight. In class java.awt.font.TextAttribute, add constants INPUT_METHOD_UNDERLINE, UNDERLINE_LOW_ONE_PIXEL, UNDERLINE_LOW_TWO_PIXEL, UNDERLINE_LOW_DOTTED, UNDERLINE_LOW_GRAY, UNDERLINE_LOW_DASHED. In class java.awt.im.InputContext, add method getLocale. In class java.awt.im.InputMethodHighlight, add constructor InputMethodHighlight(boolean, int, int, java.util.Map) and method getStyle. Provide input method loading and selection mechanisms that can detect installed input methods in JAR files, load descriptive information about them, let the user select an input method from a user interface or let an application select an input method using the API, and load the input method itself for use. Remove the IIIMP adapter from J2SDK and J2RE. Solaris Software will provide an updated IIIMP adapter that plugs into the input method engine SPI, but will be distributed separately. We request advance permission to make changes to the new interfaces (InputMethod, InputMethodDescriptor, InputMethodContext), to their location in the package hierarchy, and to the loading and selection mechanisms in response to review feedback. Additional changes to existing classes that may become necessary will be handled as separate CCC requests. Implementation: The changes so far have been implemented by Norbert Lindenberg and reviewed by Masayoshi Okutsu; further changes will be implemented and reviewed by Norbert, Masayoshi, and Naoto Satoh. The implementation is 100% Java, the total number of lines of code changed will be in the hundreds to low thousands. We expect the implementation to be complete by May 28. Reviewed by The API specification mentioned above has been reviewed by the TRC on 3/19/99. The TRC summary is appended below. The specification was distributed to licensees the same day, with a request for feedback by April 9. We have received substantial comments from five companies, generally validating our current design, but requesting additional features. Risk assessment: The input method engine SPI is based on an internal interface that exists in J2RE SE 1.2 and has been used by several licensees to implement prototype input methods. Insofar the basic ideas have been tested and validated. Risks exist in the following areas: Dependency on AWT key events. AWT key events are poorly specified and vary somewhat between platforms. This makes it difficult to write platform independent software that interprets key events. We currently try to minimize the risk by recommending input method developers to rely primarily on KEY_TYPED events, which are less platform dependent, but for function keys they still have to rely to the lower-level KEY_PRESSED and KEY_RELEASED events. Support for input modes other than by keyboard. The SPI is intended to support not only keyboard input, but also input through handwriting recognition or speech recognition. We have spent some time thinking about the particular requirements of these additional input modes, but have no resources to develop prototypes for them. Support for devices with limited screen size. Our current assumption is that input methods are responsible for managing their user interface themselves. This may involve control panels, status windows, lookup windows, dictionary editors, and possibly other windows. This model doesn't work well for devices with limited screen sizes, where screen space often needs to be centrally administered. We expect that this can be solved by implementing a super input method that plugs into the SPI, handles the user interface, and provides sub-SPIs for specialized face-less engines. However, we have no resources to develop prototypes to verify this approach. Input methods are good candidates for being offered as network services via Jini. However, we have no resources to develop prototypes to verify that the current interface is adequate for this. SQE (product testing) impact: Test cases need to be written to test communication through the input method framework. There already exist test applications using the framework's client API. A test input method needs to be developed which exercises the input method engine SPI, and it needs to be verified that applications and input methods can cooperate in producing text input. Approved by Shuna Wu. JCK (compatibility testing) impact: This SPI enables full testing for the input method framework, which previously could not be fully tested (the framework enables communication between text components and input methods, but only one side had a public API, and the JCK cannot use internal interfaces). Tests need to be written to completely test communication through the framework. These tests may be similar to those used by SQE. Approved by Steve Fleming. Doc impact: An initial draft of the specification is available (see above). By beta, we expect to produce a complete JavaDoc specification as well as a complete guide document. Alan Sommerer will review the updated documentation. Localization impact: A few localizable strings may be added or changed as part of the SPI implementation. We do not intend to bundle any input methods with the J2RE. Internationalization impact: This change enables internationalization functionality that is required by East Asian and other markets. Security impact: Based on the TRC feedback below, we expect to make locally installed input methods fully trusted. Legal impact: In December 1998, Java Software adopted a Community Process for API development. However, the design process for the input method engine SPI predates that decision. The SPI was originally part of the input method framework in JDK 1.2 and was only removed as part of an effort to meet a target FCS date of fall 1997. It then continued to evolve as an interal interface within the JRE, with continuous feedback from licensees. Because of this history, the input method engine SPI was exempt from the new process. Besides the TRC and partner reviews done so far, we're planning a public review later in the development cycle. Product marketing approval: Preapproved as Kestrel feature, confirmed by Blake Connell. TRC review summary (Bill Shannon): On 3/18/99 the TRC reviewed the input method SPI interface. The review materials are at http://javaweb.eng/~norbert/ime.latest/guide/ime/index.html Norbert explained that creation of input methods for many languages is a competitive field with multiple offerings. It is important to provide a way for companies producing such input method engines to plug into the Java platform, thus this Service Provider Interface. There is currently a private IM SPI in JDK 1.2. It has been reviewed by a number of companies. The new IM SPI is derived from this private SPI, but has not yet been reviewed outside of Sun. A number of input method engines have been developed to the private SPI. In addition, we have ported the IIIMP input method module to the new SPI. The team asked for our feedback in two important areas - security and packaging/installation. The TRC pointed out that these issues are likely to be addressed by the JDK standard extension packaging and installation work that is being reviewed next week. It is a goal that this more general work meet the needs of input method service providers. We will review this aspect of the input method SPI again after the team has had a chance to react to the new JDK installation proposal. In addition, we agreed that it was appropriate that input methods are installed locally and fully trusted. There is no need to support untrusted or partially trusted input methods. Finally, the TRC recommended that there be a clear separation between any APIs an application might use, and APIs that would only be used by an input method provider. At a minimum the documentation must make the intended use of these interfaces very clear. It was also felt to be appropriate to move such interfaces into a package of their own, java.awt.im.spi in this case, to further emphasize this distinction and avoid confusing application programmers. Some TRC members had minor comments on the APIs, provided via email to the project team as is our usual practice. The TRC agreed that it was appropriate to start an external review of the Input Method Engine SPI.
11-06-2004

EVALUATION This is a feature planned for the release after JDK 1.2. norbert.lindenberg@Eng 1998-01-20
20-01-1998