On 2/16/06, Tim Ellison <[EMAIL PROTECTED]> wrote: > Hmm, they look to me like they could be impl methods that were > inadvertently exposed. They don't seem to fit in to the BreakIterator bag. > > If I were you I'd implement them to throw a NotYetImplementedException. > > Regards, > Tim >
I agree that those methods are a bit strange... Does the proposed exception well fit to the compatibility strategy? As I know once the method was exposed it will never be removed from spec and therefore everyone can use it... I did 5 min research and found that their implementation should be very simple (sorry I provide the test not in JUnit format): Method getInt = BreakIterator.class.getDeclaredMethod("getInt", new Class[] {new byte[0].getClass(), Integer.TYPE}); getInt.setAccessible(true); Object result = getInt.invoke(null, new Object[] {new byte[] {0, 0, 0, 1, 1, 0}, new Integer(0)}); System.err.println("expected 1 = " + (new Integer(1).equals(result))); result = getInt.invoke(null, new Object[] {new byte[] {0, 0, 0, 1, 1, 0}, new Integer(1)}); System.err.println("expected 257 = " + (new Integer(257).equals(result))); result = getInt.invoke(null, new Object[] {new byte[] {0, 0, 0, 1, 10, 0}, new Integer(1)}); System.err.println("expected 266 = " + (new Integer(266).equals(result))); IMHO, it is not very difficult to implement. -- Anton Avtamonov, Intel Middleware Products Division