Currently, DfsLogger has a constructor that does not initialize the LogEntry, and then immediately calls .open() to create a new file used as the DfsLogger's LogEntry. This results in us being unable to make the logEntry field final, and makes for some confusing reasoning inside DfsLogger about whether a logEntry has been initialized or not.
This also leaves open the possibility for some race conditions... however, from what I can tell, the constructor that does not initialize logEntry always immediately calls the open method to create one, so there is never an actual race condition that occurs. Still, it would be better to code this in a way that made it clear that this was not an opion.
A "static named constructor" is the term I'm using when you construct objects using public static methods with convenient names, rather than use an overloaded constructor for different scenarios. For example,
LogEntry entry1 = LogEntry.fromPath(path); // vs. new LogEntry(path)
LogEntry entry2 = LogEntry.fromMetaWalEntry(metaEntry); // vs. new LogEntry(metaEntry)
This pattern is used with a private constructor called inside the static methods, after any validation checks that apply to the specific scenario (in my example, validation of a path or deserializing from the metadata entry).
This issue tracks the creation of two "static named constructors" in DfsLogger to replace the current two constructors, using names appropriate for the situations where they are called, and the creation of a private constructor that initializes all the fields, which should be able to be made final inside the DfsLogger. Further cleanup can be done throughout the class once the fields are final and we can guarantee that everything is properly initialized in the non-static methods.
This loosely relates to the work done in #4082 and #4085 to clean up uses of LogEntry and remove technical debt from the WAL code.
Currently, DfsLogger has a constructor that does not initialize the LogEntry, and then immediately calls .open() to create a new file used as the DfsLogger's LogEntry. This results in us being unable to make the logEntry field final, and makes for some confusing reasoning inside DfsLogger about whether a logEntry has been initialized or not.
This also leaves open the possibility for some race conditions... however, from what I can tell, the constructor that does not initialize logEntry always immediately calls the open method to create one, so there is never an actual race condition that occurs. Still, it would be better to code this in a way that made it clear that this was not an opion.
A "static named constructor" is the term I'm using when you construct objects using public static methods with convenient names, rather than use an overloaded constructor for different scenarios. For example,
This pattern is used with a private constructor called inside the static methods, after any validation checks that apply to the specific scenario (in my example, validation of a path or deserializing from the metadata entry).
This issue tracks the creation of two "static named constructors" in DfsLogger to replace the current two constructors, using names appropriate for the situations where they are called, and the creation of a private constructor that initializes all the fields, which should be able to be made final inside the DfsLogger. Further cleanup can be done throughout the class once the fields are final and we can guarantee that everything is properly initialized in the non-static methods.
This loosely relates to the work done in #4082 and #4085 to clean up uses of LogEntry and remove technical debt from the WAL code.