We Keep Coding

Passing data from Java to Python [duplicate]

This question already has answers here:
Calling Python in Java?
(12 answers)
Closed 3 years ago.
I am working on a food application. It is an Android based application. The scenario is that there is a text box in that application for users to enter comments. Now I want to apply NLP (Semantic analysis) to these comments.
Please guide me that how could I pass the comments from Java to Python so that I can apply NLP to them.

There are two approaches that come to mind depending on the architecture that makes the most sense for you. They both have their pros and cons depending on your requirements so use your best judgement.
One approach (that it sounds like you're already considering) is starting a Python runtime from within Java. As #Leo Leontev mentioned, this approach has an answer you can find here. The pros of this approach is that you don't need any extra infrastructure. The cons are that you'll need to package a (potentially large) model with your app, running two runtimes at once is probably not great for performance or battery life, and your start-up time could take a hit when loading the model.
Another approach would be creating a separate Python web server that your app can make requests to as necessary. This could be a simple REST API with whatever endpoints you need. If you're making and hosting your own model, this can speed up your app since you can persist the model in memory rather than loading it every time a user starts your app. One pro to this approach is that it's extensible (you can always build more endpoints into your API including non-ML ones). If your model is non-generic and you want to protect it from being copied, this also has added security benefits since users won't have access to the model itself.
For most use-cases, I'd recommend the second approach.

REST API: Multiple versions, single application? [closed]

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 1 year ago.
Improve this question
I am working on a REST API where I will have to introduce some breaking changes soon, so a v2 is needed. We still need to support v1 for a couple of months though in parallel, to give our clients time to switch over to the new API whenever they are ready. Our API is offered via shared cloud, and all our clients share the same system backend, especially a single, shared database.
I have found a lot of articles about REST API versioning, but they were all more from a client's point of view, or high-level design point of view. That's not really my concern, our API already has a versioning in the URI, so offering services with a /v2 base path won't be aproblem.
However I am asking myself how I am actually going to implement this, and I haven't really found good articles on that. I don't really want to branch off a v2 of my project and then build and deploy v1 and v2 as separate applications, because then I would have maintenance, bugfixing, configuration changes etc in two applications, which is double work and carries the usual dangers of redundancy (i.e.: possible inconsistencies between the versions). Also, the v2 of course is not different in every service, so most of the code would still be the same.
Is there any best practices on how to technically implement a REST API in a single application that provides multiple versions to the outside, and where some code is shared (i.e.: v2/someService would internally redirect to v1/someService), and just the actual differences are coded in new services? Maybe there's even frameworks that help with designing this? The app is coded in Java with Spring MVC if that's helpful.
I'm thankful for any tips or resources on how to tackle this. Thanks!

I'm also now facing such task, and still having no useful answers.
Though I believe having separate v1 and v2 instances in parallel can still be at least a fallback-solution, I'm currently thinking about a scheme for a single application, which will heavily use the benefits of dependency injection in the application.
So, basically idea is to configure your IoC container accordingly to a received request, so that each and every service would receive a needed version of its dependencies. This can theoretically be a good solution, but it requires an already near to ideal architecture of your application (which is often not the case) where all the concerns are separated, etc. As SOLID as possible, in other words.
At least with this approach, you'll be able to quickly identify all the components of your codebase which require refactoring, though making the whole process not a quick one. Besides, I believe the closer changes approach the core of the application, the more difficult parallel versioning may be, but we will see.
I should point out once more, that for me it's still just an idea which I'm going to research further specifically for my project, so I'm not sure how easy or problematic it will be in fact.

Hope you have seen
API design ensuring backward compatibility
http://static.googleusercontent.com/media/research.google.com/en//pubs/archive/32713.pdf
Having two versions of API in the same application is quiet enough
api.mysite.com/[version1]/api/url
api.mysite.com/[version2]/api/url
Not sure why you need to build and deploy v1 and v2 as separate applications? Unless you are planning for a Zero-Down-time rolling upgrade in production

I like to bring up the following strategies into the discussion, and both are strategies in continuous delivery.
Branch Abstraction
The basic idea is to place an abstract layer in between the clients and your current implementation. Then introduce a second implementation behind the abstract layer. This gives you the opportunity to progress within your normal code base but support new features for your next version API instantly.
See BranchByAbstraction.
Feature Toggles
Add features to your code base without making them visible to your customers. This allows you stay on your main development branch even if things are not ready for end users yet.
See Feature Toggles (aka Feature Flags)

If I were faced with the situation you speak of, I would first try to keep my new version (v2) backward compatible with my first version (v1). If that were the case, you could just add functionality and update your API documentation, keeping only one active code base. I would think you could even add things to the response payload as long as the data coming back would not break anyone's code - sort of like adding fields to an existing database schema.
If v2 was not backward compatible with v1, you could possibly move v1 to another server and notify your users that it is being placed there for a stated, limited period to give them time to make code changes necessary to switch to v2, but also notify them that this version is no longer being updated and if they have issues, they will need to switch to the new version. Hence, v2 is the HEAD version of your code base with no other branches under active development.
I hope this helps and offers something you didn't already think of.

The v1/v2 dilemma is a strong hint that you actually do not have a REST API to start with. Peers in a REST architecture exchange more or less standardized content by clients requesting representations of media-types they understand. This technique is called content-type negotiation. Of course, a badly written server may ignore proposed media-types and send one the client does not understand. This will, though, prevent the client from interacting with the server further. A well-behaved server therefore should attempt to serve a client request as best as it can.
According to Fielding:
A REST API should spend almost all of its descriptive effort in defining the media type(s) used for representing resources and driving application state, or in defining extended relation names and/or hypertext-enabled mark-up for existing standard media types. Any effort spent describing what methods to use on what URIs of interest should be entirely defined within the scope of the processing rules for a media type (and, in most cases, already defined by existing media types). [Failure here implies that out-of-band information is driving interaction instead of hypertext.] Source
A media type describes how the syntax of a payload exchanged for such a media-type looks like as well as the semantics each element in that representation has. With the help of meaningful link relation names and media types a server can teach a client on the next options available a client can make use of while progressing through its task. I.e. think of a case where a previous response contained a link relation create to the client. The client does not really know how something has to look like in order to be processable by the server, thoug on invoking the URI returned for the create link relation name the server responds with a form like representation along the line of application/vnd.xyz-form+json where this media type defines some input controls the client can use in order to generate a request representation expected by the server on the target endpoint. Similar to the Web the custom form also contains a HTTP action as well as a target URI provided by the client to send the response to and eventually also the representation preferred by the server.
Clients in a REST architecture shouldn't care about the URI, so returning an URI containing either v1 or v2 should be more or less meaningless to them. Fielding even stated that a REST API itself shouldn't be versioned at all! What is important though is that the client and server are able to understand the payload received.
Instead of versioning the URI or API, the media type describing the syntax and semantic actually need to be versioned. I.e. if you take a look at the browser based Web (the big sibling of REST) and here HTML in particular you will notice that it is designed in a way to require new version to stay backwards compatible. I.e. client and server receiving a text/html defined payload will be able to handle pure HTML (1.0) up to HTML5 content regardless which actuall syntax (maybe even a mixture) was used. Other media types, however, might not be that lenient. Here you could either make use of profiles or register a whole new media-type if you think the old and new one are completly incompatible to each other.
Either way, I hope I could shed a bit more light on REST architecture and how you might get there. I am well aware that my suggestion may not be easy to achieve, though once you got it you basically decoupled clients from your API and gave the latter one freedom to evolve while not having to fear breaking clients. There will still be a coupling but both, client and server, will couple to the media types rather than to each other. Before creating a new media-type it is probably worth looking for already existing ones

What languages/internet protocols for controlling robots/electronics remotely?

I wonder what languages are used in robots and electronics. Is it low level languages like Java, C, C++ etc?
And if these robots and electronics could be controlled from another place, what protocol is used?
It couldn't be HTTP Rest, could it? :)

Ada is also becoming a viable choice for programming language even for smaller platform. Ada has very good support for low-level operations, as well as high-level things.
As examples of smaller platforms, Ada is available for the Atmel AVR (8-bit) as AVR-Ada. See http://sourceforge.net/apps/mediawiki/avr-ada/index.php?title=Main_Page
For LEGO MindStorms, Ada is available from GNAT as GPL version, which also support the Ravenscar tasking profile. Hence you can easily create multitasking applications on the MindStorms platform. See http://libre.adacore.com/libre/tools/mindstorms/

How about LEGO Mindstorms? Unless you have specific requirements regarding the physical properties of the robot that would rule out Mindstorms/NXT, you can do a lot with it. And it's a serious piece of kit - don't be fooled by the "LEGO" brand.
http://mindstorms.lego.com/en-us/Default.aspx
In addition to shipping with its own programming language, it is also supported by Microsoft Robotics Developer Studio - so you can use .Net to code for it.
http://msdn.microsoft.com/en-us/robotics/default
The great thing about it is that it is actually LEGO, with its inherently modular brick system for constructing the robot itself, and so allows for a lot of rapid prototyping and experimenting, without having to buy specialized parts.
It has built in Bluetooth, allowing for remote control. You can also download your compiled program code to it, so that it operates autonomously, either through USB or Bluetooth.
I bought the previous version back in 2008, and expanded with some regular Technics models for parts. It includes stuff like touch sensors, sound sensors, ultrasonic sensors, light / colour sensors and (two way) servo motors, and you can get third party add-ons like gyroscope, accelerometer, compass etc. Great fun.

I would say that it depends on your project. I've used C/Assembler to program an electronic microprocessor, but I know that you can use high-level programming languages as well for some projects, if your robots operating system allows it. Such as Java/C# and so on.
There are a variety of protocols used to connect to an instrument, and my believe is that TCP/IP or UDP/IP is the most common. But some people prefer to write/program their own protocols.

Most of the robots I built were built with Lego Mindstorms. There are a few languages you can use, but the default language is a visual workbench. You can remotely control the robot via Bluetooth or IR (and Lego includes a USB-connected IR transmitter)

C/C++, Java and Python.
I would say C/C++ are more widely used than languages like Java and Python for programming robots, simply because there is so much stuff already out there. And C is also a very commonly used language for embedded applications. Many people I know in industry use C as the means for controlling robots and hardware like RS-232, UARTs, stepper motors etc.
When I was working in academic research, my German colleagues used Java almost exclusively on autonomous robots, with satisfactory results. If you use Java you simply have to abstract the hardware when you are using it, which can be done with Player / Stage or ROS.
It all depends on what you want to do, I guess. In my particular area (Mitsubishi PLCs) C++ is the language of choice. Other industries use C++ to program robotics, such as Honda ASIMO. AMD ATi use Python to program their Graphic Accelerators. Pretty much any language that can talk to a communications port can be used for robotics.
As for controlling them remotely, Battlebots would probably be a sterling example:
Whichever language you choose, you will soon find that you will need to speak in terms of zeroes and ones ;)

I recent made a simple remote controlled robot programmed in Java with the help of this book
http://www.google.co.uk/products/catalog?q=build+java+robots&hl=en&cid=346434932749925759&ei=WATITISGE5_g2ASm_tilCQ&sa=title&ved=0CAcQ8wIwADgA#p
This book showed me how to talk to the robot using bluetooth.
I've also read that BASIC is a good language to get started with, when build your first robot.

Disclaimer: I'm no expert.
I only really have experience with Arduino, which can be programmed with assembly or C (the AVR-GCC toolchain). However, if the target environment is sufficiently powerful or has enough memory, there's nothing to stop one from using a higher level language -- aside from other technical constraints such as, say, a hard realtime requirement -- such as, say, Lua or something even higher-level.
As for communications, it depends on the final transport medium as well. For, say, Bluetooth, Zigbee, just digital radio communication, or maybe, you know, a couple of wires (or even one wire) or whatever, it'd be some sufficiently low-bandwidth serial protocol... But of course, it all depends on the target platform.
For what it's worth, regarding HTTP -- I built an HTTP controllable RGB moodlight (that smoothly fades between colors! :P) using Arduino and the Ethernet Shield available for it. The HTTP server runs on the Arduino.

You can control Robots and electronic gadgets with different type of languages in which you are most comfortable .But it also depends on the type of the gadgets you are trying to control i.e if you are developing a robot or gadget from scratch you can program it with the language of your choice like C ,C++. Python ,Java etc .You can also use the the Embedded language to program the controller with your choice of language there are many different compilers available only to compile your program form the controller for example MicroC is one of them which I use often use to compile my Embedded code for microcontrollers .If you are programming some kind of board like Arduino then you can use its own IDE where you can program it . To control the the Robots and gadgets remotely you can use many different ways i.e .:
Internet : You can use internet to control them by integrating them with modules like ESP8266 , NodeMcu , GSM modules etc and use a custom web application ,Mobile app to control them.This comes under Internet Of Things (IOT).
2.Bluetooth : You can even use Bluetooth to control the devices by integrating a bluetooth module with your device but the range of bluetooth is low .
Radio Frequency RF: You can also use radio frequency RF modules to control robots in remote areas but the cost of implementation is higher than rest of the cases .

Simple Programming Theory Question

Hi guys does anyone know why the programming language C++ is used more widely in biometric security applications compared to the programming language Java? The answers that I have collected so far are 1) Virtual Compilers 2) OpenCV Library provided by C++. Can anyone help with this question??

Maybe it's the hardware support: I wrote an app that uses a fingerprint sensor. The library support for the device is C++, so I wrote the app in C++. Now they have a .NET version, so my next app will be C#.

I don't know specifically about biometric applications, but in general when security is important Java can be a stumbling block. Depending on how the security requirements are written, they can cover things that one must do manually in C++, but which are done automatically by Java. This poses a problem because one would need to demonstrate that Java properly (and in a timely manner!) satisfies the requirement. It is a lot easier to show that these requirements are met in C++ code, because the code the meets the requirement is part of the program in question.
If the security person/requirements/customer make it clear that relying on Java for some security features is acceptable, then this is no big deal. We could go round-and-round about whether or not it is reasonable to rely on/trust Java to satisfy security requirements, it really just depends on the specific security needs.

I am willing to put money on the reason being simply that the access api's for the hardware are written in c++. Most of the modern/higher-level languages are not going to easily communicate with hardware originaly exposed through a C/C++ api.
On a somewhat related note, Vala has all the languages features expected of a modern\high-level language(and then some), but compiles to C binary and source, and can easily make use of any library written in C (not sure about c++). Check it out, I havnt used it much, but its pretty cool.

Implementing a library in C++ provide a lot over java. Once written, C++ library can run on almost any platform (including embedded ones), and can be made available as a native import to a variety of other languages through tools like SWIG. Java can only run on something with enough speed and memory to run a JVM, and the only other Java programs can include the code as a native import. For biometric applications especially I think running on embedded systems would be a large concern, since you could build this into a small sensor.
The more glib answer would be no one wants to wait for your garbage collection cycle to launch the friggen missiles.

You could replace Java with any other language there. Probably it has more to do with the APIs and hardware.
Also, Java is more suited for Web Applications. Its not the best choice for desktop applications.

For some biometric applications, execution speed is crucial.
For instance, let's say you're doing facial recognition for a checkpoint, and Java takes twice the time to run the algorithm that a compiled language like C++ does. That means if you go with Java, either:
The checkpoint lines will be twice as long,
You'll have to pay to staff twice as many checkpoints, or
Your system will do half as good a job at recognizing faces
None of those are usually acceptable options, which makes using Java a non-starter.

Can Java apps integrate with VB apps?

I am not sure exactly what I am asking....The guys that do the software development for the company I work for write everything in VB. I am currently the Web developer for this company and I specialize in Flex apps. I am thinking about expanding into their area. But I do not want to do VB, I don't mean to bash on VB but the coding syntax is not for me. So I am wondering if Java can integrate with VB? Also not sure if it matters but I think everything they do is procedural, and I will be doing OOP.
Thanks.

There are lots of integration opportunities, but before examining them, if I were you I would re-examine the question itself.
It should be exceptional to introduce a new language into an established project. The desires or aesthetic preference or skillset of a single developer is not a good enough justification to do so. Introducing a new language into a project should be a strategic decision for the project, not a backhanded one.
If you do choose to expand the core languages used to develop the system,
COM interop
is possible with JACOB. I believe IBM has a bridge as well.(Check alphaworks)
Java-.NET bridging
is possible via JNBridge and other bridges. This makes sense only if VB.NET is in use.
SOAP, XML document exchange, REST
suitable over a services boundary. It requires TCP or HTTP or some network protocol.
common data stores
can serve as a rendezvous point. Both Java and VB can read and update data in SQL Server, Oracle, MSMQ, MQSeries, and so on. Even a filesystem can be an integration point.
Think of data format as related to, but ideally independent of, the integration mechanism. What I mean is: You can use an XML document for integration, whether it is stored in a database, or sent over a REST interface, or stored in a filesystem, or put/get on a queue. You can use a comma-separated file over any of those mechanisms as well.

Potentially they could expose a service layer via soap or something simpler? Also you could always work against the same database with different languages however unless most of the logic is in stored procedures (not necessarily recommending this approach) then you end up with repeated code.

Not really. Java uses CORBA for interop, and VB uses COM for interop. You may be able to make a bridge using JNI, but I understand that can be quite the pain.

I haven't done this by I believe you have the following options:
Use the Java-COM bridge, as VB uses COM. This library was already mentioned here several times
If you are using VB.net, you probably use hessian, As it has both Java and C# implementations.

You could bridge the two using a C/C++ adapter to map JNI calls with COM. But that would be horrible. I hope there is a better solution, but my understanding is that it is pretty hard to integrate .NET code and Java as both vendors (Sun and Microsoft) don't have any incentive to streamline that kind of development.