Take the 2-minute tour ×

I am wondering why the parameter to indexOf method an int , when the description says a char.

public int indexOf(int ch)

Returns the index within this string of the first occurrence of the specified **character**


Also, both of these compiles fine:
char c = 'p';

a]Basically, what I am confused about is int in java is 32bit , while unicode characters are 16 bits .

b]Why not use the character themselves rather than using int . Is this any performance optimization ?. Are chars difficult to represent than int ? How ?

I assume this should be simple reasoning for this and that makes me know about it even more !


share|improve this question
add comment

4 Answers

up vote 8 down vote accepted

The real reason is that indexOf(int) expects a Unicode codepoint, not a 16-bit UTF-16 "character". Unicode code points are actually up to 21 bits in length.

(The UTF-16 representation of a longer codepoint is actually 2 16-bit "character" values. These values are known as leading and trailing surrogates; D80016 to DBFF16, and DC0016 to DFFF16 respectively; see Unicode FAQ - UTF-8, UTF-16, UTF-32 & BOM for the gory details.)

If you give indexOf(int) a code point > 65535 it will search for the pair of UTF-16 characters that encode the codepoint.

This is stated by the javadoc (albeit not very clearly), and an examination of the code indicates that this is indeed how the method is implemented.

Why not just use 16-bit characters ?

That's pretty obvious. If they did that, there wouldn't be an easy way to locate code points greater than 65535 in Strings. That would be a major inconvenience for people who develop internationalized applications where text may contain such code points. (A lot of supposedly internationalized applications make the incorrect assumption that a char represents a code point. Often it doesn't matter, but sometimes it does.)

But it shouldn't make any difference to you. The method will still work if your Strings consist of only 16 bit codes ... or, for that matter, of only ASCII codes.

share|improve this answer
Thnx for the answer. okay, so now I see indexOf(int) expects a Unicode codepoint, my other question was .. why is that ? . Why not just use 16-bit characters ? –  codeObserver Jun 3 '11 at 4:41
add comment

Characters in Java are stored in their unicode integer representation. The Character class documentation has more details about this format.

From the docs on that page:

The methods that accept an int value support all Unicode characters, including supplementary characters. For example, Character.isLetter(0x2F81A) returns true because the code point value represents a letter (a CJK ideograph).

share|improve this answer
Thnx. 2 statements from the doc: The lower (least significant) 21 bits of int are used to represent Unicode code points and the upper (most significant) 11 bits must be zero. Unicode specification, which defined characters as fixed-width 16-bit entities So if unicode are 16 bits, why use 21 bits to represent them ? –  codeObserver Jun 2 '11 at 4:14
Yes, but Strings are byte[] under the covers, encoded as UTF-8. Standard characters (0-255) occupy only one byte (not two bytes that a full width char would occupy). Characters over 255 take multiple bytes, sometimes more than 2 bytes. An encoded character has an integer (32-bit) equivalent - that is what indexOf() searches for –  Bohemian Jun 2 '11 at 4:16
@p1 Unicode hasn't been 16-bit for a very long time. Unicode 2.0 removed the 16-bit restriction, and that was FIFTEEN years ago (I feel old). Technically ISO-10646 is a 31-bit address space, and Unicode could in theory represent any of that. In reality, UTF-16 is restricted to 21 bits, and Unicode has effectively committed to only supporting those 21 bits. It's extremely unlikely that ISO-10646 will ever be allowed to go out of sync with Unicode in a way that would break UTF-16, so 21-bit is effectively now a hardcoded limit. –  Cowan Jun 2 '11 at 6:28
@Bohemian - Your comment about String being byte[] under the covers is not correct. The normal in-memory representation uses a char[] ... not UTF-8. –  Stephen C Jul 19 '13 at 2:27
@StephenC I was dumber back then :/ - Shot you an upvote for trawling back to find this in a comment though (you must be psychic or obsessive :) ) –  Bohemian Jul 19 '13 at 2:50
show 1 more comment

The method str.indexOf(int) takes an int. If you pass a char into it, java will cast the char to int, since char is a 16-bit number.

share|improve this answer
yes, but int are 32 bits in java and that confuses me !! –  codeObserver Jun 2 '11 at 4:10
@p1, codepoints are 32-bit and that's what it searches for. –  Peter Lawrey Jun 2 '11 at 8:16
add comment

Java has a whole slew of implicit typecasting rules being carried out under the hood. For primitives, there are special rules, which are all outlined in the document Conversions and Promotions, part of Sun's Java documentation. For your specific question, the conversion of int to char is a "narrowing primitive conversion." See section 5.1.3 in the above document.

That being said, it's a common programming practice to interchange small positive integers and characters which are encoded as integers. This goes back to their use indistinguishable use in C, when ASCII was all that existed.

share|improve this answer
add comment

Your Answer


