Tuesday, 26 October 2010

Closing Applications (Correctly) in JDeveloper

The following documents a somewhat small issue we're having with JDeveloper At this time I'm unable to lodge an SR with Oracle Support as we don't understand the circumstances under which it occurs, thus we can't build the usual simple "Hello World" test case that Support so thrives on. However as we've identified the symptoms of the problem and the associated workaround I'll publish them here for others to benefit (including my team) so we don't hit the issue again.

Note this issue is only verified under JDev I have no knowledge if the issue can be replicated in other JDev versions as this stage.

Issue Symptoms

From time to time after checking out an application from SVN inside JDeveloper:

....we'd discover JDev has incidentally modified one of the project files. In the following example the ViewController project is italicized meaning it has been modified:

Pressing "Save all" and then comparing the modified file against the previous revision reveals that the ViewController project has reverted back to the default settings, losing all the changes from the previous ViewController revision:

With the ViewController modified, the project can no longer compile (because among other things it's lost the attached libraries), and the change is effectively destructive. Whatever you do, don't check the ViewController project file back into SVN as it's just plain wrong.

Workaround #1

If you've arrived at this point where a project has been automatically modified by JDeveloper when checked out of SVN, the workaround in this situation is to Revert the project file back to the previous revision.

A Known Unknown Bug

In the example above I've identified the issue with a ViewController project in an ADF application. However note this problem isn't specific to any project type (e.g. Model, ViewController, whatever). We've experienced this issue across different projects in different applications from time to time. The converse of this issue is there's been a whole lot of projects this issue doesn't occur for too (i.e. in the above example, the Model project wasn't incidentally modified too), so the problem has something to do with the specific project configuration where the error occurs. Unfortunately we're unsure what that specific configuration is. However once the problem is detected it is consistently replicable on the problematic project at hand.

Bug Preconditions

While we haven't been able to work out what configuration in the project files causes the bug, we are aware of a set of steps that do lead up to the bug.

From a day by day basis our programmers will have an application open in JDeveloper, synced with an SVN repository:

From time to time the programmer makes a decision that rather than syncing each individual file change coming from the SVN repository into the application, it's just easier to delete the local working copy of the application and check out a whole brand new copy. To do this the developer:

a) Closes JDeveloper
b) Identifies the working copy application directory on the filesystem
c) Deletes it
d) Opens JDeveloper
e) Checks out the same application from the SVN Repository into the *same* directory that the previous working copy was checked out

It's at this point we see the issue described, but as mentioned, not for all application projects, just some projects, sometimes. However once this problem occurs, repeating steps "a" to "e" from above the issue is consistently reproducible.

From what we can see for step "e" is if we check out to any other directory, the problem isn't replicated.

What we found odd about this issue is if another developer on another machine checks out the same application, the said problematic project file wouldn't be automatically modified by JDeveloper. Yet this gave us the spark of an idea of what's going wrong and how to avoid it in the first place.

Workaround #2

You'll note in the "a" to "e" description above, the developer closes JDev, then deletes the application from the file system, then re-opens JDev. What we're not giving the JDev IDE here is a chance to recognize that one of the applications it had opened has been removed completely from the file system.

The IDE seems to be partially smart in that the application is removed from the application poplist at the top of the Application Navigator when we reopen JDeveloper. Yet if we then proceed to check out the same application as described in "a" to "e" we hit the described problem.

A workaround to the problem is before closing the JDev IDE, via the Application menu selecting Close, to close the selected application. If this option is done first the end problem is not seen. The conclusion is this gives JDev a chance to tidy up it's internal state about which applications and projects are open, and somehow this avoids the bug we're experiencing.

Arguably the IDE should be able to handle this situation regardless. The fact that the bug is destructive to the project configuration is a major concern, especially if a junior programmer doesn't understand what's happening and checks in the changed project file regardless, but in the end following the workaround steps here avoid the issue in the first place.


Jan Vervecken said...

hi Chris

Thank you for describing the behaviour you see for JDeveloper making significant changes to the project files ("back to the default settings" as you describe it).

Although I typically work in such a way that I won't easily use the exact same directory to checkout sources (because of some "undiagnosed strange behaviour" I ran into in the past, which I don't even remember exactly) I might not run into the problem you describe, as "using the same directories" seems to be relevant.

But recently I was working on an example application when at some point my Model.jpr file was significantly modified by JDeveloper (
I noticed and committed the change, because (although weird) it didn't effect the scenario's in the example application I was focussing on.
see http://www.consideringred.com/files/oracle/img/2010/ADFLoggerConfigApp-Model-jpr-r230r231.png
see http://www.consideringred.com/files/oracle/img/2010/ADFLoggerConfigApp-Model-jpr-r233r234.png
After I read your blog post I tried to reproduce the change from revision 230 to 231 using a scenario similar to the one you describe, but I did not succeed.
The change from 233 to 234 was triggered after I had restarted JDeveloper (don't remember why) by a migration wizard, and this I can still reproduce using my revision 233.

So, although also about a significant modification to a project file by JDeveloper, it might not be exactly the same issue as you encounter, and I can also not reproduce it (or even describe the context in more detail).

Jan Vervecken

Chris Muir said...

Hi Jan

Thanks for the sanity check. I've tried to get traction on this issue on the OTN forums but didn't really get anybody confirming my experience, so it's good to have you confirm it in another fashion.

Coincidentally we have another project that does as you describe, after checking it out of SVN triggers the migration wizard, even though it was written in the same JDev version. Also like you describe the problem seems to come and go away from time to time. Unfortunately for me it's happening on another developer's machine and separate development project so I haven't been able to pursue the problem in any way.