Is it possible to use OLE Automation in Java? If not, why is it not possible in Java?
I'm looking to automate the exporting of excel spreadsheets in different format (ie, .csv etc...)
Thanks for the answers in advance :)
Recently (March 2013), an independent contributor added support for generic COM Automation to JNA, which is the last man standing in terms of native platform API integration from Java. JNA is still very actively maintained, unlike Jawin/JACOB/etc.
See here for an example of how it is used. The pre-cooked bindings to the Office APIs are very simple so far, but looking at the code, it seems very easy to use the COM Automation APIs (IDispatch, Variant, etc) to do late binding to almost any COM interface.
I would like to see, however, a more complete binding of the Office COM APIs, since they are by far the most often used COM API in the world. Maybe there could also be an "MSExcel2007.java", "MSExcel2010.java", etc. to cover the different API versions. So it's very much a work in progress, but JNA is now as generally useful for COM Automation as JACOB/Jawin, with the bonus that it's extremely actively maintained (as of April 2013).
You can use JACOB. But there will be some pain involved as it's not documented very well and the performance is not the best. It can also be hard to get it running correctly for you environment depending on which version of Windows you are targetting. I would definitely not use it if you are building a scalable web application. Another option would be Apache POI which has really come a long way from its early roots and is used in alot of production ready tools like JBoss Drools. If you decide to go with JACOB then I recommend you read this SO thread:
Is there a good reference for using OLE Automation (from Java)?
There is a library called JACOB that allows precisely what you're looking for. What do you mean by "from the Java API?" You mean from from the official J2SE packages? I'm not sure how to answer that other than to say that J2SE doesn't include libraries for every conceivable need under the sun, especially those that only work on a single operating system. That's why third party packages exist.
Commercial, but they seem to have a free Open-Source and Academic license...
JExcel
JExcel Developer Documents
I have no affiliation.
Related
Is there any open-source Java or JavaScript library available to parse .dwg files and get the objects from it.
I would like to extract data from a table of text for my project.
It seems that the AutoCAD developer community prefers .NET and C/C++ over JAVA.
The only free alternative I found is by converting .dwg to .dxf first and using the Kabeja lib to read from it.
The Teigha library from opendesignaliance has C++, C#, and Java interface. Teigha is the alternative of RealDWG and it is widely used by many CAD software vendors. It is stable and has the power to read/edit/write dwgs without problem. We have more than 3 years of experience with it and I can say it is excellent and a lot cheaper. When we were at the point to choose between RealDWG and Teigha we chose Teigha and I am glad we did it.
Leveraging SWIG to Create Teigha for Java
In 2013, ODA used the Java support provided by SWIG to create "Teigha
for Java". Teigha for Java includes the following:
Java access to the full Teigha API for both .dwg and .dgn files.
Support for Windows, Linux and Mac platforms.
API very similar to Teigha.NET, simplifying the transition between languages.
Credits to all who have answered, I've tested all your proposition and here's what I've found , as of 2015:
There is currently no free AND reliable solution to read and manipulate .dwg and .dxf files. This applies especially to latest versions of AutoCAD, ex : Autocad 2010, Autocad 2013 etc, RF 2013, RF 2010.
Reliable (and expensive) solutions would be Teigha by ODA (2000$ a year) and RealDWG in C# by Autocad (5000$ a year)...
Cheaper alternatives are as such :
AutoCAD I/O for 10$ per month (as suggested by Augusto Gonclaves), but limited functionalities for now.
writing LISPS routine and running them with a SCRIPT file in a paid instance of AutoCAD 2015/2016..
wait for a more complete implementation of AutoCad Core Console..
Open-source libraries such as Kabeja and YCad may be able to deal with older AutoCAD versions but do not expect much from them as these projects are inactive since a few years ago. It's worth to keep an eye out for Apache Tika though, since they started writing parsers for .dwg files but development has been slow.
On a personal note, I think that AutoDesk has a strong and selfish monopoly on the CAD market now and they are making it difficult for others to join in. The format's version of .dwg files changes so often and I guess open-source developers will have to give up at some point and use the official product instead.
Let's hope for more open-source solutions in the coming years
Autodesk developed AutoCAD mainly with a C++ and offers plug-in support for C++, .NET, JavaScript, VBA and LISP, that's why there is no native Java support. All of those will require AutoCAD installed on the machine.
Alternatively, you can use the AutoCAD I/O webservice, that is basically a running instance on the cloud, to run custom code and extract data or create new drawings. That will have support for all DWG features. Check http://developer.autodesk.com
As you pointed out, use DXF format instead, there is open source java library, YCAD also, that you can use and is very easy to use.
We want to use existing C# sources within our Java project. So far, this would not be a great problem since using e.g. Java Native Interface (JNI) is quite straight forward.
The problem is that the software shall also run on non-windows OS. So, we can compile the C# sources with Mono in order to make them executable on e.g. Linux. But how about the integration within Java? JNI or any COM-based solutions for C# <-> Java interoperability are OS-dependent and only work e.g. on Windows.
One possible solution would be the implementation of webservices. Has anybody another idea of how to solve this problem? I would be very thankful for alternative suggestions!
Thanks very much!
Regards
This is maybe not an "answer" as such, more a bit of discussion of how I viewed a similar (I think) situation.
I had a major investment in a C#/.Net-based client-server style system. So when I decided that I also wanted to support an Android "client" app I looked into various options. To me the most important factor was to maintain my C# classes as the defining classes for the object interchange between the existing system and the to-be-written Java Android app.
What I eventually settled on, and tweaked to my liking, was a system where Google Protocol Buffers is the interchange media. (If you're not familiar with them they are a sort of JSON-like interchange format.)
https://developers.google.com/protocol-buffers/
At the .Net end I use ProtoBuf-Net, written by Marc Gravell (he works here at SO, I believe). It includes the ability to take .Net objects and generate .proto files, the defining file for Protocol Buffers.
https://code.google.com/p/protobuf-net/
At the Android end I use ProtoStuff, written by David Yu. There is a part of his code that takes a .proto file and generates the corresponding Java classes.
https://code.google.com/p/protostuff/
One problem I encountered was that this didn't work well for my .Net classes that are derived classes, which was most of them. I created a workaround that is described in my comment to the answer here:
How to get protobuf-net to flatten and unflatten inherited classes in .Net?
This is now working to my satisfaction.
Note that I haven't talked at all about how the Android app connects to the Windows-based system and how the communications is performed. That was secondary for me - my primary consideration was making the C# class definitions the definitive definitions and having Java classes created from them automatically, and then the object-to-object interchange. (In the event I'm using a home-made TCP/IP communications link, but the actual communications could be anything, probably also web services.)
Hope this helps.
So I did a lot of research on this topic and want to share my findings with you:
One (from a technical point very attractive) option is to use commercial bridges between Java and .Net. For sure, the most popular products are JNBridge and Javonet. Both products seem to be quite easy-to-use, have good support and seem to be very sophisticated. Especially JNBridge already supports bridging between Java and Mono too, which allows the portation to also non-Windows OS, which is one of our main requirements as stated above. Javonet also wants to integrate Mono and is going to release this feature soon. However, both solutions are commercial and one needs to weigh their features against the respective costs. Nevertheless, from a pure technical point of view, they look great and also state to enable very fast communication between Java and .Net (faster than with web services).
Another option is to connect Java and .NET via COM. Since COM is generelly defined platform-independently, this could work on multiple OS. There are lots of open source projects that could be used for such an implementation, such as EZJCOM, J-Interop, JACOB or JCOM. The main restriction (expecially for our project) is that Mono only supports COM-interoperability under Windows (yet). So, this is not really an option for us. But if you want to create Java-.NET interoperability on Windows only, this is a good way.
The straighforward way of integrating Java and C# is to use Java Native Interface (JNI). You can also find manifold implementations that make JNI more easy to use, the most popular one is probably jni4net which seems to be a very active and frequently used project. But there are also others with specific pros and cons, such as Caffeine, Espresso or csjni. Finally, JNI is not 100% platform independet. It is applicable on different platforms, but you have to generate platform-specific code which makes it clearly less usable for our purposes. If you limit your application to Windows, jni4net seems to be a very good choice.
The third option could be to run both the Java and the .Net part within a Common Language Runtime. Ikvm.net is one possible and very popular solution therefore (as mentioned above by Samuel Audet). The drawback of this option is the loss of features and efficiency of the JDK.
The last and surely most generic alternative is to set up webservices between the Java and the .Net world. For this solution, one needs to find appropriate ways for serializing/deserializing objects from/to Java and .Net. There are manifold possible solutions for that available. RenniePet mentioned a sophisticated solution based on Protocol Buffers. Others exist as well such as http://java-cs-bridge.sourceforge.net/. This option might have a potential drawback when considering communication runtime, but may be the way to go for us.
Hope this may help anyone in the future that is confronted with the same problem.
I know how to create small desktop applications in Java. I want to know, can I make Windows Metro style apps in Java? Because on the web only C++/C/C#/JavaScript etc. are mentioned. If yes can you please give me some reference for a quick start. If not which one will be easiest language to start?
You can only create metro style apps with C#, VB, JavaScript and C++. There is currently no support for authoring metro style applications with Java.
You cannot make metro style apps with Java.
For the other part of your question, regarding starter's guide and which language is easy, MSDN has a starter's guide which helps building new metro style apps, this, this and this should be helpful.
And which language is easiest, well it depends on the developer, someone who has been developing .NET or WPF or Windows Forms applications maybe more comfortable with he familiar environment and may prefer developing using C++ and XAML or VisualBasic, depending on what he has been using before, while someone coming from web development may prefer javascript.
For new developers, i would recommend using C# and XAML, but again it is my choice, and not everyone will agree with it.
Here is another link which points to guides at MSDN, and adds some additional detail.
I believe you will not be able to use Java and WinRT. The best option for you to try is C#, because this is the language that is closest to java, in my opinion.
WinRT is still based on COM, so you should be able to access it from Java using something like the Java-COM bridge. Using that would probably be quite hard (you'd have to use strings for method names etc.).
If you wanted to use WinRT comfortably from Java, that would require modifying the Java runtime and possibly also the compiler to make them aware of WinRT types.
Actually you can quite easily write a metro style web application by using a CSS library like this one: http://metroui.org.ua/
With this CSS, it is possibly to generate plain old HTML with Java on the server side (e.g. via a servlet) and then reverence the CSS classes.
I did this by using the org.apache.ecs library (it's very old but it works pretty good).
C# and Java are similar, but with different Frameworks. Look into developing Metro Style apps in C#. Remember to sign up for a developer's license for Windows Store Apps!
You could write your app in Java and cross compile into JavaScript using GWT. We do this successfully with a couple of Windows (Phone and Desktop) apps. Additionally, the code can be shared with your iOS and Android ports.
here what i found in sourceforge.net
http://sourceforge.net/directory/os:windows/freshness:recently-updated/?q=slibrary
this is the most close ui to metro theme i saw.
I'm working on a web app that will need to process DITA documents from persistent storage (likely a JCR). The DITA Open Toolkit is the only DITA implementation I'm aware of, but it requires all of your documents to exist on the filesystem. Ideally, I'd like something that works like the DITA OT, but allows you to provide a resolver (much like an XSLT URIResolver) to pull referenced content from other sources.
If people have other ideas, such as using a virtual filesystem to trick the DITA OT into working, I'd love to hear those too. Thanks!
Edit: I forgot to mention in the original post that I'm looking for an open-source solution, as this is for a project released under the Educational Community License.
After some evaluation, the newest version of the XMLMind Dita Converter (ditac) is really up to the job. Performance is at least double that of the Open Toolkit for building identical projects: http://www.xmlmind.com/ditac/
One thing to note about XMLMind Dita Converter (ditac) is that it's released under the Mozilla Public License, which according to http://www.gnu.org/licenses/license-list.html#GPLIncompatibleLicenses is not compatible with GPL.
Look at Arbortext (specifically Arbortext Content Manager). Arbortext supports xinclude, catalog files, and it also has a production-ready PDF and digital media publishing tool that you don't get with the OTK. The OTK isn't really meant to be for production.
Yes, I'm a vendor (now), but I started as an implementer more than a decade ago. I answer a lot of community questions and sponsor two dozen resources for getting people's questions answered. The best of which is the SF Bay PTC Arbortext User Group (Virtual).
Are you looking to do something like what Juniper is doing? (I can only post one link, so it's going to be mine..) go to juniper dot net, choose support, technical documentation, ex-series platforms, any of the ex series docs. They're showing topics on the web directly (it's also inside the source code on the router and in the pdf books). It would help if I understood what you're trying to do.
Feel free to reach out to me offline.
This new set of DITA XProc pipelines on the EMC Developer Network might be worth looking into. It can be downloaded free for development (and there's an XProc engine there as well).
This package appeared at the end of October 2010.
Quote: "The aim of the project is to provide an alternative to the DITA Open Toolkit (DITA-OT) that does not rely on file system-based processing, has no direct dependency on Java and Ant, and makes use of the XML processing capabilities of XProc to offer greater flexibility, extensibility, portability, and ultimately also better performance. The pipelines use standard XProc features as much as possible, so with little or no effort, users should be able to use them with any compliant XProc implementation. The pipelines have been tested with EMC Documentum XProc Engine (Calumet) version 1.0.12."
My coworker just talk to me about DITA Compiler. Apparently it's part of xml mind.
According to him, the implementation isn't quite complete.
Maybe DITA2Go can help:
http://www.dita2go.com/
DITA2Go allows your files to be anyplace you please, as you requested. It also has numerous extensions beyond what the OT provides, such as scoped keydefs and ditavals, which are under consideration for DITA 1.3. It was created with intense collaboration of two TC members working on major live projects, and is used by hundreds of people currently.
It is also about ten times as fast as the OT, thanks to C++, and requires no programming skills at all to use.
It is free, but it is not Open Source. It is fully supported and the developers fix bugs immediately and often add new features in a day or two on request. It shares a large part of its code with a commercial product, Mif2Go, which is the tool used by about 25% of FrameMaker users who are moving to DITA, according to a recent survey.
I don't see a requirement for the tools used to create a freely-licensed document to be Open Source themselves. There are absolutely no restrictions on use of the output, which obviously belongs to the user, not to Omni Systems.
HTH!
I hope you all have a nice day.
I want to write a web service that would check some web page HTML code every 20 minutes and e-mail it to my mail box. Here I was given a suggestion to use Google App Engine for this task. Having briefly read through that site I learned that two languages could be used there: Java and Python.
Which one do you think would fit best for my task and, therefore, I would have to start learning? (I don't know either language).
Both the languages and their App Engine implementations are pretty solid and mature. As a language, Python is faster to learn, but Java comes with richer tools such as Eclipse that may partly compensate. A lot depends on what other languages you have background in -- for example, coming from C#, Java would be simpler than for somebody coming from, say, C. For such a simple task, the issues of power of the two languages and additional libraries &c doesn't really come into play.
I've tried both languages with GAE and here's my general feeling about the choice of language for it:
Python is generally simpler. So, if you're using bare GAE API, Python's one is simpler to learn and simpler to write a webapp in it.
Java is more compatible. Python's API is generally GAE-specific, while Java API resembles some standard Java technologies (servlets, JDO, deployment etc.)
So, Java is a good choice if you either have an experience with web development in Java or if you're going to use third-party libraries extensively. Otherwise, Python is better.
For your particular task, I'd suggest Python, mostly because of the existence of Beautiful Soup, an excellent HTML parser that handles poorly formed documents.