Home > vSphere API > vSphere Java API 3.0 Kicks off, code name “Crescendo”

vSphere Java API 3.0 Kicks off, code name “Crescendo”

August 26th, 2010 Leave a comment Go to comments

WIth 2.1 GAed yesterday, I am happy to announce the 3.0 project kicks off officially. For more fun, I picked up a code name for 3.0 release: Crescendo. For folks know music, crescendo means music gets louder and louder. That is where I want to bring the project to. It’s been a huge success for this VMware sponsored open source project. We’ve had 9,000+ downloads, plus 1000+ SVN code sync, after its first debut in 2008.

So where are we going next?

Time to learn how to "Google" and manage your VMware and clouds in a fast and secure


Before answering the question, let’s take a look at the themes of previous releases. The theme of 1.0 was ease of use with full object model and getter methods hiding property collector. The theme of 2.0 was Just Enough High Performance Web Service Engine resulted in not only performance boost, but also clean license with pure BSD, and much smaller footprint and zero memory leak.

Now it’s time to re-visit ease of use again, but from a different perspective. As I discussed early, the learning curve of vSphere API comes from two folds: lack of object model, and complexity of data objects. The 1.0 release solved the problem nicely. Now it’s time to tackle the second one.

There are two possible ways to take care of this. First, provide more samples with better documentation as starting point. Secondly, come up with a higher level of APIs that capture the most common use cases so that you have a giant shoulder to stand on. Crescendo will take the second approach.

Let me give a quick example here. As today if you want to add a hard disk to a virtual machine, you have to use the reconfigVM_Task() method with tons of possible parameters while you actually need just a few. What is the point to read deeply into the parameter data objects? These parameters can easily get wrong. You can, for instance, mistakingly assign a unit number that has been taken by other devices under the same controller. Many more details exposed than needed. Therefore I see a need for a higher level APIs that address this use case with far simpler method.

This is just one sample of many common use cases you may find in real projects. To make sure it’s something you find useful, I would love to hear from you on how you use vijava today and what you wish to have in the future. If you have some code to contribute, that would be even better. I can use them as the base to abstract high level of APIs. I will give you credits whenever it’s due.

Architecture wise, the new layer won’t be mixed up with existing layer, meaning you have choice to skip this layer. But if not, you will enjoy a much higher productivity than using the current abstraction.

Another important thing is that crescendo will empower system administrators on writing automation scripts. The current vijava API is mainly targeted toward software developer even though we have nice jython, Groovy tutorials. With Crescendo, the scripts will be easier and shorter.

BTW, I will be at VMworld next week presenting vSphere API best practices, helping at VMware booth in exhibition hall, and book signing at bookstore (Tuesday 12:30~1PM). If you happen to be there, please feel free to stop by.

Categories: vSphere API Tags:
  1. Mikhail
    September 22nd, 2010 at 00:49 | #1

    Hi Steve,
    Didn’t you think about switching from DOM4J to StAX to parse XML?

  2. September 22nd, 2010 at 01:08 | #2

    I haven’t thought about that. What problem do you see using DOM4J?


  3. Mikhail
    September 22nd, 2010 at 05:28 | #3

    Well, StAX is the part of JDK since 1.6, so Vi Java will not depend on 3rd party lib.

    Also it’s reported that StAX is faster than DOM4J.

  4. September 22nd, 2010 at 11:55 | #4

    Given how StAX is implemented, it should be faster than DOM4J. However, I don’t expect noticeable difference in performance with StAX. Currently DOM4J parses the response while it waits more from the server. Faster parsing doesn’t help much on the overall completion time.
    For the dependency you have a good point there. Because DOM4J is BSD, I am OK with having this additional jar there.


  5. September 30th, 2010 at 20:35 | #5

    Just wanted to say, I love your work. I am just starting to code some utilities and hope to harness the multitude of images on and off…servers in windows in linux etc etc..

    Thank you! Big ups to the 5 minute starter

  6. Tulsi
    October 14th, 2010 at 01:35 | #6


    You rock. All the best for Crecendo.

    Are you planning to add some Meta Data API to expose the types, attributes and relations?

    Adding more examples will help too.

  7. October 14th, 2010 at 11:26 | #7

    Hi Tulsi,

    Currently there is no plan on meta data api in Crescendo release. But we can consider it in the future releases. Do you wan to to file a feature request with more details at http://vijava.sf.net (from Bug link)? Thanks!


  8. Bhushan
    October 27th, 2010 at 01:05 | #8

    Hi Steve,
    I had a query regarding how often is the vijava project updated
    corresponding to the updates in the VMware SDK? Do updates in VMware SDK get incorporated in vijava instantaneously or what is the usual time time lag?

    Please let me know


  9. October 27th, 2010 at 01:23 | #9

    Good question. vijava has been released consistently within one week of VMware SDK GA release. If you are existing VMware beta customer, you can have early access. In between, we have one or two update releases. Critical bugs have been fixed in 24 hours, and made immediately into subversion. Hope it helps.


  10. Tos2k
    February 22nd, 2011 at 12:39 | #10

    Hi Steve!

    Thanks for the impressive job you have done with vijava.

    Where is the main forum to post questions you will answer?
    I read that the current release does not support vApps, is that true?
    If I would implement that feature, what do you think about having the community participating in vijava (main public branch)?
    Why do not all entities like datacenter, folder, datastore provide a getVMs() method?
    Can you explain the main concept of vijava concerning that?

    Do you think that VMware one day will only publish your Java API? It has soooo many advantages, or is VMware adopting some of your development experiences/result?

    Dont know where the best place is to post that…


  11. February 22nd, 2011 at 13:34 | #11

    Hi Tos2k,

    I am glad you like the vijava API.

    1. The main forum for questions is here: https://sourceforge.net/projects/vijava/forums/forum/826592
    2. The vApps feature is supported in latest VI Java API 2.1. You can check out the VirtualApp managed object.
    3. getVMs() method is a getter method for the property vm defined in a managed object. If there is such a property defined, there will be a corresponding method; otherwise no. I try my best to make the API as close to the vSphere API spec. After all, VI Java is NOT another API, but an implementation of vSphere API.
    4. This open source API *IS* sponsored by VMware although it’s not an official product therefore no support. The VI Java community has done a good job to help each other and I believe we ran a great community forum.


  1. No trackbacks yet.