Java wrapper for SDK

[lukpotSym]

Type of change

- [ ] Bug fix
- [x] New feature development
- [ ] Tech debt (refactoring, code cleanup, dependency upgrades, etc)
- [ ] Build/deploy pipeline (DevOps)
- [ ] Other

Objective

Added a Maven-based Java project that wraps native C library for the SDK and exposed its commands through BitwardenClient class.

Code changes

• Updated schemas.ts to generate Java classes for the API - difference with current generators is that it creates multiple files
• Added BitWardenClient class as a wrapper for the native SDK library
• BitwardenLibrary inteface uses JNA to link to the native lib
• AutoCloseable inteface implemented to deal with freeing memory, client can be used with try-with-resources or close() can be called explicitly (finalize() method is deprecated in newer Java versions)

[Hinton]

Please follow the .NET sdk and unwrap all responses. A consumer of the library shouldn't be exposed to the internal response models.

[vgrassia]

Workflows look good to me.

[dani-garcia]

Code looks good to me, two small naming changes, but I don't think they are very important

[bitwarden-bot]

Checkmarx One – Scan Summary & Details – 9e449228-3143-43b1-8a67-570a00135650

New Issues

Severity	Issue	Source File / Package	Checkmarx Insight
	Reflected_XSS	/languages/kotlin/app/src/main/java/com/bitwarden/myapplication/MainActivity.kt: 294	Attack Vector
	Unchecked_Input_for_Loop_Condition	/languages/kotlin/app/src/main/java/com/bitwarden/myapplication/MainActivity.kt: 294	Attack Vector

Fixed Issues

Severity	Issue	Source File / Package
	Reflected_XSS	/languages/kotlin/app/src/main/java/com/bitwarden/myapplication/MainActivity.kt: 115
	Unchecked_Input_for_Loop_Condition	/languages/kotlin/app/src/main/java/com/bitwarden/myapplication/MainActivity.kt: 115

[Hinton]

Some minor nits, please also run intellij reformat code since many of the members can be made final.

[Hinton]

Minor nit remaining in the readme, looks good otherwise.

[lukpotSym]

Hi @dani-garcia @Hinton, I re-requested the review since some prechecks failed - a folder name for generate schemas wasn't updated after changing package name, and schemas.ts file needed prettier reformat. It seems I need approvals for prechecks to run again, hopefully they will pass this time.

[dani-garcia]

Seems the android workflow doesn't work correctly with external PRs and is failing, but that's not related to these changes.

[lukpotSym]

Seems the android workflow doesn't work correctly with external PRs and is failing, but that's not related to these changes.

Yes, android fails for all external PRs. I fixed a gradle issue that appeared on java workflow, it passes locally, but need to confirm if it now works on github environment

[dani-garcia]

The java workflow seems to be failing still. I can reproduce the issue locally if I copy the libbitwarden_c.dylib file myself into src/main/resources/darwin-aarch64. If I run gradle jar after that, the build fails.

To solve it I just commented this whole block:

/*
jar {
//  Requires GitHub workflow to copy native library to resources
//  Uncomment the line below and copyNativeLib task above to use the local build (modify architecture if needed)
//    dependsOn tasks.named("copyNativeLib")
    into('darwin-aarch64') {
        from 'src/main/resources/darwin-aarch64'
    }
    into('darwin-x64') {
        from 'src/main/resources/darwin-x64'
    }
    into('ubuntu-x64') {
        from 'src/main/resources/ubuntu-x64'
    }
    into('windows-x64') {
        from 'src/main/resources/windows-x64'
    }
}
*/

The native libraries seem to be copied just fine as long as they are in the resources folder, and the error goes away, maybe that can work for CI too? For local development you can uncomment the copyNativeLib task and use that to copy the files to the correct place.

[lukpotSym]

The java workflow seems to be failing still. I can reproduce the issue locally if I copy the libbitwarden_c.dylib file myself into src/main/resources/darwin-aarch64. If I run gradle jar after that, the build fails.

To solve it I just commented this whole block:

/*
jar {
//  Requires GitHub workflow to copy native library to resources
//  Uncomment the line below and copyNativeLib task above to use the local build (modify architecture if needed)
//    dependsOn tasks.named("copyNativeLib")
    into('darwin-aarch64') {
        from 'src/main/resources/darwin-aarch64'
    }
    into('darwin-x64') {
        from 'src/main/resources/darwin-x64'
    }
    into('ubuntu-x64') {
        from 'src/main/resources/ubuntu-x64'
    }
    into('windows-x64') {
        from 'src/main/resources/windows-x64'
    }
}
*/

The native libraries seem to be copied just fine as long as they are in the resources folder, and the error goes away, maybe that can work for CI too? For local development you can uncomment the copyNativeLib task and use that to copy the files to the correct place.

Thanks for the suggestion, it does indeed copy all resources without the jar task, and I've think I managed to set it up to correctly to copy local libs when uncommented.

[lukpotSym]

Hi @dani-garcia @vgrassia @Hinton , please let me know if the current Build Java SDK workflow failure is expected on the forked repo - publishing the package gets 403 forbidden error. I am using the same approach as the android build, with secrets.GITHUB_TOKEN.

[Hinton]

Pull requests from forks don't have access to the repository secrets and the GH token is read only. I would expect the publish step to fail but all steps leading up to it should succeed.