JAVA-5505 minor refactoring #1488
Conversation
There was a problem hiding this comment.
I am not sure it's wise to refactor tlschannel code, which at some point we may have to synchronize with the upstream again. Detecting which discrepancies are functional and must not be lost when we synchronize, and which were done for other reasons, may be more difficult if we change the tlschannel code without necessity.
| @@ -159,7 +159,7 @@ static final class WriteOperation extends Operation { | |||
|
|
|||
| private final Selector selector; | |||
|
|
|||
| final ExecutorService executor; | |||
| private final ExecutorService executor; | |||
There was a problem hiding this comment.
@stIncMale I can roll back the finals. The reduced visibility refactor would ensure that (in the near future) the user-set executor is not shut down from outside this class. Up to you - is this worth the potential future merge conflict?
There was a problem hiding this comment.
This looks like something worth discussing the team on the catchup meeting, or asking Jeff/Ross here, as they are likely the only ones who have idea on our process of syncing the tlschannel code.
There was a problem hiding this comment.
Force rebased. Removed finals commit, kept visibility commit.
katcharov
force-pushed
the
JAVA-5505-refactor
branch
from
b490993 to
fc7b4b8
Compare
| @@ -702,7 +706,7 @@ public void shutdownNow() { | |||
| * | |||
| * @return whether the channel is terminated | |||
| */ | |||
| public boolean isTerminated() { | |||
| private boolean isTerminated() { | |||
There was a problem hiding this comment.
This change seems irrelevant to making sure that the rest of the tlschannel code can't terminate a user-supplied executor. If that's so, let's not do the change.
|
Test failures appear to be unrelated. |
JAVA-5505
Mostly-automated refactoring to remove IDE nags. I've left unused methods like
getCurrentRegistrationCountinAsynchronousTlsChannelGroup.