I recently decided to use the Sample CRUD Application that is available in the NetBeans IDE as the basis for a demonstration that I did at a conference. (More about that in a future post.) It is a very useful sample that illustrates how to get up and running with database access from a NetBeans Platform Application.
Side note: The sample is an Ant-based application, which is in my opinion better for a demonstration than a Maven-based one. And that is simply because it won’t want to download dependencies at the worst possible time during the demonstration, making everybody wait. 🙂
So I installed JDK 8 and NetBeans 8.1, and without further delay created the application.
But when I tried to run the application, I got this compile error:
error: cannot access ExplorerManager
class file for org.openide.explorer.ExplorerManager not found[/text]
This appears on the surface to be a really strange error… ExplorerManager is not even mentioned on that line! I decided to just add a dependency on the Explorer & Property Sheet API for the CustomerEditor module, and the code compiled. Now I could use the sample for my demonstration, and I didn’t give it any more thought. But when I sat down this morning to write about the demonstration, I realised that I need to find an explanation for this issue.
So let us consider the structure of the sample project, as it stands just after creation by the project wizard. It is a very modular design, since that is partially what the sample is meant to demonstrate. The CustomerEditor (the module that is causing the compile error) depends on the CustomerViewer, which is perfectly sensible. And the CustomerViewer does have a dependency on the Explorer & Property Sheet API module from the NetBeans Platform since it uses classes that live there. Again, a perfectly sensible arrangement.
And then it hit me – I have seen this issue before in my own code! When compiling a NetBeans Platform Application on JDK 8, it is sometimes necessary to include direct dependencies on modules that are used by classes in dependent modules. Dependencies that are definitely NOT required when compiling with JDK 7. The sample is not broken, it is simply JDK 8 that is stricter in its requirements when compiling the code!
Side note: Looking at the code in the sample application, we can form an idea of how old the code is. This still has the Settings.xml and Wstcref.xml files for each TopComponent, which means that it dates back to before the introduction of annotations to register TopComponents. 🙂
One last issue did arise when I ran the application:
[text]Warning – could not install some modules:
Command-line Serviceability – The module named
org.netbeans.modules.autoupdate.services was needed and not found.[/text]
This must be due to new modules introduced since the creation of the sample source code. In an Ant-based NetBeans Platform Application, new modules that are introduced in clusters or projects that the application depends on will automatically get included. This is because the way the dependencies are specified is by listing the EXCLUDED modules from each cluster.
I could safely click Disable and Continue without affecting functionality, so I removed the Command-line Serviceability module from the application (CRUD Customer DB Manager project properties > libraries tab) and thus permanently resolved the last issue.
Now we are finally ready for the demonstration code… coming soon!