I am successful in working with Open Office via UNO. Now I want to embed the Open Office library into my Java application, is it possible?
Yes you can. You need the OpenOffice SDK.
Find examples here: (you'll see it speaks about the StarOffice SDK but it's the same, remember StarOffice was just the Sun-branded build of OpenOffice.org with the addition of commercial fonts and clip-art)
If you just want to manipulate ODF files from a Java app without actually loading up openoffice.org, check this lib.
FC
I had a similar question. I've found some documentation about Using the Desktop in the Apache OpenOffice Developer's Guide. With regards to compatibility of examples from StarOffice, perhaps some of the StarOffice examples would be viable? The guide mentions a certain matter, a "redesign of the OpenOffice.org GUI in StarOffice 5.x".
The guide's examples are provided alternately in StarOffice Basic and in Java, in using the UNO Development Kit. There's also a convenient tutorial, earlier in the Developer's Guide. UNO IDL is introduced under the section, Writing UNO Components. The UNO component model perhaps might seem similar to OMG CORBA or Microsoft's COM -- I'm not aware of how it might be interfaced in C#
Failing to find an exact solution to the question, the following represents my "Best guess" as far as "how to".
Though I've been unable to find any exacting items of documentation if towards embedding an OpenOffice component within an external Java application, but -- towards a view of the UNO API -- referencing the Using the Desktop article, there's an UNO interface, XFrame, introduced. The XFrame interface publishes a method, getComponentWindow moreover - returning an object of type ::com::sun::star::awt::XWindow, an UNO IDL interface. Sure, in the interface methods published by XWindow, I don't see any methods for obtaining a native window object. Of course, there would be a native window object, accessed somewhere in the application. Personally, I'm not immediately familiar with the OpenOffice source tree.
Perhaps it may be a simpler task, if to embed an application as an extension within OpenOffice, alternate to embedding OpenOffice within an application? Towards extending OpenOffice, there's a tutorial at DZone, How Fast Can OpenOffice.org Be Extended? Also, the "First contact" tutorial provides some additional information, if towards extending OpenOffice. In the latter, the author is using Ant for the build process. Surely that would be easy enough to convert to use Apache Maven, if needed, such as to apply Maven's JAR builder in a similar regards.
HTH
Related
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 am new to Java and trying to learn more about it. I studied the documentation and found the following for Java,
Java Docs
Are the packages listed here the same as standard libraries?
Yes. That is the library that Java's creators have provided.
here is a list of things to know:
java.lang is for all the basic classes that are actually imported automatically
(implicitly) because it is all the basic ones (String, Integer, Double, etc)
java.util contains all your data structures you learned in school and more. Read the documentation, and the more you know and practice, the better
java.io for file reading. Look into java.util.Scanner for simple file reading, but for any more complicated, low level file reading info, use java.io, its built for efficiency, while Scanner is for simplicity
java.math if you ever need to use arbitrary precision values (built-in in python, not in java)
java.net for sockets, connections, etc
javax.swing for GUI, which is an extension of the older java.awt
Hope that helps.
Yes they are the same. This library is also downloadable if you want to view it offline. Also there should be a src.zip file in your java installation files. On unzipping it you will find the source code of all the standard library classes.
Also the Java Language Specification should help you.
When you install Java, there will be a .zip file which contains the source of the standard library called, src.zip in root folder.These are the standard library.
In Java 9+, javafx replaces javax as the main UI library:
Is JavaFX replacing Swing as the new client UI library for Java SE?
Yes. However, Swing will remain part of the Java SE specification for
the foreseeable future, and therefore included in the JRE. While we
recommend developers to leverage JavaFX APIs as much as possible when
building new applications, it is possible to extend a Swing
application with JavaFX, allowing for a smoother transition.
JavaFX FAQ - Oracle.
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.
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.
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!