Over a million developers have joined DZone.

Jazz Improvisor in Swing Developed in NetBeans IDE

· Java Zone

Discover how powerful static code analysis and ergonomic design make development not only productive but also an enjoyable experience, brought to you in partnership with JetBrains

Toni Epple told me about a cool Swing application today, which is for jazz musicians to help them improvise music. The application, named Impro-Visor (homepage here) is "a music notation program designed to help jazz musicians compose and hear solos similar to ones that might be improvised. The objective is to improve understanding of solo construction and tune chord changes."

When you download and run the application, you can model your solos based on the styles of known jazz musicians, as you can see below:

It's an especially cool application if you're a NetBeans IDE user, because it turns out that, if you browse their site and, especially, their fun project team photos, they're using NetBeans IDE as the development environment of this application:

Indeed, when you get hold of the sources, you'll find you have a NetBeans "free-form" project, i.e., a project that uses an external build.xml file, rather than one created by NetBeans IDE. And, as you can also see, they're using the Matisse GUI Builder in NetBeans IDE:

Now, if you look at the above source structure, as well as at the UI of the application itself, there are several things that this application stands to gain from being ported to the NetBeans Platform, which is a Swing framework. Most notably, the following would be the advantages:

  • Modularity. Rather than having all the sources within a single application, they'd be split into logical units called "modules". The advantages of this would be as follows:

    • Developer benefits. The development team would be able to split into smaller groupings, each working on isolated pieces of code, i.e., by working on separated modules rather than on a whole large application. Errors made by one smaller group of developers are less likely to impact the whole team, because only if the modules were to depend on each other would there be an impact. For example, right now, if a small error is made in the preferences window, the entire application cannot start up! However, if the preferences window were to be in a separate non-mandatory application module, errors in that module wouldn't prevent the entire application from starting up. In addition, the development team could distribute patches and updates as modules. 

    • End user benefits. The user would be able to install only those modules they need. They'd end up with a smaller application containing more useful features and less features that they never use. They could also create plugins themselves, if they had the skills to do so, without even needing to have the whole source base available. They'd only need the API's Javadoc and then they'd be able to make their own modules and install them into the application. They'd also be able to install modules created for other NetBeans Platform applications, some of which (such as a Google toolbar, for example) might be useful to this application. Especially in the domain of music composition, a few other applications already exist on the NetBeans Platform, hence these could reuse modules from each other, especially if the developers working on these applications were to create some kind of shared platform together, as Boeing has done, for example.

  • Reusable Components & Frameworks. Since this application is being developed in NetBeans IDE, the developers on this project are probably quite familiar with this development environment. Probably there are parts of NetBeans IDE that they'd like to be able to use in their own application. The Favorites window, for example. Or the Palette. Or the Options window. Or one of several other standalone components, many of which provide their own API and can simply be integrated into this application, since this application is Swing-based, just like NetBeans IDE. Another example is the NetBeans Welcome Screen, which can be reused as is, or modified, or enhanced, etc.

    Another clear example is the NetBeans window system. When I look at this jazz application, I see multiple tabs, each of which could be max/minimizable and dock/undockable, if they had been TopComponents in the NetBeans window system, rather than standard Swing components. Especially if the user has multiple monitors, being able to drag/drop tabs around from monitor to monitor is useful. The NetBeans window system provides windows (these are called "TopComponents") that have this functionality out of the box, i.e., without you needing to do any kind of coding at all.

    The central concept here is that... the developers would be able to focus on the business logic of their application (i.e., the jazz improvisation layer) rather than all the infrastructural concerns of toolbars, windows, options windows, and so on. That's not their primary interest, after all. And that's not the primary benefit that the end user is interested in, i.e., they didn't ask for a window system, but for a jazz improvisation application. And that's what this development team's area of expertise is, while the underlying infrastructure is something that the NetBeans Platform engineers in Prague are mostly focused on. So, why not simply reuse that common infrastructure while you focus on your domain knowledge?

Yes, there'd be quite a bit of work involved in rearchitecting this application to make the most of the NetBeans Platform. On the other hand, all applications need to be re-architected (at least its architecture needs to be re-assessed) at some point in its lifecycle. And, it wouldn't be the first example of an application being ported to the NetBeans Platform, so there are several other development teams who can share their experiences and offer tips and tricks for doing so. There are now also several books and tutorials that give a lot of guidance to getting maximum benefit out of the NetBeans Platform.

What about the overhead? What about the NetBeans Platform being very large and unwieldy? Well, here's something that programmer Herman Matthes at Siemens says, in the context of his TimeKeeper application on the NetBeans Platform. When asked "But doesn't the NetBeans Platform make your application very large and unwieldy?", he replies: "No, on the contrary! TimeKeeper currently has more than 100,000 lines of code and I use many external libraries, such as for writing Excel Sheets, generating PDF Reports, bar charts, or gantt diagrams, sending e-mails, and so on. These libraries also extend the application size, but they would do so just as much if I were to write them myself. And it would take a lot of time to implement all these features. It's the same thing with the NetBeans Platform modules—I use a lot of NetBeans Platform modules for features which I otherwise would have to write myself. And I'm not sure if I would be able to implement them with the same level of quality as I get (and for free!) from the NetBeans Platform."

The end result would be an application that would be far more agile than it currently is. The developers would get their application infrastructure (base architecture, UI components, frameworks) out of the box, allowing them to focus on their domain expertise, while being able to quickly distribute exactly the patches and updates that the end user needs. The end user would be able to tailor the application to the size and complexity that they need, plus they'd have a better set of base components, such as a far more flexible window system than they currently have.

Learn more about Kotlin, a new programming language designed to solve problems that software developers face every day brought to you in partnership with JetBrains.


The best of DZone straight to your inbox.

Please provide a valid email address.

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}