-
Notifications
You must be signed in to change notification settings - Fork 26
Description
For example:
@FunctionalInterface
public interface Cleanup extends DokanCallback {
void callback(WString rawPath, DokanFileInfo dokanFileInfo);
public static final Cleanup DEFAULT = (rawPath, dokanFileInfo) -> {}; //default NO-OP
}
(For ZwCreateFile, for example, you can provide the very reasonable default NIO code, that is already there!)
Then in DokanyOperations you can initialize the class with reasonable defaults (note how I renamed the class field name, more on that later)
public class DokanyOperations extends Structure{
...
public Cleanup cleanup = Cleanup.DEFAULT;
}
and objects of class DonanyOperations are usable immediately after creation:
DokanyOperations do = new DokanyOperations();//Usable, no null pointer exceptions!
The bigger advantage, however, is that developers can easily create their own DokanyOperation classes overriding defaults only for what they need to:
class MySpecificDoknayOperations extends DonanyOperations{
MySpecificDoknayOperations(){
//I only override the operations I care about in this constructor!
this.cleaner = MyDonayOperations::myOwnCleanup;
}
//I may want to keep this private .. or not!
private void myOwnCleanup (WString rawPath, DokanFileInfo dokanFileInfo){
...
}
}
NOTE 1
The above enhancement represents an alternative, simpler, more functional approach to extending dokan-java compared to the big interfaces/classes DokanFileSystem/AbsrarctDokanFileSystem/DokanFileSystemStub.
However, you can still keep DokanFileSystem/AbsrarctDokanFileSystem/DokanFileSystemStub around.
NOTE 2
Also there is no need for questionable use of reflection/annotations and the associated risks with this (for example: what if I make spelling error and annotate with NotImplemented("ZWCreateFile")? Will I get a silent failure at runtime?)
NOTE 3
Not sure why DokanOperations breaks the Java conventions for naming member fields? Is this a JNA thing? For example it should be this:
public ZwCreateFile zwCreateFile = null;
and not this:
public ZwCreateFile ZwCreateFile = null;
Naming the member exactly as the interface is bad a idea - can we change the name either of the field or the interface? This will make the above patch a bit more convoluted, because:
private Cleanup Cleanup = Cleanup.DEFAULT;
is illegal in Java.
NOTE 4
Please consider getting all DokanCallback interfaces out of the DokanOperations class. It may be easier for developers to find them (although keeping them inside the class is probably fine, never confused me)