A few weeks ago, I was approached by an acquisition editor with Packt Publishing, asking if I might be interested in working on a book with them. Long story short, I signed the paper work and started working on the title Java 9 Blueprints. Books in Packt’s Blueprints series offer a different project in each chapter, showing each is built, explaining the technologies used, etc. So far, it feels a lot like what I aim for in my blog posts, only longer. The target release is Q1 of next year. I have a lot of work ahead of me. :)
Yesterday, the NetBeans team announced plans to move NetBeans from Oracle to Apache. This move was met by a mix of skepticism and optimism. I’ve ranged between the two myself, to be honest, but I’ve landed on optimsim.
I have a grand total of one Android application in the Play Store, Cub Tracker. It serves two functions for me: it helps me manage my sons' Cub Scout den, and it gives me a means for experimentation in the mobile realm. For the most part, it has done well for me on both counts for the past few years. I am currently faced with an issue of new functionality (which is mostly irrelevant for this discussion) that has brought up a question in the realm of experimentation. This post is a discussion of my options which will allow me to think out loud, if you will, as well as getting (I hope) some feedback on my options.
If you’ve been following my blog, you’ve probably noticed that I’ve been spending a lot of time with Kotlin of late. (For the curious, I really like it so far, but I haven’t done just a whole lot with it.) I’ve experimented with writing simple JSF and JAX-RS apps in it, largely to see if I can make it work. With those hurdles cleared, I’m trying something a bit more ambitious: a complete (if basic) Java EE application, written completely in Kotlin. Because I’m a sucker for a bad joke, I’ve dubbed the project KotlinEE. I’m not quite ready to walk through that application yet, but I what I would like to discuss now is an issue I ran into trying to get CDI working with Kotlin.
In keeping with theme of "use existing frameworks with Kotlin" and misleading titles, here’s a quick and dirty demonstration of writing JAX-RS applications using Kotlin.
There’s a chance that at least some of you saw the blog title and thought: "Ah ha! A Kotlin wrapper/helper for JSF!" and rushed over to check it out. If so, mission accomplished. :) This really isn’t anything that ambitious. Sorry. :)
At JavaOne this week, I spent a good deal of time talk to Hadi Hariri, Developer Advocacy Team Lead at JetBrains, about their Kotlin language. With my long background in Java webapps, I often reach for my webapp hammer when trying to learn a new language, so I asked Hadi what Kotlin library he would suggest. His answer, in a nutshell, was that the Java interop in Kotlin is so good, just use whatever you want, so I thought I’d put that to the test with a really simple JSF app. Here it is.
If you’re a Doctor Horrible fan, here’s something fun and goofy to start your week. No clue how they did it, but it’s hilarious. :)
(h/t to my brother)
I recently came across an interesting piece of code at work:
private static final DateFormat DATE_FORMAT = new SimpleDateFormat("yyyy-MM-dd");
What struck me as odd was the
private qualifier and that the fact that
SimpleDateFormat is not thread-safe. Is the
odd attempt to work around concurrency issues, or was thread safety just overlooked? That led me to this question: Is a
still one instance per JVM, or does the
private actually change anything? My understanding was that this was a bug, but I thought I’d
write a test just to make sure.
- Tips for Writing Pluggable Java EE Applications
- JSFTemplating and Woodstock: Component Authoring Made Easy
- Jason Lee in depth: Mojarra and Scales
- Jason Lee: Postmortem for JavaOne 2008
- International Environmental: A Cooling Company Which Prefers Hot Software
- IEC donates custom JSF component to Mojarra Scales