[Submission]: Qiskit4Java

[gnietof]

Project name

Qiskit4Java

Description

A set of Java classes which allow interfacing with IBM Quantum from Java. 
The idea is being able to run primitives from Java without having to deal with Python. So, classes to deal with Pauli, Primitives, Backends ... are included.

Contact email

genaro@es.ibm.com

Category

SDK

Labels

No response

Qiskit Pattern steps

Execute on hardware, Post-process results

GitHub repository

https://github.com/gnietof/QREST

Home page

No response

Documentation

No response

Packages

Reference paper

No response

Code of Conduct

• I agree to follow the Qiskit Code of Conduct

[mtreinish]

Does this library interface with the qiskit c API or is it just an independent Java library that doesn't link against qiskit?

[gnietof]

No. This is an API which interfaces with the REST API provided by Qiskit. Kind of a REST API wrapper.
Although some code has been added to deal with Pauli, SparsePauliOp, Primitives and so on.

[mtreinish]

Qiskit doesn't provide a REST API. IBM quantum computing service does and while the service is branded with qiskit in the name it's not part of open source qiskit library itself. I would ask that you rename the library to make it clear this doesn't integrate with the Qiskit library and is about calling IBM Quantum's REST API. I'm worried this will be potentially confusing especially as there are language bindings to Qiskit's C API under active development (see: https://github.com/Qiskit/qiskit-cpp, https://github.com/Qiskit/qiskit-rs, and https://github.com/Qiskit/qiskit.jl/ ) so if someone were to develop a Java binding to the C API it would be easy to confuse with this library.

[gnietof]

I agree with you. In fact, the repository for this code is called QREST.

But, in the end, the objective for this piece of code is making it possible to run quantum circuits from Java. So, maybe, that should be mentioned somehow in the name. Thoughts?

[gnietof]

I have also included a few classes to be able to create circuits in Java. That is just a work in progress. More testing than usable.
But once again, the idea is just generating the QASM to be transpiled using either the Cloud service (if available, not to me in my open account) or through the TranspilationService I included which runs a Python service in local.

[gnietof]

I have been having a look at the repositories you mentioned. I also have something similar. Still early stages.

QuantumRegister qr1 = new QuantumRegister(1);
QuantumRegister qr2 = new QuantumRegister(2);
QuantumRegister qr3 = new QuantumRegister(2,"x1");
ClassicalRegister cr1 = new ClassicalRegister(1);
ClassicalRegister cr2 = new ClassicalRegister(2);

List<String> names = Register.getRegisters();
for (String name: names) {
	System.out.println(name);
}

QuantumCircuit qc = new QuantumCircuit(qr1,qr2,cr1);
qc.h(0);
qc.x(1);
qc.h(1);
qc.cx(0,1);
qc.cx(1,2);
qc.cx(List.of(0,1),2);
qc.cx(qr2,qr3);

System.out.println(qc.dump());

And then this is the dump output. Python code.

q0 = QuantumRegister(1)
q1 = QuantumRegister(2)
c0 = ClassicalRegister(1)
qc = QuantumCircuit(q0,q1,c0)
qc.h(0)
qc.x(1)
qc.h(1)
qc.cx(1,1)
qc.cx(2,2)
qc.cx(2,2)
qc.cx(2,2)
qc.cx(0,0)
qc.cx(1,1)

So that is one piece. My main focus was on being able to submit circuits from Java:

Backend backend = service.backend(BACKEND);

Estimator estimator = new Estimator(backend);
String qasm = "OPENQASM 3.0;include \"stdgates.inc\";rz(pi/2) $0;sx $0;rz(pi/2) $0;rz(pi/2) $1;sx $1;rz(pi/2) $1;cz $0, $1;rz(pi/2) $1;sx $1;rz(pi/2) $1;";
SparsePauliOp observables1 = SparsePauliOp.fromSparseList(new Paulis(new Pauli("YZ", new int[] {0,1},2),new Pauli("ZY", new int[] {0,1},1)),2);
SparsePauliOp observables2 = SparsePauliOp.fromSparseList(new Paulis(new Pauli("XZ", new int[] {0,1},1),new Pauli("ZX", new int[] {0,1},2)),2);
EstimatorPUB pub1 = new EstimatorPUB.Builder().
		circuit(qasm).
		observables(List.of(observables1.getPaulis())).
		build();
EstimatorPUB pub2 = new EstimatorPUB.Builder().
		circuit(qasm).
		observables(List.of(observables2.getPaulis())).
		build();

Job job = estimator.run(List.of(pub1,pub2));
if (job!=null) {
	service.tags(job.getId(), new Tags("Broad","Estimator"));
}

And then retrieving the results.

PrimitiveResults results = service.jobResults(job.getId());

for (Result result: results.getResults()) {
	SamplerData data = (SamplerData) result.getData();
	Map<String, SamplerRegisters> registers = data.getRegisters();
	for (String key1 : registers.keySet()) {
		System.out.println(String.format("\n\n** %s",key1));
		SamplerRegisters register = registers.get(key1);
		for (int i=0;i<register.size();i++) {
			System.out.println(String.format("\t%d",i));
			BitString ss = register.getBitString(i);
			System.out.println(ss);
			Map<String, Long> counts1 = register.getCounts(i);
			for (String key: counts1.keySet()) {
				Long count = counts1.get(key);
				System.out.println(key+": "+count);
			}
			Map<Integer, Long> counts2 = register.getIntCounts(i);
			for (Integer key: counts2.keySet()) {
				Long count = counts2.get(key);
				System.out.println(key+": "+count);
			}
		}
	}
}

I guess both pieces should go together.

[1ucian0]

So, maybe, that should be mentioned somehow in the name. Thoughts?

IBMQuantum4Java ? Keeps the spirit of the original name and makes it more clear, I think.

[gnietof]

I do like the name. Although it sounds 'pretentious' to my initiative. 😄
I was wondering if the name should follow the naming above. Something like qiskit-java (which I like less than your suggestion).

Other than the name, I do not know if there are additional steps pending on my side.

[1ucian0]

Indeed... the only blocker right now is the name.

Some other suggestions, if it helps:

• qasm2ibm4java or openqasm2ibm: Read as (Open)QASM to IBM for Java. It makes the input format clear and specifies that IBM services are the target.
• jqasm2iqp or qasm2ibm: Similarly, QASM to IBM Quantum Platform. Also includes the input format and target. j for Java, although it may not need to be explicit since Java can be a label or topic. IQP is a common acronym for IBM's platform.
• ibmquantumqasmclient: Fits your current description from the README (Java implementation of a REST client for IBM Quantum) and is descriptive of the current functionality.
• ibm-quantum-client-for-openqasm: Also straightforward match for the described functionality.
• qasmsubmitter: A totally different approach. It says "this takes a quantum circuit as QASM and submits it somewhere".

Another option is to go full fantasy, like quantumcoffee or QASM-brew.

The main problem with the current name (Qiskit4Java) is that the package is not related to Qiskit in any way, as mentioned. It takes a standard format, OpenQASM, which may or may not be generated with Qiskit, and submits it to one of the IBM services. It does not bind to https://github.com/Qiskit/qiskit-ibm-runtime-c or use the C API from the Qiskit SDK. It also does not allow creating or manipulating quantum circuits as objects (which is a core part of Qiskit) beyond a OpenQASM description of them.

Please do not take this the wrong way. It is great to have a client that lets Java users submit OpenQASM to IBM Quantum services. You explain it very nicely in the README. The name is just a bit confusing. And don't worry, you are dealing with one of the hardest problems in computer science.