A salesforce.com colleague asked me last month if we could talk about something by video iChat; I replied that my current Mac was still my 12" G4/867 PowerBook, and I therefore did not have a camera immediately at hand. "A classic machine," he said approvingly, and I agreed -- I like the compact size and excellent keyboard. I added that I recognized the strengths of the newer Intel-CPU MacBook Pro systems, but that I saw no rush to upgrade before I could get one this month with the Unix and Xcode goodies of Leopard pre-installed.

Now, I'm wondering when the newborn Leopard will have its eyes fully open to developer needs. Issues of LAMP stack support and, in particular, Java 6 non-support are glowing white-hot on developers' thermal imagers, even while some extol Leopard's many developer-oriented benefits.

I've owned and used Macs of various sorts since 1985, side-by-side with DOS and Win3.x/9x and OS/2 and NT4 and Win2K/XP machines: I'm not religious about whether I do any given task on any particular system. There are tasks that I find easier to do with tools that I happen to have on my PowerBook, just as there some applications that I only have installed on a 1 GHz Win2K Vaio with only 256 MB RAM -- making it actually preferable to far more powerful machines for solving certain problems.

I'm dismayed, however, by the prospect that a MacBook Pro running Leopard might take some time to rise to the top of my list (it's fallen off James Gosling's, with Solaris engaging new interest) for Unix/Java-oriented development. It can't be a good sign that Java is literally nowhere mentioned on the "300+ New Features" page for OS X 10.5. JavaScript, yes; Objective-C 2.0, yes; even Ruby on Rails, yes. But Java support, which I've seen as a real strength of Apple's platform since 2002, is unaccountably absent from the list.

Is this an actual problem, or just the typical lag between an OS X update and Java support to match? Do you care? And if so, how will you respond?

Many customers and partners have a need to send emails when building integrations with salesforce.com.  With the APEX API's you can now leverage the platform to send emails.

You can send individual emails to email addresses, contacts, leads or users, and additionally you can CC or BCC email addresses to the email you are sending.

Mass Emails can be sent to contacts, users or leads, using templates. The API provides an option to save the email as an activity on the contact or lead you are sending the email to.

To see a code example and learn more about send emails through the APEX API click here.

For an example of using the sendEmail API in an scontrol, click here.

Below is a snippet of code to give you an idea of how easy it is to get started sending email on the platform.  We hope you can make use of this great new feature when leveraging the API to extend the platform!  

	       
 sendEmailResults = binding.sendEmail(new SingleEmailMessage[] {email});
		    	   
			        System.out.println(sendEmailResults);
		        
			           for (SendEmailResult sendEmailResult : sendEmailResults) { 
			                   if(sendEmailResult.isSuccess()){ 
			                         System.out.println("success"); 
			                   } else{ 
			                         System.out.println("error");
			                   } 
			           } 

In Java 6, Sun began shipping a web service stack with the Java SDK.   The stack is the Reference Implementation of JAX-WS, the new JCP standard API for web services.     During our first look at 2.0 last year, we found a few issues with the RI (e.g. no support for compression).  Since then, the folks at Sun have been working with us to make sure that the JAX-WS RI would work seamlessly with the Salesforce.com API.

As of this week, with the release of JAX-WS 2.1, it does.   

Sun was also kind enough to put together a QuickStart package for us, which you can now find over at our Wiki: JAX-WS QuickStart.     Check it out!   

We haven't run our own tests yet, but the reports we've heard on it's performance so far are promising.    The combination of a high performance web service stack with a standards based API that ships in the JDK has some real appeal.   

If you have any experience working with the JAX-WS RI, we'd love to your hear your thoughts in the comment section below. 

Axis 1.3 just shipped and now includes support for gzip compression in the CommonsHTTPSender class, I wrote up some notes on how to enable it.

SForce developer Simon Fell will be one of the speakers in the JavaOne session "Java and .NET: Interoperability Challenges and Rewards" (TS-3553, Wednesday 06/29/2005 4 PM)

Now that Axis 1.2 is GA, you might be tempted to move from your Sforce integrations from Axis 1.1 to Axis 1.2 (or if you're trying to move to Java 5.0, Axis 1.1 doesn't really work well with Java 5.0), if so here's a few of the gotchas you'll run into.

• Axis no longer generates a wrapper class for simple type restrictions, this means that the ID class disappears, ID is now treated as a plain jane String.
• The naming convention for some classes changed, mainly those that used to get a leading _ in the name no longer do, so _SessionHeader is now just SessionHeader
• For the Partner WSDL, query & retrieve calls that have null field values, will now correctly populate a null value in the Any array, however if you include Id in your field list, this will not appear in the Any collection (this is a bug in 1.2 that looks like it'll be fixed in the upcoming Axis 1.2.1 release). This means the Any array will 1 smaller than you expect if you include Id in the field list.

There's a number of bug fixes, the most noticeable one, is that it correctly handles arrays of subclasses of SObject, so in the Enterprise WSDL, you can create and pass an Account [] directly to create or update, you don't need to pass an array of SObjects, where each SObject is of type account, e.g. you can do

Account [] a = new Account{1};
a[0] = new Account();
...
proxy.create(a);

rather than having to do

SObject [] a = new SObject[1];
Account act = new Account();
...
a[0] = act;
proxy.create(a);

On the downside, the enormous amounts of memory requires to parse a Partner WSDL response that includes lots of fields is still there, If you're querying all fields via the Partner WSDL, be aware that your process can require large amounts of memory while parsing the response, if you started the VM without a large enough heap size this can lead to Out Of Memory exceptions.

Congrats to Glen, Dims and the rest of the Axis folks on shipping Axis v1.2. I've done some quick sanity tests and everything appears to work fine with Sforce.

The short answer is "probably not". These are release candidates not final releases and still have bugs in them. Every Axis 1.2 RC released so far has had regressions from the 1.1 release that affect its use with the Sforce API. For now stick with Axis 1.1, its stable and has a small & well known set of issues.

Lots of people use Axis 1.1 to access the Sforce API, here's a few a bug's in Axis 1.1. that you might run into. (The first 2 appear to be fixed in upcoming 1.2 release)

1. Using the Enterprise WSDL, calling create / update with a strongly typed array will fail because Axis forgets to send the xsi:type in this case (e.g.
           Account [] a = new Account[2];
           populateAccounts(a);
           SaveResult [] sr = svc.create(a);
   will fail, you need to pass an SObject array to create, e.g.
           SObject [] so = new SObject[a.length];
           for (int i=0; i<a.length; i++)  so[i] = a[i];
           SaveResult [] sr = svc.create(so);
2. Using the Partner WSDL, calling query or retrieve will return a MessageElement [] for the any collection, but it will be missing all the elements that have a null value.
3. Similar to the previous one, using the Partner WSDL, calling query or retrieve will return a MessageElement [] for the any collection, but it will be missing the Id element, even if you specifically asked for it in the field list. (The Id value on the SObject itself though will be there)
4. Using the Partner WSDL, de-serializing a large number of MessageElement [] items (e.g. you call query and get back 2000 rows with 100 fields), will use up insane amounts of memory. (You can send up a batch size header in this case to reduce the number of MessagesElements you handle in one go)

And as mentioned in the performance post, you'll want to use commonsHTTPSender instead of the default HTTPSender class so that you get HTTP/1.1 persistent connections.