The NullpointerException bug has been fixed, it was probably an abvious one to experienced programmers, but I had to bang my head at it for two whole days before I could figure out what cased it. On the bright side, I finally started paying attention to how debugging works in IntelliJ, and I now know object member variables, even if they are "declared and initialized" at the beginning of the class like "int a = 4;" They will actually not be anything but null until the constructor has been called.
Logging
I finally managed to get SLF4J and Logback up and running. It took some fiddling with the build.Gradle file, writing a proper logback.groovy config file, figuring out where to place it (/src/main/resources) etc.
But we now have basic logging.
Exactly what it's good for I'm still not sure of, the logback manual is rather long and very abstract and vague, so I suppose it will take another weeks worth of reading before I fully come to understand the potential of logging http://logback.qos.ch/manual/index.html
Hayabaya now called Main
I hope it's okay, but on my own repo I have renamed HayaBaya to MainClass. I just find it more natural that the class containing the main method should be called something with Main. I hope this is okay as a temporary change.
In the Hayabaya / MainClass itself, the biggest change is that I now use an ArrayList to handle all of the different instances. And then I use forach loops to iterate over all of the Looper instances in the list, and another for each loop to iterate over all of the operation types, which I then apply to all of the Loopers object. Then I write the result to disk.
List<Loopers> looperList = new ArrayList<>();
int asize = RunSettings.ARRAY_SIZE_MIN;
int acycle = RunSettings.CYCLES_MIN;
Loopers loopersInt = new LoopersInt(asize, acycle);
Loopers loopersLong = new LoopersLong( asize, acycle);
---
looperList.add(loopersInt);
looperList.add(loopersLong);
/** Loops over entire experiment */
for ( int repetitions = 0; repetitions < RunSettings.TOTAL_EXP_REPS; repetitions++ )
{
/**Loops over objects (Loopers)*/
for (Loopers thisLooper : looperList)
{
/** Loops over operations*/
for (Operation operation : Operation.values())
{
result = thisLooper.makeResults(operation);
Utility.writeResultsToCsv(result);
}
}
Utility.setResultCounter(repetitions);
}
The Code runs without any complaints for all of the primitive data types, but when I include the Autoboxed Loopers a java.lang.NullPointerException pops up.
It originates in Main from Looper.makeResults(Operation) which leads to line 108 in Loopers.Java class. Here we are calling
operateLoop(operation);
This method is however declared abstract in Looper, and not initialized on line 58
public long test(Operation operation) {
operateLoop(operation);
}
The operateLoop(Operation) function is an abstract method to be implemented by the child classes. I cannot see any difference in the implementation between the Looper-PrimitiveDatatype and the Looper-BoxedDataType classes. But for some reason, the Autoboxed classes ends up with a nullpointer exception.
Commenting out the call to operateLoop in Looper makes the nullperointerException go away, then no operations are performed and all of the result files are just empty.
Loopers Classes
I have added a toString()* method to all of the Looper classes. The toString method is likely overkill, but I would like to emphasize that whe I am running the program and looking at the intermediate output of the Loopers.toString, it seems to me like the elements of the data arays are never altered. Is this intentional?**
Unit Testing
I have made my first weak attempts of doing some unit testing. I know the tests I have written are so trivial that it's laughable, and more than a few Java programmers has told me to stop writing such simple tests. But I must insist that I do this so I can learn JUnit!
There is a strong lack of good JUnit documentation out there, and writing tests is the only real way to learn unit testing.
I feel like I have the basics down now, and I am ready to start writing Unittests for the Loopers classes and then eventually for the main class / entire program. But I am having some questions about variable scope in Unit testing and the "@Before" and "@BeforeClass" annotation. Perhaps you can answer some of those questions?
Conclusion
I wanted to do more refactoring and editing of the code. But I generally often found myself breaking the code and making it unable to run. And when I did that, I also often had very little idea about what had broken the code. So I decided that having Unittests in place to tell me whenever and wherever anything broke was a good idea.
Likewise, I think that this is a learning experience, I have to write "bad" code before I can write good code.
Making the mistakes, struggling with the consequences of those mistakes, and staying up for nights to rewrite the code to be more readable is just a part of the learning experience.
Although I wish it would go a bit faster. Even though I can clearly feel that I have improved since I started working with you, I still feel that I am way too slow and I make way too many mistakes. And there are just SOOOO many areas of Java / The JVM ecosystem I haven't even heard of! It's a truly daunting field! :o
But I also really like programming, I really do. I am just not used to being a beginner and sucking at something :)
NullpointerException
The NullpointerException bug has been fixed, it was probably an abvious one to experienced programmers, but I had to bang my head at it for two whole days before I could figure out what cased it. On the bright side, I finally started paying attention to how debugging works in IntelliJ, and I now know object member variables, even if they are "declared and initialized" at the beginning of the class like "int a = 4;" They will actually not be anything but null until the constructor has been called.
Logging
I finally managed to get SLF4J and Logback up and running. It took some fiddling with the build.Gradle file, writing a proper logback.groovy config file, figuring out where to place it (/src/main/resources) etc.
But we now have basic logging. Exactly what it's good for I'm still not sure of, the logback manual is rather long and very abstract and vague, so I suppose it will take another weeks worth of reading before I fully come to understand the potential of logging http://logback.qos.ch/manual/index.html
Hayabaya now called Main
I hope it's okay, but on my own repo I have renamed HayaBaya to MainClass. I just find it more natural that the class containing the main method should be called something with Main. I hope this is okay as a temporary change.
In the Hayabaya / MainClass itself, the biggest change is that I now use an ArrayList to handle all of the different instances. And then I use forach loops to iterate over all of the Looper instances in the list, and another for each loop to iterate over all of the operation types, which I then apply to all of the Loopers object. Then I write the result to disk.
The Code runs without any complaints for all of the primitive data types, but when I include the Autoboxed Loopers a java.lang.NullPointerException pops up. It originates in Main from Looper.makeResults(Operation) which leads to line 108 in Loopers.Java class. Here we are calling
This method is however declared abstract in Looper, and not initialized on line 58
The operateLoop(Operation) function is an abstract method to be implemented by the child classes. I cannot see any difference in the implementation between the Looper-PrimitiveDatatype and the Looper-BoxedDataType classes. But for some reason, the Autoboxed classes ends up with a nullpointer exception.
Commenting out the call to operateLoop in Looper makes the nullperointerException go away, then no operations are performed and all of the result files are just empty.
Loopers Classes
I have added a toString()* method to all of the Looper classes. The toString method is likely overkill, but I would like to emphasize that whe I am running the program and looking at the intermediate output of the Loopers.toString, it seems to me like the elements of the data arays are never altered. Is this intentional?**
Unit Testing
I have made my first weak attempts of doing some unit testing. I know the tests I have written are so trivial that it's laughable, and more than a few Java programmers has told me to stop writing such simple tests. But I must insist that I do this so I can learn JUnit! There is a strong lack of good JUnit documentation out there, and writing tests is the only real way to learn unit testing.
I feel like I have the basics down now, and I am ready to start writing Unittests for the Loopers classes and then eventually for the main class / entire program. But I am having some questions about variable scope in Unit testing and the "@Before" and "@BeforeClass" annotation. Perhaps you can answer some of those questions?
Conclusion
I wanted to do more refactoring and editing of the code. But I generally often found myself breaking the code and making it unable to run. And when I did that, I also often had very little idea about what had broken the code. So I decided that having Unittests in place to tell me whenever and wherever anything broke was a good idea.
Likewise, I think that this is a learning experience, I have to write "bad" code before I can write good code. Making the mistakes, struggling with the consequences of those mistakes, and staying up for nights to rewrite the code to be more readable is just a part of the learning experience.
Although I wish it would go a bit faster. Even though I can clearly feel that I have improved since I started working with you, I still feel that I am way too slow and I make way too many mistakes. And there are just SOOOO many areas of Java / The JVM ecosystem I haven't even heard of! It's a truly daunting field! :o But I also really like programming, I really do. I am just not used to being a beginner and sucking at something :)
Cheers Soren