Is it possible to make use of the Open Office spell-checker outside of Open Office for other Java programs?
Walter
We have done exactly that - used the hunspell engine from java. There is a JNA bridge that can be used to invoke hunspell from java. Very nice to use - takes care of loading the appropriate native library from the jar.
The only problem is that the bridge is not updated with the latest hunspell engine - it is at version 1.1.12, and at the time I looked (last year), hunspell was at 1.2.18, which contained fixes we needed. It's not a big deal to build the hunspell libraries and rebuild the JNA wrapper with the latest hunspell engines, although it does involve cross-platform compilation. IIRC we used a windows box and a linux box to rebuild both those platforms (cygwin on windows didn't cut it) and we didn't need the version for OS X. I can let you have what we built if that's useful.
See
Java API for Hunspell
jna.dev.java.net
OpenOffice simply uses hunspell for the spell checking - you should investigate it instead. Its home page mentions the existence of two java interfaces/ports.
Related
I have some Java-app and a customer with some UWP-app implemented in C#, distributed through the Windows Store etc., who wants to use some pieces of my app. Those pieces are pretty OS-independent, only parsing of some special binary file formats, applying some business logic configured using YAML files and stuff. No network, GUI, only some accesses to files etc.
We currently use IKVM to make the code of interest available to C# but ran into different problems already. Some were supporting .NET Core, some had to do with the native toolchain in Release etc. While right now things seem to work after applying some workarounds, I'm looking for alternatives to IKVM already a bit.
The only thing I currently use of IKVM is simply creating a DLL of my code using ikvmc, which can then be referenced in the UWP-project. The compiler is summarized like the following:
The ikvmc tool converts Java bytecode to .NET dll's and exe's.
That's where the support to create native Windows images of GraalVM came into my mind. Others seem to already build native binaries for Windows and according to the docs, GraalVM is able to create shared libs using "--shared". From my understanding, IKVM implements a JVM in .NET and maps things as needed and possible. That sounds pretty much like what "Substrate VM" does in case of a native image, doesn't it?
This executable includes the application, the libraries, the JDK and
does not run on the Java VM, but includes necessary components like
memory management and thread scheduling from a different virtual
machine, called “Substrate VM”. Substrate VM is the name for the
runtime components (like the deoptimizer, garbage collector, thread
scheduling etc.).
https://www.graalvm.org/docs/reference-manual/native-image/
So, is there any chance that a native image in form of a DLL can replace the DLL created by ikvmc currently? Did anyone try that already and has any experiences? Did anyone try already to create a native DLL and consume that in some other native Windows app? From my understanding UWP "only" applies additional restrictions which one might be able to work around again. Or is this approach totally impossible for some reasons?
Thanks all for your input!
I'm not very familiar with the IKVM project, so this answer is mostly about the generic question:
Can you create a native DLL/shared library and consume that in some other native Windows app?
It should be possible. You can compile Java code into a shared library. The entry points are marked with the #CEntrypoint annotation.
You can then use the generated shared library and the header files to consume your library from a native application.
This way for example GraalVM distributions use the GraalVM JIT compiler by default:
The GraalVM JIT is written in Java
Compiled as a shared library with the native-image
Used in Hotspot.
Here's a page describing how to consume those from Java through the JNI: https://www.graalvm.org/reference-manual/native-image/ImplementingNativeMethodsInJavaWithSVM/
which could be very similar to how would you use a shared library from a C# application.
GraalVM native images are not very flexible, unlike IKVM.NET images. Unless you like writing wrappers and playing with P/Invoke, you should stick to IKVM.NET.
NOTE: I am behind an IKVM.NET fork
is the information on this page still up to date?
http://leodemoura.github.io/blog/2012/12/10/z3-for-java.html
I see that both rc and stable have a examples/java folder with an actual example,
does it mean that java bindings are now part of the stable/rc branch?
How can I enable and build them?
Regards,
Yes, the Java bindings are now (as of the 4.3.2 release) part of Z3. For documentation you might want to look at the comments in the Java source code. However, there is still an open issue regarding memory leaks (see this codeplex issue).
The build instructions on de Mouras Blog are a bit out-of-date it seems i.e., you do not need to pass "--java" to mk_make, building the java bindings is the new default (but there is a "--nojava" option it seems). So you have:
python scripts/mk_make.py
cd build
make all
I should add that you can download prebuild packages on the Z3 codeplex download page (see the panel on the right and switch to "planned" if you are not a Windows user or want the latest unstable branch) which contain the Java bindings.
What I'd like to ask is if anybody knows about an hardware USB-dongle for software protection which offers a very complete out-of-the-box API support for cross-platform Java deployments.
Its SDK should provide a jar (only one, not one different library per OS & bitness) ready to be added to one's project as a library.
The jar should contain all the native stuff for the various OSes and bitnesses
From the application's point of view, one should continue to write (api calls) once and run everywhere, without having to care where the end-user will run the software
The provided jar should itself deal with loading the appropriate native library
Does such a thing exist?
With what I've tried so far, you have different APIs and compiled libraries for win32, linux32, win64, linux64, etc (or you even have to compile stuff yourself on the target machine), but hey, we're doing Java here, we don't know (and don't care) where the program will run!
And we can't expect the end-user to be a software engineer, tweak (and break!) its linux server, link libraries, mess with gcc, litter the filesystem, etc...
In general, Java support (in a transparent cross-platform fashion) is quite bad with the dongle SDKs I've evaluated so far (e.g. KeyLok and SecuTech's UniKey).
I even purchased (no free evaluation kit available) SecureMetric SDKs&dongles (they should've been "soooo" straighforward to integrate -- according to marketing material :\ ) and they were the worst ever: SecureDongle X has no 64bit support and SecureDongle SD is not cross-platform at all.
So, has anyone out there been through this and found the ultimate Java security usb dongle for cross-platform deployments?
Note: software is low-volume, high-value; application is off-line (intranet with no internet access), so no online-activation alternatives and the like.
-- EDIT
Tried out HASP dongles (used to be called "Aladdin"), and added them to the no-no list: here, too, there is no out-of-the-box (out-of-the-jar) support: e.g. end-linux-user has to manually put the .so library (the specific file for the appropriate bitness) in the right place on his filesystem, and export an env. variable accordingly.
Full disclaimer: I work for a company that makes software-protection dongles (CodeMeter). But I believe we might have a solution that meets your requirement: we have a single API for all platforms (Win, Mac, Linux, etc both 32- and 64-bits). Each end-user machine merely requires a runtime (service on Windows; daemon on Linux). We use a native Java API which uses TCP/IP to call our runtime, so no special device drivers are required. You can do activations either before you ship the dongle (pre-programming), or via file exchange (NikeNet) on deployments with no Internet access, or you can remove the dongle, take it to a machine that DOES have Internet connectivity and update the license there.
At a higher level than the API we have AxProtector, which is an automated protection/encryption tool that you can use to test our protection system with no source code changes. This would let you test the implementation on all platforms you are interested in--you don't need to create multiple versions for different platforms.
We had a Fortune 100 company use this to protect a Java app that ran on non-Intel Solaris, so we know it's been stress-tested as a cross-platform solution.
We have a free fully-functional eval system which we can get you asap. If you email me at the email address in my profile we can ship you out an SDK and help you quickly determine if this will solve your problem.
You can use Dinkey Pro dongles to achieve exactly this. While they do use separate native libraries for each operating system and architecture you just need to call their Java API and it takes care of any platform specific bits. Wrap the libraries up in a JAR file with the .class (the API) and you've got a neat solution. The dongles themselves are driverless.
I can only recommend to avoid the SecuTech UniKey system. During evaluation the product met all requirements we needed. We started integrating this solution and discovered one issue after another.
Here is a short list of the major issues that are part of the SDK 6.2.7:
Enveloper settings change randomly when saving and loading the same solution (Video).
DLL files that are wrapped with the enveloper do not load.
The console version of the enveloper for script based builds does not work. It is unable to wrap exe/dll's that can be wrapped with the GUI based version of the enveloper.
Support is reactive but does not really tackle the problems.
After all we wasted almost a month of work integrating this protection system, but now have to switch due to the massive quality issues.
We are starting some new app development but because of special business requirements, need to support back to Mac OS X 10.3 as well as PPC/Intel CPUs.
The latest Xcode 4 isn't an option, from what I can tell it only goes back to 10.5 and doesn't support PPC at all. Is Xcode 3 an option? Would it be easier to just use Java?
P.S. From anyone experienced in either, can you please comment on some of the pros and cons you've bumped into?
EDIT
As requested, here's a brief overview of the app:
The app needs to talk to a server which will expose JSON web services. The app itself needs to be built in a way that will allow plugins (not 3rd party, but in-house with the ability to customize which features the customer owns). Each plugin will gather specific information about the host OS - such as running apps, users, CPU usage, etc.
If you can find a way to make Objective-C work with your requirements, it is worth it in my opinion.
I myself am a former Java developer who has moved into the creation of native Mac OS and iOS apps. I tried using Java for some of my early Mac OS projects and always found the support to be lacking. It can be done, but it was always more difficult than it should've been and never worked as well as a native app.
Here is a link to another SO post that describes some workarounds for getting older SDK versions working in Xcode 4. I can't vouch for how well they work with current versions of Xcode, but it's worth trying.
In view of your requirements, especially the need to do some system evaluation, I would strongly recommend to use Objective-C and the Apple development environment. You will have a lot of difficulties using Java to retrieve the neccessary information about the host OS, that you want to use in your application.
You could try to run Xcode with older SDK versions, but I have virtually no experience on OSX to give you solid advice on how to do this.
EDIT: My Xcode 4 gives me an option to select a "Deployment Target", where I can go back to supporting 10.1, but I have no idea, if this is the right thing...
Well,
Apple isn't a Java friendly company. You don't have all the bindings you may need on their JVM.
So I strongelly recommend (given that your project will be Mac OS X only) Objective C instead of Java
I program in Java but on Mac OS X, Objective-C is better than Java because it is faster and developed by Apple itself. Moreover, if you develop a program in Objective-C, you can sell it on the Mac App Store while if you develop it with Java you can't.
So go with Objective-C.
I would like to know if there is any way that I could build a very simple GUI app (it doesn't even have to look good) that will run on a fresh install of Windows Vista and OS X with no other installations needed by the user. I would perfer not to use Java (just out of personal programming preference). I will use it though, if it is the only way. Specically, I am wondering if I can write a swing app with Scala or Groovy and run in on windows without them having to install anything. Sorry if this is a silly question, I am a Obj-C developer by trade.
You can pack the Scala jars into your own, which should work as long as Java is installed (which it usually is on a 3rd party vendor install of Vista or OS X). If you use Java web start, no installations are needed beyond Java itself. Plus, if you're going to install your own code, why not just copy along the Scala jars also?
If you really mean a fresh install--nothing but what the OS provides--then no, I don't think so.
Edit: You do always have javascript on the browser(s). I assume this won't cut it for what you want?
If you really, really don't want to install anything (or carry anything in your app), then write the application as a web app (possibly a javascript app). Then any user can run that UI from any machine with a decent browser. But then, this will require that you host the app somewhere.
If that is not an option, you can develop your app to as a single html/xhtml file containing a self-contained, self-modifiable javascript application (like TiddlyWiki which I use a lot). Then the user user can download on it on his machine, point his browser to it and voila.
If you combine javascript with HTML5 (and assuming the user has a HTML5 compliant browser like safari), your application can use localStorage to keep its state in the user's machine (thus no longer needing to be self-modifiable to save state as TiddlyWiki does.)
But this would break your rule of not downloading anything on the user's host machine. It is a chicken-and-egg problem that has no solution since each OS implements its own set of application libraries. For multi-platform support, you must use a layer that abstracts out differences between operating systems, be it a vm (like JVM, Ruby or Mono) or a set of libraries (Qt, Gnome).
As far as i know you won't be able to accomplish that with no other installations needed by the user. If you violate this restriction, mono (with gtk#) is a good choice.
Scala and Groovy will have the same deployment issues as Java; all of these require a JVM to be installed. You generally have to first install the JVM (which is not included with Windows) and then install your program. Java is included in OS X, however.
It is possible to use Ruby or Python and one of the cross platform libraries (like wxWidgets) and compile these to an executable file that includes the entire set of runtime libraries (e.g. all of ruby and python).
REAL Studio (formally REALbasic) certainly meets this requirement. It creates native applications that have no external dependencies for OS X and Windows (plus Linux).
In theory you could write a .net application using Mono that it should run without issues on any other one with the .net runtime environment installed.
But I'm not sure if it will work on practice.
I've had some success with XulRunner
There's also a couple of recommendations from these questions I asked
Building Cross Platform app - recommendation
Building XUL app a-la SongBird
XULRunner is pretty cool once you get into it, but it's a tad confusing at first (I thought).. the folks on the mozilla google groups are really nice and helpful though!