Getting started with OCI SDK 3.x for Java

Getting started with OCI SDK 3.x for Java

Hello & Happy New Year!

Today we'll see how to get started with the Oracle Cloud Infrastructure (OCI) Java SDK. The Java SDK enables you to interact & manage Oracle Cloud Infrastructure resources right from your code.

The aim of this project is to be able to authenticate to your account via the SDK, and to start playing with Object Storage by listing pre-existing buckets.

The tech setup is a local windows machine & Eclipse IDE with Maven2Eclipse installed.

Don't have time to bother with the local configurations? You can also directly connect to the Cloud Shell and use pre-built examples to test it and skip this article !

I'll be assuming you have access to your OCI account & you'll be using your own user. Othe pre-requisite: have Java 17 (or 11 or 8) configured.

If you haven't done so already when working with the OCI CLI, you'll need a local config file (there are other methods) which contains a few necessary information (reference to your private key for authentication, tenant OCID, etc.) . You can simply create by following those steps or go to the official documentation.

Step 1 : Create a maven project

I did it directly from the Eclipse IDE via the maven 2 eclipse plug-in. There should be no specific difficulty in using the wizard to create a new Maven Project. I've chosen the simple quickstart archetype :

If all goes well, you should have a structured java project like this without error (with a working Hello World app):

Step 2 : Adapting your maven project

1st method : the uber jar (failed for me)

To add the OCI SDK to my project, I edit the POM.XML with the following dependency which is supposed to import an uber jar with all the SDK and its dependencies locally renamed (shaded) to avoid any conflict (more information in the documentation ) :

After facing what I thought were authentication-related responses, I added the following dependency

<dependency>
<groupId>com.oracle.oci.sdk</groupId>
<artifactId>oci-java-sdk-common-httpclient-jersey</artifactId>
<version>3.0.0</version>
</dependency>

Unfortunately I stumbled upon this kind of error later (despite successful builds and no errors on Eclipse) when trying to run my code :

The NoSuchMethodError related to shaded.com.oracle.co.javasdk.com.fasterxml... was a mystery to me after (a lot of) tries so I decided to have more control over the dependencies by reverting to the 2nd way of using the SDK in my project.

2nd: importing separate dependencies (worked for me)

I don't want to paraphrase the documentation here, in a nutshell this method consists in choosing the SDK's specific dependencies you'll need to run the project.

A few tips ...

If you noticed, I added the SL4J dependency to better debug it. In Eclipse, I changed the debug level by right-clicking on my app, and changing the VM argument:

Finally : Coding & Running the app

We can then work on the client app code. There are many examples available on OCI Java SDK github, I personnally used this one for a simple test of Object Storage.

Here is a link my adapted version of it if you're interested. It requires you to create a few Object Storage buckets first to check if it works, and note down (from the UI) your buckets' compartment identifier called "OCID". Otherwise by default it will search for buckets in the root compartment.

Next we validate the project, test, compile & package it by right-clicking in Eclipse and using "clean verify" and then "package" as a goal (more info on maven lifecycle here).

The build should be successful and look like this :

We can finally run the app also directly from Eclipse (Run as -> Java App) and we get the following type of output in our console.

You have now opened the gate to the OCI SDK for Java. I hope you enjoyed the reading ! See you later for other posts !

Walid Hajeri

Further reading :

What's new in OCI Java SDK v3: https://blogs.oracle.com/cloud-infrastructure/post/announcing-oci-java-sdk-300

https://github.com/oracle/oci-java-sdk/releases

Disclaimer : Views are my own , none of the ideas expressed in this post are shared, supported, or endorsed in any manner by my current employer.