I ran into an interesting bug today when messing around with Beret, my WIP attempt at a Java decompiler. For some reason, it would fail to read certain class files, in which it would encounter an invalid constant pool entry and crash, unable to proceed. Upon further investigation I found that it was actually reading into the next structure of the class file (the access flags) in an attempt to parse them as constant structures, and would freak out when it didn't recognize the data. Without much effort I discovered it was inexplicably discovering two fewer structures in the table than indicated by the defined pool size.
So, I tweaked the code to subtract two from the expected size and commented out everything but the pool dump. Then I compared it to the javap dump and realized
javap was printing out something like this:
At. . .
You can view a demo of the project from this post here.
I've been working a lot on fairly technical projects lately, and since I've been sick the past few days and thus had some extra free time, I thought I'd switch it up a little and make something fun. I'm a big fan of the Monstercat label, and in particular, their visualizer. Essentially, it's an audio spectrum overlaid on a particle system which adjusts its speed to the audio. It's a lot cooler and less stuffy than I'm making it sound, so check it out for yourself if you get the chance.
Unfortunately, I didn't exactly start from scratch. My project was based on another meant to do essentially the same thing, but I wasn't quite happy with a few aspects of it and thought I might tweak it a little to make it closer to the real deal. The original. . .
A little over a year ago, I started a project called MGLib. MGLib was a library essentially designed to serve as a generic backend for Bukkit minigame plugins, making it easier for developers to make their own gamemodes without having to go through the tedium of writing all the arena, round, and player management code that needs to be there every single time. (Indeed, having a unified backend proved to be efficient; a basic spleef plugin could be written in ~8 KB of code.) My inspiration for the project was another plugin of mine called TTT, whose core engine was desparately in need of an update. The solution I arrived at was to separate it so it could be updated separately from the plugin's more unique features.
This was a decent solution, as I found, and made. . .
Java 6 was released in 2006. It is now 2015. It has been 9 years since the release of Java 6. Therefore, I feel it's time to bump the version I compile my software against.
Let's look at Java 7. Java 7 was released in 2011 and has since been succeeded by Java 8. It will reach its end-of-life after April of this year, which is exactly when I intend to switch to using it as a standard. It's a little backwards, but there's not really much more I can do while Java 8 has less than a 50% market share.
So in summary: starting in May, all future releases of my software, plugins, games, whatever, will be compiled against Java 7, dropping support for 6. It's not an easy choice, but I feel it's necessary, and I'd like to begin using features introduced to the language more recently. That being said, I offer my apologies to those that are affected by this.
It's now been more than three months since my post about the fall of Bukkit. Since then, however, the situation has massively changed. Spigot has updated their server software to 1.8, as well as Bukkit and CraftBukkit. They were essentially able to do this (seemingly) legally because the free code is merged with the non-free code by the server owners themselves, but that's a little bit complicated and an explanation for another post.
Anyhow, despite these legal workarounds, the project is still on shaky turf as it still uses DMCA'ed code, especially considering Wolvereness himself explicitly threatened legal action (although he doesn't seem to have done anything yet and is currently dedicating his time to crafting extremely huffy and self-righteous. . .