java and solidworks

Java can not interact with COM since the death of J++ and the MS-JVM.

J++ was greate for doing this back in the day. Now days your best bet would be J# for a java like language to program against SW.

Stephen.

This simply isn't true. There is nothing magical about COM. While J++ made it easier, it is still possible with out the need for using a language that claimed to be Java but wasn't.

I have at the moment, a working framework for creating 100% Java addins. I have written a small 'connector' addin which uses JNI to bridge the gap between Java and COM. It handles all the ugly details of registering itself, processing callbacks, marshalling across threads and what not. A Java addin writer simply has to conform to a very simple inteface and some basic rules to allow an addin to be picked up at runtime by my 'connector' addin.

I am in the process of porting the API, which is just a matter of some simple argument translation between Java and C++. As proof of concept, I use a Java addin to run all my unit tests ot exercise the API.

Jim S.

That sounds good. Any changes you would share this?

Johnny

message

OK, maybe I should have said can not easily interact with out a load of extra work.

On a slight tangent, unless you are seriously tied to java, I see no point in using a 'platform independant' language to write addins for an application that is irrevocably tied to a single platform. Use one of the other languages with pre built, tried and tested COM support. Make your life easier and save a load of time reinventing the wheel.

Stephen.

Because solidworks-data are not the only data used in business. If you you develop a busines platform (server or client) a platform indipendent language can be usefull.

Also I don't like it that solidworks is so tightly bounded to Micosoft.

Indeed, but you don't have to use the same thing everywhere, if your systems are tied together with an open standard, such as one of the XML based protocols like SOAP, or your just pulling data from an RDBMS there nothing really stopping you from using the best tool for the job.

Should have known you would say something like that!

Stephen

You are right when saying to use the best tool to do the job thats why I use Solidworks. :-) (no offence)

It will be open source eventually. I have no desire to sell it or profit from it. Until more of the API has been ported, it will be of little use. I'll post here when I have something worth sharing.

Jim S.

My goal is to create a Java-SW API that makes it *easier* than the current VB/C++ mess.

The problem with using one of the pre-built COM supported solutions is that you are still stuck with the horrible structure of the API, which was written around the less powerful of the languages (VB).

Yes, it is a lot of work to write all the Java bindings, but in the process, monumental improvements can be made in the way the API is exposed to the programmer. SafeArrays, Variants, packed double arrays and such make API programming tedious. Many of these 'features' can be replaced by true OO concepts so that the API makes more sense to those familiar with OO languages.

The platform independence of Java isn't its only benefit. There are a

*huge* number of class libraries available, many of which are open source or free and can be used to hook all sorts of interesting features into SW. In my opinion, Java is more powerful than VB and far more friendly than C++.

Jim S.

Would be nice. If you need some help, I can maybe give you a hand.

Johnny