Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Introduce FileLockService.Locking to leverage try-with-resource-blocks #2853

Merged
merged 1 commit into from
Sep 27, 2023

Conversation

HannesWell
Copy link
Member

This allows to simplify the usage of the FileLocker/FileLockingService to:

try (var locking = fileLockService.lock(fileToProtect)) {
// do something
}

With this changes the FileLocker interface is only used in tests. Therefore my suggestion is to remove it completely and just use the FileLockService.Locking instead.

@github-actions
Copy link

github-actions bot commented Sep 25, 2023

Test Results

   561 files  ±0     561 suites  ±0   4h 36m 6s ⏱️ + 18m 0s
   363 tests ±0     357 ✔️ ±0    6 💤 ±0  0 ±0 
1 089 runs  ±0  1 070 ✔️ ±0  19 💤 ±0  0 ±0 

Results for commit 4654a3c. ± Comparison against base commit 5eabc18.

♻️ This comment has been updated with latest results.

@@ -20,11 +20,34 @@
*/
public interface FileLockService {

interface Locking extends AutoCloseable {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do we need a new interface and can not simply use the existing FileLocker one?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As said above, actually the FileLocker interface is not necessary anymore with this auto-closable style.
And from the name FileLocker describes something that can lock something (in this case a file), the implementation of Locking represent a locked state (it could also be named LockedFile or similar). Therefore I would just remove FileLocker and add something that reflects the state representation better and just extends AutoClosable.
That being said, I mainly introduced Locking just because AutoClosable throws an Exception. But using Closable instead only throws an IOException which is already handled in almost all callers anyway.

For now I removed the FileLocker interface entirly and only kept FileLockerImpl as an implementation detail of FileLockServiceImpl that is queried in the FileLockServiceTest. But if there would be a real isLocked checked in the test, even FileLockServiceImpl could become a hidden internal class of FileLockServiceImpl, probably stripped down to the minimum.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This interface originally used the Equinox resource API and was somehow driven by what this API offers, so from my side if Tycho does not use this functionality anymore it could be removed.

@HannesWell HannesWell force-pushed the simplifyLocking branch 3 times, most recently from 96d7bbc to 4713547 Compare September 26, 2023 23:47
This allows to simplify the usage of the FileLocker/FileLockingService
to:
try (var locked = fileLockService.lock(fileToProtect)) {
  // do something
}

Remove FileFlocker and simplify FileLockServiceImpl and FileLockerImpl.
@HannesWell HannesWell marked this pull request as ready for review September 26, 2023 23:50
@HannesWell HannesWell merged commit 05c76bd into eclipse-tycho:master Sep 27, 2023
8 checks passed
@HannesWell HannesWell deleted the simplifyLocking branch September 27, 2023 06:54
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants