Old MATLAB Improvements, Java Data Objects Primer

Matlab m-file (Download and run) 

Matlab Source Code (to view online)

For the most part I haven't changed the workings of this code. I did change one error dialog that told you the height needed to be between 0 and 20,000 meters when inputting an incorrect value for the height increments. Just a copy-paste situation where I forgot to edit the message. The big changes here are comments. It's quite thoroughly commented now and should be a bit easier to follow. I also commented-out the "Standards Selection" box, which was unusable, and centered the title information to make it look more natural. Finally I cleaned up a function call that was passing the constants array despite the fact that the other function had full view of the same array. Basically, unnecessary transferring of variables. Theoretically should have sped up the code. Considering the ambiguity of some of this code and the amount of time that passed between writing it last and doing this editing, I'm quite pleased with my ability to understand what was performing which actions throughout.

After finishing that I decided not to start the new assignment yet. Instead I started reading my book on JDO. The more I read, the more excited I get about the system. It really seems quite easy to work with and I'm excited for the implementation of it all.

I'm not sure I've talked much about JDO and why it's important to my application and Java in general, so here goes. Java code is run in a Java Virtual Machine. This is what enables it to be so universal... once the JVM is started up, one computer "appears" to be exactly like any other. At least in terms of executing the code. Unfortunately, every action the code performs is done in this Virtual Machine, and this means that everything that's been done is deleted when the code finishes, as the code finishing results in the JVM being closed. Saving in Java is done by file output during the execution of the code, by Serialization, or by storing the values of a class's variables in a database.

The first, file output, is mostly for saving a text file or similar. It's simple and useful sometimes, but it's simple and therefore not useful other times. In the case of my simulation, it's impractical due to the methods of parsing a text file back in (it would take AGES) and due to the ease of editing that text file between sessions to hack the game. Besides that, saving the file on your computer makes it tough to have an exciting multiplayer experience.

The second, Serialization, is complex. Essentially it converts the state of an object into a stream of bits and bytes, then on loading deserializes it back into its object form. These bytestreams can be large, but more importantly it's a bit unwieldy to program a class to be Serializable and program the Serialization and Deserialization across a full application like the simulation. There's also, again, the problem of things being stored on a client computer and making multiplayer a bit lackluster.

The third is storing values in a database. To start with, we'll ignore JDO. Storing values in the database means building a database (using SQL, most likely), linking the Java code up with it through the JDBC API, and programming in all the possible commands for editing the database that the client will ever use. While it sounds daunting, it's certainly doable and it had my vote for a while. Every time the client-side application is run, the user would log into the database and it would load all of his/her details, initializing all the objects necessary and setting the values back to what they are in the database.

Then comes JDO. JDO is a standard that allows me, as a Java developer, to program everything in Java code. I don't need to build my database with SQL to start with, I don't need to include ridiculous amounts of SQL hidden among the Java I'm writing, I don't need to specially format my classes. All I do is write the class as normal, enhance it with an automated tool (which builds into the class all of the methods necessary to view and edit it, automatically), initiate my database with a similar automated tool, and tell my program to make an object persistent whenever I need it to. Loading that object isn't always done per se, more often you just access the values in the database. It's just that those values are set within the Java application and without any complicated translation are plopped into the database in a Java-accessible structure.

It's really the easiest of the bunch I've seen so far. I can't wait to actually use it.

But first... I have more MATLAB to code.