[spyder0101]

I'm writing a min-cut EA with a fairly large population and trying to make it as efficient as possible. One of the things I'm trying to do is store the graph in a Singleton where all the members of the population can find it. Basically I need the following SSCCE to print 1 instead of null. How do I do this?

public class Test {
 	private static Integer myInt;
 
	public static void main(String[] args){
 		Test.setMyInt(1);
 		System.out.println(Test.getMyInt());
 	}
 
	 public static void setMyInt(Integer myInt) {
		if(myInt==null)Test.myInt = myInt;
	}
 
 	public static Integer getMyInt() {
 		return myInt;
 	}
}

[NormR]

You are having the common problem people have when they name the args to a method with the same name as member names.

[spyder0101]

I don't believe so. That type of scoping problem was the first thing I checked for and I have referenced the correct objects in the code above. As I stated, this is a SSCCE , not the working code and the original had different names. I reran my test as shown below and got the same result, just to make sure.

public class Test {
 	private static Integer myStaticInt;
 
	public static void main(String[] args){
 		Test.setMyInt(1);
 		System.out.println(Test.getMyInt());//should be "1", is "null"
 	}
 
	 public static void setMyInt(Integer myInt) {
		if(myInt==null)Test.myStaticInt = myInt;
	}
 
 	public static Integer getMyInt() {
 		return myStaticInt;
 	}
}

The results were the same.

The problem does appear to be a scope issue, as I have had it print when it updated the value but it always is null as soon as the setter exits. Any ideas?

[jzd]

Line 10 only sets myInt if the value passed in NULL. I think you might actually mean !=null

[NormR]

What does this code test for and why?

public static void setMyInt(Integer myInt) {
  if(myInt==null)
 ...

[HeadOnAPlate]

NormR is actually correct in his assessment. you might want to check out your setter-method again

[spyder0101]

Actually, should have been the myStaticInt there, so I guess NormR was right. Changing that fixes the problem. Thanks.

[tagmanadvance]

You might consider throwing an exception instead of returning on null. Wouldn't it be better to know where the null came from in the first place than to ignore it?