There were quite a few things we did to make setting up JRebel for Eclipse easier. First, the plug-in is now available from the Eclipse Marketplace, making finding the plug-in and the installation process easier. Second, there is now a new plug-in that embeds JRebel itself — meaning that you will not have to install it separately, the Marketplace install contains everything you need. Third, with this release we also started signing our Eclipse plug-ins, eliminating one more step from the install process.

We also made other improvements to our Eclipse integration, including

• improvements to the debugger integration — stepping should now perform exactly as you expect
• support for more launch configurations (WTP server editor sections and JRebel tabs for launch configurations), including OSGi and Virgo launch configurations
• small UI improvements, making it easier to find logs, change JRebel’s settings, see licensing information and redeploy statistics
• numerous other small improvements

If you are not already using JRebel, we offer evaluation licenses to JRebel for Eclipse users and free licenses to open source and Scala developers. But be warned: once you give it a try, you’ll never look back!

Some Java game development tools are already being built as Eclipse plug-ins and most likely more will be in the future. But right now they must provide them as a plug-in for an existing Eclipse installation that has all the clutter or build a completely custom Eclipse-based application, possibly an RCP app that doesn’t even include the Java Tools. I think this shouldn’t have to be the case: users of Java game dev tools should be able to download a version of Eclipse that is freed (as much as possible) from the cruft that they will not need, and be able to install specific tools and engine specific libraries into that baseline game development environment.

So I’m thinking of creating a lighter distribution of Eclipse JDT + XML tools that removes rarely used features from the Eclipse for Java Developers distribution and is specifically geared towards game development rather than enterprise Java or application development. Perhaps this should also extend to C/C++, but I am not familiar with the CDT so I’m not considering that aspect right now.

This distribution shouldn’t come from eclipse.org of course, but rather from the open source game engine and tools developers. I am willing to work on such a project, as long as it provides actual value to game developers and doesn’t eat up too much of my time. The first version of it could be fairly basic, just a lighter distro of Eclipse. Later versions can start incorporating game dev specific tools and UI concepts. Is there anyone interested in contributing to such a project? Or using such a build of Eclipse? Please let me know.

The first step of the project should be to create a reduced version of Eclipse JDT + XML tools that is still updateable, so that game development plug-ins and plug-ins such as Scala IDE, M2Eclipse, Subclipse, EGit can be installed. I have done some initial experiments and found an approximate list of features that can be easily removed from Eclipse JDT. If you would be interested in using such a distribution, please comment what you would like to be kept:

• APT or Annotation Processing Tool support — I think this is very rarely used and just clutters the UI in some screens.
• Ant support — I think a lot of people would be against this, so it should probably stay
• CVS support — CVS should not be used by anyone for other than legacy reasons, now that we have Git, Mercurial, SVN etc. And I expect that games development will not involve much poking around in legacy repositories. I think most open source game tools use SVN (correct me if I’m wrong).
• Help — this is debatable, but I would remove it from the first version and decide later what to do with it
• Welcome screen — same as help, can be added back later if it’s found to have some use
• JUnit3 support — JUnit4 should be enough, I think
• Various internal tools and plug-ins, backwards compatibility stuff

I’m estimating that the size of this distro would be somewhere between 50-70 MB. The P2 update manager included in Eclipse will increase the size on disk though, because it may create a lot of meta data and caches. But disk space is relatively cheap, and I don’t think there’s a better update manager available. My main concern is removing UI clutter so that game dev tools that plug into it will have more UI space and better visibility. Compared to the Eclipse IDE for Java Developers distribution, which lists the following “features” (feature in Eclipse terms is a collection of plug-ins):

• org.eclipse.cvs
• org.eclipse.epp.usagedata.feature
• org.eclipse.equinox.p2.user.ui
• org.eclipse.help
• org.eclipse.jdt
• org.eclipse.mylyn.bugzilla_feature
• org.eclipse.mylyn.context_feature
• org.eclipse.mylyn.ide_feature
• org.eclipse.mylyn.java_feature
• org.eclipse.mylyn.wikitext_feature
• org.eclipse.mylyn_feature
• org.eclipse.platform
• org.eclipse.rcp
• org.eclipse.wst.xml_ui.feature

Only these would remain (and even those not in complete form):

• org.eclipse.equinox.p2.user.ui (this is the update manager)
• org.eclipse.jdt (custom lite version with APT and maybe a couple of more small things removed)
• org.eclipse.platform (custom, with various plug-ins removed)
• org.eclipse.rcp
• org.eclipse.wst.xml_ui.feature (possibly custom with a couple of plug-ins removed)

Later versions could add optional updates that bundle engine-specific tools and libraries, Scala, SVN, Mercurial, Git or Maven support etc.

What do you think? Is there need for such an Eclipse distribution? I’m especially interested of the opinion of Eclipse based game tool developers, if any of you happen to read this post. Would you contribute if someone does the initial work? Has someone already done something like this (not engine specific)?

There are two usability issues with this. The first is that after selecting the “Visual Editor” feature from the site, I don’t have a “select dependencies” option. But from past usage of VE I remember that it requires Java EMF Model. So I select that too. A new user would not know to select this. I’ll have to navigate to the next page to find out if there are unresolved dependencies. And then we come to the second problem, which is this screen:

Am I really supposed to decipher this text and take action based on that? No thanks, I’ll just skip installing VE this time, I don’t have actual need for it right now.

Eclipse defaults to UTF-8?

This happens in an Eclipse Galileo milestone (3.5M6), I can’t remember which exact package I downloaded, because I required some unusual combination of plug-ins.

If it was truly the case that UTF-8 is now the default, it would be awesome, because often programmers forget to change the default setting when creating a new workspace and end up committing something in an encoding specific to their machine. Which is guaranteed to cause pain at some point.

Unfortunately I think this is probably just a bug, because I downloaded another 3.5M6 package and it still defaulted to my region-and-operating-system-specific encoding. And even if I create a new workspace with this instance of Eclipse, it will also default to the other encoding. I wonder what exactly could have caused this instance to default to UTF-8 for a particular workspace…

Also, I noticed a curiosity: I wrote the most complex parts of the mixed projects in Scala, but I mostly created bugs in the comparatively trivial Java code. The Scala code ended up almost bug free from the start, even with hours and hours of coding without actually running the code. Is it really harder to create bugs in Scala? I’d like to think so.

We’ll, a couple of weeks ago I decided to take the time and rewrote the main server code in Scala. That took only about a week and a half, the bot is now live again and running Hitchhiker’s Guide to the Galaxy. There are still several Java libraries in use of course: Z-Machine from Zinc, Bulletin Board API and ECF, Velocity, HTTPClient etc. But the main server code is now written in Scala.

My main goal for this rewrite, besides switching to Scala, was to simplify the architecture (back to the roots, I guess): the previous architecture was becoming too enterprisey for such a small project. It had too many layers of abstraction, some multi-threading issues made the code hard to debug, and using an OSGi runtime proved to be not that useful in my context. I still think OSGi is great, but sometimes simplicity is even better :)

Thankfully, ECF still works outside of OSGi and only requires two libraries from Equinox. By dropping OSGi, I could simplify the build process (or at least move it to what I’m more comfortable with – Maven). On the server I’m simply launching a Scala object with a main method instead of an OSGi runtime and that is good enough for this project.

The management console application was dropped as well, but I’m exposing some MXBeans on the server so VisualVM or JConsole can be used for management. Web-based management is planned for the future.

Another simplification was dropping some layers of abstraction and removing code that was there only to support hypothetical future features (such as games on IRC and IM, many Interactive Fiction VM implementations etc.). I may be adding some of those layers back in the future, but for now the code should focus on making the core functionality (running a Z-machine game in a vBulletin or phpBB forum thread) as good as it can be.

Perhaps the most improvement that came from this rewrite was that Scala code tends to be about two times shorter than equivalent Java code, as I aslo experienced with my Scala port of Box2D, which I mentioned in a previous post.

But I would say that using Actors for communication between different threads has also gained me some simplicity and I was now better able to understand and fix some of the concurrency issues that used to make the server hang. However, I wasn’t able to move to a completely Actor-based communication model yet, as some of aspects of the messaging between the Z-machine and the forum bot still seemed easier done using other methods, such as blocking queues. Maybe I just don’t know enough about actors yet.

Overall, I’m happy with the result so far and since I find programming in Scala to be more enjoyable than Java, I think I will be more motivated to further develop Ziggy and keep it running smoothly from now on.

I’m not sure what the moral of the story is, but it surely raises a question for me: is Blogger easily hackable? If whoever hacked it would have guessed/sniffed my password somehow, they would also have access to my Gmail account, which would be quite a bit more worrying, but that doesn’t seem to be the case. Of course, I changed my Google account’s password after this.

I do remember one time when logging into Blogger with my account, I actually gained access to someone else’s blog, who was probably coming from the same IP address as I. Might they be doing any security checks based on IP? At that time I did nothing about it, but in hindsight I probably should have notified Blogger about that incident.

In any case, I’m moving my blog to villane.wordpress.com for the moment, also considering moving it to my own server later.