1. java.lang.intrument

    För oss som gillar (eller snarare behöver) att fippla med bytekod så finns sedan Java SE 5.0 API:et java.lang.instrument. Med detta API kan man relativt smärtfritt koppla in en bytekodstransformator på klassladdaren för att instrumentera/transformera bytekoden för utvalda klasser. I kombination med t.ex. ett API för bytekodstransformation (t.ex. ASM eller BCEL) kan man göra mycket skoj t.ex. mätning av kodtäckning eller loggning.

  2. Fun and easy 3D in Java!

    Ever since I ran across Povray in the early nineties I’ve been a sucker for all aspects of 3D computer graphics. I loved playing around with 3D-modellers such as 3D Studio MAX, Maya or Blender (to name a few), trying to create my own 3D renderer from scratch (with a very poor result), experimenting with a wide range of 3D-engines, tried DirectX in both C++ and C# (Managed DirectX in C# is really quite nice, compared to the old-school C++ approach) and OpenGL in MANY different languages (including Scheme). However, since my skills in creating anything visually pleasing is comparable to a 3-year-old boy with crayons, the only area within the 3D computer graphics domain I can be productive in is ”pure” 3D programming in DirectX or OpenGL and rely on the 3D models available from the web (also, my color blindness has proved to be somewhat of an issue with results varying from simply weird to ”ouch, my eyes hurts!”).

    Anyone who ever tried to learn 3D programming in any other language than Java or C# are aware of how much effort you have to put in to simply displaying an empty window. On top of that comes the fairly complex way of managing all related data structures (vertices, vectors, matrices etc.). For me, this was the major reason I never got further than creating simple 3D demos (e.g., rotating cubes etc.). It wasn’t so much due to OpenGL but rather the language I used. The amount of work required took the fun out of the task.

    Imagine my anticipation when I first came across JOGL. I love developing in Java since it is so easy to work with. Setting up an OpenGL window was a piece of cake and creating a set of small utility-classes for managing matrices, vectors and vertices proved much more simple in Java than in C++. With the very nice user-input handing (KeyListener, MouseListener, MouseMotionListener etc.) in Java, creating interactive application with JOGL were a no-brainer.

    This was back in 2003. Now, in 2007, JOGL has its own finalized JSR (JSR-231) and an updated version (JOGL 1.1) will soon be available. A visit to jogl.dev.java.net shows a bunch of ready-to-use applications built on-top of JOGL, and jogl-demos.dev.java.net contains a long list of examples of visually stunning examples for those who still doubt that OpenGL on Java is as good as OpenGL in C++ or any other native programming language. FPS-fans can now run the Java port of Quake2, Jake2, from any machine supporting JOGL using Java Web Start (i.e., click’n'play). With the release of Java 6 and all the cool desktop-features, we can finally create 3D applications that are both useful and looks cool. The embedded version of OpenGL (OpenGL ES) has its own JSR started and will hopefully deliver hardware accelerated support for Java ME (both CLDC 1 and 1.1).
    Some of the things I think (or rather hope) we will see during 2007 regarding JOGL:

    • Java-based Google Earth? I bet someone at Google is already working on this…
    • Real, working examples of applications with 3D interfaces. Increased research in Human-Computer Interaction with 3D user-interfaces.
    • JOGL (and Java) support on Playstation (2 and 3), Wii and XBox 360 (ok, the last one is probably hoping to much.. ;). I know this is a bit of a stretch to hope for this, but it would be cool to be able to write your own games for these platforms (Playstation already has Linux-support so that one shouldn’t be an issue really). :)
    • Tons and tons of really cool 3D games in Java…

    Getting sick and tired of all frameworks, toolkits and APIs for developing ”state-of-the-art” AJAX-enabled, enterprise applications using *insert name of framework here*? Having nightmares about JavaScript, OR-mappings and aspects? Have you read the words Spring so many times lately that it left a scar on your retina? Try something completely different; OpenGL development in Java. :)

    There are many tutorials, demos and examples to get started with JOGL and if you prefer books you can find many good ones with a simple search on Amazon (I’m listing a bunch of resource to get you started below). I truly hope that more developers, both from the Java-community and from the gaming-industry, will discover how fantastic JOGL really is. For those of you living in Sweden I recommend visiting jFokus in Stockholm (January 30th) or JavaForum in Gothenburg (Februari 7th) to see my presentation ”JOGL and friends”. So come on everyone! Lets help make Java on the desktop really cool this year!

    Recommended JOGL-related links:

    • JOGL API Project – The main page for JOGL.
    • JOGL Demos – Cool demonstrations and examples in JOGL.
    • Xith 3D – A very nice scene graph and game middleware using JOGL.
    • Javagaming.org – Nice community and forum for Java game developers.
    • Foundations of 3D Graphics Programming: Using JOGL and Java3D – A very nice starter book for those interested in OpenGL development in Java.
    • Practical Java Game Programming – A little outdated by still a very good book on general game development in Java.
    • NeHe OpenGL tutorials – In my opinion, the best tutorial on OpenGL available on the net. The code in the tutorial is in C, but since the method calls in JOGL are basically the same it is still very useful.
    • OpenGL.org – The main site for everything related to OpenGL.
    • Shwup – A very cool P2P application for sharing picture that uses JOGL for rendering.
    • Jake2 – The Java port of Quake 2 from ID Software. Available as a Java Web Start application.

  3. Be True

    You can see it in their dull glaze- developers facing the details of a complicated web interface. Breadcrumbs. Form redirects. Sort columns. Synchronizing back/forward button. Uploads. 10 ways to do ”basically the same thing”. Bookmarks. i18n… and then there is the application to code, they mumble.
    There are many good reasons and rationale one should abide by when deciding on a presentation technology for a web application. Or at least I am sure there are. I just picked Spring MVC for a little e-shop I did for my wife because I wanted to play with it. Fortunately for her it all turned out well, and I can fill in the back-story.

    A rule of thumb I like to follow is to try to stay true to the core business and core technology. Just as a UI designer describes interactions which best fit the type of application being built, a software architect/designer could pick technologies which align well with the application platform. If I am developing an HTTP based web application then I may pick a presentation tier technology that fits well with the HTTP request / response paradigm. I have found that technologies which disguise their core implementation or try to generalize themselves into a broader classification tend to irritate me with limitations down the road.

    Back to Spring MVC.. The name betrays its rather clean implementation of servlet based request dispatch. You can choose from several different types of ”controllers”, from basic Get functionality to one supporting a more complex multi-page form post (wizard). The Model and View aspects of a web MVC pattern are abstracted out a bit more in Spring MVC, with POJIs and technology specific implementations. The Controller is the key here and Spring MVC gives you enough rope..

    Controller: ”We have a special guest, I will show them something fancy.”
    Model: ”You are always trying to get involved in my business. Its me they really want to see.”

    I liked how Spring MVC helps deal with the presentation issues I mentioned at the start- it seems to stay true to the technology, not trying to extend out into new territories (that would be Spring WebFlow).

    Spring MVC is covered nicely on the Springframework site, but there was not much describing it’s integration with Struts Tiles. So a few little details which may help someone. Three steps will get you there:

    1) Include your dependencies
        *     Struts version 1.1 or higher
        *     Commons BeanUtils
        *     Commons Digester
        *     Commons Lang
        *     Commons Logging

    2) Point to your Tiles config files through the Spring configuration of a TilesConfigurer. This includes a property for the factoryClass used (standard Tiles org.apache.struts.tiles.xmlDefinition.I18nFactorySet default).

    3) Select a ViewResolver which can recognize the Tiles configuration. Configure the InternalResourceViewResolver with the supplied Spring view class TilesView. This will resolve the String name from a controller into a matching Tiles definition name found in your Tiles config file.

    If you need your controller to redirect or forward to another controller and not a view, Spring MVC lets you put the keywords ”redirect:” or ”forward:” in front of the view name. If you inject the view names into the controllers, you gain some reuse with your controllers, leaving the flow of the application (either to a tiles view or another controller) specified clearly in the MVC application context configuration file.