We Keep Coding

Java Stream.builder() in Collector null problem

The aim is to use a Stream to iterate over an array, filtering/extending values as required and collecting the result in a new Stream.
Trying to use Stream.builder(), as in the following three examples, I'll always get a Stream with the expected Strings, but lots of trailing nulls. In addition, I can't process null elements this way.
I suspect, the internal fixed buffer in Stream.builder() is the problem.
Is there a way, to prevent 'trailing' nulls with this approach, without loosing the ability to use null values as Stream elements?
String[] whitespaces = new String[] { " ", "\n", "\r", "\t" };
int len = whitespaces.length;
boolean addNulls = false;
int flexBoundary = addNulls ? len : len - 1;
Stream<String> whitespaceNullStringStream = IntStream.rangeClosed(0, flexBoundary)
.mapToObj(idx ->
addNulls && idx == flexBoundary
? null
: whitespaces[idx])
// #1
.collect(Stream::<String>builder, Builder::add, (b1, b2) -> Stream.concat(b1.build(), b2.build())).build();
// #2
// .collect(Stream::<String>builder, Builder::add, (b1, b2) -> Stream.builder().add(b1).add(b2)).build();
// #3
// .collect(
// Collector.of(
// Stream::<String>builder,
// Builder::add,
// (b1, b2) -> b1.add(b2.build().reduce(String::concat).get()),
// Builder::build
// )
// );
If I instead use the following, it'll work as expected, except null values are converted to Strings, of course, which is not desirable here:
.collect(
Collector.of(
StringBuilder::new,
StringBuilder::append,
StringBuilder::append,
(sb) -> Stream.of(sb.toString())
)
)
To overcome this, I've used the following approach:
Stream<String> stream = IntStream.rangeClosed(0, flexBoundary)
.mapToObj(idx -> addNulls && idx == flexBoundary ? null : whitespaces[idx])
.collect(Collector.of(
ArrayList<String>::new,
List::add,
(l1, l2) -> { l1.addAll(l2); return l1; },
(list) -> list.stream()
)
);
But, as described above, I'd like to use the Stream.builder() approach inside a Collector, which works the same.

Most of the stream API will fast-crash when null is involved. The things just aren't designed for it.
There are different ideas about what null actually means. Reductively, null in java means one of 3 things:
The field was not initialized (private String hello; starts out as null)
The array slot was never written to (new String[10] starts with 10 null values)
Somebody explicitly used null, the keyword.
But that's not too useful. Let's talk semantics. What does it mean when an API returns null for something, or when you use null in some code?
There are different semantic takes on it too:
It means: Not initialized, not applicable, unexpected, no result.
In this case, exceptions are good and anything you could possibly want here would be wrong. You can't ask "concatenate this unknown thing to this string". The correct answer is not to silently just skip it. The correct answer is to crash: You can't concatenate an unknown. This is what SQL does with null quite consistently, and is a usage of null in java that I strongly recommend. It turns nulls downsides into upside: You use null when you want that exception to occur if any code attempts to interact with the thing the pointer is pointing at (because the idea is: There is no value and the code flow should therefore not even check. If it does, there is a bug, and I would like an exception to occur exactly at the moment the bug is written please!).
In light of your code, if that's your interpretation of null, then your code is acting correctly, by throwing an exception.
It's a sentinel value for something else
This is also common: That null is being returned and that this has an explicit semantic meaning, hopefully described in the documentation. If you're ever written this statement:
if (x == null || x.isEmpty())
it is exceedingly likely you're using this semantic meaning of null. After all, that code says: "At least for the purposes of this if, there is no difference at all between an empty string and a null pointer.
I strongly recommend you never do this. It's not necessary (just return an empty string instead!!), and it leads to friction: If you have a method in a Person class named getTitle() that returns null when there is no title, and the project also states that title-less persons should just act as if the title is the empty string (Seems logical), then this is just wrong. Don't return null. Return "". After all, if I call person.getTitle().length(), then there is a undebatably correct answer to the question posed for someone with no title, and that is 0.
Sometimes, some system defines specific behaviour that strongly leans towards 'undefined/unknown/unset' behaviour for a given field. For example, let's say the rules are: If the person's .getStudentId() call returns a blank string that just means they don't have an ID yet. Then you should also never use null then. If a value can represent a thing, then it should represent that thing in only one way. Use null if you want exceptions if any code tries to ask anything at all about the nature of this value, use an existing value if one exists that does everything you want, and make a sentinel object that throws on certain calls but returns default values for others if you need really fine grained control.
Yes, if you ever write if (x == null || x.isEmpty()), that's right: That's a code smell. Code that is highly indicative of suboptimal design. (Exception: Boundary code. If you're receiving objects from a system or from code that isn't under your direct control, then you roll with the punches. But if their APIs are bad, you should write an in-between isolating layer that takes their badly designed stuff and translates it to well-designed stuff explicitly. That translation layer is allowed to write if (x == null || x.isEmpty()).
It sounds like this is the null you want: It sounds like you want the act of appending null to the stringbuilder to mean: "Just append nothing, then".
Thus, you want where you now have null to act as follows when you append that to a stringbuilder: To do nothing at all to that stringbuilder.
There is already an object that does what you want: It's "".
Thus:
mapToObj(idx ->
addNulls && idx == flexBoundary
? ""
: whitespaces[idx])
You might want to rename your addNulls variable to something else :)

If condition stopped working in my Java page connecting database

public String function(String person, String area){
System.out.println("area"+area); //verified "null" is obtained here
if(area==null){
System.out.println("case1:"+area);
}
return area;
}
I am not getting the print specified inside the if condition why is it happening? it is a database connecting page consists of 2100 lines of codes. can any one tell me possible reason for this? am really fed up with this. it was working fine before. :(

could it be that area is "null" and not null?
if that is the case and area is a database value of type varchar try this:
if(area==null || area.toLowerCase().equals("null")){
btw. not sure if toLowerCase is needed.
and by the way :-) this is much better.
if(area==null || "null".equals(area.toLowerCase())){
anyway. null safetyness is not necessary because of the area==null.
if area is null the whole if condition will be true.

Java(ME) SQLlite vicious circle on Datatype Mismatch

I am trying to obtain a float value from my Database
The following checks if its null else returns 1; (works if null in DB but errors if a float)
month = row.getString(39) != null ? row.getFloat(39): 1;
On the other hand, the following gets float directly. (works if float in DB but errors if null)
float test = row.getFloat(39);
How would I go about obtaining a float from the DB, and in the case of a null, return a default value. I cant get it in either format as it causes errors when in a diff format.
Preferably without changing the SQL statement. As since there are 45 variables, it would get far too big, messy and unmanageable. I havent looked into it, but I assume with SQL I can do some kind of IFNULL(field,default). Or maybe this is the best way... Although Id probably need AS field on the end too.

The following seems to work for any data type. Using getObject and checking if it is null. Even in the case of floats, where != null would otherwise be invalid comparison.
month = row.getObject(39) != null ? row.getFloat(39): 1;

java : Handling Null check through a Combination

I am able to handle null check on a String with this below piece of code
if (acct != null && !acct.isEmpty()|| !acct.equals(""))
what i mean from the above code is , if
Accountid is not equal to null And
Accountid length is greater than 0
(These two is a combination of checks )
Or
Accountid is not equal to ""
Does my code satisfy these combination i mentioned above , or do i need to add any brackets ?? to satisfy the combination ( first 1 and 2 ) i mentioned above ??
Thanks

Yes it does, and is always evaluated before or, i.e. your code is the same as
if ((acct != null && !acct.isEmpty()) || !acct.equals(""))
However, logically it does not make sense to me. Do you really need the last part? Isn't "acct.isEmpty()" the same as "acct.equals(""))" in this specific instance?

isEmpty() and .equals("") are exactly the same condition. And your test will throw a NullPointerException if acct is null.
I don't understand exactly which test you want to make, but this one is wrong. Think about it once again, and implement a unit test to test all the cases:
null string,
empty string,
not empty string.

As per your question framed by you, it should have brackets as below
if ((acct != null && !acct.isEmpty()) || !("".equals(acct) ))
After the || operator, the code is changed which will avoid facing NullPointerException when acct is NULL.
This SO answer explains more about using "".equals().
https://stackoverflow.com/a/3321548/713414

null comparison

This might sound like a real dumb question but please bear with me :)
so I have a if condition in my code like if ((msgBO.getEmpId().equals("") == false )) {
// do something
} My question is, if I make the above statement as msgBO.getEmpId().equals(null) == false
would it make any difference or this way I am trying to compare two different things?

Yes, there is a big difference between "" (the empty String) and null (no String at all).
Any Object reference can point to null. That represents 'no data' or 'nothing.' The empty string "" represents a String with no length.
An example of this is the following:
String one = null;
String two = "";
int oneLength = one.length();
int twoLength = two.length();
The first call to length will throw a NullPointerException. And the second will return 0.

These are different things. In particular, the test
msgBO.getEmpId.equals(null) == false
a.k.a.
!msgBO.getEmpId.equals(null)
is guaranteed to always succeed (at least, if the equals method involved is written according to the standard set of rules), since no object is ever allowed to compare equal to null:
For any non-null reference value x, x.equals(null) should return false.
(Documentation of equals)
So, in other word, if you already know, that msgBO.getEmpId != null, then you also know the outcome of the call to equals. And unless you know that msgBO.getEmpId != null, calling equals is a NullPointerException waiting to happen. So, one often sees:
msgBO.getEmpId != null && msgBO.getEmpId.equals("...stuff...")
or even
"...stuff...".equals(msgBO.getEmpId)

"" (an empty string) and null are not the same. .equals(null) on a String will never return true.

A null reference and String of length 0 are two completely different things in Java. Two other points:
getEmpId is either a getter method missing the braces for method invocation or a public field, which is generally frowned upon (and badly named in this case).
if getEmpId is/returns null, teh calling equals() on it will caus a NullPointerException - which is why you should reverse the comparison when comparing with literal strings: if("foo".equals(variable))
Comparing a boolean expression explicitly using == is ugly. Instead you can use negation: if(!msgBO.getEmpId.equals("")) or if(!msgBO.getEmpId != null)

They are different , what you want is
msgBO.getEmpId == null
for the other case

You are trying to compare two different things. It might still work, but one is checking for an empty string and one is checking if the variable is null.
Also a faster check to see if the string is empty is just to check
if (string.length == 0).
(You will get an exception, however, if the string is null so don't do this if null checking, unless you want to handle the null case with the caught exception).

It does make a difference.
msgBO.getEmpId.equals("") compares msgBO.getEmpId with an empty String
msgBO.getEmpId.equals(null) compares msgBO.getEmpId with a null value. This is wrong because it will throw NullPointerException if msgBO.getEmpId is null. If you want to check if the value is null you should use such a condition instead: msgBO.getEmpId == null.
What is correct in this situation depends on the type of a value returned by msgBO.getEmpId. If it isn't String then only comparing with null makes sense. If it is String both values may have sense and then it depends how you represent an empty value of msgBO.getEmpId. In this case if you use null for an empty value you should compare with null and if you use "" for an empty value you should compare with "".