I am very pleased to announce general availability of VI (VSphere) Java API 2.0 today. The 2.0 release represents 6 months of continuous (spare time) engineering effort since this January. It has packed many features:

• New high performance web service engine. When I told people that we replaced AXIS, most of them wanted me to confirm what I said. The new engine is 15X times faster in loading, 4+X in de-serialization than AXIS 1.4 with only 1/4 of size.
• vSphere 4 support.
• REST client API.
• Caching framework API.
• Multiple version support with single set of APIs.
• Clean licenses. The API and dependent dom4j are all BSD licenses.

This GA release fixed the following bugs. Many thanks to my colleagues Veronika Fleisher, Daniel Parrella and Gavin Gray for final QA for this GA release.

• 2795610 NoSuchFieldException on EventManager.queryEvents. Thanks to Hai Nguyen.
• 2798429 Caching: NPE occurs if a watched entity's value is null. Thanks to James Burke.
• 2800694 overwriteCustomizationSpec should not take a String. Thanks to Gavin Gray.
• 2810870 XmlGen.java does not compile with JDK6U13 or later. Thanks to George Costea.
• 2811320 Method back compatibility. Thanks to Joe Zeppy for his question on the forum that reminded me of this bug.

I would like to thank all the community for the support/help. During 2.0 development, 47 bugs were reported and 45 of them are fixed/closed.

Moving forward, we are planning the new features of 3.0. Please let me know what you want from the API by filing feature requests here.

Steve Jin

The same day a year ago, I released the first version of VI Java API. It's been downloaded for 2,300+ copies (not including VMware internal downloads) and used widely since then.

Today, I am pleased to announce another important milestone -- the vSphere 4 support with VI Java 2 Beta 3 ( With the name change of VI to vSphere, should we change the API to vSphere Java API as well?).

As you will find out, it has 20+ more managed object types and many more data object types. The way how it works remains the same. All you need to do is to get familiar with the additional classes and methods.

To patch the interface changes (about 10 methods), VI Java API adds additional shorthand methods. So your existing application runs as it is using VI Java API.

I plan to GA the VI Java 2.0 in a month. Please give beta 3 a try and help to file bugs.

Steve Jin

It's been a month since the 2.0 beta 2 update 2 was released. I haven't received any critical bug for one month. The API especially the web service engine is now stable.

This new 2.0 beta 2 update 3 is mainly about a new experimental feature - the caching framework. It not only caches the content, but also watches the changes on the server side for you. If you want to develop a large scale application, this feature is what you want. Check out this sample code to find out how to use it

Same as the rest of the API, you will find it very easy to use. Please let me know how you like the caching framework and how you would like to improve it.

Also included in this release is a fix to the following bug:

2785235 searchManagedEntity() fails on empty managed entity

I am considering to add two new pages on project home:

• List of the products/projects/companies who use the VI Java API.
• Users' testimonials. Tell us your sucess story.

Please let me (sjin at vmware.com) know if you or your company is interested to leverage this opportunity.

Steve

On April 21, VMware launched vSphere 4 -- the industry's first Cloud Computing System. It was a great event with a lot of media coverages.

Coming with vSphere 4 is the vSphere SDK. We are ready to support it. The internal version of the API has been tested against the latest vSphere SDK. Once vSphere GAs, we will release the new API so that you can start to leverage the new features of vSphere 4.

Stay tuned...Please sign up the RSS feed for notification.

Steve Jin

As of today (April 11, 2009), VI Java API has got 2,004 downloads. Quite an acceleration of adoption since 2.0 Beta was released in Feb. For the first 1,000 download milestone, it took about 8 months; for the second 1,000 downloads, it only took about 3 months even though 2.0 still in Beta. I expect it will take even less time for the next 1,000 downloads after 2.0 GAs.

After two beta releases and several updates, the VIJ is now stabilized, and also optimized. We don't have critical bugs on the project tracker now. Although the first beta outperforms AXIS several times, the latest beta 2 u2 is two times faster than the first beta. One of the developers told me he observed 10+ speed improvement in his application.

Other major technical benefits include:

• The code size is much smaller: 1/5 of AXIS 1.4, and 1/40 of AXIS 2. Yes, you read it correctly. It is 1 to 40 in size compared with AXIS 2.
• VIJ 2.0 works for all the versions of VI, despite their namespace difference. If your application has to work with multiple version of targets, the space saving is even more -- as high as 1: 120.

Business wise, the VI Java API license is very clean. The API itself and the dependent dom4j are all coming with BSD type license, one of the most lenient license types. You can redistribute them with your application with a peace of mind. This is critical for ISVs -- you don't want your customers to download and configure AXIS after installing your software.

Behind the success of the VI Java API project is an active community. I would like to thank everyone in the community who provided suggestions, tried the API, filed the bugs, promoted the API and helped others to use the API in various forums.

Looking into future, we need your help to share success stories with others so that more people in the VMware community can leverage the power of VI Java API.

Steve Jin

This update release fixes the following two bugs:

• 2738911 IllegalArgumentException from retrieveObjectProperties()
• 2738959 InvalidLogin should be throw from login method

Many thanks to the folks who reported/filed the above bugs: Andrew(Hyper9), Steve Strassmann, Gavin Gray(VMware), and one anonymous user (turned out to be Brian McFeely from TripWire, 2738911) who not only correctly analyzed the root cause, but also provided a quick fix.

Bug 2738911 causes an application fail after calling the retrieveObjectProperties() for about 200 times. Since this method is used by many getters, you might easily get into this problem. That is why it's an urgent update.

To get notified about future releases and project news, please sign up project RSS feed.

Steve Jin

A new update to the VI Java API 2.0 beta 2 was just released to fix the following bugs:

• 2710085 Unable to serialize java.lang.Byte
• 2717348 issue with queryPerfCounter() call
• 2721464 Issue with returning Calendar
• 2722374 Issue with returning ManagedObjectReference[]
• 2722381 issue with multiple XML parsing
• 2726014 issue with findExtension method when none found
• 2726016 issue with methods returning ManagedObjectReference[]
• 2726018 Error with configureLicenseSource

Many thanks to the folks who reported/filed the above bugs: George Costea, Eric Forgette (NetApp), Daniel Parrella (VMware), and two anonymous users (2717348, 2721464)

The big thing of this release is another round of refactoring and optimization. For the same test application we tried with beta 2, it now takes 0.840s -- 0.05s reduction from the beta 2. Taking away the time spent on the server side, it's 0.120s vs 0.170s. Quite a good result!

So what changes got us this result?

First of all, the class type caching is added. Previously we call Class.forName() for every data object types in the com.vmware.vim25 package. Now it's called only once and placed into a HashMap object.

Secondly, remove un-necessary object instantiation. For example, I used to have a method to create an ArrayList object for all the elements which has the same tags. This method is changed to return only the number of the same tags.

Thirdly, change the string comparison to the type comparison. For example, I used to compare the object's type name to "ManagedObjectReference." We now just check with the following:

fRealType == ManagedObjectReference.class

Last, but not least, I start to use parallel garbage collector in the testing. All needed is to add the following option to the command: -XX:+UseParallelGC

If you run your application with Eclipse, you can go to the "Run" dialog, click on the "Arguments" tab and add the above in the "VM arguments."

The parallel GC made a big difference with the test application, which retrieves properties from 51 managed objects for 60 times. In each retrieval, a lot of objects get created -- DOM objects after the initial parsing, the data objects for all the properties.

To get notified about future releases and project news, please sign up project RSS feed.

Steve Jin

After the beta one and three updates therefore, we finally hit Beta 2 which includes all the fixes to the bugs the community has reported. It's now stable than ever. We're on track to GA release synchronized with next major VI SDK release.

In addition, beta 2 has moderate performance improvement and fixed following bugs:

• 2692371 OptionManager#getSetting() fails -- a typo in property name
• 2692265 Update readme with latest information
• 2690376 Incorrect serialization of Calendar if first level object
• 2689088 Using streaming feature in parsing XML
• 2688913 Typo in the VIM20 namespace
• 2685661 si.invoke("currentTime") does not return valid result. Note: the client REST API behind this bug is experimental.

Many thanks to the folks who reported/filed the above bugs: Brian McFeely (TripWire), Andrew Kutz (Hyper9), soyuppy, Kem, Trak Marba.

The big thing of this release is the optimization of the web service engine, mainly leveraging the streaming feature of the XML parser. So don't be surprised to notice the performance improvement.

In my test application which grabs all the properties of 50 managed objects, it takes about 0.930s on average of 60 times with beta 1. With this beta 2, it takes about 0.890s. From its face value, it's not big deal. But when breaking down the time, I find it's not bad at all.

In both cases, about 0.720s is spent on waiting for the server. So the real time on the client side is about 0.210s (b1) vs 0.170 (b2). Among them, about 0.094 is spent on XmlGen. So b1 takes about 0.106s to read SOAP response message, manipulate the string, and then parse the XML; b2 takes about 0.66 to read and parse.

Why is b2 faster? Instead of receiving the whole SOAP return as a string, b2 now hooks the InputStream to the dom4j parser directly. Therefore the parser can work in parallel while waiting for more data from the server. Essentially we get the XML parsing almost for free.

To download, visit here

To get notified about future releases and project news, please sign up project RSS feed.

Steve Jin

A new update to the VI Java API 2.0 beta was just released to fix the following bugs:

• 2671806 Need a method to specify the namespace of a target
• 2665725 createSnapshot_Task(...).waitForMe() throws RemoteException
• 2663642 PerformanceManager.queryPerf fails with Exception
• 2657981 Task.waitForMe should throw appropriate MethodFault
• 2657952 HostSystem.reconnectHost does not follow "_task" convention
• 2655705 WSClient.invoke attempts to instantiate enum
• 2646499 Task.waitForMe prints stack trace output from MethodFault
• 2639448 OptionManager.updateOptions() does not work
• 2639433 The searchDatastore_Task() returns null

Many thanks to the folks who reported/filed bugs: David Kelly(NetApp), James Burke (NetApp), Steve Strassmann(VMware), Garvin Gray(VMware), Daniel Parrella (VMware), Ryan Stokes, HiepFirescope(VMware Community ID), Andrew Kutz(Hyper9).

To download, visit here. The more we use the API, the more stable it will be. I am committed to make it the best of its kind.

BTW, the API was used in the vCloud demo of VMware CTO Steve Herrod's keynote at VMworld Europe 2009. Check it out here

To get notified about future releases and project news, please sign up project RSS feed.

Steve Jin

As of today, the project summary feed shows 1,500 downloads, quite a boost from last year which saw 1,025 downloads in 8 months. The newly released 2.0 brought in much needed performance boost, and the legal cleaness. All the code in 2.0 are under BSD type of licenses, which are great for the ISVs to freely redistribute the API with their applications written on top of 2.0. The user experience can therefore be much better. You don't want to ask your users, and they don't want neither, to download another package and configure it after your application is installed.

Currently 2.0 is still in beta, please help to give it a try and file bugs with the project tracker.

Steve Jin

An update to the VI Java API 2.0 beta update 1 was released to fix the following two bugs:

• 2625999 Typo in a method name of TaskManager
• 2626003 Null is returned for the existing Multipath policy

To download, visit here. The old beta update 1 was taken offline.

To get notified about future releases and project news, please sign up project RSS feed.

Steve Jin

An update to the VI Java API 2.0 beta was released to fix the following two bugs:

• 2597336 Error is serializaation enumeration data type
• 2596689 Error in serializing Calendar data type into XML

If you use a method whose parameters include either Calendar type or enumeration type and you happen to use them, you are affected. Please download this update. Visit here. The old beta was taken offline.

Steve Jin

I am very pleased to announce the VI Java API 2.0 Beta. It comes with many feastures and improvements as follows:

• High performance Web Service Engine to replace AXIS. It's about 15 times faster in loading the library, and 4+ faster in serialization/deserialization than AXIS.
• Much smaller size of libraries, 1/5 of what is required using AXIS.
• POJO Data Objects and Java Enum Types.
• REST Client API. It's a super light weighted library.
• Updated samples using the APIs.
• Multiple version support with same library.
• Easy access the SOAP response, allowing further performance optimization for demanding applications.

To download the binary and source code, click here Given the increased size, the binary (.zip) and source (.jar) are packaged separately for the first time.The binary also include the dom4j 1.6.1 binary. That is the only 3rd party you will need. No AXIS anymore!

The VI Java API interfaces do not change, so the applications still work. Since Java enum type is used for XML enumeration types, the related code to access these types may need to be updated. Check out the samples to find more.

Steve Jin, Creator of VI Java API

This minor release fixes several bugs reported by the community, and includes one more sample code.

The bugs addressed are:
• 2538326 NPE with PropertyCollectorUtil multi-properties. Check out the MultiProperties.java in the sample folder on how to tell a null value in the Hashtable returned from retrieveProperties() method
• 2488659 NoSuchMethodException while calling getEffectiveRole() on VM.
• 2188735 Tries to instantiate abstract classes.

To download the latest, click here

Since its debut in May 2008, VI Java API has quickly caught the attention of VMware developer communities due to its elegant design and simplicity. As I know, many commercial companies use it for their product development and really enjoy the benefits the API brings in.

Accoding to the project statistics, it hit the 1,000 download milestone days ago. As of today, the total number of direct download is 1,025.

Many thanks for your support and I look forward to bringing you more features in 2009!

Happy New Year!

Steve Jin, Creator of VI Java API

Five months after the first release, we are glad to announce the version 1.0 is ready for you to download. Besides bug fixes, we also added more support on retrieving multiple properties from single or multiple managed objects. You can find out how to use by reading a new sample code MultiProperties.java.

You can download the 1.0 release and start playing with it. Please let us know any bug and what else you want for future releases by filling out a tracker item.

VMWorld took place in Las Vegas with record 14,000+ people in the industry event. Register here for two VMWorld keynote speeches by Paul Maritz (CEO) and Steve Herrod (CTO).

Jython looks very much like Python. If you know how to program Python, you pretty much know how to code in Jython.

With the VI Java API, it's made possible to manage VMware Infrastructure with Jython. Please check out this presentation to get started with Jython programming.

There are 18 more samples released into the project depository including networking, scheduling, virtual machine management, session management, event management. Please check them out here .

I'm very pleased to introduce Andrew, who recently joined our open source project. Andrew has been very active in VMware developer community and is now VMware valued community member. He has done many great projects in VI plugin, VI SDK, etc. His postings are among the most viewed by the VMware community. To know more about him, please take a look at the VMware community blog by Pablo Roesch.

Andrew has decided to combine his VI Java toolkit into VI Java API project. He will help with the devleopment of VI Java API project.

Please join me to welcome Andrew on board!

-Steve Jin

The Virtual Infrastructure API just got open sourced under BSD license. This API aims to simplify the VI SDK web services interface and improve productivity.

The key benefits include:

• Enables OO programming with a well defined managed object model
• Reduces the need to use ManagedObjectReference
• Hides the complexity of the PropertyCollector
• Provides necessary utility classes to simplify VI SDK web interfaces
• Leverages current VI SDK web services interface while keeping it intact

The downloadable jar you will find in the download page is very small (264KB ompressed), but includes binary, source and 10 sample code.

To find out more about this API and the object model behind it, please check out these two documents: Get started with VI Java API (2 pages),and Object model of VI Java API (3 pages)

To download the API package, please start here and choose latest build. This project is an open source project, please feel free to leverage this API and share your experience with the rest of community.

We look forward to hearing from you. If you would like to help with the API development itself, please let us know and we will love to have you.