OrientDB is written 100% in Java. You can use the native Java APIs without any driver or adapter. Here is the Javadocs.
OrientDB provides 3 different Java APIs to work with OrientDB. Each one has pros and cons.
Which API to choose between Graph and Document? Look also at Graph-or-Document-API?.
Use OrientDB as a Graph Database working with Vertices and Edges. Graph API is 100% compliant with TinkerPop standard.
API: Graph API
Handles records as documents. Documents are comprised of fields. Fields can be any of the types supported. Does not need a Java domain POJO, as required for the Object Database. Can be used as schema-less or schema-base modes.
API: Document API
It's the JPA like interface where POJO are automatically bound to the database as documents. Can be used in schema-less or schema-based modes. This API hasn't been improved since OrientDB v1.5. Please consider using Document or Graph API by writing an additional layer of mapping with your POJO. While you can use both Graph and Document APIs at the same time, the Object API is compatible with Document API, but it doesn't work very well with the Graph API. The main reason is that you should create POJOs that mimic the Vertex and Edge classes with sub optimal performance in comparison with direct Graph API. For this reason we don't suggest to work with Object API with a Graph domain. You could evaluate using Object Mapping on top of OrientDB Blueprints Graph API, such as TinkerPop Frames, Ferma and Totorom.
API: Object Database
|API||Graph API||Document API||Object Database|
|Use this if||You work with graphs and want your code to be portable across TinkerPop Blueprints implementations||Your domain fits better the Document Database use case with schema-less structures||If you need a full Object Oriented abstraction that binds all the database entities to POJO (Plain Old Java Object)|
|Easy to switch from||Other GraphDBs like Neo4J or Titan. If you used TinkerPop standard OrientDB is a drop-in replacement||Other DocumentDB like MongoDB and CouchDB||JPA applications|
* Speed comparison for generic CRUD operations such as query, insertion, update and deletion. Larger is better. 100% is fastest. In general the price of a high level of abstraction is a speed penalty, but remember that Orient is orders of magnitude faster than the classic RDBMS. So using the Object Database gives you a high level of abstraction with much less code to develop and maintain.
OrientDB comes with some jar files contained in the lib directory
|JAR name||Description||When required||Depends on 3rd party jars|
||Remote client||When your application talks with a remote server|
||Deprecated since v2.2. Base package with the protocol and network classes shared by client and server||When your application talks with a remote server|
||Server component||It's used by the server component. Include it only if you're embedding a server|
||Contain the console and console commands||Never, unless you want to execute console command directly by your application. Used by the console application|
||Contain the Object Database interface||Include it if you're using this interface||
||Contain the GraphDB interface||Include it if you're using this interface||
||Contain the distributed plugin||Include it if you're working with a server cluster||