Java string split gives different outputs on Windows and linux - java

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

Related

Compare strings bwlow API 18

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");

Investigating a Java bug regarding String.valueOf(float)

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.

Java BigDecimal.doubleValue between Java 6 and Java 8

Case 1: In Java6 BigDecimal("0.0050000").doubleValue() returns 0.0050, and in Java 8 return value is 0.005
Case 2: In Java6 BigDecimal("0.0250000").doubleValue() returns 0.025, and in Java 8 return value is 0.025
In case 1: Java 6 returns with extra trailing zero.. Any idea?? Also how to make Java 8 return the same output as Java 6
There is difference how System.out.println works in java6 and java 8.
Also we talk about doubles, BigDecimal is not a problem here. We can simplify this example to:
System.out.println(Double.toString(0.0050000));
Because println calls java.io.PrintStream#print(double) and then calls String.valueOf(d) you can check it in JDK.
But java.lang.Double#toString(double) looks different in JDK6 and JDK8:
return FloatingDecimal.toJavaFormatString(d); //JDK 6
return new FloatingDecimal(d).toJavaFormatString();//JDK 8
I've found some JDK issues which has been fixed in java 7 (java 7 has same output like in java 8)
I think this issue maybe a cause:
http://bugs.java.com/view_bug.do?bug_id=6935102
http://bugs.java.com/view_bug.do?bug_id=7039369
http://bugs.java.com/view_bug.do?bug_id=7032154

Java Path interface and OCPJP7 Exam

I’m preparing for OCPJP7 exam on these days. I got two questions and accepting answers. First one is relevant to java and other one is about exam achievements.
import java.nio.file.*;
class Test13{
public static void main(String arfd[]){
Path a = Paths.get("D:\\OCPJP7\\programs\\..\\NIO2\\SRC\\.\\Subpath.java");
a=a.normalize();
System.out.println(a);
}
}
According to the above code segment, I was expected the output as “D:\OCPJP7\programs\NIO2\SRC\Subpath.java”
But it is not. It provides “D:\OCPJP7\NIO2\SRC\Subpath.java”
As I know normalize() removes any redundant elements from the given path including single dot and double dot. Then why it removes \programs\ element?
In order to be an Oracle Certified Professional, Java 7 Programmer, we have to sit for two exams;
OCA -JP (Oracle Certified Associate, Java 7 programmer).
Java SE 7 programmer.
As I know we can achieve both exams in any order. So I’m intended to do first Java SE 7 programmer and then OCA.
My question is what will offer by the Oracle, after passing both exams.
Are they offering two certificates for both exams? or one certificate for both? And anything else?
As I know normalize() removes any redundant elements from the given
path including single dot and double dot. Then why it removes
\programs\ element?
.. refers to the the parent directory. In other words, /programs brings you forward and /.. brings you back.
The Javadoc of Path#normalize() states
If a ".." is preceded by a non-".." name then both names are
considered redundant (the process to identify such names is repeated
until it is no longer applicable).
So \\programs\\.. is redundant and removed.
I can't answer your second question.

Why are there no binary literals in Java?

Is there any particular reason why this kind of literal is not included whereas hex and octal formats are allowed?
Java 7 includes it.Check the new features.
Example:
int binary = 0b1001_1001;
Binary literals were introduced in Java 7. See "Improved Integer Literals":
int i = 0b1001001;
The reason for not including them from day one is most likely the following: Java is a high-level language and has been quite restrictive when it comes to language constructs that are less important and low level. Java developers have had a general policy of "if in doubt, keep it out".
If you're on Java 6 or older, your best option is to do
int yourInteger = Integer.parseInt("100100101", 2);
actually, it is. in java7.
http://code.joejag.com/2009/new-language-features-in-java-7/
The associated bug is open since April 2004, has low priority and is considered as a request for enhancement by Sun/Oracle.
I guess they think binary literals would make the language more complex and doesn't provide obvious benefits...
There seems to be an impression here that implementing binary literals is complex. It isn't. It would take about five minutes. Plus the test cases of course.
Java 7 does allow binary literals !
Check this:
int binVal = 0b11010;
at this link:
http://docs.oracle.com/javase/tutorial/java/nutsandbolts/datatypes.html

Categories