More 'usual' Java API

[daune_jf]

Hi guys,

I am experimenting with Java API, and it is quite unusual in Java world.

Two examples:

1) You do not comply with JavaBeans naming convention (which requires getField() instead of GetField()). This prevents introspection.
2) You have implemented your own Collection.

One result: I cannot feed Velocity template engine with EA SDK classes (I try to export part of my model as XML)

Maybe you could change API before it is used by too many customers...

Best regards,

J-F

[KP]

These should be configurable via "Tools > Options > Source Code Engineering > Java".

[«Midnight»]

Duane,

You are quite correct. The Java API is unusual in the Java world. The API itself is the COM API that EA has always presented, with a third-party compatibility wrapper.

This is clearly documented, and has been since the Java API was first released in beta form more than a year ago.

So you're stuck with the COM naming (and other) conventions. But it is better than nothing.

IMHO an alternative would be to have Sparx write another API, using a compatibility layer that was 'closer to the metal' and hidden from users. This would be a huge effort on their part, would likely reduce the long-term reliability of EA, and would take away from product improvements in other areas. Not great (again, IMHO).

David

[daune_jf]

Having taken a look at Java API code, I really don't get it. Why a huge effort? Why should that have any impact on EA reliability?

Here is a sample of Package.java:

 public Collection<Diagram> GetDiagrams(){
   return comGetDiagrams(comObject);
 }

And how it could be improved:

 public Collection<Diagram> getDiagrams(){
   // CollectionWrapperUtils creates java.util.Collection
   return CollectionWrapperUtils.wrap(comGetDiagrams(comObject));
 }

Calling the method 'getDiagrams()' instead is one of the simplest refactoring. Modern IDEs handle such refactoring automatically.

I must be missing something. I guess the Java API is generated by some tool...

J-F

[«Midnight»]

The problem little if anything to do with the complexity of Java code.

It is all about the complexity of a product when you add a second API. Each API would have a different underlying structure (i.e. Java is not COM) which would mean two different code streams had to be created and synchronized each time the underlying product developed.

The same problem would occur if there were only a Java (built from the ground up as you describe) API. In that case it would be comparatively simple to get things working correctly, as you point out. However adding a second COM based API would increase the complexity of the product, with the same risks as I've pointed out earlier.

Of course the final decision on these things rests with Sparx, not with us. At least not individually. You are certainly not alone in wanting a more 'natural' Java API. If there were enough feature requests for improvement here, perhaps even a native API, then it might get into a future release.

If you want to make that point, I'd suggest a feature request directly to Sparx. Use the Feature Request link below the Support link at the bottom of any forum page. If you are a registered user click the appropriate link at the top of the resulting page, otherwise fill out the form. [You'll see what I mean.]

David

[daune_jf]

Well, please, do not put words in my mouth. I have never suggested to 'build a new API from the ground up'.

I just suggest that wrapping of existing EA COM object model (i.e. native calls to SSJavaCOM.dll) could more Java-friendly.

That was the point of my example. There are only two little differences, not 'structural' at all: a) appropriate capitalization, b) use of Java built-in collections.

Those two 'little' improvements make a lot of differences to many Java tools.

So, to sum up, my suggestions is that EA keep their SSJavaCOM.dll, but slightly redesign wrapping classes.

[«Midnight»]

...
IMHO an alternative would be to have Sparx write another API...(again, IMHO).

Sorry to offend Duane. I thought I had been clear.

IMHO is a common acronym here, and throughout the Internet. It means In my humble opinion. The words were mine, and I did not mean to imply otherwise.

This completes my participation in this conversation.

David

[Eve]

1) You do not comply with JavaBeans naming convention (which requires getField() instead of GetField()). This prevents introspection.
2) You have implemented your own Collection.

It's already too late to change.

Regarding the collection.  We haven't really implemented our own collection.  As with all the other objects it is just a wrapper around the COM collection object.

In this area the Java API is far ahead of .Net and even direct COM clients.  They have a mix of collections with no type security (which leads to confusing errors like mistakes casting something from Attribute.TaggedValues as TaggedValue, when it is actually AttributeTag) and custom collection/object pairs (eg. Swimlanes/Swimlane).

The wrapper around all collections in the Java API provides type safety and iterator support.