refactor: Separate functions for encryption and decryption to HOEncryption

[sgcr]

1. changes proposed in this pull request:
   provided)
   Separate functions for encryption and decryption to HOEncryption.

2. src/main/resources/release_notes.md ...

• does not require update

[tychobrailleur]

New classes should be in Kotlin, in particular unit tests. I also think this refactoring does not bring much value, at this point, so I would keep those methods where they are, and convert the unit test to Kotlin.

[sgcr]

New classes should be in Kotlin, in particular unit tests. I also think this refactoring does not bring much value, at this point, so I would keep those methods where they are, and convert the unit test to Kotlin.

Thanks for the note. I acknowledge the long-term Kotlin migration goal for a potential Android port.

In this PR we’re adding exactly one new class plus one unit test, both in a Java-heavy area. Converting just these two files to Kotlin would be churn and sets an undesirable precedent where Kotlin becomes a review gate for small refactors.

I’ll keep this change in Java (focused on separating HO-specific encryption from a generic helper and adding regression coverage). Kotlin conversion should be done as an explicit, dedicated migration step when we actually scope and drive the Android/Kotlin migration.

Otherwise we’ll end up litigating “rewrite in Kotlin” on every small PR, which is not a good use of time given current priorities.

[tychobrailleur]

Otherwise we’ll end up litigating “rewrite in Kotlin” on every small PR, which is not a good use of time given current priorities.

Note that this “litigating” is only caused by the fact that you systematically ignore any comment to do so in the first place. You continuously dismiss any suggestion that does not meet your preference, ignoring the project context and other contributors' experience.

Also note that the big kotlin rewrite had attempts, but the direction from @wsbrenk was to first ensure sufficient test coverage before the migration, and then to progressively migrate to preserve git history.

I still fail to understand the value of this PR (and other ones), other than messing a bit more with git history, but at the very least it should be consistent with the rest of the codebase, and be HOCrypto or something like that (which, incidentally, would have fit in this at some point), because that's what the practice of the project is (please do not raise a PR renaming all the HO... classes to Ho...).

I do agree that given priorities, we have better things to do than this; I'll leave you and the project in peace, and do my own thing.

[sgcr]

I still fail to understand the value of this PR (and other ones), other than messing a bit more with git history, but at the very least it should be consistent with the rest of the codebase, and be HOCrypto or something like that (which, incidentally, would have fit in this at some point), because that's what the practice of the project is (please do not raise a PR renaming all the HO... classes to Ho...).

Renamed HoEncryption to HOEncryption to match the existing project naming convention (HO… prefix). No broader renaming intended.

[sgcr]

Just to be clear:
I’m not opposed to Kotlin - I’m fine writing Kotlin when it’s part of an actual, scoped Android port effort. What I’m pushing back on is making Kotlin conversion a default merge gate without a concrete Android plan (scope/owners/sequence), especially while there are still many bugs and low test coverage that we should address first.

For now I’m prioritizing robustness (small refactors that clarify responsibilities + add regression tests). Once we have an Android port plan and this area is explicitly in scope, I’m happy to migrate it to Kotlin as a dedicated step.

If it helps, I can open an issue to capture the Android port plan (milestones + which packages to migrate first), so Kotlin work is driven by a roadmap rather than by individual PR comments.

Also, Kotlin expertise/ownership is limited in the active team, so Kotlin as a merge gate increases maintenance risk.

[tychobrailleur]

For now I’m prioritizing

Case in point.

Kotlin expertise/ownership is limited in the active team

This is the whole point of getting people to start writing Kotlin code as part of new code: building that familiarity. We are all learning here. Kotlin is also very similar to Java, so Java expertise is pretty much sufficient from what I have seen.

Kotlin as a merge gate increases maintenance risk.

What maintenance risk? It has not been an issue to date – this comes across as “this will slow down my steady stream of cosmetic PRs because I prefer Java” more than anything else.

In any case, I am done. Best of luck with the project.

[sgcr]

Understood.

To make this less ad-hoc going forward, I’ve created two milestones: “Migration to Kotlin" and “Android App”, so language and Android-related work can be planned and tracked explicitly rather than debated in individual PRs.

I’ll keep this PR focused and move it forward accordingly. Thanks for the input so far.