This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
This happens trying to get the nodeDelegate for an invalid DataObject (one whose FileSystem has been dismounted). The symptom is debugging output printed to stderr, and possibly an exception dialog (if the code in DataObjectListEditor in my path which catches the exception has not yet been integrated.) It's very easy to reproduce: Create a JarContent called JC in filesystem A. Add DataFolder DF in filesystem B to its contents. Restart the IDE. Dismount B (never opening DF's parent folder). Select JC and bring up its contents property. What getNodeDelegate does is (eventually) call DataObjectPool$Item.run, which wants to create the nodeDelegate. The DataObject is invalid by now, so the result of getDataObjectOrNull is null, with the stack: at org.openide.loaders.DataObjectPool$Item.getDataObjectOrNull(DataObjectPool.java:443) at org.openide.loaders.DataObjectPool$Item.run(DataObjectPool.java:488) at org.openide.util.Mutex.readAccess(Mutex.java:241) at org.openide.loaders.DataObject.getNodeDelegate(DataObject.java:237) at org.netbeans.modules.jarpackager.DataObjectListEditor.getNodeDelegate(DataObjectListEditor.java:455) at org.netbeans.modules.jarpackager.DataObjectListEditor$ContentMemberTableRenderer.getTableCellRendererComponent(DataObjectListEditor.java:890 ) ... Since the Item can't find the DataObject, it of course can't create its delegate. I don't understand the entire mechanism, but apparently setting DF to invalid (when B is dismounted) takes it out of the pool, resulting in the null return. If it doesn't happen for you, check org.netbeans.modules.jarpackager.DataObjectListEditor for a method called getNodeDelegate.
Reassigning to Jesse. Jesse I couldn't reproduce it with latest version of jarpackager. Anyway trying to get node from invalid DataObject is wrong, and throwing ISE seems to me like correct behavior of DataObject in such situation. Mike did you changed this part of jarpackager since the time you have reported this?
Yes there is a workaround in jarpackager now: if a random exception is thrown getting the node delegate, a plain node is returned. I agree that the jarpackager should not be attempting to call getNodeDelegate on an invalid object at all. (It should check in advance and do something else.) I agree with Vita that it ought to throw an exception if the data object is invalid (I used to think otherwise but am now convinced). However bugs should be filed for any piece of code that might make this call on an invalid object. And probably DataObject should be smarter about what it does in this case.
Then if the debugging lines written to stderr in this situation are removed, we'll all be happy. This is what I asked for in the first place.
DataObject.java 1.60 throws an ISE reliably if you call getNodeDelegate and the object is invalid. It does not print to stderr. But please avoid even calling getNodeDelegate unless you are sure the object is valid; much better to test first, than to catch the exception (it is not documented what if anything will be thrown, remember).
That is, since a DataObject can become invalid at any moment due to user action (deleting the file or dismounting the filesystem) the proper calling sequence for getNodeDelegate is: node = null; if (dataObj.isValid()) { node = dataObj.getNodeDelegate(); } Even leaving aside the obvious race condition, the reason exceptions exist is to make this sort of code unecessary. And there's nothing preventing RuntimeExceptions from being documented -- if that's the expected behavior, please do so.
Yes, there is a possible race condition. The reason I suggested doing an explicit check for isValid is because in your case there is a clear possibility that the data object will not be valid--i.e. in situations where a data object is collected at one point and then later on used, some filtering of newly invalidated ones make sense because it is quite probable there will be some. You are right that the IllegalStateException could be documented as expected behavior, though catching ISE is not really nice because it could have been thrown from totally unrelated code, which if caught and ignored would hide serious bugs elsewhere--so for this kind of situation it is better to have a specific exception class you can catch. Of course best of all would some API-level mutex for datasystems which would prevent the possible race condition to begin with, but this is a longer-term goal.
Verified
Resolved for 3.4.x or earlier, no new info since then -> closing.