Strange behavior running JAR in different machines

Question

I found a strange (at least for me) behavior in my small Java application. I have an app.jar which running from command line to do a simple task. The task is, find duplicate values from the given list and remove them. The application was developed with JDK-7 and running with JRE-7.

From command line of my PC everything is OK, but when running the same JAR in virtual machine which is Windows-7 as mine and with the same JRE it doesn’t remove duplicates and no any error occurs.

Here is my code:

public List<String> removeDuplicatedFin(List<String> coreList,
            Map<String, String> strToRemoveMap) {
        for (int y = 0; y < coreList.size(); y++) {
            String str = coreList.get(y).getPosts().get(0).getMyStr();
            String id = coreList.get(y).getPosts().get(0).getId();
            if (strToRemoveMap.get(str) != null
                    && strToRemoveMap.get(str).equals(idPost)) {
                coreList.get(y).getPosts().remove(0);
            }
        }
        return coreList;
    }

coreList is the main list

strToRemoveMap contains values to be deleted

Any idea or some help please?

Thanks in advance

The problem is likely to be in some of the code you haven't shown us... — Jon Skeet, Aug 16 '16 at 09:57
can you share your code, where you are removing the duplicate ? There must be some problem with your code. — AmanSinghal, Aug 16 '16 at 09:59
@AmanSinghal Thanks for your reply. I will share it once I'll be in home, but why then it works fine in my local PC? I guess if there is problem with code, it should be fail everywhere? — Arsench, Aug 16 '16 at 10:40
I can't see the code where you are adding data in the map. Since finsToRemoveMap will always empty, the given code will never remove any elements from the coreList — AmanSinghal, Aug 16 '16 at 11:02
@AmanSinghal the variable finsToRemoveMap is not empty it comes from another methos already added duplicate values to be removed — Arsench, Aug 16 '16 at 11:07
Your code seems to be very bad :/ You should use some iterator with your list. And the contains() methods for both List and Map. Anyway, the only reason I see your jar doesn't work everywhere is because there is some path variable missing. Could you add how you create your lists and run your program in the main ? — Kapcash, Aug 16 '16 at 12:09
Maybe they are not true identical values when running on your windows box, maybe some have a dos CRLF at end while others have only a unix LF and the CR is read together with the value making it different. Or something like that. — Stefan Hegny, Aug 16 '16 at 12:10
@StefanHegny Thanks Stefan,the problem was in the string comparison task as I've post below. — Arsench, Aug 16 '16 at 13:13

score 0 · Answer 1 · answered Aug 16 '16 at 13:07

0

Many thanks for your reply. Finally I found that this anomaly occurs because I was comparing two string with the example

if(str1.equals(str2))

and I don’t know why when I changed

if(str1 == str2)

it works perfectly. However in Eclipse and in my PC it was working with equals() too.

I need to learn more about this kind of things and not only.

Thanks and have a nice day.

answered Aug 16 '16 at 13:07

Arsench

179
2
4
17

@StefanHegny I'm trying to run it in Linux, and in other PC's too, it is very strange for me too :) – Arsench Aug 16 '16 at 13:27

Stephen C · Answer 2 · 2020-02-18T13:21:47.607

Contrary to what you may think that you have discovered, the correct way to compare two strings in Java is to use String.equals; see How do I compare strings in Java?.

There are situations where str1 == str2 is false and str1.equals(str2) is true. Two strings that are equal are not necessarily the same object.

However, it is not possible for str1 == str2 to be true and str1.equals(str2) to be false; the specification of String.equals does not allow that.

If you have really come across a situation where that seems to be the case, then the most likely explanation is that you have a race condition or memory anomaly caused by the behavior of another thread. It is hard to be more specific without seeing your real code in action.

This could also explain why your (actual) code works in some circumstances and not others. It is not unusual for concurrency related bugs to only show up on certain platforms. For example, they might be OS dependent, or Java version dependent or they might depend on the number of physical cores your system has.

^{For what it is worth, your (supposed) example method does not compile. Since coreList is a List<String>, coreList.get(y) will give you a String. But String doesn't declare a getPosts() method so the three places where you have coreList.get(y).getPosts() will be compilation errors.}

^{I suspect that you have modified the actual code that exhibits the problem. But in doing so you have turned it into something that is nonsensical. This is why we asked for a minimal reproducible example.}

Strange behavior running JAR in different machines

2 Answers2