I'm working on an Android project and support minSdkVersion=7. When sdk version below 8, it will use java5. And I found String.isEmpty() doesn't exit in java5. So it caused many crashes.
To fix crashes , I have changed String.isEmpty() to String.length() == 0. After that I searched google and didn't find a convenient document figured out the API difference between java5 and java6.
So my question is where can I find such document?
AFAIK, there is no document that exhaustively lists all of the differences between different Java versions at the API level. However, in the (Oracle Java) javadocs, new classes and classes typically have a "Since" tag that says when they were added.
For example, the javadocs for String.isEmpty() say:
public boolean isEmpty()
Returns true if, and only if, length() is 0.
Returns:
true if length() is 0, otherwise false
Since:
1.6
Related
I searched and got clear that == is not used to compare the content of string variables but equals().
However, AS reports that equals() is only available on API 19 (Android 4.4) and up and I targetted API 18 (my only phone is Android 4.3)
So right now, I'm doing if (var1.contains(var2)) or if (array[i].contains(var)) to compare strings and it works but it doesn't seem correct to me.
What would be the correct way to achieve this on API < 19?
Thanks.
Edit: for clarification (I don't know how to put inline images)
With ==
With equals()
Comparison fails with equals().
The equals function of the Object class was added in Java JDK 1.0.
This version was released on January 23, 1996. It was called 'Oak' back then, so technically it predates even Java itself. (source).
In contrast, Android API 1 was released on September 23, 2008. At this time it would be made with Java JDK 1.5 (latest version was Java SE 5 Update 16).
So in conclusion, equals is available on API level 18, there must be some other error.
After seeing the posted code, you are using Objects.equals(), which is a utility method that checks equals() in a null-safe manner.
In many cases, like yours, you don't need the extra null check because you know at least one of the objects is not null and you can just call equals directly:
if("una".equals(hourNames[realHour]))
Your hourNames array will probably not contain null elements so you should turn it around to the more readable order:
if(hourNames[realHour].equals("una"))
use hourNames[realHour].equals("una")
yeah, that is a bug on android studio (or maybe from intellij idea).
Since if (var1.contains(var2)) works for you why don't you post the exact strings ? In case you don't have debug capability, I would suggest using these to debug the point in difference in the strings:-
boolean contentEquals(CharSequence cs)
public int compareTo(String anotherString)
https://docs.oracle.com/javase/7/docs/api/java/lang/String.html#compareTo(java.lang.String)
Also you could use the simulator env and run this small test:-
String s1 = "Test";
String s2 = "Test";
if (s1.equals(s2))
System.out.println("Equal");
else
System.out.println("Not Equal");
In Java is it a possibility that String.valueOf(float) would format a float number differently based on what operating system the code is run on, the version of java and/or the operating systems locale.
For example, with the float number 4.5 would it ever be formatted to "4,5" instead of "4.5"?
String.valueOf(float) calls Float.toString().
Float.toString() calls intern sun.misc.FloatingDecimal.toJavaFormatString(float)
The result string will never contain the sign , bacause of hard-coded '.' (ASCII: 46) inside the BinaryToASCIIBuffer.getChars(chars[])
You can see it if you decompile sun.misc.FloatingDecimal class (in my case java 8 jdk) or see the (similar) implementation in openjdk.
Please see the below code --
String s11 ="!country=India ";
String[] ss =s11.split("((?<=[!&|])|(?=[!&|]))");
System.out.println(ss.length);
for(String s :ss) {
System.out.println(s);
}
On Windows it gives
2
!
country=India
Whereas with Ubuntu it gives
3
!
country=India
Why would that be ?
This behavior is not because of different operating systems, but likely different versions of the JVM are used.
This "behavior change" has caused bugs to be filed incorrectly for Java 8.
The documentation has been updated for JDK 8, and is also discussed at length in this question, where split in Java 8 removes empty strings at the start of the result array. This is why the additional empty string before the ! is not created (hence the length of 2 instead 3).
Notice the difference in documentation for the split() method in Java 7 and in Java 8 for the Pattern class, and the string class (Java 7, Java 8) respectively. See the original question linked for further information on this.
I have also reproduced this issue on Java 7: sun-jdk-1.7.0_10 (ideone) and Java 8 sun-jdk-8u25 (ideone). See the Java versions here. Java 8's split will provide not add the extra empty string into the array, while Java 7's split will.
This it is not because of the system being Linux or Windows, but rather the JVM version. You can double check your JVM's version with java -version
My coding is to create 100 prime numbers randomly in a range of 1 to 1000, but I got an error message The operator > is undefined for the argument type(s) Integer, int at
Integer date;
int count = 0;
for (int i = 0; i < 100; i++)
{
date = new Integer(value.nextInt(1000));
if(date > 1 && prime(date) != -1)`
tree.add(date);
}
I guess it yields error since We cannot say integer > 1? But then how should we say it?
And forprime(date) != -1), I'm not clear for what does it mean, look like unnecessary.
The last time that error was produced by a Java compiler was with version 1.4, superseded by 1.5 in the year 2004, when the language specification introduced the autoboxing behavior needed to make your example compile without problems.
I have tried your code with Java 8 and it compiles fine (after adding the obviously missing details).
The solution seems clear: either use a modern Java compiler and do not force it to work in 1.4 compatibility mode, or, if you happen to work on a legacy project, abide by the rules governing the pertinent historical version of Java. The "manual unboxing" method on Integer is intValue().
If you happen to be working with Java 8 on a slightly outdated Eclipse, and your project is maven-based, then you may get this issue because the m2e plugin doesn't recognize version 1.8 and falls back to its default, which is 1.4. In that case I advise upgrading to the newest Eclipse (Luna).
If you are for some reason bound to an earlier version of Java, try date.intValue() > 1
Comparing the two docs for Java 6 and 7 I see no mention in the first one whether 0L might be returned "because of an I/O exception" (quite a broad description), as well. Additionally, if Java 6 behaves the same, I expect there would be a way to check for this distinction (java.nio.file.Files), which again seems to lack.
Does anyone have experience with this behavior under J6?