According to this answer to an earlier question of mine, the WinInet Windows API is the correct way to read and write internet connection settings in Windows. How can I use this API from Java? I'd prefer a free, open-source solution.
There's always JNI and JNA, but if you don't already know C or C++ there'll be a learning curve involved, especially with JNI: JNI Reference, JNA Site
Over the last months I had to mix with my Java project some C, C++ and Win32 alternatives for native access. After a lot work with JNA and recently with JInvoke for such integration, I can tell you that JInvoke is a little mature than JNA. Even JInvoke be older than JNA, I found its syntax more concise and simple. Sorry for those who loves JNA but using JInvoke I could literally hook the windows api from Java.
I see there's a commercial library called JInvoke that:
enables Java developers to easily
invoke native methods (such as the
Win32 API or C-based Windows DLLs and
Unix dynamic libraries) with pure Java
code.
However I'd prefer something free and specifically targetted at the WinInet API.
Have a look at JACOB project
JACOB is a JAVA-COM Bridge that allows
you to call COM Automation components
from Java. It uses JNI to make native
calls to the COM libraries. JACOB runs
on x86 and x64 environments supporting
32 bit and 64 bit JVMs
http://sourceforge.net/projects/jacob-project/
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 there any attempt in the works to make a Java version of LLVM?
Note: I am not asking about either LLVM front ends or back ends. I am asking about the LLVM toolset itself. I would like to experiment with LLVM but I find I am much more productive working with Java and Java libraries rather than C++.
There is a C interface to all LLVM libraries. It's quite stable and functional, and is used by Python and Haskell bindings.
So you can use it with JNI to create LLVM bitcode, optimize or transform it as you wish, save and run it, etc.
I need this for calling a C function from Java class (JNI) and I know that there are options to do this using "Microsoft Visual C++ compiler". (explained here)
But I am interested to know if something similar can be done using TC or TCC.
I don't have a copy of "Microsoft Visual C++" and not sure if cl.exe is available without having to install "Microsoft Visual studio"
Short answer: TC is perfectly capable to create a DLL.
Long answer: Turbo C++ is very old. The JNI include files might be using some language features not supported by TC. You might have better luck using another free compiler, for example Visual C++ 2008 Express.
MinGW is a free port of gcc. Great alternative to VS. Here is a tutorial on how to build jni libraries. TC is too old.
cl.exe is available without the full Visual Studio IDE. The 'Express' install for Visual Studio C++ has an option to install only the command line tools (handy for build machines).
Of course, you can install the IDE, too. You'll get the command line tools in that installation as well.
Finally, the Windows Driver Kit (WDK) comes with a command line compiler.
Also, the Turbo C/C++ you linked to is from 1991 - I'm not sure if it can generate DLLs, but it almost certainly can't generate a Win32 DLL (I'd guess that the best if can do is a Win16 DLL). I wouldn't use it for anything except curiosity/nostalgia. I'd consider it a miracle if it could do anything with JNI.
Yes I agree with DR. You will be much better off using one for MS's free tools (Visaul C++ Express) Just create a library project, code away and then compile it down to a DLL.
Cheers
Yes its possible
I have written a simple tutorial for implementing a "Hello World" program using "Borland Turbo C++" and JDK 1.5
Check it out - here
Is there a Java library to access the native Windows API? Either with COM or JNI.
You could try these two, I have seen success with both.
http://jawinproject.sourceforge.net
The Java/Win32 integration project
(Jawin) is a free, open source
architecture for interoperation
between Java and components exposed
through Microsoft's Component Object
Model (COM) or through Win32 Dynamic
Link Libraries (DLLs).
https://github.com/twall/jna/
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. This functionality is
comparable to Windows' Platform/Invoke
and Python's ctypes. Access is dynamic
at runtime without code generation.
JNA allows you to call directly into
native functions using natural Java
method invocation. The Java call looks
just like it does in native code. Most
calls require no special handling or
configuration; no boilerplate or
generated code is required.
Also read up here:
http://en.wikipedia.org/wiki/Java_Native_Interface
The Java Native Interface (JNI) is a
programming framework that allows Java
code running in a Java Virtual Machine
(JVM) to call and to be called1 by
native applications (programs specific
to a hardware and operating system
platform) and libraries written in
other languages, such as C, C++ and
assembly.
http://en.wikipedia.org/wiki/Java_Native_Access
Java Native Access provides Java
programs easy access to native shared
libraries without using the Java
Native Interface. JNA's design aims to
provide native access in a natural way
with a minimum of effort. No
boilerplate or generated glue code is
required.
JNA is pretty nice. I'm just a beginner and I found it very easy. Works not only for the Win32 API but for almost any other DLL.
Jacob is quite good on the COM side (but it's real COM - like you write in C++ - if you are familiar with true COM programming, then Jacob is a snap to use)
JNIWrapper or ConfyJ from from TeamDev.
One more option is WinRun4J. It has a native binding layer that aims to be compatible with pinvoke.net (the native binding format used in dot net). See examples for more information. Its a little early days so YMMV.
(full disclosure: i work on the project).
Yet another option is JFFI - this is used in jruby and jython to interact with native libraries.
Check out Waffle
I've been interested in doing some work on a desktop application for while now and my most proficient language is Java. Due to wanting to be able to compile down to a native executable, does anyone have any experience they would like to share about using gcj to compile, and CNI for libraries? I was hoping to use of of the native toolkits, not just Swing/SWT.
As Eclipse has been sucessfully compiled natively (see http://www.linuxjournal.com/article/7413) I would say it's possible.
I used GCJ to embed Java code into an C++ application, but I would not use it for a UI application. I would go pure Java there (probably Eclipse RCP based) as that is where I have experience.
Have fun experimenting!
I haven't used gcj for compiling to a native executable but for interfacing to native libraries I've found JNA to be a very nice way to do it as you don't have to write any native code at all to make native calls. Note that doing it this way does result in a performance penalty so it probably wouldn't be an option if you're calling into native code in a tight loop where performance is likely to be an issue.