Implementing hash-object part 2: The hashening

So a lot has changed about Java since I last dabbled in it. The last time I worked a lot in Java was around Java 8 or 9. We are now on Java 18 and boy is there a lot to get caught up on.

For instance finishing up the hash-object implementation had me doing a lot of googling and I saw some code that looked markedly un-java-like from my understanding. Java code that looked like it was doing some type inferencing? Cool as heck. So I did learn something.

I have finally completed the hash-object implementation this afternoon! I last left off nearly 24 hours ago too tired to figure out what zlib compression was but I looked it up today and it’s pretty straightforward. Even more straightforward is the fact that Java’s deflators use zlib compression so I could just use a DeflaterOutputStream to compress the contents of the file.

Where “bytes” is the byte array of the file contents.

This got me to my next checkpoint: more test errors.

Another “doh!” moment

This was helpful because it showed me 2 things: I was accidentally using the file name as the “contents” of said file and I wasn’t doing the null byte correctly which on second look also made total sense. So I went in and fixed the code up by first actually reading the contents of the file and using an actual 0 value byte for the null byte:

I don’t know what past Taylor was thinking.

From here I was able to achieve sweet, sweet victory. I took the time to also change how I was calculating the hex string by using Java’s hex utility instead of manually trying to convert it and voila. The hash-object part of git has been completed.

That feels good.

The next stage is “Read a tree object” which I am immediately going to nope out of for this evening as I would much prefer reading my book instead. I’ll probably start it sometime tomorrow.

Learnings

It’s good to be back in Java land again and startling to see how much I have to get caught up on. Shooting 10 versions ahead in time I definitely feel way behind on the actual best practices for Java at the moment so this is a great opportunity to learn about all the new stuff. One thing making it a little hard though is that whenever I want to look at documentation and I look up something like “java <class name>” it only comes up with the Java 8 documentation. This has been super weird and I think I need to dive in and figure out how to better look at the updated documentation for Java.

Relatedly I started this project in Sublime and just testing and compiling things through CLI and currently have everything in just one file. This last iteration of work shows me I really can’t continue in this way. I think this “basic” set up is slowing me down more than anything. I’m not even sure what the suggested workflow for Java is but I was thinking of trying to set up SpaceVim and use their Layers functionality to make it into a lightweight IDE I can use for the remainder of this project. (And just after typing that out I downloaded it and have started poking around - i’ll keep you updated on how it goes)

And lastly - the time tested learning of “timebox the thing then walk away and come back to it later” continues to result in positive outcomes. I worked on this implementation in roughly 15-30 minute increments and every time I was able to get somewhere and get met with a new error or a new test failure I was able to evaluate how tired I was and determine if I had the energy to look into the problem or not. This felt like a good pattern to get into because I never dug in and got so stuck that things became frustrating. I was always making a fairly steady stream of progress which is nice to experience after working a long day as a full time engineer as well.