I want to open and manipulate Excel files with ActiveX. I've had success with Python's Win32 Extensions and Groovy's Scriptom libraries on other projects but need to do this is pure Java this time if possible.
I've tried the Jacob Java COM Bridge but that doesn't seem as straightforward or simple to use, and I couldn't get it to retrieve cell values (even though this is the library underlying Scriptom). Are there alternatives?
Jacob is really the tool for the job here. I recommend that you take the time to learn a bit about how COM and ActiveX work, and I think you'll find that it's easier to use. COM is quite an accomplishment, but it's hard. Wrappers like VB make it seem easy (For the limited use that they work for), but it is not at all easy. I have a great book on learning COM, but don't have the name handy right now...
You want to learn about the IDispatch interface (this is what most of Excel's COM interface is developed around). It's a nasty, nasty interface (one of those viral things that you can do so much with it that it becomes impossible to tell what is actually happening) - but learning it is key.
If you are having issues in just one area (i.e. getting a value from a cell), you could grab the source for Scriptom and see what they do (open source, after all!).
Another suggestion is to try to implement some test cases of your code in VBA and make sure that you are correctly thinking through all the return values. When we were doing Excel automation in one of our Java apps, we implemented the general algorithm from Word's VBA, worked through the problem cases, etc... After that, transferring over to Jacob was pretty straightforward.
K
how about http://www.nevaobject.com/_docs/_java2com/java2com.htm -- this is commercial but works better.
Have you looked at JExcelAPI? Instead of using ActiveX this is a Java library which directly reads and writes Excel files.
Not an exact answer to your questions but it might solve the problem just as well, especially if you're looking for a pure Java solution.
There's also JIntegra, which does a similar thing. Also commercial.
And there's JNIWrapper, which does a similar thing. again, also commercial.
Related
I have a Java GUI application that has been interacting quite nicely with a standard C++ based DLL on the back end via SWIG-generated files. The back end program is currently a combination of C++ and managed C++/CLI. The problem is that we may eventually port all of it to C++/CLI.
Please correct me if I'm wrong, but from what I've been able to tell, SWIG currently doesn't work with C++/CLI and there are no plans to make it do so. I imagine that I could do write JNI code to make it work. But using SWIG was a whole lot easier. So what other options are there? The simpler to use, the better.
It is not correct to say that SWIG won't work with C++/CLI... You should be able to use the generated interop stubs exactly the same way you did. I didn't encounter a scenario where switching on the CLR support broke existing well formed C++ code...
Weird title, I know, let me explain.
I am a developer most familiar with C# and Javascript. I am completely sunk into those semi-functional worlds to the point that most of my code is about mapping/reducing/filtering collections. In C# that means I use LINQ just about everywhere, in Javascript it's Underscore.js and jQuery.
I have currently been assigned to an ongoing Java project and am feeling rather stifled. I simply do not think in terms of "create an array, shuffle stuff from one to another". I can (and did) create my own versions of the main map/reduce functions using anonymous types implementing interfaces but why re-invent the wheel? The project I am currently on already has commons-collections-3.1.jar and looking through the classes contained it seems like it likely can do everything that I want and more.
For the life of me, I can't find how to actually use it. Looking through the dozens of classes therein is not very helpful and the only thing I can google up is the api doc which is equally as helpful.
How do you use it to Map/Select, Filter/Where, Reduce/Aggregate? Is there anywhere that gives an actual tutorial on this library?
(Comment as answer for formatting purposes.)
Not so much, other than the limited user guide.
That said, I'm not sure where specifically you're having problems--filtering and selecting is mostly wrapped up in the functors package, and utilized by the CollectionUtils class.
While you're not looking for a replacement, you might find things like Guava or Lambda4J a bit more similar to what you're used to (within Java's constraints), and they're a bit less verbose.
Try these links :
http://commons.apache.org/collections/userguide.html (basic tutorial)
http://larvalabs.com/collections/tutorial.html (advanced tutorial with generic)
#george-mauer, you might have to rely on articles like this or a book like Jakarta Commons Cookbook. I have also found it rather useful to learn by creating samples of my own.
I know the .Net framework very well and know where to find things ie: StreamReader, StreamWriter, Graphics, etc, and I know Java has similar things. The syntax is different but quite similar to c++ which I have a lot of native c++ experience. Therefore, what would you recomend as a good starting point for tutorials and such. Thanks
In my new job, I quickly found myself working on a common library in C++, C# and Java. I had no Java knowledge and yet found it pretty intuitive to make simple mods to the Java code - the general C# principle that there is a framework class/namespace for most things you want to do, appear to hold in Java.
The thing that bothers me is that this MO would not teach me tricks and improvements in Java that are specific to that language. That's where I would like to see other answers to this question lead.
In the meantime: http://en.wikipedia.org/wiki/Comparison_of_C_Sharp_and_Java
btw while I found C# and Java pretty congruent, I would not say the same about C++ vs Java.
If you work in eclipse/netbeans/intelliJ it may actually be a no-brainer. Guess at a class name, start typing it and hit ctrl-space (for eclipse, others vary). Regardless of which package it is in, it will find all the classes that match and list them for you faster than you could look them up anywhere else.
The other really nice thing to have on hand is the javadocs for the SDK you are working with--you can code effectively with nothing else. They are online (just search for JDK 6.0 or whatever version) or they can be downloaded from the same place you get the JDK.
The javadocs are your friend - once you figure out some of the main packages in java.*, it's easier to know where to look for specific classes / functionality.
Once you're writing some code, buy Effective Java - it's full of tips for the language, and is just a good programming book.
Are there inexpensive or free gateways from .NET to Java? I'm looking at some data acquisition hardware which has drivers for C/C++ and .NET -- I really don't want to do any programming in .NET.
Update: I haven't done what I originally wanted to do, but I've done something similar, using JNA to encapsulate some functions from a DLL, in order to control a USB hardware device from Java. (the DLL comes from the device manufacturer) It works really nicely. Thanks!
You could also try to use JNA for accessing the native library. JNA provides Java programs easy access to native shared libraries (DLLs on Windows) without writing anything but Java code—no JNI or native code is required. If their API is fairly straight foward, this might be the path of least resistance.
See their getting started guide where they call some native code (printf and GetSystemTime).
Well, there's JNBridge and EZ JCom, just from a Google search.
You could also use IKVM which is a slightly different approach.
(Any reason for not wanting to learn .NET, out of interest? It's a nice platform, and C# is a lovely language...)
If they have C++ versions of the drivers then you could write a wrapper around it using JNI and then load that in Java. JNI can be a bit of a pain, but it would let you use the C++ version of their drivers and not have to deal with .Net at all if you don't want.
I am partial to the recommendation to jump in the deep end with C# since it is so similar to Java. I did this and used IKVM to compile my favorite Java libs. to .NET assemblies and you get [nearly] all the core java runtime classes to boot, so if you tire of trying to find just the right C# collection type, you can always go back to java.util. (No generic collections though. Not sure why.)
Depending on what platform you're on, you have several choices for free IDEs too. For windows you can get Visual Studio Express for free but I also use SharpDevelop. You can also get the Mono IDE on Linux (and a few flavours of Unix, I think ?).
The C# learning curve is shallow if you already know Java. I only blew off 1.5 limbs on landmines that came out of nowhere for reasons I still don't understand, but workarounds were easy to come by. The worst thing about it was the darn developer docs which are AWFUL on account of being so slow. I really miss the snappiness of JavaDoc. Not only are the online docs incredibly slow, the problem is compounded by someones's iffy decision to put class summaries, constructors and methods/properties all on seperate pages so it just takes forever. Someone said to get the docs installer and install docs locally for a slightly improved experience. Not a bad idea I suppose.
I am author of jni4net, open source interprocess bridge between JVM and CLR. It's build on top of JNI and PInvoke. No C/C++ code needed. I hope it will help you.
If you have a Java application, the JNI mentioned by the others will be the way to go. You write some wrapper classes, and that's it.
If writing the wrappes is a too big task (depending on the number of methods you have to wrap), have a look at SWIG . I think it generates wrappers automatically, but I never actually used it.
If you want to code in the Java language, but you don't care if your program will run on the JRE/JVM, then you might as well use Microsoft J#. Basically, it's writing Java-Code wich is compiled to .NET-Bytecode and can use the .NET classes of the driver as well as your existing Java classes. With J# you will run into problems if your existing Java-code is newer than Java 1.4, look at this question on how to solve them.
From that point on, you could later add code in J#, C# or any other .NET language. However, you won't get back to the JRE/JVM easily.
Is it possible to easily embed ActiveX controls in Java application? Is it worth it. In my next project I should either use existing activex in Java app or have to reimplement everything from scratch, so I'm wondering what will be less hassle.
I don't think there's a way to do this without resorting to a third party library. (Or rolling your own, but you did say "easily".)
SWT (The "Standard Widget Toolkit") contains support for embedding ActiveX controls. SWT is an alternative to Swing, though there is a degree of interoperability between them.
Here's an example of embedding Windows Media Player in an SWT window.
Alternatively there's the Jacob project, though I haven't used that myself.
As for "is it worth it?" Well, I can say from experience that SWT makes it relatively easy, but unless your application can gracefully deal with not having them available, by relying on COM components you are losing the ability to run on multiple platforms that makes Java attractive in the first place.
It really depends on how much you are going to have to re-implement. The Jacob project is quite good (we use it extensively for automation of Excel and Word), but you have to really understand COM to use it, especially the vagaries of the IDispatch interface (very few people who use ActiveX / COM actually understand COM - they just rely on Microsoft's template generation).
If you are just trying to save yourself some typing for some simple DAO objects, you'll probably be better off re-implementing (heck, you could probably take the DTD and write a script to generate Java code for it).
http://www.codeproject.com/KB/cross-platform/javacom.aspx?msg=1776281 might help if you're willing to do stuff by hand...
Doesn't seem quite as flexible though...