Tag Archives: Java/Java EE

Welcome to TheServerSide Java Symposium 2011!

Posted on by
1
I'm Speaking at TheServerSide Java Symposium Jeanne and I are both be presenting talks at TheServerSide Java Symposium this week in sunny Las Vegas! Come join us and feel free to say hello.

I’m giving a lecture Wednesday morning entitled “GWT Roundup: An Overview of Google’s Web Toolkit and Hybrid Integration” which provides a review of GWT for old and new GWT developers alike. I will also be speaking as part of a panel hosted by Cameron McKenzie on Friday afternoon called “Client Side Development Smackdown” .

Jeanne’s giving a talk on Friday afternoon called “Throw Away All The Rules. Now What Process Do You Follow?” and is about what processes are important if you aren’t being forced to follow any. It uses the CodeRanch forum conversion project as an example.

GWT 2.2 Breaks Most Plug-ins

Posted on by
3
Google Web Toolkit I often comment that the GWT API is extremely unstable, more so than most other open source projects, due to the vast number of changes in each release. When Google released GWT 2.2 a few weeks ago, the release notes implied this was a relatively minor release. After attempted to update a fairly large GWT project to 2.2, I discovered a major issue: all of the referenced GWT plugins broke and required a new version that was GWT 2.2-compatible.

The API Change – Small and Subtle

In GWT 2.2, Google changed the class library JClassType from an abstract class to an interface. On the surface, this may seem like a minor change that would not affect most developers. Java compiler experts may be aware, though, that changing the class type alters the byte code of classes that compile against this class. In other words, any JAR or library compiled prior to GWT 2.2 that references this class will be unable to be used in GWT 2.2.

The error often manifests during a GWT Production mode compilation as:

[ERROR]  Internal compiler error
java.lang.IncompatibleClassChangeError: Found interface com.google.gwt.core.ext.typeinfo.JClassType, but class was expected

The Fallout

Because of this API change, most GWT plug-in libraries must be recompiled to GWT 2.2, and the resulting JAR will not be compatible with versions of GWT older than 2.2. In my case, this affected all the plug-ins I was using.

On the plus side, many GWT plug-in developers have already noticed the issue and begun issuing new versions. For example, if you are using Ext GWT, Sencha just released a new version this morning that is compatible with GWT 2.2. Bst-player, a plug-in I have contributed to, has also been updated for GWT 2.2.

Unfortunately, Google Maps, one of the most commonly used plug-ins, has not yet been updated and is therefore not currently compatible with GWT 2.2, as described in this bug report (please “Star” this issue if you have a G-mail/Google account!). If you rely on Google Maps in your GWT application, I strongly recommend you hold off upgrading to GWT 2.2. If you refer to the ticket, a user has posted their own GWT 2.2-compiled JAR, but this is not an official release.

All or Nothing

The major problem with this update is that it forces developers to update GWT and all plug-ins at the same time. If you upgrade to GWT 2.2, you are required to update all of your plug-in libraries and if, as in the case of Google Maps, there is no such update available, then you cannot upgrade at this time. Alternatively, if you keep the older version of GWT, then you cannot upgrade any of your plug-ins since the new versions will not be compatible with versions of GWT older than 2.2.

Conclusion

When I upgraded from GWT 1 to 2.0, a much more significant process, most plug-ins still worked, albeit with some issues. The fact that the GWT 2.2 upgrade completely breaks existing plug-ins is a serious issue, one I hope Google does not repeat in the future. With any luck, this is not a sign of things to come, and Google will consider supporting existing software in the future.

I'm Speaking at TheServerSide Java Symposium Reminder: Jeanne and I are both presenting at TheServerSide Java Symposium next week. My lecture is entitled “GWT Roundup: An Overview of Google’s Web Toolkit and Hybrid Integration” and Jeanne’s presentation is called “Throw Away All The Rules. Now What Process Do You Follow?.” The conference is being held in Las Vegas and it’s not too late to register to attend.

3 plus/3 minus in WPILibj robotics library

Posted on by
Reply

WPILibJ is a library used for FIRST robotics code when programming in Java.  Helping the Stuypulse team gave me the opportunity to look at some of the code.  In honor of ship date this year, I decided to blog some thoughts on the library.  You can see the JavaDoc to follow along.

Good design point #1
The class names have strong ties to the “business.”  Class names like Joystick , DigitalInput and SpeedController are very clear and provide a mapping to a good concept.  They also encourage good object oriented code.

Good design point #2
For the most part the documentation is good and the classes logical.  Many classes have useful comments and tips on usage.

Good design point #3
There are patches released through the competition season.  Care is taken for changes to be backward compatible and not break existing code.  Much appreciated on a six week project.

Surprise #1
In the Image class, care appears to be taken for immutability (classes that cannot be changed.)  It has a package private constructor.  Only getters are provided.  The object can be written to a file, but you need to create a new object if you want to read from a file.  Then comes the surprise.  The image instance field is public!  And that public field is of type Pointer – a wrapper to native memory.   Eek.  Memory leak if you mess with it without being careful?

Surprise #2
The CANJaguar class had the biggest surprise.   When you instantiate an object, you pass the control mode.  Straightforward.  I expect the code to behave differently when different modes are passed.  Then you try to call setVoltageRampRate.  The JavaDoc clearly states what it does:

Set the maximum voltage change rate. When in percent voltage output mode, the rate at which the voltage changes can be limited to reduce current spikes. Set this to 0.0 to disable rate limiting.

Then there is what it does in reality.  If the control mode is kPercentVBus or kVoltage, a formula is used to set the ramp rate.  For the other three modes, the method does nothing.  That’s right nothing.  It doesn’t throw an exception or set it to zero or log an error or anything.  Which means you don’t realize it doesn’t do anything without reading the code.

Surprise #3
I can’t really call this a surprise as I’ve known about it since beta testing.  But I was surprised then.  Last year, there was a Dashboard class for custom output.  It was hard to use and they added a SmartDashboard class this year.  And logically, they added an interface IDashboard for the commonalities between them.  There aren’t many commonalities, but that’s not what I find surprising about the interface.

To use the old Dashboard, you write:


Dashboard d = DriverStation.getInstance().getDashboardPackerLow()
d.addXXX();

To use the new SimpleDashboard, you write:
SmartDashboard.init();
SmartDashboard.logXXX();
That’s right – the new one uses statics. This is where the interface becomes confusing. If we are calling static methods, an interface doesn’t make sense.

The worst bug
The worst bug we encountered wasn’t actually in the WPILib code.  It was in the underlying National Instruments code and affected all three wrapper APIs (Java, C++ and LabView.)  The Encoder class works in an illogical manner. In particular, it only lets you use the first, third, fifth and eighth encoders to get the rate of movement.  (No, that isn’t a typo.  It is a seemingly random collection of orders rather than every other.)  That’s if you are in one mode.  In another mode, the working encoders change.  We have to fool the low level code by creating dummy ones to the “real” encoders get the proper constructor call ordering.  While this was documented on chief delphi (the unofficial FIRST robotics forums), we wasted a lot of time assuming we were doing something wrong.

Conclusion
The longer text for the surprises doesn’t mean that the code is bad.  Just that there is more to write about unexpected things. All in all, I appreciate all the API gives us. Congratulations to team #694 (Stuypulse) on a great build season and for completing an awesome robot on time!