Sostituzione per il metodo Normalizer.getClass (c) in Java 6

Question

Il metodo getClass(char c) della classe Normalizer sembra mancare da Java 6 in poi.

Questo metodo è presente nel nostro codice legacy e viene utilizzato come mostrato di seguito. Dobbiamo migrarlo a Java 6. Qualche suggerimento su come può essere sostituito?

import sun.text.Normalizer; 

/** 
* Returns an array of strings that have all the possible 
* permutations of the characters in the input string. 
* This is used to get a list of all possible orderings 
* of a set of combining marks. Note that some of the permutations 
* are invalid because of combining class collisions, and these 
* possibilities must be removed because they are not canonically 
* equivalent. 
*/ 
private String[] producePermutations(String input) { 
    if (input.length() == 1) 
     return new String[] {input}; 

    if (input.length() == 2) { 
     if (getClass(input.charAt(1)) == 
      getClass(input.charAt(0))) { 
      return new String[] {input}; 
     } 
     String[] result = new String[2]; 
     result[0] = input; 
     StringBuffer sb = new StringBuffer(2); 
     sb.append(input.charAt(1)); 
     sb.append(input.charAt(0)); 
     result[1] = sb.toString(); 
     return result; 
    } 

    int length = 1; 
    for(int x=1; x<input.length(); x++) 
     length = length * (x+1); 

    String[] temp = new String[length]; 

    int combClass[] = new int[input.length()]; 
    for(int x=0; x<input.length(); x++) 
     combClass[x] = getClass(input.charAt(x)); 

    // For each char, take it out and add the permutations 
    // of the remaining chars 
    int index = 0; 
loop: for(int x=0; x<input.length(); x++) { 
     boolean skip = false; 
     for(int y=x-1; y>=0; y--) { 
      if (combClass[y] == combClass[x]) { 
       continue loop; 
      } 
     } 
     StringBuffer sb = new StringBuffer(input); 
     String otherChars = sb.delete(x, x+1).toString(); 
     String[] subResult = producePermutations(otherChars); 

     String prefix = input.substring(x, x+1); 
     for(int y=0; y<subResult.length; y++) 
      temp[index++] = prefix + subResult[y]; 
    } 
    String[] result = new String[index]; 
    for (int x=0; x<index; x++) 
     result[x] = temp[x]; 
    return result; 
} 

private int getClass(char c) { 
    return Normalizer.getClass(c); 
} 

Answer 1

normalizzatore da java.text non ci sono stesse funzionalità di Normalizer da sun.text

basato solo su questo pezzo di codice inserito, il modo più semplice per fare ciò che si vuole è utilizzare ICU4J dipendenza. Se si utilizza Maven, come questo:

<dependency> 
    <groupId>com.ibm.icu</groupId> 
    <artifactId>icu4j</artifactId> 
    <version>4.6</version> 
</dependency> 

Quindi, è possibile scrivere una classe come questa:

package com.ibm.icu.text; 

public class Normalizer { 

    public static final int getClass(final char ch) { 
     final int value = DecompData.canonClass.elementAt(ch); 
     return value >= 0 ? value : value + 256; 
    } 

} 

Dal DecompData ha visibilità pacchetto-privato, creare Normalizer nel pacchetto stesso in voi applicazione.

Answer 2

Lo snippet di codice, come altri hanno sottolineato, è sun.text.Normalizer e non java.text.Normalizer. In Java 6 vedo che sun.text.Normalizer ha un metodo chiamato getCombiningClass(int ch) che è descritto come "Restituisce la combinazione della classe del carattere specificato" nonostante si sia preso uno int e non uno char. Questo è probabilmente il metodo che stai cercando.

Devo notare che, essendo una classe sun.*, questi tipi di metodi sono soggetti a questi tipi di modifiche (ridenominazione, scomparsa) senza preavviso e vengono utilizzati a proprio rischio. Caveat coder!

Answer 3

In Java 6, il metodo è stato rinominato getCharacterClass, e il parametro è stato cambiato da un char a un int, perché quel tipo di sostituzione è stato fatto in tutto il mondo per ospitare i caratteri Unicode con valori maggiori di 65.535.

Un metodo da un pacchetto avviato con sun non dovrebbe mai essere stato utilizzato in primo luogo. Questo è probabilmente il motivo per cui la chiamata è in un metodo separato, nel caso in cui debba essere riscritta se il metodo viene rimosso. Sfortunatamente, non riesco a trovare un equivalente nell'API Java pubblica, quindi la sostituzione dovrà essere scritta da zero o non documentata.