Eric Bruno originally posted this on Dr.Dobb's Journal | Eric Bruno Blog.

My friend and co-author, Jim Connors, posted a recent blog entry about his early opinion of the upcoming new JavaFX 2.0. In summary, JavaFX 2.0 will provide a universal Java API accessible from any JVM-supported language (i.e. Java, JRuby, Groovy, Scala, and so on), and will no longer support JavaFX Script.

Other benefits to this move are improved performance (especially with the new Prism graphics engine), Swing interoperability, and a better development and debugging environment.

You can read more about the new JavaFX 2.0 roadmap here.

jonr originally posted this on Jon Rose's Blog.

I thought I would post a holiday treat.  I’ve been hard at work on “FlexMonkey Reloaded.”  It should be out there for use soon.  Here is a screen shot:

admin originally posted this on Saturnboy.

I’ve been writing a lot of Java lately, and a lot of tests. We always write tests, right? Alas, no cool record-and-playback stuff like FlexMonkey or FoneMonkey, just plain old JUnit 4 tests with plently of Hamcrest goodness.

Suddenly, I realized that I really needed to test some private methods. So, a quick google for “testing private methods java” brings up a good article by Bill Venners. He lists all possible options to test private methods:

1. Don’t test private methods
2. Give the methods package access
3. Use a nested test class
4. Use reflection

Basically, the only real one is #4, use reflection. Bill didn’t give me the exact code I needed, so lots of googling later I realized that the world is filled with opinionated people (like me), and boy do they love to talk about #1. I just wanted some code, not a lecture, so I had to write my own code. Here is that code for anyone else that just wants to test private methods.

Imagine you have a class MyClass and it has a private method, myMethod(). Sorta like this:

public class MyClass {
    private String myMethod(String s) {
        return s;
    }
}

Then you could use reflection to invoke the method like this:

MyClass myClass = new MyClass();
Method method = MyClass.class.getDeclaredMethod("myMethod", String.class);
method.setAccessible(true);
String output = (String) method.invoke(myClass, "some input");

The real magic is setAccessible(true) which allows the private method to be called outside the class. And shazam, I can now test all my private methods. I was really hoping JUnit 4 would provide some additional facilities specifically for testing private methods, but not luck.

A Better Example

Here’s a more complete example. Suppose we have a NovelWriter class that in a feat of API cleanliness only exposes the writeNovel() method. It happens to have a few private utility methods that we’d like to test:

public class NovelWriter {
    public String writeNovel() {
        //...the magic goes here...
        return null;
    }
 
    private String shout(String s) {
        return s.toUpperCase().replaceAll("\\.", "!");
    }
 
    private List<Integer> countLetters(List<String> words) {
        List<Integer> out = new ArrayList<Integer>();
        for (String word : words) {
            out.add( word.replaceAll("[^A-Za-z]+","").length() );
        }
        return out;
    }
}

I won’t get into all the details, but it seems easy to imagine a clean API that has private helper methods. Furthermore, it seems very logical to me to want to bring all methods, both public and private, so I can be sure they are being exercised to the fullest.

Our JUnit 4 + Hamcrest test class:

public class NovelWriterTest {
    public static NovelWriter novelWriter;
 
    @BeforeClass
    public static void beforeClass() {
        novelWriter = new NovelWriter();
    }
 
    @Test
    public void privateShout() throws NoSuchMethodException,
            InvocationTargetException, IllegalAccessException {
 
        String input = "This is magic.";
 
        Method method = NovelWriter.class.getDeclaredMethod("shout", String.class);
        method.setAccessible(true);
        String output = (String) method.invoke(novelWriter, input);
 
        assertThat(output, notNullValue());
        assertThat(output, is("THIS IS MAGIC!"));
    }
 
    @Test
    @SuppressWarnings("unchecked")
    public void privateCountLetters() throws NoSuchMethodException,
            InvocationTargetException, IllegalAccessException {
 
        List<String> input = Arrays.asList("Foo", "Foobar123", "Foo Bar Baz");
 
        Method method = NovelWriter.class.getDeclaredMethod("countLetters", List.class);
        method.setAccessible(true);
        List<Integer> output = (List<Integer>) method.invoke(novelWriter, input);
 
        assertThat(output, notNullValue());
        assertThat(output.size(), is(3));
        assertThat(output, hasItems(3, 6, 9));
    }
}

The nice thing about using the Reflection API like this is that it really doesn’t get too messy. I’m not inspecting anything at runtime, because I know exactly the return type and the types of all the parameters. I’m just invoking the method with known inputs, followed by a simple cast on the output type. And as you can see in the second test above, privateCountLetters(), it’s not a problem to use generics because we’re not doing any inspection only invocation.

Happy testing.

Files

• novel.tgz – download the complete Eclipse project

Stu Stern originally posted this on Big Gorilla - Stu Stern's Blog.

Eric Bruno originally posted this on Dr.Dobb's Journal | Eric Bruno Blog.

According to AppleInsider.com, Apple and Oracle have formed a partnership to ensure future versions of Java will be available on the Mac OS X platform. Apple has agreed to contribute the JVM code for the Apple platform to the OpenJDK project, and Oracle has committed to producing timely Java releases for the OS X platform going forward.

admin originally posted this on Eldorado Software.

.jar *, and substitute your new trinidad jar.


There are posts related to this, and the problem seems to have been thought to have been fixed previously:

TRINIDAD-1349:_uixLocaleTZ stores the timezone offset of the server at
* the time the page was displayed (Current time), and currentDateTZOffset
* is the timezone offset of client at the current time as well. However,
* the timezone offsets for both client and server can differ for the
* date that was picked due to daylight savings rules. For example, the
* current time is 3 Dec 2008 and the server is in PST (UTC -8) and
* client is in Perth (AWDT, UTC + 9) so the difference is 17h. But if
* the user picks Apr 25, the server is actually in PDT then (UTC-7) and
* the client in AWST (UTC +8) so the difference is actually 15h. The original
* code would subtract 17h, which would cause the resulting date to move
* to the previous day. *

Eric Bruno originally posted this on Dr.Dobb's Journal | Eric Bruno Blog.

Oracle is planning to continue Java development in, primarily, the open through the OpenJDK. However, there are quite a few features planned to remain proprietary, and the code for them will not be contributed to open source. For instance, according to Oracle's Henrik Stahl, aspects of Java such as Java for Business, Oracle's JRockit Mission Control, JRockit Real-time, and JRockit Virtual Edition will be proprietary add-ons that you'll have to pay to use.

This isn't a shock to me. Remember that Oracle owns Java now, and they have the right to do with their IP as they please. I wouldn't be surprised to see other new features, such as advanced garbage collection and other performance improvements, become part of the proprietary Java version in the future also.

On a positive note, Stahl mentions that Oracle estimates that code from JRockit will be the single largest contribution to OpenJDK since its inception. That's a lot of otherwise closed/proprietary code to become open-source. That's a big step for Oracle, in my opinion.

Happy Coding!
-Eric

admin originally posted this on Saturnboy.

Back in December 2009, I had the amazing opportunity to teach for a whole week at Boulder Digital Works. BDW had just started that fall and the first class of 12 students¹ was just getting started on a 60-week program.

Teaching was a ton of fun! We wrote some PHP code together and everyone was able to experience a little slice of the joy/hell that is development. We also did a lot of talking, which was fun, too. Since most of the class was non-technical, we didn’t geek out technology stuff, instead we spent a lot of time talking about meta-development. We talked about process, how developers think, how development fits into digital, what it means to actually build something real, etc. I found the whole thing to be very cathartic, having 12 smart people listening to me and participating in a fun discussion was just awesome.

To Be Great

One of the more interesting topics I discussed during class was how to be a great developer. I spend a lot of my time and brainpower thinking about what I can do to be better. That’s the mountaintop, but it’s always a long way away.

Some options for improvement are external but many are internal. For example, I’m always asking myself: Who knows something that I want to know? Who can I model? What can I borrow from those around me? Who can I mentor? Who should I ask to mentor me? What should I learn next? What should I forget? What can I read? Do I need to change my approach? What is today’s definition of value?

I always think my kung-fu is strong, but I’m not a master. So here’s a quick summary of the components of greatness as I see them today. Please feel free to ignore everything as you see fit.

Undying Hunger

If you have the hunger to be better then you’re always on the upslope. And this isn’t the vanilla-level hunger of “Hey, there’s more I could learn.” This is the full on, I’m-starving-more-is-never-enough hunger.

Once upon a time, back when I was a young lad of 10 or so, there was a series of TV commercials asking “Do you see the glass half full or half empty? Blah blah blah” After the hundredth viewing, I turned to my dad and said, “Dad, I see it as not enough! What does that make me?” And in his infinite wisdom, my dad replied, “That makes you a hog!” – which is an apt description without a doubt.

To be great, you need to be a hog.

Effort

Where hunger is internal, effort is external. Where hunger is mostly mental, effort is mostly physical. Effort is all about doing the work, expending the energy, getting really tired, waking up the next day, and doing it all over again. There is an obvious correlation between hunger and effort, but it’s definitely not one of causation. I fully control my decision to turn off the TV and pick up a book or sling some code.

The best thing about effort is that it’s just a switch, and I truly believe that. You can decide for yourself to turn it on any time you want. And with the right carrot, you can even flip the switch on for someone else. In my many years of coaching frisbee, I have repeatedly witnessed the switch being flipped. People can be taught to work hard, but it’s a heck of a lot easier when they are on a team of hard workers.

Unfortunately for me, the effort switch is more of a dimmer switch then an on-off switch. Burning bright and bringing a high level of effort for an extended period of time is hard. Motivation naturally ebbs and flows, and it’s challenging to maintain it. The best solution I’ve found to keep motivation high is to find a partner in crime. When there’s someone else to work with and compete against, it’s much easier to work hard. When I’m on my own, the only trick I have is to maximize variety, some days I work hard by doing some extra reading, some days it’s writing, some days it’s hacking, etc.

Effort in athletics is pretty easy to recognize. It’s spending time in the weight room during the off-season and out-hustling the other guy during the game. Effort in development is a little harder to figure out. Some of my typical outside-of-work adventures include reading (books, blogs), writing (this blog, the occasional article), speaking (local user group), teaching (BDW), and lots of side projects (contribute to open source, silly iPhone apps). There are also quite a few at-work hustle opportunities: you can give a brown bag talk, you can mentor others, and you can be a good mentee (basically you need find someone who knows something you want to know and beg them to teach you). But my favorite thing to do at work is find a like-minded peer and inspire them to work hard. You can do this by co-reading, co-writing, co-speaking, pair programming, etc.

To be great, you must work hard, constantly.

Creative & Pedantic

Unfortunately, no matter how hungry you are or how hard you work, you must also be creative to be a great programmer. Without creativity, you will forever be a cog in the machine. You might be the best cog ever, but you are a cog none the less. In Hackers & Painters², Paul Graham talks a lot about the creative nature of software construction. Hackers, painters, architects, and writers are all makers in Paul’s world, and he spends quite a bit of prose comparing them.

I really like Paul’s take on the process of construction, and the different disciplines that practice it, but I try to take a more practical view. To me, creativity is nothing more than a measure of one’s ability to escape the box. I see it as just another skill that can be learned, practiced, and improved. Over time, you can learn to recognize the box faster and more fully. The more boxes you see, and solve, the more solution patterns you will remember. Eventually, you will develop a toolbox of escape tactics.

Again, it’s still not enough. No amount of creativity will help you actually implement a solution to any given box. There are a lot of details that are critically important to the construction process. Paul Graham writes, “In both painting and hacking there are some tasks that are terrifyingly ambitious, and others that are comfortingly routine.” Much like Superman has Bizarro, the creativity has pedanticalness (yes that’s a word). Many of the routine tasks in programming are routine to the point of being tedious.

I often liken the pedantic aspect of development to licking envelopes. It’s easy, but yuck! Who actually likes the taste of envelopes? If you don’t do it right, then don’t be surprised if you mail explodes while in transit. In my experience, there are a multitude of development tasks that taste a heck of a lot like envelope glue, but you don’t really have much choice. You can either do them the right way, or watch them explode.

To be great, you must embrace both the creative side of development and the pedantic side.

Ego

The number one, most important, aspect of greatness is ego. The truth of development is that not everything goes your way. And even when it does, it can be exceedingly difficult. For all those times when you are tumbling down the mountain, you need a certain amount of ego to arrest your fall and start upwards again. I’ve actually spent time and effort into stroking my own ego for this simple reason: you learn more when you lose than when you win.

I heard a pretty amazing football stat the other day. In 9 of the last 10 seasons in the NFL, at least one last place division team fought their way to first place in their division the following year. Most recently, the Saints finished 8-8 in 2008 and were in last place in the NFC South. In 2009, they won their division at 13-3 and went on to win the Superbowl. Why? Because you learn more when you lose than when you win. Fact.

The mud is a great teacher. But you must have a certain level of mental fortitude to climb out and get clean again. To me ego is just that – confidence in yourself and your ability, lack of fear, and a basic mental toughness. I’ll go willingly into the mud to take on a difficult problem or learn a new language (or maybe a new API instead of another language). And if I get thrown into the mud unexpectedly, which happens all the time in consulting, there won’t be any fear or panic.

Do I get dirty? Hell yes. Does it stink? Of course. Having confidence in yourself and believing in your abilities doesn’t magically transform the metaphoric mud into flowers, it’s still mud.

To be great, you must be confident and fearless.

Conclusion

It’s hard to know what you don’t know. In fact, it’s really damn hard. But I don’t find it discouraging in the least to know the code I write today is going to suck compared to the code I write tomorrow. That’s called progress.

I feel good when I focus on what I do know. I know I want to be the best dad I can be, the best husband I can be, and the best developer I can be. And today, that means this:

• undying hunger — more is never enough
• effort — constantly work hard
• creative & pedantic — embrace both sides, writing elegant algorithms and head-pounding debugging
• ego — be confident in yourself

So stay hungry, work your ass off, lick your envelopes, and welcome the mud at every opportunity. Good luck.

“And whenever men and women straighten their backs up, they are going somewhere, because a man can’t ride your back unless it is bent.” — Martin Luther King, Jr ³

Footnotes

1. I’d like to thank BDW’s First 12 for listening to a crazy opinionated developer. @botvinick, @kygalle, @dasn101, @tetonmarketing, @jefferyjake, @justinmccammon, @rosErin, @JadedSkipping, @hseal, @tegoenfuego, @dviens, @ndubsglobal
2. Hackers & Painters by Paul Graham
3. I’ve Been to the Mountaintop by Martin Luther King, Jr. This speech was given on April 3, 1968.

Stu Stern originally posted this on Big Gorilla - Stu Stern's Blog.

Stu Stern originally posted this on Big Gorilla - Stu Stern's Blog.