27th Sep 2019, the new JDeveloper version 188.8.131.52.0 became publicly available. We waited two years for the latest version. Is this version worse waiting for it?
In the next couple of blogs, I go through some of the new features offered. Before I start with the new features, I summarize my findings.
The list of fixed bugs available from https://www.oracle.com/technologies/developer-tools/jdeveloper/12214rn.html is impressive. However, some of the bug descriptions are not descriptive without knowing the actual case. Anyway, I found many bugs I filed for 12.2.1.x versions. You should read through the list, and you’ll find that some bugs which you have run into have been fixed in 184.108.40.206.
When 220.127.116.11 became available the documentation about what has changed or which features have been added, was thin, very thin. In the last couple of weeks, this documentation became available too. Some broken links have also been corrected. You should look at the JDeveloper homepage (https://www.oracle.com/technologies/developer-tools/jdeveloper/jdeveloper.html) regularly and search for new documents. Some other users and I ask support and the product management to add documentation which we found missing. Oracle support and product management reacted very fast and provided everything we asked for within a couple of weeks.
I’m using JDev 18.104.22.168 for four weeks now regularly. My impression is that the IDE is more stable. I do see some exceptions in the IDE, but the IDE keeps running. Older versions of the IDE (22.214.171.124, 126.96.36.199 and 188.8.131.52) sometimes crashed (once a day). It no fun to lose small parts of your latest changes.
One defect (see https://community.oracle.com/thread/4299239) is reproducible in 184.108.40.206 too. This problem, while old, has just filed as an SR to support.oracle.com. Let’s hope Oracle can fix it ASAP.
I don’t see a significant performance gain in my daily work. Starting the integrated WLS takes a bit longer on my test machine. I’m running it on a LINUX system (Ubuntu 18.04 with 8GB RAM and JDK 1.8.0_221, 4 CPUs) in a VirtualBox. For me, it looks like the minimal configuration you can work on. I can work fine, but it’s not cutting edge. I don’t have to wait too long for audits or insights. I know it becomes better with more resources. In the next couple of months, I’ll move the installation to a better setup with more memory and more CPUs.
The first task, as usual, was to create a new ADF Fusion Web Application, add some business components from DB tables and build a small UI with the created objects. As I said before, the list of fixed bugs is impressive. However, making this first application, I found new problems.
The wizard used to build ‘Business Components from Tables’ doesn’t obey all the package names specified. The ApplicationModule package is simply ignored. It’s not a big deal, as you can refactor this easily. If you specify the package names globally (Tools->Preferences->ADF Business Components->Packages) it works OK. Another problem using this wizard is that an application module is generated, even if you deselected the option for this. This problem is known in the community (I learned that other users have this problem in older JDev versions), but it seems unknown to Oracle. Maybe nobody filed an SR for this. I submitted an SR for this now.
Migrating some of my projects to 220.127.116.11 (from 18.104.22.168, 22.214.171.124) worked smoothly. All applications I wrote from my blog articles (12c only) migrated without a problem. I could run all of them too.
One problem I run into is using Maven as a build tool for ADF applications. There were problems using Maven as a build tool in old 12c JDeveloper versions. Oracle fixed a lot of bugs regarding Maven. While testing Maven again in 126.96.36.199.0 I found most of the older bugs fixed, but I found a new one. I can’t say that they fixed all Maven bugs as the newly found bug prevents the complete test. Running JUnit test for business components from Maven doesn’t work. Somehow the fixture used to create the application module can’t create the JDBC connection because the credentials can’t be found or are wrong. Oracle is investigating this problem. For now, Maven testing is stalled.
The next thing I tried was installing the Rich Client Demo on my test machine. The last time I tried this (for 188.8.131.52) this process was laborious. Once you had installed the demo all you could do was running it. There is a new description of how to install the demo on your client machine (https://www.oracle.com/technetwork/developer-tools/adf/documentation/adf-faces-rc-demo-083799.html). This description isn’t perfect as you need to add two more libraries (‘ADF Model Runtime’ and ‘apache-commons-lang-2.6’), but it’s simple to follow. The client demo runs on my test installation. I can even change things (or debug it). I’m not sure if this was possible for older version, I simply can’t remember the last time I tried to do this.
I found some other small problems which I disclose in one of the next blogs when I start to show some of the new features or enhancements of JDeveloper 184.108.40.206.0
I expected to find some problems. Some of them are stupid or embarrassing. Still, I like the new version. Keep in mind that I did not mention all the good stuff which works OK.