I have a Java project, in which I have to achieve parallelization through OpenMP technology (that is, I have to, somehow, make a bridge between C/C++ and Java). So far I was told about using JNI for integrating C/C++ code in java, but, also I was suggested to use JaMP instead. I don't know much about these techniques/frameworks, so my question is, which is less pain to use, and, generally, how can I implement OpenMP stuff in Java code? Can I achieve the same functionality using only Java threads (without using OpenMP)? I'm a beginner in this domain, so absolutely any help is much appreciated.
Hint: the project is to build a collaborative graphic editor, by "putting" onto one core the interactions between the server and the clients, and "putting" onto another core the effective graphic processing.
From your brief and slightly confusing explanation of your project I don't see any need for you to be using OpenMP at all. All that you want to do can be done entirely within Java which has good (enough) facilities for concurrent programming.
OpenMP was designed for a completely different type of 'concurrent' program -- really for parallel programs; at its heart it's for spreading loop iterations across processors. This is not a good fit to your problem.
If you have been told that you must use Java and OpenMP then I suppose you must. If this is so, go with JaMP. Only if someone holds a gun to your head should you set out on the path of Java+JNI+C/C+++OpenMp.
Futures can also be given a look for your project.
Which I think is not used by many traditional programmers for parallelizing their work.
Related
I am trying to optimize the performance of some natural language processing in a python project I am currently working on. Basically I would like to outsource the computationally intensive parts to use apache OpenNLP, which is written in Java.
My question is what would be the recommended way to link Java functions/classes back to my python code? The three main ways I have thought about are
using C/C++ bindings in python and then embedding a JVM in my C program. This is what I am leaning towards because I am somewhat familiar writing C extensions to python, but using a triangle of languages where C only functions as an intermediary doesn't seem right somehow.
using Jython. My main concern with this is that CPython is the overwhelmingly popular python implementation as far as I know and I don't want to break compatibility with other collaborators or packages.
streaming input and output to the binaries that come with OpenNLP. Apache provides tokenizers and such as stand-alone binaries that you can pipe data to and from. This would probably be the easiest option to implement, but it also seems like the most crude.
I'm wondering if anyone who has experience interfacing python and java knows how much the performance is likely to differ between these options, and which one is "recommended" or considered best practice in such a situation - or of course if there is an entirely different way to do it that I haven't thought of.
I did search SO for existing answers and found this, but it's an answer from 3.5 years ago and mentions some projects that are either dead, hard to integrate/configure/install or still under development.
Some comments mentioned that the overhead for all three methods is likely to be insignificant compared to the time required to run the actual NLP code. This is probably true, but I'm still interested in what the answer is from a more general perspective.
Thanks!
Consider building a java server with existing language independent RPC mecahnism(thirift, ....). And use python as the RPC client to talk with the server. It has loose coupling。
I'm a big fan of functional programming languages (namely Standard ML and its dialects), mainly because of their expressiveness which allows for very consise, clean code. I can solve many problems dramatically faster with ML than with say Java.
However, Java is really great when it comes to programming GUIs (->SWT). I would definitely not wanna do that in a functional language.
This brings us to my actual question: Is there a good way to write a program in ML and then wrap it with a GUI written in Java?
What I have come up with so far is the following:
Compile the ML programm (e.g. with MLton or Poly ML) and execute the binary as
an external program from Java
(http://www.rgagnon.com/javadetails/java-0014.html).
Problem: The only way the Frontend/Backend can communicate is via Strings. This might require tons of (difficult) encoding/decoding.
Use JNI/JNA. From what I read, this will allow you to transfer Integers, Arrays etc. I think the external programms have to be written in C/C++ for this to work. With MLton's Foreign Function Interface I can write an Interface to my functional program in C and statically link the whole thing.
Problem: Apparantly, this only works with dynamic libraries, that is dlls in Windows. However, MLton will only let me compile the ML/C Programm to an executable. When trying to create a dll, I get a whole bunch of errors.
Does anyone have experience with this? Is there a better way to do this?
Thanks in advance! -Steffen
EDIT: I know about Scala which tries to bring concepts from functional programming to Java. I have tried it but I dont think it can compete with an actual functional programming language (in terms of expressivness)
That's not quite the exact answer but there is a functional language which is very ml-orientated for the JVM: Yeti
So if you like coding in ML than that's probably currently the closes you can get on the JVM and it integrates of course very well with all the Java APIs.
Is there a good way to write a program in ML and then wrap it with a GUI written in Java?
I don't know if this is a good way for small applications, but it is definitely a way, one that works for big IDE style stuff: Isabelle/ML vs. Isabelle/Scala/JVM. This is an application of interactive theorem proving, but plain SML programming is a trivial instance of that, in a sense.
So you can write basic Isabelle/ML code that emits some messages in the manner of the old-fashioned REPL, but the output can be interpreted by GUI components on the JVM side. Isabelle/jEdit does that routinely for pretty-printing of colored text, with a tiny little bit of rich text (sub/superscripts and bold).
Concerning explicit recoding of functional values over pipes/sockets as strings: that turns out quite simple in Isabelle/ML/Scala, due to some imitation of the way SML would represent typed values in untyped memory, but using untyped XML trees here instead of bits. The XML transfer syntax is specific to keep things simple: YXML instead of official quasi-human-readable XML. All of that fits into approx. 8000 bytes of SML source -- I am tempted to post the sources here, but better search the web for "Isabelle YXML" or "YXML PIDE".
Since Scala/JVM alone has been mentioned as standalone alternative: it definitely works, Scala is also very powerful and flexibile in imitating many programming styles (higher-order functional-object oriented), but for sophisticated symbolic applications like theorem proving, it just won't reach the purity and stability of SML. (Note that the underlying SML platform here is Poly/ML.)
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
I currently have a C++ backend that I need to connect with a GUI, and since I've never built a GUI before, I was confused on where to start.
I'm comfortable writing code in C++ and Java, so I'd prefer my GUI to be in one of those languages. Also, the GUI has to be reasonably OS independent over Windows and Linux (and hopefully, hence Macs).
Now I understand that if I use Java to do it, I'll need some wrappers to do it - but I've also heard (strictly second hand) that writing a GUI in C++ is a pain.
I don't want to rewrite too much of my backend code in Java (who does??) and I was hoping for input on:
Does either language offer serious advantages/disadvantages compared to the other?
How serious is the wrapping issue, and how much rewriting would come in if I used Java.
Are there any specific resources I should look at that people think would be relevant?
Thanks and Cheers All :)
Have a look at Qt.
In my experience communicating between two different language runtimes is always challenging. If you have a non-trivial application to build the following often pose challenges:-
Error Handling.
Memory Management.
Multithreading and Synchronization
Semantics.
Apart from increasing one level of indirection due to wrappers, it requires a lot of thinking like circumstances where you need to pass data structures across GUI and backend etc.
For example:- Consider passing a Java String from GUI to backend C++.
Essentially, we have to extract the characters from a Java String object and make them available to the C++ developer without leaking the memory which holds them. This is an example of a basic problem (there are other aspects too like the encoding in which the characters are to be returned).
You say you already know C++ and Java, and that you never did a GUI before. That means:
no matter if you go for a Java GUI or a C++ GUI, you will need to learn how to handle the GUI framework
if you chose Java, you also need to learn how to interface between the two languages
So staying in C++ saves you one thing to learn. Well, it's always a good idea to learn something, but might be a bad idea to learn two new concepts at the same time. Anyway, the learning might be the smaller burden, I guess there is a lot of actual work involed, even when you use tools like SWIG.
You might want to know if writing a GUI in Java or doing it in C++ is easier. It depends on the chosen Framework. For Java, you have AWT and Swing which are part of the default Java distribution, and then there is SWT which is used by Eclipse, for example. For C++, there are many toolkits, with Qt, GTK and wxWidgets being the most popular ones, and all three support every major platform. Most of those "C++" GUI toolkits also have a Java binding or even a Java port, so you could use them with Java as well.
So far I've used Swing, Qt and a few others which don't help in your situation (The UI thingy that came with Borland C++ Builder and WinForms on .NET). Basically, the concepts are the same for all those frameworks, and I found none of them being harder or easier than the other. The only exception maybe Java, because I never got those LayoutManagers to work, even though the other toolkits have equivalents to LayoutManagers that are easy to master. But maybe thats just me.
People also will tell you that Java GUIs are always ugly and don't fit the host system. Well, most Java GUIs really are, but IMHO thats not because of Java, but because of bad programming. It takes two lines of code to let a Swing app adapt to the look and feel of the OS, and most programmers simply don't put enough effort into their Java GUIs to copy and paste those two lines... you can imagine how much they care about the rest of their GUI design.
For your current situation, I would recommend a C++ GUI, but if you know how your future plans look like, and if you know you will doing Java GUIs for the rest of your life, then it's probably ok to start that now and take the extra effort of .
And if you chose C++ for the GUI, people will tell you all kind of things to pull you in any direction. All of the three big portable frameworks have their pros and their cons, but I don't believe there is any single best or worst one among them. I'd recommend Qt simply because I already used it - but if I'd happten to have used GTK or wxWidgets instead, I'd probably suggest that.
Depending on your needs, a simple web interface might be the simplest when you have no existing frontend code. Embed a tiny web server in your application and open a browser on "http://localhost:12345" (or what port you end up using).
I can't say much about coupling Java and C++, but I suggest you have a look at Qt.
It's a C++ library for a lot of things, like file and network access, but it's most famous for GUI development. It also has a nice IDE were you can build your GUI with drag-and-drop.
I would also say that Qt is as OS-agnostic as it gets for GUI libraries.
Writing a GUI in C++ is no more of a pain than doing it in Java.
There are numerous cross-platform GUI libraries. GTK, gtk--, FoX, WX, etc. I would not recommend Qt since it's not really C++ (uses an extended version of the language requiring a special preprocessor before compilation). Plus it costs a fortune if you don't want to give away your product.
BTW, that's not how the word "hence" is used.
You did not mention the richness of the interaction between front and back ends, which would weight the importance of the existing language in your decision.
I've worked with Qt, Swing and SWT, and typically used both C++ and Java code with all of these toolkits. The interaction between languages can add additional cost/risk. However, sometimes that cost is warranted given other benefits.
If for any reason you choose a Java front end, look at JNA and SWIG.
Let's all be honest here. C++ just ain't on the map when it comes to portable GUIs.
Java has a consistent, portable, widely used, thoroughly documented, mature GUI toolkit. C++ has a bunch of half-assed OSS libraries that barely work, none are truly portable, plus some expensive commercial libraries that don't work on all targets they claim to, work spotty on the remaining targets, and invert control so that you are stuck in their weird framework.
Unless you need C++ for other reasons (of which there are plenty), choose Java for the GUI. The cross-over coding is trivial for someone who knows both languages, but it can get messy to manage, so you'll want to minimize the native interface as best you can. My advice here is to make a pact with your team that you will never attempt to hold pointers (or references) across the interface. It just gets messier if you do, and no debugger can save you when the lines get tangled. Instead, use integer or string keys and pass them across the native interface.
How about eclipse? Looks good and performs well on all platforms. My guess is most of eclipse is Java.
Why you don't you learn native C++ GUI like WINAPI or X11? Then you can make console software to compatible one of them like winehq, cygwin or other open sources compatibility or emulated software, since you never developed GUI on C++. Don't go for Java because it uses much more RAM. Of course, unless you have lots of RAM. For example, Eclipse (which is coded in Java) can use 500mb of RAM when running with no project opened.
Wrapping is not rewriting, it's just an adapter to make both languages meet. It is straight-forward
As you don't seem to be fixed on a language, I would choose a .NET Gui (With C++ CLR) you'll have a GUI that is machine independent and you can easily communicate with your existing code.
For beginners WinForms is maybe easier, but try to use WPF, it's the most modern variant for GUI development in the .NET world.
Personnally I would use C#/.NET for the GUI and use a C++ CLR wrapper DLL. But it is not the only solution.
Under Linux, the best .NET implementation is MONO. For all WinForms apps I have developped (they are not the craziest ones), they ran without change. With C++/Qt you will have to recompile for each target OS.
Do not use Java for creating GUIs unless platform independence is a must. The user experience will be sluggish and interoperability to C++ will be a pain.
For creating native GUI in C++, you can either use GTKmm along with a library like Boost or QT. Additionally, these libraries are available for most platforms (GNU/Linux, Windows, OS X) so your application can be recompiled anywhere.
edit: use GLADE for quickly creating GUI and fill in the signal slots with C++ code in GTKmm.
I'm about to port a smallish library from Java to Python and wanted some advice (smallish ~ a few thousand lines of code). I've studied the Java code a little, and noticed some design patterns that are common in both languages. However, there were definitely some Java-only idioms (singletons, etc) present that are generally not-well-received in Python-world.
I know at least one tool (j2py) exists that will turn a .java file into a .py file by walking the AST. Some initial experimentation yielded less than favorable results.
Should I even be considering using an automated tool to generate some code, or are the languages different enough that any tool would create enough re-work to have justified writing from scratch?
If tools aren't the devil, are there any besides j2py that can at least handle same-project import management? I don't expect any tool to match 3rd party libraries from one language to a substitute in another.
If it were me, I'd consider doing the work by hand. A couple thousand lines of code isn't a lot of code, and by rewriting it yourself (rather than translating it automatically), you'll be in a position to decide how to take advantage of Python idioms appropriately. (FWIW, I worked Java almost exclusively for 9 years, and I'm now working in Python, so I know the kind of translation you'd have to do.)
Code is always better the second time you write it anyway....
Plus a few thousand lines of Java can probably be translated into a few hundred of Python.
Have a look at Jython. It can fairly seamlessly integrate Python on top of Java, and provide access to Java libraries but still let you act on them dynamically.
Automatic translators (f2c, j2py, whatever) normally emit code you wouldn't want to touch by hand. This is fine when all you need to do is use the output (for example, if you have a C compiler and no Fortran compiler, f2c allows you to compile Fortran programs), but terrible when you need to do anything to the code afterwards. If you intend to use this as anything other than a black box, translate it by hand. At that size, it won't be too hard.
I would write it again by hand. I don't know of any automated tools that would generate non-disgusting looking Python, and having ported Java code to Python myself, I found the result was both higher quality than the original and considerably shorter.
You gain quality because Python is more expressive (for example, anonymous inner class MouseAdapters and the like go away in favor of simple first class functions), and you also gain the benefit of writing it a second time.
It also is considerably shorter: for example, 99% of getters/setters can just be left out in favor of directly accessing the fields. For the other 1% which actually do something you can use property().
However as David mentioned, if you don't ever need to read or maintain the code, an automatic translator would be fine.
Jython's not what you're looking for in the final solution, but it will make the porting go much smoother.
My approach would be:
If there are existing tests (unit or otherwise), rewrite them in Jython (using Python's unittest)
Write some characterization tests in Jython (tests that record the current behavior)
Start porting class by class:
For each class, subclass it in Jython and port the methods one by one, making the method in the superclass abstract
After each change, run the tests!
You'll now have working Jython code that hopefully has minimal dependencies on Java.
Run the tests in CPython and fix whatever's left.
Refactor - you'll want to Pythonify the code, probably simplifying it a lot with Python idioms. This is safe and easy because of the tests.
I've this in the past with great success.
I've used Java2Python. It's not too bad, you still need to understand the code as it doesn't do everything correctly, but it does help.
I have to integrate a large Java library in a quite large C++ application. A solution is to use JNI but this requires to hand code all the classes. Python has, for example, a wonderful solution with JPype (http://jpype.sourceforge.net/) that automatizes the process (although the same solution cannot be applied to C++ due to C++ and Python different natures).
Thanks,
Das
SWIG is a tool that lets you auto-generate bindings from one language to another. It supports C++ and Java and a dozen other languages.
Seems that my question was not clear enough. Maybe the confusion comes from JNI that allows the access in booth directions ...
What I want to do is to access a Java library FROM C++. That is, someone give me a JAR file that contains a collection od JAVA compiled classes and I must write code in C++ to access it (as I want to integrate the functionality of that Java library into a C++ application).
Hope that this clarifies the direction of access :)
Thanks,
Das
Not sure if this commercial tool makes life any easier, but you might wanna explore -- http://www.teamdev.com/jniwrapper/index.jsf
JNA is not quite what you're looking for, but it does make your life a lot easier. It doesn't require any boilerplate/generated code - you just write an interface for the methods you want to call.
Certainly, there is every reason to use JNA instead of JNI.
I have two suggestions which may or may not work for you:
First, you could try something very simple. Run the Java code in a separate process, and communicate with it with pipes or sockets. This is fairly easy to do, and doesn't require any crazy libraries. The downside is that the communication is somewhat limited (just some simple pipes), you'll need to write your own wrapper around it to send data across
Secondly, what exactly is this library? Perhaps we can suggest alternatives that are not written in Java, that would be much easier to use in your C++ application?