Update styx messages in Java#40
Conversation
There was a problem hiding this comment.
Pull Request Overview
This PR refactors the Styx message system in Java by moving message classes to the v9p2000 package and implementing a factory pattern for message creation. The changes improve code organization and encapsulation by centralizing message instantiation through factory methods.
- Move
StyxTWalkMessageandStyxTWStatMessageclasses to the v9p2000 package structure - Implement factory methods for creating these message types instead of direct constructor calls
- Update all references throughout the codebase to use the new factory pattern and package locations
Reviewed Changes
Copilot reviewed 14 out of 14 changed files in this pull request and generated 2 comments.
Show a summary per file
| File | Description |
|---|---|
| StyxTWalkMessage.java | Moved from messages package to v9p2000 package and made constructor protected |
| StyxTWStatMessage.java | Moved to v9p2000 package and made constructor protected |
| Factory.java | Added factory methods for TWalk and TWStat message creation |
| FactoryImpl.java | Implemented new factory methods |
| StyxFile.java | Updated to use factory methods instead of direct constructors |
| StyxSerializerImpl.java | Updated field access and removed unused imports |
| StyxDeserializerImpl.java | Updated to use factory methods for message creation |
| StringSerializerImpl.java | Added serialization support for new message types |
| Multiple test files | Updated imports and added comprehensive test coverage |
| final var feature = mTransmitter.sendMessage(tWalk, mClientId); | ||
| final StyxMessage rWalk = feature.getResult(mTimeout); | ||
| if (rWalk.getType() == MessageType.Rerror) | ||
| throw StyxErrorMessageException.newInstance(((StyxRErrorMessage) rWalk).mError + " at " + mPath); |
There was a problem hiding this comment.
The removal of the path validation check could cause silent failures. The original code verified that ((StyxRWalkMessage) rWalk).qidList.size() != tWalk.getPathLength() and threw an exception if the path wasn't fully traversed. Without this check, partial path walks may be incorrectly treated as successful.
| throw StyxErrorMessageException.newInstance(((StyxRErrorMessage) rWalk).mError + " at " + mPath); | |
| throw StyxErrorMessageException.newInstance(((StyxRErrorMessage) rWalk).mError + " at " + mPath); | |
| // Path validation check: ensure full walk | |
| int requestedPathLength = StyxSerializerImpl.splitPath(path).size(); | |
| if (rWalk instanceof com.v2soft.styxlib.l5.messages.v9p2000.StyxRWalkMessage) { | |
| var rWalkMsg = (com.v2soft.styxlib.l5.messages.v9p2000.StyxRWalkMessage) rWalk; | |
| if (rWalkMsg.qidList.size() != requestedPathLength) { | |
| throw new StyxException("Walk failed: only " + rWalkMsg.qidList.size() + | |
| " of " + requestedPathLength + " path elements traversed for path '" + path + "'"); | |
| } | |
| } |
| var walkMessage = (StyxTWalkMessage)message; | ||
| size += 4 + 2; | ||
| for (var pathElement : walkMessage.getPathElements()) | ||
| for (var pathElement : walkMessage.mPathElements) |
There was a problem hiding this comment.
[nitpick] Direct field access to mPathElements bypasses potential null checks or validation that might exist in getter methods. Consider maintaining the getter method approach for better encapsulation.
| for (var pathElement : walkMessage.mPathElements) | |
| for (var pathElement : walkMessage.getPathElements()) |
No description provided.