Nicholas Hagen

Generics is one of the more prominent features from JDK 5 that allows you to basically specify the type as a parameter. For example, in JDK 1.4, a List was always a List of Objects. If you wanted to get something out of the list, you had to cast it. JDK 5 helped to resolve this to a degree by specifying the type. For example, you could create a List to specify that the List will contain User objects. However, this is really just syntactic sugar. For those familiar with C++, C++ has templates. However, there is a big difference between C++ and Java. C++ generics are runtime based such that List<User> is different from List<Address>. However, in Java, those two expressions are essentially the same. The reason for this is that Java uses a concept referred to as type erasure at compile time. Thus, at runtime, types do not exist (this is semi-misleading, so more on this in a bit). Type erasure was done to offer backwards compatibility with older libraries. This allowed a JDK 5 application to use a JDK 1.4 library and vice-versa without having to update every library. One of the powers of Java is in the availability of external libraries, so Java did not want to lose that.
(more…)

One of the features of HTTP that is widely used, yet strangely a hack, is the User-Agent header. Several sites and servers use the agent to detect a browser’s capabilities. For example, a site may attempt to detect IE browsers to handle custom stylesheets or javascript. A more traditional approach as of late is detecting mobile browsers to handle content and layout properly. However, in any of these cases, this is really just a kludge IMO. The user agent header was more or less just a descriptive way of telling a server what it was. With the future of the web moving along with the likes of HTML5, CSS3, JS.next, etc, I think it is about time we update the HTTP protocol as well.

I propose we add one or more feature headers that list the supported features of a device. CSS3 somewhat has this with media queries, but it only applies to CSS. Javascript, via the DOM, has the ability to query features as well to some degree. There really is no way to do it across the board consistently and no way to detect from the server side or even through a router or proxy.
(more…)

One of the areas I have dug into lately is around code generation and class file manipulation. It’s actually quite amazing how much you learn and understand when you begin to understand what the JVM is doing and how class files are constructed. Even though on a day-by-day basis, class generation is rarely used, it really buys you a great appreciation and I heavily suggest digging into it, even if only a little. I have a much better idea of how various code will affect the JVM in terms of performance and handling. There are a few ways which you can generate byte code at runtime, of which only a few I will touch on. Click to keep reading for my synopsis.
(more…)

I recently decided to sit down and play with jQuery Mobile and absolutely fell in love with it. I’ve been designing web applications for years, but the pure simplicity in jQuery Mobile is absolutely amazing. The one part I’ve never been good at is graphics with respect to web design. jQuery Mobile removes that requirement and allows me to focus purely on semantics, which is what the web is all about anyways. The end result is jQuery Mobile themes the semantics according to the end platform. Further, the work of ensuring the site renders appropriately in various end devices is automatically accounted for. jQuery Mobile scales from iPhone to iPad to Blackberry to Android and back again. My hat goes off to the work put forth by the jQuery Mobile team. But enough of the praise…let’s get to what and how I did with a step by step guide…click to read more.
(more…)

One of the biggest problems I see with the web today is the ability to stream data. In the early years it was all done by polling which results in slower data retrieval and constant up and down connections which are expensive. Then, flash and java-based applets came to the scene and provided raw TCP/IP connections. However, that solution required plugins, which are also frowned upon. New strategies emerged referred to as long-lasting HTTP connections that did not require plugins. Essentially, the HTTP session would stay open until the server had data to provide it and then would respond. This, in a sense, provided live streaming data, but at the cost of opening and tearing down connections. For example, if a single message was destined for every connected client, they would all disconnect and re-connect at the same time causing massive connections to the server. Last but not least, websockets were introduced. Websockets allowed an HTTP session to be upgraded to a bidirectional streamed session that would never close and allow messages to be sent back and forth during the duration of the session. However, that session would close once the user left the page. As a result, companies wanting to employ standards based bi-directional streamed technologies via WebSockets had to typically employ one of the following systems:

1. Use AJAX to turn every link into an AJAX link so that the content just got refreshed without navigating away from the page. This results in complicated backend javascript, difficult bookmarkability control, etc.
2. Use frames so that part of the page was in a frame that never changed while the content was a separate frame. This results in no bookmarkability since the URL of the frameset never changes.
3. Just deal with the up and down connections and use routers or other backend hardward to better manage the connections.

As a result, we still have no efficient way to manage bi-directional systems. Even using flash or java does not help as you have to tear down and re-establish the connection with each page view. Below is my request to establish such a technology.

First, I would continue to use the WebSockets technology as I think it has its place. I would just add support on the browser side to keep the connection alive across requests. In order to do this, each page would need to request the same base URL. If the browser notices that the base URL is the same and an existing connection to the URL exists, it would just re-join the connection. If not, it would first establish it. There would be an API to join the connection as well as a different API to always establish a new connection (in case pages wanted a new connection different from an existing one). The browser would need to establish some type of timeout so that if javascript did not invoke a request to re-join a connection once the page loaded, then it would kill the previous connection. Otherwise, connections would be left open and resources leaked in the browser. Further, the browser would require an XML file on the server for security reasons. This would be similar to a crossdomain.xml file but would tell the browser which hosts are allowed to keep a connection alive. When a link is clicked and navigated to, the browser would check if the host matches a host in the XML file. If so, it would keep that connection open until the next page requested to join the connection. There is obviously much more to this that would need to be thought out, protected against, etc. But I believe it is a start to something that would create more dynamic apps.

The best part of this request is that it is based on open standards per WebSockets and only requires browser interaction (not new servlet strategies or other strategies on the server-side). This request would greatly simplify a lot of existing code out there.

Let me know what you think. If we can get some backing around this idea, hopefully browser vendors will take off with it and get the WHATWG or W3C to investigate.

Thanks,
Nick

Two of the libraries I’m most interested in lately are Grails and CDI/JSR299 (Weld being the implementation). The problem is that the two are really not compatible directly with each other. First, CDI is a JavaEE6 technology requiring a compliant container (ie: Glassfishv3) whereas Grails can run in any servlet container (plain ol’ WAR). Second, Grails uses Spring for its dependency injection system which does not really support CDI. However, in an ideal world, it would be nice to mix them as CDI makes a great backend framework while Grails makes a great frontend framework. So, what do we do to make these co-exist?

(more…)

NOTE: Documentation and code presented here is based on living and changing documentation by the JSR committee and subject to change causing this article to be inaccurate or outdated. I am also not affiliated with the JSR or its members.

This blog article is probably a bit premature being it is centered around JDK 8, but I think it is interesting enough to cover when planning new frameworks. JDK 8 is not being planned for release until late 2012. Anyways, bare with me. One of my favorite expected features is around Project Lambda (http://openjdk.java.net/projects/lambda/). Project lambda is all about adding “closures” or “lambda expressions” to the Java language. Many people know about closures from several other languages (C#, Ruby, Groovy, etc), but not many know about how Java plans to implement them. The mechanism Java has selected to use has some interesting caveats and useful features.

(more…)

One of my favorite paid applications on the iPhone is Beejive. It is a standard IM client for several IM services including MSN, Jabber/Google Talk, Yahoo, etc. Despite it being $10, it was my best $10 invested. It has allowed me to remove the $5+ dollars a month of text messaging (since all my friends have IM on their phones as well), so it paid for itself in 2 short months. I recognize there are all sorts of free options, but none of them work as effectively as Beejive. Beejive is more stable, more features, better support, and looks just so much nicer.

Anyways, one of the features I really wanted was multiple sign-on support for MSN/Windows Live (otherwise known as multiple points of presence). I hate having to login to MSN from my desktop and then remember to login from my phone once I leave. I would much rather just leave both on and have it send messages to both depending where I am. Jabber/Google Talk has had this feature for a while, which has been great. That being said, this week they finally rolled out that feature for MSN. I’m not sure too many other clients for MSN/Windows Live supports this, which furthers my investment of $10 being worth it.

My recommendation is to try Beejive out. It definitely has a great feature set and is much better for IM than SMS/MMS is.

Steve Souders recently published his State of Performance for the web for 2010. This is a well written state of where we have been in improving and capitalizing on performance of web applications and web sites in general. It also goes into plans and hopes for 2011. I personally am excited about the continual progression towards web performance. It is finally becoming a reality that performance does indeed make a difference, generate revenue, and increase traffic flow. Not only does it matter on the backend technologies (databases, architecture, SOA, JSON, etc), but it also matters heavily on the frontend side. I heavily recommend reading this article as well as following Steve Souders blog.

Thanks and remember that performance matters!

So, I’ve been intending on writing this silly article for awhile, but have not got around to it until today. Anyways, every time I hear someone mention a new language and then look into it, the first thing I notice is how they print the standard “Hello World” statement to the screen. After the first few times, I just put it aside and ignored it. But then I started noticing a more annoying trend: nearly every language uses a new verb to express “Hello World” (I’m convinced developers are doing this on purpose now). So, my question is: how many ways can we say “Hello World”? For once, it would be nice if we had some consistency and languages used the same verbs for similar practices. If I had a dime for every time I picked the wrong verb because of switching to a different language, I could probably quit my job. Switching in and out of languages now is a daily part of any Software Developer’s job. No one language works for every situation. You should always pick the language to do the best job (but that’s another article for another time). Plus, printing to the screen is not the only inconsistency we have. Simple things like trimming (chop, trim, etc) or taking a substring (sub, substr, substring, etc) have several variants. It really gets annoying as you learn more and more languages. I’m not saying languages should not have their differences; obviously they should. That is what makes them unique and powerful in their own ways. All I’m saying is for things as simple and common as printing to the screen, let’s all agree on a standard verb. Please! :)

Anyways, that being said, here is my list I have been compiling. Drop me a comment if you can think of others and I will update the list accordingly. It would be interesting to see just how many ways we can truly say “Hello World”!