001 /*
002 * Licensed to the Apache Software Foundation (ASF) under one
003 * or more contributor license agreements. See the NOTICE file
004 * distributed with this work for additional information
005 * regarding copyright ownership. The ASF licenses this file
006 * to you under the Apache License, Version 2.0 (the "License");
007 * you may not use this file except in compliance with the License.
008 * You may obtain a copy of the License at
009 *
010 * http://www.apache.org/licenses/LICENSE-2.0
011 *
012 * Unless required by applicable law or agreed to in writing, software
013 * distributed under the License is distributed on an "AS IS" BASIS,
014 * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
015 * See the License for the specific language governing permissions and
016 * limitations under the License.
017 */
018 /*
019 * $Id: CustomStringPool.java 475904 2006-11-16 20:09:39Z minchau $
020 */
021
022 package org.apache.xml.dtm.ref;
023 import java.util.Hashtable;
024
025 /** <p>CustomStringPool is an example of appliction provided data structure
026 * for a DTM implementation to hold symbol references, e.g. elelment names.
027 * It will follow the DTMDStringPool interface and use two simple methods
028 * indexToString(int i) and stringToIndex(Sring s) to map between a set of
029 * string values and a set of integer index values. Therefore, an application
030 * may improve DTM processing speed by substituting the DTM symbol resolution
031 * tables with application specific quick symbol resolution tables.</p>
032 *
033 * %REVIEW% The only difference between this an DTMStringPool seems to be that
034 * it uses a java.lang.Hashtable full of Integers rather than implementing its
035 * own hashing. Joe deliberately avoided that approach when writing
036 * DTMStringPool, since it is both much more memory-hungry and probably slower
037 * -- especially in JDK 1.1.x, where Hashtable is synchronized. We need to
038 * either justify this implementation or discard it.
039 *
040 * %REVIEW% Xalan-J has dropped support for 1.1.x and we can now use
041 * the colletion classes in 1.2, such as java.util.HashMap which is
042 * similar to java.util.Hashtable but not synchronized. For performance reasons
043 * one could change m_stringToInt to be a HashMap, but is it OK to do that?
044 * Are such CustomStringPool objects already used in a thread-safe way?
045 *
046 * <p>Status: In progress, under discussion.</p>
047 * */
048 public class CustomStringPool extends DTMStringPool {
049 //final Vector m_intToString;
050 //static final int HASHPRIME=101;
051 //int[] m_hashStart=new int[HASHPRIME];
052 final Hashtable m_stringToInt = new Hashtable(); // can this be a HashMap instead?
053 public static final int NULL=-1;
054
055 public CustomStringPool()
056 {
057 super();
058 /*m_intToString=new Vector();
059 System.out.println("In constructor m_intToString is " +
060 ((null == m_intToString) ? "null" : "not null"));*/
061 //m_stringToInt=new Hashtable();
062 //removeAllElements();
063 }
064
065 public void removeAllElements()
066 {
067 m_intToString.removeAllElements();
068 if (m_stringToInt != null)
069 m_stringToInt.clear();
070 }
071
072 /** @return string whose value is uniquely identified by this integer index.
073 * @throws java.lang.ArrayIndexOutOfBoundsException
074 * if index doesn't map to a string.
075 * */
076 public String indexToString(int i)
077 throws java.lang.ArrayIndexOutOfBoundsException
078 {
079 return(String) m_intToString.elementAt(i);
080 }
081
082 /** @return integer index uniquely identifying the value of this string. */
083 public int stringToIndex(String s)
084 {
085 if (s==null) return NULL;
086 Integer iobj=(Integer)m_stringToInt.get(s);
087 if (iobj==null) {
088 m_intToString.addElement(s);
089 iobj=new Integer(m_intToString.size());
090 m_stringToInt.put(s,iobj);
091 }
092 return iobj.intValue();
093 }
094 }