Major changes underway at Oracle: SPARC and Solaris teams laid off, Java EE oversight goes to Eclipse Foundation, future Java SE major releases proposed for twice a year

Oracle has been rather busy last few weeks. First, news that the Solaris and SPARC teams from Oracle’s acquisition of Sun Microsystems have reached the end of the road, and the majority of the teams have been laid off. The layoffs started at the start of this year, and the recent round apparently leaves only a small team left.

Last month there was a blog post to The Aquarium suggesting that Oracle would be open for another group or organization to drive stewardship for the Java EE spec. Looking back at past events, it’s no surprise that some significant changes were coming. Things started changing with the layoffs of the majority of the Java evangelists back in September 2015 and the letter assumed to be from one of the evangelists to InfoWorld stating that “… Java has no interest to them anymore”. Oracle’s lack of involvement in the development of Java EE started to gain notice by the other JCP members in minutes of the JCP Executive Committee in May and June 2016 leading to statements in the public minutes such as:

“…concern that Oracle, despite its role as steward of Java, has not made any public statements or explanations for the apparent lack of activity on Java EE”

There was also a formal statement by the JCR Executive Committee directed to Oracle formally voicing their concern with recent lack of JSR activity and involvement by Oracle:

“EC members expressed their serious concerns about the lack of progress on Java EE. They believe that Java EE is critical to the Java ecosystem and to their organizations and customers. They fully accept Oracle’s right to direct its investment where it wishes, but expressed the hope that they and other members of the Java community be permitted to step in and help with the ongoing development of the platform, particularly in areas where Oracle wishes to reduce its investment. They therefore requested a dialog with Oracle about how to make such a transition.”

This was followed in June 2016 by a statement by ‘Oracle spokesman’ Mike Moeller that Oracle were still committed to Java EE and were planning on a proposal to the community a t JavaOne 2016. This proposal turned out to be a ‘refocusing’ of the changes in the Java EE 8 proposal, namely dropping new features and changes that were not aligned with current industry trends (particularly microservices, so the MVC spec and a number of other proposals got dropped from the EE8 JSR).

From last month’s post that Oracle was open to consider another organization to drive future development of Java EE, yesterday it was announced (more here) that the Eclipse Foundation will be the new stewards of Java EE. Given Oracle’s recent lack of involvement, it’s great that they even considered this move, and hopefully the future of EE will be in good hands with the Eclipse Foundation.

If that news was not enough, Mark Reinhold also posted recently that after the slow release schedule of the past few major Java SE releases, they’re considering a twice yearly major release cycle moving forward after the planned release of Java 9 on September 21 (after many delays already). Two major releases a year is a massive change compared to the 3 year current release cycle (between Java 7 to Java 8 and between 8 and the upcoming Java 9 releases). Hopefully this means some good things are going to be coming to Java across the board, SE and EE, in the near future.

Project Jigsaw for Java has been a long time coming – are we really going to see it in Java SE 9 this year?

Java SE 9 general availability date is 7/27/17, per the release schedule here. Project Jigsaw been a long time coming and been postposed from release to release (it was originally planned for SE7, pushed to SE8, and now SE9), but this year we’ll see Project Jigsaw come with SE 9.

It’s funny what you find unexpectedly when searching for stuff online – reading around for Jigsaw related articles I found this Jigsaw mailing list post by Mark Reinhold back in 2012 including a link to one of my blog posts, discussing the Jigsaw ‘plan A’ vs ‘plan B’ options back when Jigsaw was pushed out from SE 8 to 9. Hopefully we really will see Jigsaw in SE9 later this year.

Game development in progress: Space Invaders clone – update 2

Earlier this year I started developing a Space Invaders inspired game for Android. I started back in March, and have worked on it for a around 20 to 30 hours or so, on and off. Not being an expert in Android development or game development in general, it’s been a learning experience. The book I read back in March, Android Game Development by Example, was a good book to get started. I realize I probably could have got to a playable game quicker if I’d used a game development platform like Unity3d, but I wanted to get to grips with writing a game by from the ground up first. I’ll circle back and probably rewrite it using something like Unity later.

Right now I’m at a point where it’s playable but there’s a few key features I still need to add, like the bases/shields at the bottom of the screen, and the invaders need to shoot missiles at the player. It’s a pretty easy game at this point 🙂 I have a few ideas for some gameplay variations to add too.

I started implementing as a standalone Java app using the Java2d api and the 2d game engine that I’d previously worked on for my first attempt at a game in Java, a version of one of the classic Nintendo Game n Watch games, Turtle Bridge.

I tried to replicate the animation of the invaders moving one at a time, one row at a time and got pretty close:

Compared to current day AAA tier video game development projects which typically have multi-million dollar budgets and teams of artists, story writers, sound engineers, QA, developers, as well as marketing and PR teams, I find it fascinating that Space Invaders was originally developed by a single developer, Tomohiro Nishikado. Not only did he develop the sofware for the game, but he also designed the hardware on which the game runs.

There’s some interesting features of the game that were not part of the original design, but resulted from limitations of the hardware. For example, the invaders speed up as fewer are left remaining on the screen. This is a defining feature of the game, but was a side effect from the 8080 processor being unable to animate a full screen of invaders at the same speed compared to a screen with only 1 or 2 remaining. Rather compensate in software to keep a constant frame rate, this feature was kept.

Other features in the game play logic could easily be overlooked by a casual player:

  • The mystery ship appears on a regular, timed basis, at around each 25 seconds
  • The mystery ship is worth 300 points on the first 23rd shot on each screen, and then 300 on every 15th shot for the remainder of the screen. For all other shots it’s 100 points (if you play for high scores, then this fact is probably very well known to you 🙂 )
  • Missiles from the invaders will not kill the player if fired from the last row on the screen

Here’s a quick video of how far I’ve got so far. This is running on a device simulator, so the frame rate is not as fast as on a real device:

I’ve still got some work to do, but I’m pleased on my progress so far.

Android development: drawing text on a Canvas

I have an Android project bubbling away. More details soon 🙂

I’m using a SurfaceView and needed to draw some text on it. The rest of the app is mostly drawing on the SurfaceView Canvas directly, but I need some text too.

I’ve dabbled with some Android development before, and I have to admit getting the layouts to do what you want them too almost seems to suck up the majority of my development time 🙁 This time round I got sidetracked trying to create a layout that was using a mix of TextView elements and adding my SurfaceView programmatically. This didn’t go too well, didn’t work at all, so I found a few posts like this, and worked out you need to draw directly on the canvas. Something like this does the job:

Paint textPaint = new Paint();
textPaint.setColor(Color.WHITE);
this.canvas.drawText("Hello world!", 20,50, textPaint);

This code is in the middle of a game display loop, but for completeness, to be able to draw to the Canvas first you need:

SurfaceHolder surfaceHolder = this.getHolder();
if (surfaceHolder.getSurface().isValid()) {
    this.canvas = surfaceHolder.lockCanvas();
   ...
}

And then to release the Canvas after you’ve finished drawing:

this.surfaceHolder.unlockCanvasAndPost(this.canvas);

 

Ok, next up, what about custom TTF fonts? Drop the TTF font you want to use in your assets/fonts folder, and then load it up with:

Typeface typeFace = Typeface.createFromAsset(this.context.getAssets(), 
    "fonts/yourfont.ttf");

To use this font with the text snippet above, just call setTypeface() and pass it in:

textPaint.setTypeface(this.typeFace);

Ok, how about specifying a font size that’s proportional to the resolution of the user’s screen? This is an interesting question. To avoid using fixed pixel size fonts and then having them not scale appropriately for different devices with different screen resolutions, Android uses a concept called ‘scale independent pixels’, or SP. This is described in this post here. In short, defines an SP value in /res/values/dimens.xml/dimens.xml like:

<dimen name="scoreFontSize">20sp</dimen>

And then reference and set it like this:

int fontSize = getResources().getDimensionPixelSize(R.dimen.scoreFontSize);
textPaint.setTextSize(fontSize);

Done! (I’ll share more on what I’m working on in a few days 🙂