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.
I am missing some kind of notification about moving of FileObjects in the FileSystem API. Even though the FileObject provides support for the move. I am not sure what is the best way to achieve this. Maybe introducing FileMoveEvent with getNewFileObject() in FileChangeListener.fileDeleted()?
Possible duplicate of issue #28497? IMHO without identity-retaining proxies, a FileMoveEvent does not make much sense because you can do a copy-delete move without invoking any special code in FS API (just copy streams, then delete original) and of course no event would be fired as a result.
Will identity-retaining proxies handle a file manipulation without using FS API as Jesse mentioned (eg copy stream, then delete original)? IMO FS API should notify at least about operations performed via that API. BTW the issue #28497 and the thread on nbdev says nothing about event notification.
I prefer being notified than retain identity. I think that retain identity is almost the same as be notified about change for user of API. Retain identity means to introduce new FileSystem only because move should be handled in different way.Moreover identity-retaining complicates also slightly client code to be correct. First you must call FileUtil.proxy (and mainly you must know about such method) to get another instance of FileObject. Also if you need instance of original FileSystem you must be aware that from ProxyFileObject you can`t get it anymore. Next mentioned problem with equals. Jan asked the same question as I asked for myself. And the answer is, that naturally also identity-retaining impl. is not able to handle all obscure cases how to move FileObject (e.g.: original FileObject may be deleted month after original FileObject was copied, while IDE was restarted for umpteenth time).
Created attachment 9039 [details] I implemented some way. A little different approach, then I announced.
Created attachment 9041 [details] I added simple impl. and I would like to know if it is acceptable. Here is simplified usage.
1. Prefer ChangeListener to a PropertyChangeListener with a dummy property. 2. I think "public final" is preferred to "final public" for readability - consult Checkstyle. 3. Dislike that moveNotify is package private. IMHO there is a problem that the filesystems package has API & SPI in the same package, because there is always a temptation to make the "official" impls have abilities that independent impls of FileSystem/FileObject cannot possibly have. The use of instanceof in getFileObjectIdentity is an obvious symptom. Suggest perhaps in FileObject: protected boolean supportsFileObjectIdentity() { return false; // overridden in AbstractFolder to return true } protected void changeIdentity(FileObject nue) { FileObjectIdentity.moveNotify(this, nue); } Of course if changeIdentity is only ever called by FileUtil.move anyway, then *all* file objects support it, and there is no need for such methods in FileObject.
You are right in your comments, but I'm not sure that I understand the last paragraph. Is it hypothetical, if everybody used FileUtil.moveFile instead of FileObject.move ?
Huh, sorry, did not see that FileObject.move() existed. So as to comment #3: use of FileUtil.moveFile vs. FileObject.move() is irrelevant, since FU.mF just delegates. Therefore, you *do* need the protected SPI methods I suggested in FileObject: if someone is directly extending FileObject, they may be overriding move(), and so they will need access to the stuff in FOI, to have the same power as AbstractFileSystem & MultiFileSystem. So suggest slightly different: class FileObject { // ... /** override to return true if you call changeIdentity() in move() */ protected boolean supportsFileObjectIdentity() { return false; // overridden in AbstractFileObject to return true } protected void changeIdentity(FileObject nue) { FileObjectIdentity.moveNotify(this, nue); } move(...) { // ... as before, but call changeIdentity in else-block } } class AbstractFileObject { // ... move(...) { // ...as before, but maybe call changeIdentity() } } class MultiFileObject { // ... move(...) { // ...as before, but maybe call changeIdentity() } } Now FOI should call supportsChangeIdentity rather than using instanceof. Only compat problem here is that for an older FileSystem which extends FileObject directly but does not override move(), sFOI() will return false, though it could return true. But that is OK I think - not really incompatible, since FOI was not supported before at all.
I would like to implement the solution without the need to add protected (final) methods into FileObject. Enough there are those fireFile*Event ones. But I have to admit, I do not see an easy way. supportChangeIdentity is more likely attribute of all FileObjects on one FileSystem. So it might be property of FileSystem. Either protected method there (nearly as ugly as above) or which I think is better - new argument to (protected) constructor. This would nearly hide the feature for API users and left it there just for SPI writers. As the main purpose for supportChangeIdentity and notifyIdentityChange methods is to give writers extending directly FileSystem outside of the api package (which not many people do) we do not need to make it too simple. Thus I suggest: class FileSystem { protected FileSystem (FileObjectIdentityFactory identity) { this.foif = identity; } /** package private */ FileObjectIdentityFactory getFOIF () { return foif; } } /** Just pure SPI */ interface FileObjectIdentityFactory { FileObjectIdentity createIdentity (FileObject fo); } implementation FileObjectIdentity as is now, just does not create new identity itself, but asks the filesystem. Both AbstractFS and MultiFS return their own identity. Now a bit from API point of view: It is not very useful to allow null as valid return value from getIdentity (). Imagine I am writing CloneableEditorSupport and need the identity. How the code will look like if null is allowed value? There will be field of type Object either being assigned by FOIdentity or by FO. Actually what CES needs is the simplest identity that guarantees as much as possible. That means I can listen on the FOIdentity and be notified when the FO is moved or renamed (update the window title) or is no longer valid (close the window). Thus by default just provide the best impl possible (no support for move, just support for delete). Ok? Naming murmuring: Do not you guys find silly to start every class in the package by "FileObject" prefix? If you really feel that Identity should start with it than better make it innerclass of FileObject and provide FileObject.getIdentity method. If you do not like the innerclass why not call it just Identity?
Probably this RFE should be reconsidered in light of masterfs, which might make it easier to implement. Could be valuable in a number of places, I think.
Reassigning to new module owner jskrivanek.
If there is still a need for a move notification, please reopen with some use case. It seems not for four years at least.