Eclipse e4 M4 has introduce a new look and feel for the tabs in the workbench. See Eclipse e4 M4 New and Noteworthy. Unfortunately the news and noteworthy document did not give information how to enable this feature.

The e4 mailing list has recently discussed this topic and Remy Suen was kind enough to provide this information. To turn this feature on you have to add the tag “newtablook” to your PartStack.

For example if you create an new e4 application with the e4 wizard you can add this tag via:

<children xsi:type="application:PartSashContainer" xmi:id="_vTa8kiuFEd-PeMLywHTM-g" id="_vTa8kiuFEd-PeMLywHTM-g">
  <children xsi:type="application:PartStack" xmi:id="_vTa8kyuFEd-PeMLywHTM-g" id="_vTa8kyuFEd-PeMLywHTM-g">
     <tags>newtablook</tags>
   <children xsi:type="application:Part" xmi:id="_vTa8lCuFEd-PeMLywHTM-g" id="_vTa8lCuFEd-PeMLywHTM-g" label="Main"/>
</children>

This lead to the following result:

Compared to the “old” look and feel.

For this topic see also Bug 305147 which discusses to move this feature to the CSS styling capabilities.

 

Based on my tutorial website I frequently receive questions from users. Some are very nice, precise, encouraging and some are of perceived bad quality. I also ask lot of questions in the Eclipse community and I try to ask good questions. Of course I frequently fail to ask good questions but at least I try.

So what makes a question, a good or even an excellent question?

I personally believe the following rules are a good guideline:

10 Golden Rules

1. Don’t be rude
2. Try to be as precise and as short as possible
3. Do your homework before asking (Google, search newgroups, read tutorials,…)
4. Try to ask one question at the time
5. Proof-read your question after writing it
6. Don’t expect others to do your work
7. Avoid private email if other channels exists
8. Remind yourself that people help you voluntary
9. Read and follow up on suggestions
10. If you get a solution let others know

What do you think? Did I miss an important point?

For a detailed discussion of how to ask good questions see How to ask smart questions.

 

I’m not very enthusiastic about Microsoft, mostly because they have been a copy cat for decades. But before Microsoft started with Windows, they’ve produced programming languages and were respected by many. I came into contact with Microsoft when playing with AmigaBasic which was build by Microsoft. Understanding BASIC on a VC20 was hard, I had [...]

Since recently I try to deliver presentation with more visual effects based on the Presentation Zen approach. Of course one of the problems is to find nice pictures.

I’m aware of the following sites:

• stock.xchng
• Flickr

Thanks to Florian Heidenreich for pointing stock.xchng out to me in Twittter.

If you select images from these sites make sure to check the usage license, some may require permission from the author, others may ask you to give credit to the author, etc. Also make sure to give the author credit for his work in any case. A common approach to give credit to the author is to add a slide to the presentation which lists the URL of the pictures.

I personally really liked stock.xchng; it made it easy to find beautiful pictures which have a very permissive licenses. My first impression from Flickr was not as amazing; there are simple to many pictures to select from. Peter Friese pointed out a program ViewFinder for the Mac but I have not yet tried that.

The major pay site with beautiful artwork is istockphoto. Really great images but you have to pay for them.

If you know other web sites for nice pictures please let me know. Or perhaps you want to share your tricks how to select good images at Flickr.

 

San Francisco Java User Group presents Kohsuke Kawaguchi from Sun who introduces us to Hudson, an open-source continuous integration (CI) system, which improves the productivity of a development team by automating various things. Additional resources: Hudson Blog Continuous Integration: The Cornerstone of a Great Shop Continuous Integration Tools Directory

OSGi focusses on modularity and it is right now (future may change it) the only viable way to split your application into modules with well-defined dependencies. It solves, however, "only" the technical problem - which is actually relatively easy. Before you going to introduce OSGi into your project, answer the following questions:

1. What is your versioning scheme for modules(bundles)? Do you care about minor versions, major versions etc?
2. Whats your scm strategy - do you plan to open and maintain a branch for every version of a module? How many branches do you plan to maintain? (with svn? :-))
3. How many versioned modules will be active at the same time in production?
4. How the system is going to be tested? Each module and all the combination of modules. Every version will increase the complexity significantly.
5. What is your release-management strategy? Do you really plan to provide customer-specific module combinations? What is your bug-fixing / patch strategy (trunk, branch)?
6. Do you really want to replace modules in running system? If it is a serverside system - what happens with in-flight transactions?
7. If it is an Eclipse-RCP application - are you even allowed to expose the plugins to the end-user? (in the majority of my projects, we had to disable the update manager in production :-))
8. What is your software distribution system - many companies have already a software-distribution system in place. Often not only the application, but also the JVM are packaged into one binary file and entirely installed. Incremental updates are often impossible.
9. What is exactly the contract between the modules? Only a Java-Interface? If so - what to do with direct relations between JPA-entities. If you disallow direct JPA-relations - you will probably see a huge "domain" package with all domain objects inside it. You will need to provide "friend" relations between modules as well.
10. Is maven the canonical representation of modules, OSGi, or both? A single representation would be the best. Will maven module versions be reflected in the OSGi bundle versions?

The major OSGi-challenge is not the technology, rather than the governance of your modules and bundles. The problem is very similar to SOA.

For most enterprise applications you will get only one variant of your business logic, or even UI - so you will end up with modules, which will probably never be replaced. Because of additional complexity - you will probably test and deliver the whole system at once.

If you are building an IDE, platform or a server - governance, modularization and versioning are a major part of your problem domain / functional requirements. You will have to solve that anyway. It is far more likely, that someone will have to install a new driver to an application server, or even maintain different versions of the driver at the same time. IDEs without plugins are also extremely rare.

Replacing an algorithm in a business application is far more uncommon - often even not allowed. Its just crazy to introduce a modularization solution and then not use it.

[See also "Real World Java EE Patterns, Rethinking Best Practices" book, Page 253, (Premature Encapsulation Is the Root of All Evil) for more in-depth discussion]

Just thought of providing an outline for design and implementation of JavaFX application. I briefly described this in one of previous post - Custom Layout.To start with we will most likely receive a huge PSD file from designer. You may use Production Suite tools to import the content into JavaFX. Here is manual approach..

First we need to identify various functional areas in the UI. Most likely the UI is already grouped. Areas can be Settings, Authentication, Data-Entry/Update View, ToolBar, Search etc. From this we can identify set of packages to be created in JavaFX. If the UI is simple, we may have the entire UI under "view" package. Now we can breakup the UI in to multiple classes based on the functional area. It will be easier if we could make these classes extend Container or CustomNode. From there we come down to actual layout of Controls..

Given below is the layout used in one of MiG Layout Demos - Layout Showdown. Refer to MiG Layout Site for more information. Refer to JFXtras project for more information on MiG Layout for JavaFX.

We will try to implement this UI in JavaFX..

Now we need to visualize a grid on top of the layout so as to identify some pattern in UI. It will be much easier if we could do this mapping. You may refer to various sites such as Layout Cookbook, RIA Screen Layouts or RIA Screen Design to get some idea..

Once we get the mapping, we can implement the layout using various layoutNode functions in Container. Please refer to PersonalDetailsView.fx source for more information.

To launch click on above image or

Please try it out and let me know feedback..

var dzone_style = '2';

The Mobile Times 2010 conference in Dusseldorf, which took place last Thursday, featured a lot of talks on how to do approach cross platform development. A lot of them suggested web development technics as a way to escape native vendor lock-in, such as Apple's iPhone OS.

There are mainly two approaches:

1. You develop a web site using HTML, JavaScript and CSS zip it and deploy it together with a Player

2. Or you develop a custom website which is served from your servers

The first approach is usually tackled using a framework such as PhoneGap. It event provides an API to include platform specific functionality such as GPS in your application.

The second approach either uses traditional web development technics or targets a specific browser, such as WebKit. One example is jQTouch, a jQuery plugin with cross platform support - unfortunately only WebKit.

The presentations, advocating those two approaches, mentioned mainly two advantages:

1. No need to comply with platform policies (think of Apple's App Store)

2. And you can leverage cheap web coding skills

Those are the facts, I collected during Mobile Times 2010. Unfortunately, the benefits using the web development approaches were not really balanced by any downsides.

I really doubt that the web development approach is the way to go in terms of cross platform mobile app development. I think frameworks like PhoneGap are doing an awesome job, putting an abstraction around the native platform.

Unfortunately you get the least denominator of your platform is capable of and that's a real downside to me. If I put on "average Joe head", I want an app that is using the full potential of my phone. I don't care that it was cheaper to develop a web-based solution and I definitely don't care that the framework I'm using is only offering partial support for my phone features.

Another problem is platform defragmentation! I won't go into it - don't worry - I simply want to point out one downside: In my humble opinion, it is not possible with web development technics to "write once, run anywhere"! You will have to tweak the CSS and work around the abstractions of the framework your are using! It might be cheaper, because we all know that the average web development frickler (amateur craftsman), only charges what he deserves. However, I don't think it gets you anywhere in the long run.

I think we shouldn't approach mobile application development with only the engineering side in mind. Instead we should rather focus on the customer and what he asks from a mobile app. I think the success of the App Store has proven that native apps are the way to go, even if they mean more effort on the development side.

I will spend few hours in Gothenburg at the SDC 2010 conference and give a talk with the title "Lightweight Killer Apps with Nothing But Vanilla Java EE 6". I'm really curious whether my first slide will look familiar to you - people outside Sweden are thinking, that it is the Golden Gate Bridge, what is entirely wrong.

I will have some time after the session. So if you have some questions, want to discuss, or hack some code - just ping me. I planned to spend more time in Gothenburg - a really nice city. Because of the project (over)load, probably caused by the general Java EE 6 take off :-), - I will only spend few hours.

I am often asked two questions: “What makes JXInsight so much more faster and scalable than other solutions?” and “How can the high quality of JXInsight be maintained with such high frequency (bi-weekly) of software updates?”.

One factor common in answering both questions is in the clean separation of instrumentation, measurement and data (model) collection within our highly extensible & configurable activity based resource metering runtime – a separation that is not present in other tools, certainly not at the same degree.

For the most part what gets instrumented by other vendor solutions is what gets measured and collected. So any new features added by vendors outside of possible optimization of these concerns usually entails additional overhead as well a possible impact to reliability – release after release. We have observed this phenomenon across a number of products which we track internally even when there is an option to disable a feature there is still some residue of overhead which is to be expected if there is tight coupling between the implementation of each concern.

In the design of our probes technology we avoided many limitations of legacy call tx/trace/path solutions by not coupling our runtime to any particular instrumentation technology by way of an Open API that whilst affording an extremely efficient interface for the purpose of instrumentation allowed for the deferral of both measurement and typed data collection based on dynamic aspects of the metered execution as well as the external configuration of optional features by a system administrator.

Below is diagram showing how our metering runtime stack looks straight out-of-the-box. The blue layers represent what is exposed directly to our customers. It is important to note that the hundreds of technology specific instrumentation extension libraries we provide, which can be simply dropped into class path, all use the same underlying Open API made available to customers for the purpose of custom instrumentation, reporting, resource metering and billing. The brown layer, our strategy probes provider, dynamically determines whether particular instrumented method calls are measured (metered) and hence whether any data is collected. By default the runtime only collects metering information aggregated by cost groups derived from composite probe names. Any additional data collection requirements such as stacks, tracks (traces), transactions, charges, and billings needs to be explicitly enabled by installing the appropriate probes provider via a system property. This gives our customer complete control over our resource metering overhead.

Note: There is no mechanism in the Open API to programmatically enable capabilities as we are targeting production environments which are generally managed via configuration under change control. It is possible to query the runtime for installation of particular data model augmentation providers.

The strategy probes provider is one of a number of providers used to break the link between what is instrumented and what is measured. Based on actual live metering information the strategy probes provider can dynamically disable future measurement of instrumented calls for a particular named probe which generally maps to a Java class method though we support this same capability in other VM languages (JRuby, Jython). The strategy provider is enabled by default but it is still optional and can be disabled as depicted below.

All of our AOP extensions go through our Open API so it is relatively easy to integrate with other instrumentation technologies. You can also use our Open API directly within your code if you need to create contextual named probes which do not map easily to method calls.

Note: Generally customers that use the Open API also use the AOP SDK though such usage is not mandatory.

The real differentiator comes into play when you consider the number of providers available today some of which offer their own extension points via a SPI. We have measurement filtering providers that can dynamically elect whether to meter a particular instrumentation event/call based on aspects of the execution such as the degree of concurrency. Below these we offer various data model augmentation providers that create and maintain additional software execution model structures as well as performing statistical analysis on the model. What is impressive is that we have achieved all this in a very coherent manner in terms of execution behavior and data models whilst maintaining the integrity of the runtime design that we truly believe has unlimited potential and application (even outside of the application performance management domain).

This is not the end as we continue to design and develop new ways of measuring, collecting and modeling execution behavior below the surface of the Open API which will benefit all extensions and custom integrations layered above. We have many more updates coming each introducing new providers which can be injected into the runtime completely transparently.

So yesterday I bumped into this bug: a listener of a tree object (not Swing's JTree. A tree with nodes and labeled edges, a-la Data Structures 101) was referencing a null object:

public class Auditor implements TreeListener {

  private Map<String,Date> map = new HashMap<String,Date>();

  public void nodeAdded(Node n) {
    map.put(n.id(), new Date());
  }

  public void nodeRemoved(Node n) {
    Date d = map.get(n.id());
    String s = d.toString();  // <-- NPE is here!!
    map.removeKey(n.id());

    // some other things ...
  }
}

My unit tests told me that the Auditor and Tree class are working fine - the tree fires the correct events and the Auditor reacts correctly. Of course, a Green bar does not guarantee "no bugs" so I double checked the code and it seemed fine.

Indeed the problem was elsewhere. Turns out that a bug in my app caused each listener to be registered twice. Auditor was not expecting to be called twice for each event, hence the NPE.

So I fixed the bug. Then I went back to the addListener() method of the Tree class. It is a very simple method:

public class Tree {

  private List<TreeListener> listeners
    = new ArrayList<TreeListener>();

  public void addListener(TreeListener arg) {
    listeners.add(arg);
  }

  // Additional methods ...
}

Looking at the code I tried to think if this method should be changed in order to prevent future occurrences of this bug. As I was thinking about it I realized that this simple method is an excellent illustration to one software's most fundamental truths:

Programming is about making (design) decisions.

I am not the first one to say this (see Joakim Holm's "Programming is all Design" or Alistair Cockburn). Here's the (probably partial) list of decision that a programmer has to make when writing a one-liner method that should simply add a listener to a list.

1. Should the listeners field be private? Maybe we want subclasses to manipulate/inspect it in some way, which calls for protected visibility.
   
   
2. What is the order of notification? Should we use a "first-registered first-notified" policy? or maybe "last-registered first-notified". Is order important at all? If not then maybe we would like to force the application not to depend on the order by random shuffling?
   
   
3. Can a listener be registered with more than one Tree object? If so, then the listener interface should probably specify the originating tree, not just the node
   
   
4. Can a listener be registered more than once with a single Tree object? Usually the answer is no, but there are scenarios where multiple registration does make sense.
   
   
5. Assuming each listener may be registered exactly once, how do we deal with multiple registrations?
   
   • Throw an exception?
   • A standard Java assertion? Could be disabled which may be good or bad depending on context.
   • Throw an AssertionError? Has a more dramatic effect than a plain Exception. Also will be reported by JUnit as a failure rather than an error. Again, may be either good or bad.
   • Silently ignore. Return from the method without adding the listener. This seems very natural but it has the drawback that it hides the problem. If I choose to silently ignore then I will get no notification about future problems. How about logging?
   • Return a Boolean value indicating whether the listener was already registered. Puts the responsibility on the client code to check this value. Will not always happen.
     
     
6. Do I need to provide some thread protection?
   
   • Define the method as synchronized?
   • Define the listeners field as a ConcurrentLinkedList?
   
   
7. How should this list of listeners interact with the Garbage Collector? Should a listener that is only accessible from this list be collectible (by storing it as a WeakReference)? A "No" answer puts additional burden on client code: must remove listeners from the Tree object when they are no longer needed. If listeners are dynamically added as the app is running this may become a big problem.
   
   Note that choosing weak references is not always a good idea. Some listeners are only accessible from the listened-to object. Take for example a listener that inspects the tree and updates the title of the main window. It is created, pushed onto the listeners list and all other traces to it are lost. A weak reference will make such a listener disappear with the very first collection cycle.
   
   
8. Do I want to refactor the whole "listeners" concern into a dedicated strategy class. This will improve testability and decoupling.

As I said this is a partial list. Point is simple: a programming task requires much more decision (and mental energy) that what initially seems. In other words: If you want to design everything upfront you'll end up programming upfront but without the assistance of tools such as IDE, Unit tests, Refactoring, and the likes. Good luck.

The Griffon team is very pleased to announce that Griffon 0.3 has been released!. This release is loaded with new features, plus a good number of bug fixes. Here's a quick tour on what 0.3 has to offer:

Addon enhancements

As you may know, addons are Griffon's runtime plugins; you can use them to extend the capabilities of an application. Addons were introduced in 0.2 however they only exposed a small set of hooks (factories, methods, props) plus their own life cycle hooks. Starting form this release addons are able to contribute application event listeners and all types of delegates that a FactoryBuilderSupport builder can handle.

Native libraries support

What do you do if your application requires a platform specific library or jar? What if you need to package several of those depending on which platform you intend to run on? What about plugins and native libraries? Well all these questions and more can now be solved by following a file placement convention that can save you lots of time. Supported platforms at the moment include: Windows, Linux, OSX and Solaris (all 32bit versions).

Packaging enhancements

Closely related to native libraries support, you're now able to specify additional settings and resources that can merged into the generated JNLP files when running on webstart and applet modes. No need to manually fumble with those files anymore. Plugins can take advantage of this feature too.

Artifacts API

Since the beginning Griffon has had basic artifacts (Model, View, Controller) but there was no easy way to query them for additional info. This is precisely what the artifacts API does for you now. Additional artifact types may be added an listed when calling 'griffon stats'. this API is further enhanced by the artifacts-plugin.

Lightweight services

Griffon 0.3 introduces services support. Services in Griffon differ from their Grails counterparts as they are not transactional. The Griffon runtime will inject an instance of a particular service to other artifatcs following a simple naming convention; this is not a replacement for a full DI solution but gets the job done without installing additional plugins.

Threading additions

While SwingBuilder's edt{}, doLater{} and doOutside{} are very handy they only work if the current toolkit is Swing. Griffon supports other toolkits via plugins (SWT, Pivot, Gtk, and JavaFX) so it makes sense to have generic threading facilities that can work with any toolkit. This is precisely what UIThreadHelper does.

In addition to this features, a new set of plugins is available too; check'em out

• artifacts - further enhancements to the artifacts API. distributed as a plugin to keep core's dependency count low.
• i18n - message i18n support using Spring's MessageSources.
• erlang - support for making RPC calls to Erlang servers using Erlang's JInterface.
• flyingsaucer - an XHTML renderer component.
• processing - make 2D/3D renders and animations with the Processing Programming language and Griffon.
• serial - serial port communication libraries.
• thrift - Apache Thrift support (another serialization option).
• jmx - a straight port of the Grails JMX plugin, originally created by Ken Sipe.
• p6spy - another Grails plugin port.

Speaking of toolkits the following plugins have become available too:

• swt - relies on SWTBuilder.
• pivot - brand new UI Toolkit from VMWare labs, donated to Apache.
• gtk - GNOME integration via java-gnome.

Griffon couldn't stay behind the recent NoSQL movement:

• berkeleydb - available now!
• db4o - available now!
• couchdb - preview mode
• neo4j - preview mode
• riak - preview mode

Other existing plugins have been updated, perhaps most notably Spring, GSQL and builder plugins.

Let us know what your impressions are of these new features and tools. We would also appreciate if you let us know if Griffon has been of use to you and how. Feedback is welcome always.

Keep on Groovying!

Having seen how to teach Naked Objects to support Java 5 enums directly, let's use this new capability to avoid inheritance hierarchies in entities using powertypes. Typically we use inheritance as a way of achieving polymorphism: different behaviours for different types. For example, in the Library example we have CDs ...

In the previous post we saw how to write a FacetFactory so that Naked Objects treats enums as value types. Let's now complete the story by also showing how to provide drop-down lists for any properties or action parameters of that type. We'll start by defining a new ChoicesFacet, to ...

In the previous posts we've seen how to simulate enums in Naked Objects 4.0. But it'd be nice if Naked Objects supported enums natively. So let's see how, half in this post and half in the one that follows. What we're going to do here is to extend the ...

In my last post I showed how to simulate enums, and then Giorgio asked in the comments as to how this fits in with the choices() method, used to provide a drop-down list of values. To start with, let's add an all() method to StockType: import org.nakedobjects.applib.DomainObjectContainer; public class StockType extends EnumeratedAbstract { ...

One thing that Naked Objects 4.0 doesn't yet support is Java 5-style enums. We think we know what we need to do to support it (I guess that will be 4.1), but for now let me offer you a way to get the same general effect. Let's make this concrete ...

Here in the UK we have the ability to petition our prime minister. So Rob Bowley has set up an e-petition asking the government to review how IT systems are procured. In essence: please stop wasting money using waterfall development processes; use agile instead. So, if you are ...

I've started work on moving Tested Objects' FitNesse support onto the latest version of FitNesse, using the new SLIM protocol. Now for the previous version I manually installed the fitnesse.jar into my local Maven repository and also scp'ed it up to the release repository on StarObjects. This time round ...

If you've just stumbled across this blog and are wondering what "domain driven design" is all about, you might like to check out an article I wrote for the Methods and Tools journal. It's downloadable in their (free) PDF magazine, and is also available online in HTML form. Thanks to ...