Should searching behavior for 0-length string “” using String.indexOf be considered as undefined?...
[Edited]
Since some people having difficulties on understating what this question is all about, I'll add a line or a few. When talking about API, there is something called UNDEFINED BEHAVIOR, which means the result of certain programmatic action is not guaranteed by the author. This terminology stems from the days of z80 processor, where cunning programmers was taking advantages of UNDOCUMENTED OPCODES. These opcodes are sometimes handy in optimization, but were supposed to
be considered as UNDEFIND even though these opcodes were making consistent result back then. However, as time passed by, companies started to make z80 compatible environment without reproducing the behaviors of these UNDOCUMENTED OPCODE, and and guess what, those program using these opcodes are now broke.
The moral of this story is that you should not rely on undefined programmatic components such as undefined opcodes or API components that is not defined properly, as their result can be changed from time to time.
Now we have a certain method of Java that is producing somewhat strange result under a certain condition. So I was asking whether I should take it's result as UNDEFINED BEHAVIOR or as an reliable official result. This question maybe a bit technical unless you have some background in stuffs like API programming or low-level programming, but I still don't consider my question vague, as there were people already answering to my question.
We all know that indexOf("")
returns 0, although that is not documented officially.
But do you know what happen when indexOf("", int num)
is used instead?
int num
is more logical answer than 0, and indeed it returns num
if the string undet test is longer than num.
But what about those with shorter strings? Well the old version of Java should return -1 according to its source code, as it has a guard against the str.length() <= num
situation at beginning . However, I just noticed that the android version of Java returning the value of str.length()
instead.
So now I'm seriously wonder the behavior of "" search should be considered unreliable. By saying reliable, I mean any code relying on the these behavior will not break in the future versions of Java.
java compatibility
closed as unclear what you're asking by Jens, sfat, Roman Pokrovskij, Mickael Maison, manish Jan 1 at 15:45
Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.
add a comment |
[Edited]
Since some people having difficulties on understating what this question is all about, I'll add a line or a few. When talking about API, there is something called UNDEFINED BEHAVIOR, which means the result of certain programmatic action is not guaranteed by the author. This terminology stems from the days of z80 processor, where cunning programmers was taking advantages of UNDOCUMENTED OPCODES. These opcodes are sometimes handy in optimization, but were supposed to
be considered as UNDEFIND even though these opcodes were making consistent result back then. However, as time passed by, companies started to make z80 compatible environment without reproducing the behaviors of these UNDOCUMENTED OPCODE, and and guess what, those program using these opcodes are now broke.
The moral of this story is that you should not rely on undefined programmatic components such as undefined opcodes or API components that is not defined properly, as their result can be changed from time to time.
Now we have a certain method of Java that is producing somewhat strange result under a certain condition. So I was asking whether I should take it's result as UNDEFINED BEHAVIOR or as an reliable official result. This question maybe a bit technical unless you have some background in stuffs like API programming or low-level programming, but I still don't consider my question vague, as there were people already answering to my question.
We all know that indexOf("")
returns 0, although that is not documented officially.
But do you know what happen when indexOf("", int num)
is used instead?
int num
is more logical answer than 0, and indeed it returns num
if the string undet test is longer than num.
But what about those with shorter strings? Well the old version of Java should return -1 according to its source code, as it has a guard against the str.length() <= num
situation at beginning . However, I just noticed that the android version of Java returning the value of str.length()
instead.
So now I'm seriously wonder the behavior of "" search should be considered unreliable. By saying reliable, I mean any code relying on the these behavior will not break in the future versions of Java.
java compatibility
closed as unclear what you're asking by Jens, sfat, Roman Pokrovskij, Mickael Maison, manish Jan 1 at 15:45
Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.
I don't feel that there is something wrong with the empty string behaviour, every string contains the empty string at the beginning (and between all its characters as well). The strange thing is that something less thannum
(other than -1) is ever returned.
– Henry
Jan 1 at 11:30
add a comment |
[Edited]
Since some people having difficulties on understating what this question is all about, I'll add a line or a few. When talking about API, there is something called UNDEFINED BEHAVIOR, which means the result of certain programmatic action is not guaranteed by the author. This terminology stems from the days of z80 processor, where cunning programmers was taking advantages of UNDOCUMENTED OPCODES. These opcodes are sometimes handy in optimization, but were supposed to
be considered as UNDEFIND even though these opcodes were making consistent result back then. However, as time passed by, companies started to make z80 compatible environment without reproducing the behaviors of these UNDOCUMENTED OPCODE, and and guess what, those program using these opcodes are now broke.
The moral of this story is that you should not rely on undefined programmatic components such as undefined opcodes or API components that is not defined properly, as their result can be changed from time to time.
Now we have a certain method of Java that is producing somewhat strange result under a certain condition. So I was asking whether I should take it's result as UNDEFINED BEHAVIOR or as an reliable official result. This question maybe a bit technical unless you have some background in stuffs like API programming or low-level programming, but I still don't consider my question vague, as there were people already answering to my question.
We all know that indexOf("")
returns 0, although that is not documented officially.
But do you know what happen when indexOf("", int num)
is used instead?
int num
is more logical answer than 0, and indeed it returns num
if the string undet test is longer than num.
But what about those with shorter strings? Well the old version of Java should return -1 according to its source code, as it has a guard against the str.length() <= num
situation at beginning . However, I just noticed that the android version of Java returning the value of str.length()
instead.
So now I'm seriously wonder the behavior of "" search should be considered unreliable. By saying reliable, I mean any code relying on the these behavior will not break in the future versions of Java.
java compatibility
[Edited]
Since some people having difficulties on understating what this question is all about, I'll add a line or a few. When talking about API, there is something called UNDEFINED BEHAVIOR, which means the result of certain programmatic action is not guaranteed by the author. This terminology stems from the days of z80 processor, where cunning programmers was taking advantages of UNDOCUMENTED OPCODES. These opcodes are sometimes handy in optimization, but were supposed to
be considered as UNDEFIND even though these opcodes were making consistent result back then. However, as time passed by, companies started to make z80 compatible environment without reproducing the behaviors of these UNDOCUMENTED OPCODE, and and guess what, those program using these opcodes are now broke.
The moral of this story is that you should not rely on undefined programmatic components such as undefined opcodes or API components that is not defined properly, as their result can be changed from time to time.
Now we have a certain method of Java that is producing somewhat strange result under a certain condition. So I was asking whether I should take it's result as UNDEFINED BEHAVIOR or as an reliable official result. This question maybe a bit technical unless you have some background in stuffs like API programming or low-level programming, but I still don't consider my question vague, as there were people already answering to my question.
We all know that indexOf("")
returns 0, although that is not documented officially.
But do you know what happen when indexOf("", int num)
is used instead?
int num
is more logical answer than 0, and indeed it returns num
if the string undet test is longer than num.
But what about those with shorter strings? Well the old version of Java should return -1 according to its source code, as it has a guard against the str.length() <= num
situation at beginning . However, I just noticed that the android version of Java returning the value of str.length()
instead.
So now I'm seriously wonder the behavior of "" search should be considered unreliable. By saying reliable, I mean any code relying on the these behavior will not break in the future versions of Java.
java compatibility
java compatibility
edited Jan 2 at 16:03
Brian Tompsett - 汤莱恩
4,2321338102
4,2321338102
asked Jan 1 at 9:49
JavaToTavaLJavaToTavaL
155
155
closed as unclear what you're asking by Jens, sfat, Roman Pokrovskij, Mickael Maison, manish Jan 1 at 15:45
Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.
closed as unclear what you're asking by Jens, sfat, Roman Pokrovskij, Mickael Maison, manish Jan 1 at 15:45
Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.
I don't feel that there is something wrong with the empty string behaviour, every string contains the empty string at the beginning (and between all its characters as well). The strange thing is that something less thannum
(other than -1) is ever returned.
– Henry
Jan 1 at 11:30
add a comment |
I don't feel that there is something wrong with the empty string behaviour, every string contains the empty string at the beginning (and between all its characters as well). The strange thing is that something less thannum
(other than -1) is ever returned.
– Henry
Jan 1 at 11:30
I don't feel that there is something wrong with the empty string behaviour, every string contains the empty string at the beginning (and between all its characters as well). The strange thing is that something less than
num
(other than -1) is ever returned.– Henry
Jan 1 at 11:30
I don't feel that there is something wrong with the empty string behaviour, every string contains the empty string at the beginning (and between all its characters as well). The strange thing is that something less than
num
(other than -1) is ever returned.– Henry
Jan 1 at 11:30
add a comment |
2 Answers
2
active
oldest
votes
The Javadoc states:
int java.lang.String.indexOf(String str, int fromIndex)
Returns the index within this string of the first occurrence of the specified substring, starting at the specified index.
The returned index is the smallest value k for which:
k >= fromIndex && this.startsWith(str, k)
If no such value of k exists, then -1 is returned.
If you pass fromIndex > str.length
, there can be no k
such that k >= fromIndex && this.startsWith(str, k)
, so it should return -1
.
However, as you stated, this is not the implemented behavior.
indexOf(String str, int fromIndex)
calls:
static int indexOf(char source, int sourceOffset, int sourceCount,
char target, int targetOffset, int targetCount,
int fromIndex)
which starts with:
if (fromIndex >= sourceCount) {
return (targetCount == 0 ? sourceCount : -1);
}
targetCount
is the length of the String
passed to indexOf
, and sourceCount
is the length of the String
on which you call indexOf
, which means if fromIndex >= str.length()
, str.length()
is returned when you call str.indexOf("",fromIndex)
.
This is either a documentation bug or implementation bug.
BTW, I didn't test this on Android. I tested it on JDK 8.
That said, I would never write code that calls str.indexOf(subStr,index)
for index >= str.length()
, since I don't expect subStr
to be found within str
in such cases (regardless of whether or not subStr
is empty).
I would probably never pass an empty String
to indexOf
either, since it seems pointless.
Well, you can write a library program that take a portion of String and an offset as an input, and say it makes you the lists of books that has the string part in their name after this offset. The string can be empty as well as the names of some book shorter than the offset. Of course you can add some extra code to avoid supprises, but my point is that there can be situations where we have to deal with empty string etc.
– JavaToTavaL
Jan 1 at 13:36
add a comment |
In java8, this code:
String s="abcdefg";
System.out.println(s.indexOf(""));
System.out.println(s.indexOf("",3));
System.out.println(s.indexOf("",18);
Output:
0
3
7
in which 7
is the length of s
.
While java doc(https://docs.oracle.com/javase/8/docs/api/java/lang/String.html#indexOf-java.lang.String-int-) says:
public int indexOf(String str,
int fromIndex)
Returns the index within this string of the first occurrence of the
specified substring, starting at the specified index.
The returned index is the smallest value k for which:
k >= fromIndex && this.startsWith(str, k)
If no such value of k exists, then -1 is returned.
So I think there is a doc bug for java8. As I don't know your java version by saying old version for android
, cann't juedge the situation for that.
Actually I have read the old java source(1.4? 1.6?) wrong at the time I was writing this. I tested it, and it DOES yeild the same result as yours. So I think it's an old bug.
– JavaToTavaL
Jan 1 at 13:17
Suprisingly, I checked the doc of jdk1.5&jdk6, and found that the doc says:public int indexOf(String str, int fromIndex) Returns the index within this string of the first occurrence of the specified substring, starting at the specified index. The integer returned is the smallest value k for which: k >= Math.min(fromIndex, this.length()) && this.startsWith(str, k) If no such value of k exists, then -1 is returned.
Note that theMath.min
method. @JavaToTavaL
– ZhaoGang
Jan 1 at 13:25
docs.oracle.com/javase/1.5.0/docs/api/java/lang/…
– ZhaoGang
Jan 1 at 13:27
docs.oracle.com/javase/6/docs/api/java/lang/…
– ZhaoGang
Jan 1 at 13:27
If so, it is describing the behavior right at least. Although I doubt that they intented it that way from the begining.
– JavaToTavaL
Jan 1 at 14:11
add a comment |
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
The Javadoc states:
int java.lang.String.indexOf(String str, int fromIndex)
Returns the index within this string of the first occurrence of the specified substring, starting at the specified index.
The returned index is the smallest value k for which:
k >= fromIndex && this.startsWith(str, k)
If no such value of k exists, then -1 is returned.
If you pass fromIndex > str.length
, there can be no k
such that k >= fromIndex && this.startsWith(str, k)
, so it should return -1
.
However, as you stated, this is not the implemented behavior.
indexOf(String str, int fromIndex)
calls:
static int indexOf(char source, int sourceOffset, int sourceCount,
char target, int targetOffset, int targetCount,
int fromIndex)
which starts with:
if (fromIndex >= sourceCount) {
return (targetCount == 0 ? sourceCount : -1);
}
targetCount
is the length of the String
passed to indexOf
, and sourceCount
is the length of the String
on which you call indexOf
, which means if fromIndex >= str.length()
, str.length()
is returned when you call str.indexOf("",fromIndex)
.
This is either a documentation bug or implementation bug.
BTW, I didn't test this on Android. I tested it on JDK 8.
That said, I would never write code that calls str.indexOf(subStr,index)
for index >= str.length()
, since I don't expect subStr
to be found within str
in such cases (regardless of whether or not subStr
is empty).
I would probably never pass an empty String
to indexOf
either, since it seems pointless.
Well, you can write a library program that take a portion of String and an offset as an input, and say it makes you the lists of books that has the string part in their name after this offset. The string can be empty as well as the names of some book shorter than the offset. Of course you can add some extra code to avoid supprises, but my point is that there can be situations where we have to deal with empty string etc.
– JavaToTavaL
Jan 1 at 13:36
add a comment |
The Javadoc states:
int java.lang.String.indexOf(String str, int fromIndex)
Returns the index within this string of the first occurrence of the specified substring, starting at the specified index.
The returned index is the smallest value k for which:
k >= fromIndex && this.startsWith(str, k)
If no such value of k exists, then -1 is returned.
If you pass fromIndex > str.length
, there can be no k
such that k >= fromIndex && this.startsWith(str, k)
, so it should return -1
.
However, as you stated, this is not the implemented behavior.
indexOf(String str, int fromIndex)
calls:
static int indexOf(char source, int sourceOffset, int sourceCount,
char target, int targetOffset, int targetCount,
int fromIndex)
which starts with:
if (fromIndex >= sourceCount) {
return (targetCount == 0 ? sourceCount : -1);
}
targetCount
is the length of the String
passed to indexOf
, and sourceCount
is the length of the String
on which you call indexOf
, which means if fromIndex >= str.length()
, str.length()
is returned when you call str.indexOf("",fromIndex)
.
This is either a documentation bug or implementation bug.
BTW, I didn't test this on Android. I tested it on JDK 8.
That said, I would never write code that calls str.indexOf(subStr,index)
for index >= str.length()
, since I don't expect subStr
to be found within str
in such cases (regardless of whether or not subStr
is empty).
I would probably never pass an empty String
to indexOf
either, since it seems pointless.
Well, you can write a library program that take a portion of String and an offset as an input, and say it makes you the lists of books that has the string part in their name after this offset. The string can be empty as well as the names of some book shorter than the offset. Of course you can add some extra code to avoid supprises, but my point is that there can be situations where we have to deal with empty string etc.
– JavaToTavaL
Jan 1 at 13:36
add a comment |
The Javadoc states:
int java.lang.String.indexOf(String str, int fromIndex)
Returns the index within this string of the first occurrence of the specified substring, starting at the specified index.
The returned index is the smallest value k for which:
k >= fromIndex && this.startsWith(str, k)
If no such value of k exists, then -1 is returned.
If you pass fromIndex > str.length
, there can be no k
such that k >= fromIndex && this.startsWith(str, k)
, so it should return -1
.
However, as you stated, this is not the implemented behavior.
indexOf(String str, int fromIndex)
calls:
static int indexOf(char source, int sourceOffset, int sourceCount,
char target, int targetOffset, int targetCount,
int fromIndex)
which starts with:
if (fromIndex >= sourceCount) {
return (targetCount == 0 ? sourceCount : -1);
}
targetCount
is the length of the String
passed to indexOf
, and sourceCount
is the length of the String
on which you call indexOf
, which means if fromIndex >= str.length()
, str.length()
is returned when you call str.indexOf("",fromIndex)
.
This is either a documentation bug or implementation bug.
BTW, I didn't test this on Android. I tested it on JDK 8.
That said, I would never write code that calls str.indexOf(subStr,index)
for index >= str.length()
, since I don't expect subStr
to be found within str
in such cases (regardless of whether or not subStr
is empty).
I would probably never pass an empty String
to indexOf
either, since it seems pointless.
The Javadoc states:
int java.lang.String.indexOf(String str, int fromIndex)
Returns the index within this string of the first occurrence of the specified substring, starting at the specified index.
The returned index is the smallest value k for which:
k >= fromIndex && this.startsWith(str, k)
If no such value of k exists, then -1 is returned.
If you pass fromIndex > str.length
, there can be no k
such that k >= fromIndex && this.startsWith(str, k)
, so it should return -1
.
However, as you stated, this is not the implemented behavior.
indexOf(String str, int fromIndex)
calls:
static int indexOf(char source, int sourceOffset, int sourceCount,
char target, int targetOffset, int targetCount,
int fromIndex)
which starts with:
if (fromIndex >= sourceCount) {
return (targetCount == 0 ? sourceCount : -1);
}
targetCount
is the length of the String
passed to indexOf
, and sourceCount
is the length of the String
on which you call indexOf
, which means if fromIndex >= str.length()
, str.length()
is returned when you call str.indexOf("",fromIndex)
.
This is either a documentation bug or implementation bug.
BTW, I didn't test this on Android. I tested it on JDK 8.
That said, I would never write code that calls str.indexOf(subStr,index)
for index >= str.length()
, since I don't expect subStr
to be found within str
in such cases (regardless of whether or not subStr
is empty).
I would probably never pass an empty String
to indexOf
either, since it seems pointless.
edited Jan 1 at 10:27
answered Jan 1 at 10:21
EranEran
287k37467557
287k37467557
Well, you can write a library program that take a portion of String and an offset as an input, and say it makes you the lists of books that has the string part in their name after this offset. The string can be empty as well as the names of some book shorter than the offset. Of course you can add some extra code to avoid supprises, but my point is that there can be situations where we have to deal with empty string etc.
– JavaToTavaL
Jan 1 at 13:36
add a comment |
Well, you can write a library program that take a portion of String and an offset as an input, and say it makes you the lists of books that has the string part in their name after this offset. The string can be empty as well as the names of some book shorter than the offset. Of course you can add some extra code to avoid supprises, but my point is that there can be situations where we have to deal with empty string etc.
– JavaToTavaL
Jan 1 at 13:36
Well, you can write a library program that take a portion of String and an offset as an input, and say it makes you the lists of books that has the string part in their name after this offset. The string can be empty as well as the names of some book shorter than the offset. Of course you can add some extra code to avoid supprises, but my point is that there can be situations where we have to deal with empty string etc.
– JavaToTavaL
Jan 1 at 13:36
Well, you can write a library program that take a portion of String and an offset as an input, and say it makes you the lists of books that has the string part in their name after this offset. The string can be empty as well as the names of some book shorter than the offset. Of course you can add some extra code to avoid supprises, but my point is that there can be situations where we have to deal with empty string etc.
– JavaToTavaL
Jan 1 at 13:36
add a comment |
In java8, this code:
String s="abcdefg";
System.out.println(s.indexOf(""));
System.out.println(s.indexOf("",3));
System.out.println(s.indexOf("",18);
Output:
0
3
7
in which 7
is the length of s
.
While java doc(https://docs.oracle.com/javase/8/docs/api/java/lang/String.html#indexOf-java.lang.String-int-) says:
public int indexOf(String str,
int fromIndex)
Returns the index within this string of the first occurrence of the
specified substring, starting at the specified index.
The returned index is the smallest value k for which:
k >= fromIndex && this.startsWith(str, k)
If no such value of k exists, then -1 is returned.
So I think there is a doc bug for java8. As I don't know your java version by saying old version for android
, cann't juedge the situation for that.
Actually I have read the old java source(1.4? 1.6?) wrong at the time I was writing this. I tested it, and it DOES yeild the same result as yours. So I think it's an old bug.
– JavaToTavaL
Jan 1 at 13:17
Suprisingly, I checked the doc of jdk1.5&jdk6, and found that the doc says:public int indexOf(String str, int fromIndex) Returns the index within this string of the first occurrence of the specified substring, starting at the specified index. The integer returned is the smallest value k for which: k >= Math.min(fromIndex, this.length()) && this.startsWith(str, k) If no such value of k exists, then -1 is returned.
Note that theMath.min
method. @JavaToTavaL
– ZhaoGang
Jan 1 at 13:25
docs.oracle.com/javase/1.5.0/docs/api/java/lang/…
– ZhaoGang
Jan 1 at 13:27
docs.oracle.com/javase/6/docs/api/java/lang/…
– ZhaoGang
Jan 1 at 13:27
If so, it is describing the behavior right at least. Although I doubt that they intented it that way from the begining.
– JavaToTavaL
Jan 1 at 14:11
add a comment |
In java8, this code:
String s="abcdefg";
System.out.println(s.indexOf(""));
System.out.println(s.indexOf("",3));
System.out.println(s.indexOf("",18);
Output:
0
3
7
in which 7
is the length of s
.
While java doc(https://docs.oracle.com/javase/8/docs/api/java/lang/String.html#indexOf-java.lang.String-int-) says:
public int indexOf(String str,
int fromIndex)
Returns the index within this string of the first occurrence of the
specified substring, starting at the specified index.
The returned index is the smallest value k for which:
k >= fromIndex && this.startsWith(str, k)
If no such value of k exists, then -1 is returned.
So I think there is a doc bug for java8. As I don't know your java version by saying old version for android
, cann't juedge the situation for that.
Actually I have read the old java source(1.4? 1.6?) wrong at the time I was writing this. I tested it, and it DOES yeild the same result as yours. So I think it's an old bug.
– JavaToTavaL
Jan 1 at 13:17
Suprisingly, I checked the doc of jdk1.5&jdk6, and found that the doc says:public int indexOf(String str, int fromIndex) Returns the index within this string of the first occurrence of the specified substring, starting at the specified index. The integer returned is the smallest value k for which: k >= Math.min(fromIndex, this.length()) && this.startsWith(str, k) If no such value of k exists, then -1 is returned.
Note that theMath.min
method. @JavaToTavaL
– ZhaoGang
Jan 1 at 13:25
docs.oracle.com/javase/1.5.0/docs/api/java/lang/…
– ZhaoGang
Jan 1 at 13:27
docs.oracle.com/javase/6/docs/api/java/lang/…
– ZhaoGang
Jan 1 at 13:27
If so, it is describing the behavior right at least. Although I doubt that they intented it that way from the begining.
– JavaToTavaL
Jan 1 at 14:11
add a comment |
In java8, this code:
String s="abcdefg";
System.out.println(s.indexOf(""));
System.out.println(s.indexOf("",3));
System.out.println(s.indexOf("",18);
Output:
0
3
7
in which 7
is the length of s
.
While java doc(https://docs.oracle.com/javase/8/docs/api/java/lang/String.html#indexOf-java.lang.String-int-) says:
public int indexOf(String str,
int fromIndex)
Returns the index within this string of the first occurrence of the
specified substring, starting at the specified index.
The returned index is the smallest value k for which:
k >= fromIndex && this.startsWith(str, k)
If no such value of k exists, then -1 is returned.
So I think there is a doc bug for java8. As I don't know your java version by saying old version for android
, cann't juedge the situation for that.
In java8, this code:
String s="abcdefg";
System.out.println(s.indexOf(""));
System.out.println(s.indexOf("",3));
System.out.println(s.indexOf("",18);
Output:
0
3
7
in which 7
is the length of s
.
While java doc(https://docs.oracle.com/javase/8/docs/api/java/lang/String.html#indexOf-java.lang.String-int-) says:
public int indexOf(String str,
int fromIndex)
Returns the index within this string of the first occurrence of the
specified substring, starting at the specified index.
The returned index is the smallest value k for which:
k >= fromIndex && this.startsWith(str, k)
If no such value of k exists, then -1 is returned.
So I think there is a doc bug for java8. As I don't know your java version by saying old version for android
, cann't juedge the situation for that.
answered Jan 1 at 11:12
ZhaoGangZhaoGang
2,0751118
2,0751118
Actually I have read the old java source(1.4? 1.6?) wrong at the time I was writing this. I tested it, and it DOES yeild the same result as yours. So I think it's an old bug.
– JavaToTavaL
Jan 1 at 13:17
Suprisingly, I checked the doc of jdk1.5&jdk6, and found that the doc says:public int indexOf(String str, int fromIndex) Returns the index within this string of the first occurrence of the specified substring, starting at the specified index. The integer returned is the smallest value k for which: k >= Math.min(fromIndex, this.length()) && this.startsWith(str, k) If no such value of k exists, then -1 is returned.
Note that theMath.min
method. @JavaToTavaL
– ZhaoGang
Jan 1 at 13:25
docs.oracle.com/javase/1.5.0/docs/api/java/lang/…
– ZhaoGang
Jan 1 at 13:27
docs.oracle.com/javase/6/docs/api/java/lang/…
– ZhaoGang
Jan 1 at 13:27
If so, it is describing the behavior right at least. Although I doubt that they intented it that way from the begining.
– JavaToTavaL
Jan 1 at 14:11
add a comment |
Actually I have read the old java source(1.4? 1.6?) wrong at the time I was writing this. I tested it, and it DOES yeild the same result as yours. So I think it's an old bug.
– JavaToTavaL
Jan 1 at 13:17
Suprisingly, I checked the doc of jdk1.5&jdk6, and found that the doc says:public int indexOf(String str, int fromIndex) Returns the index within this string of the first occurrence of the specified substring, starting at the specified index. The integer returned is the smallest value k for which: k >= Math.min(fromIndex, this.length()) && this.startsWith(str, k) If no such value of k exists, then -1 is returned.
Note that theMath.min
method. @JavaToTavaL
– ZhaoGang
Jan 1 at 13:25
docs.oracle.com/javase/1.5.0/docs/api/java/lang/…
– ZhaoGang
Jan 1 at 13:27
docs.oracle.com/javase/6/docs/api/java/lang/…
– ZhaoGang
Jan 1 at 13:27
If so, it is describing the behavior right at least. Although I doubt that they intented it that way from the begining.
– JavaToTavaL
Jan 1 at 14:11
Actually I have read the old java source(1.4? 1.6?) wrong at the time I was writing this. I tested it, and it DOES yeild the same result as yours. So I think it's an old bug.
– JavaToTavaL
Jan 1 at 13:17
Actually I have read the old java source(1.4? 1.6?) wrong at the time I was writing this. I tested it, and it DOES yeild the same result as yours. So I think it's an old bug.
– JavaToTavaL
Jan 1 at 13:17
Suprisingly, I checked the doc of jdk1.5&jdk6, and found that the doc says:
public int indexOf(String str, int fromIndex) Returns the index within this string of the first occurrence of the specified substring, starting at the specified index. The integer returned is the smallest value k for which: k >= Math.min(fromIndex, this.length()) && this.startsWith(str, k) If no such value of k exists, then -1 is returned.
Note that the Math.min
method. @JavaToTavaL– ZhaoGang
Jan 1 at 13:25
Suprisingly, I checked the doc of jdk1.5&jdk6, and found that the doc says:
public int indexOf(String str, int fromIndex) Returns the index within this string of the first occurrence of the specified substring, starting at the specified index. The integer returned is the smallest value k for which: k >= Math.min(fromIndex, this.length()) && this.startsWith(str, k) If no such value of k exists, then -1 is returned.
Note that the Math.min
method. @JavaToTavaL– ZhaoGang
Jan 1 at 13:25
docs.oracle.com/javase/1.5.0/docs/api/java/lang/…
– ZhaoGang
Jan 1 at 13:27
docs.oracle.com/javase/1.5.0/docs/api/java/lang/…
– ZhaoGang
Jan 1 at 13:27
docs.oracle.com/javase/6/docs/api/java/lang/…
– ZhaoGang
Jan 1 at 13:27
docs.oracle.com/javase/6/docs/api/java/lang/…
– ZhaoGang
Jan 1 at 13:27
If so, it is describing the behavior right at least. Although I doubt that they intented it that way from the begining.
– JavaToTavaL
Jan 1 at 14:11
If so, it is describing the behavior right at least. Although I doubt that they intented it that way from the begining.
– JavaToTavaL
Jan 1 at 14:11
add a comment |
I don't feel that there is something wrong with the empty string behaviour, every string contains the empty string at the beginning (and between all its characters as well). The strange thing is that something less than
num
(other than -1) is ever returned.– Henry
Jan 1 at 11:30