We Keep Coding

TObjectIntMap.get() returns 0 if null Trove

I am using trove library to create hash maps
http://trove.starlight-systems.com/
The class I am using is TObjectIntMap in which I had to use the function get.
The issue is that get returns 0 if two cases
1- If the value of the specified key is zero
2- If the key does not exist
For example in the following code
TObjectIntMap<String> featuresMap = new TObjectIntHashMap<String>();
if(String.valueOf(featuresMap.get("B")) == null)
System.out.println("NULL");
else
System.out.println("NotNull");
System.out.println(featuresMap.get("B"));
The program will print the following
1- NotNull: because it gets zero. Although the key "B" has not been set
2- Zero: The return of featuresMap.get("B") is zero instead of null.
I have checked their documentation in the link below and it was a mistake that they solved. So get actually return zero instead of null because int cannot be null.
https://bitbucket.org/robeden/trove/issue/43/incorrect-javadoc-for-tobjectintmapget
Now my question is: How to differentiate between a zero and Null in this case. Is their any way around to address this issue.

Try their containsKey method. If the value comes back 0, use that method to check if the map contains the key - if it does, then the key's value really is 0. If it doesn't, then the key is not set.

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.

Jasper report decimal format with zero value is giving null

We are using jasper report.
And for one of field in report we have set formula, like if value of rate1 field is null then display "-" in report otherwise format rate1 value such as ##0.0000.
$F{rate1}?new DecimalFormat("##0.0000").format(new
BigDecimal(""+$F{rate1})):"-"
But if value of rate1 is 0 then also it is displaying "-" instead of 0.0000
What can be issue ?

You need to change it to following.
$F{rate1} != null ? new DecimalFormat("##0.0000").format(new BigDecimal(""+$F{rate1})):"-"
To explain, I have not checked in JasperReports and dont have a setup to test right away.
But In C, zero is considered false, while a non zero value is considered true.
Somewhere while the reports are being parsed and executed this might be happening, this might be the scenario happening. You better confirm with the community about this.

How do I use ArrayList<Integer>#contains when I only have a BigInteger?

I am pulling data values from a database that returns a List of <Integer>. However, I would like to see if the List contains my BigInteger. Is there a simple way to do this?
I currently have the following code in Java:
ArrayList<Integer> arr = new ArrayList<Integer>() {{add(new Integer(29415));}};
boolean contains = arr.contains(29415); // true
boolean contains2 = arr.contains(new BigInteger("29415")); // false
I'm not sure on an efficient way to do this?

The correct answer will be returned by evaluation of the following:
val != null
&& BigInteger.valueOf(Integer.MIN_VALUE).compareTo(val) < 0
&& BigInteger.valueOf(Integer.MAX_VALUE).compareTo(val) > 0
&& list.contains(val.intValue())
This will correctly solve the question of whether the BigInteger you have is "contained" within the List<Integer>. Note that here we only downcast where necessary. If the val is outside the range of Integer values there is no need to downcast as we know that the value cannot be within the list.
A more relevant question is whether you should actually be using a List<BigInteger> in place of a List<Integer> but that is a different question and not part of the answer to your explicit question

While arshajii provides a solution which works, i would vote against it.
You should never downcast values. You are running in danger of your program producing larger values which translate to invalid values when downcasted. This kind of bug will be super nasty to troubleshoot months later.
If your code works with BigInteger, then you should convert all values from the database into BigInteger. This is an upcast where you cannot loose values.
Overall I would value correctness over efficiency. If at all, I would reconsider your usage of BigInteger (maybe long is fine?) but because you have it, I assume you have a reason for it.

In Java List.contains() uses the equals() method internally and because BigInteger.equals(Integer) returns false, your List.contains() also returns false. Either use the an List<BigInteger> or extract the Int value from BigInteger (as arshajii explained!). Of course, if you really want to search effectively, you should think of a binary search (in a sorted list) or of another data structure like Map.

You can try using BigInteger#intValue():
arr.contains(myBigInteger.intValue())
Note, however, that if myBigInteger is too big to fit into an int, then only the lower 32 bits will be returned (as described in the linked docs). Therefore, you might want to check if myBigInteger is less than or equal to Integer.MAX_VALUE before checking for containment.

Java string to double conversion

I've been reading up on the net about the issues with handling float and double types in java. Unfortunately, the image is still not clear. Hence, i'm asking here direct. :(
My MySQL table has various DECIMAL(m,d) columns. The m may range from 5 to 30. d stays a constant at 2.
Question 1.
What equivalent data-type should i be using in Java to work (i.e store, retrieve, and process) with the size of the values in my table? (I've settled with double - hence this post).
Question 2.
While trying to parse a double from a string, i'm getting errors
Double dpu = new Double(dpuField.getText());
for example -
"1" -> java.lang.NumberFormatException: empty String
"10" -> 1.0
"101" -> 10.0
"101." -> 101.0
"101.1" -> 101.0
"101.19" -> 101.1
What am i doing wrong? What is the correct way to convert a string to a double value?
And what measures should i take to perform operations on such values?
EDIT
This is the code -
System.out.println(dpuField.getText());
Double dpu = new Double(dpuField.getText());
System.out.println(dpu);
Yes, the problem lies with getText() reporting the wrong value of the dpuField.
This method is called on the JTextField keyTyped event. So what's going wrong here?
EDIT 2
Looking at :
http://journals.ecs.soton.ac.uk/java/tutorial/post1.0/ui/keylistener.html
Apparently, keyTyped() does not give me the keycode. I'll have to switch to keyRealeased()

What equivalent data-type should i be using in Java to work (i.e store, retrieve, and process) with the size of the values in my table? (I've settled with double - hence this post).
Since it's a DECIMAL field, you should prefer java.math.BigDecimal. You can store it in DB using PreparedStatement#setBigDecimal() and you can retrieve it from DB using ResultSet#getBigDecimal().
While trying to parse a double from a string, i'm getting errors
This can't be true. The problem lies somewhere else. Maybe it is just not returning the data you expect to be returned or you are not using/debugging the values you expect them to be.

if you need exact precision without rounding errors, you should use a BigDecimal.
Your code looks OK - could it be that dpuField.getText() somehow cuts the last character from the string values you list above?
Update: you say
Yes, the problem lies with getText() reporting the wrong value of the dpuField. This method is called on the JTextField keyTyped event.
Could it be that getText() returns the value of the field before the last typed key is actually appended to it?

For decimal, I believe you risk losing precision if you don't use a BigDecimal on the Java side, as some decimal fractions can't be stored as a binary fraction.
Prefer Double.valueOf(String) over the constructor, but that's a valid way. Something else must be going on (i.e. I doubt those are the actual String values you're passing in).

Question1: It's bad idea to map DECIMAL columns to Double, usually the BigDecimal is the correct type. http://java.sun.com/j2se/1.3/docs/guide/jdbc/getstart/mapping.html#1055175
Question 2: You are doing something wrong; print the String value before converting.