I'm curious to know if it's possible to fetch data from other applications to my Java program. I know java is running in a virtual environment, hence JVM and therefore have problems communicating with other applications unless you were to use the Robot class or so forth.
What I would like to do, for starters as educational purposes is to take let's say a music application like Spotify/iTunes, fetch the playlist (text data) and send/display it in a text file. I've tried a few things so far, and the only thing I've come close to is by using the Robot class, opening the application, doing Ctrl+A, pasting it in to a text document and so forth but that's more like a macro. I would like to make a java application that would do this automatically. Is that possible in any sense with Java or are you just better off changing languages? I wish to do it with Java though because it's the language I've studied for the past year and what I'm trying to master. (Sorry for the long explanation.)
It's nothing to do with Java and the JVM. Any language has the same problems and solutions for this sort of situation.
The thing you need to talk to has to provide you a way to talk to it. You need to talk to it using that way.
Methods include pipes, custom network protocols, SOAP and Restful web services, etc.
Just because an application runs in a virtual machine doesn't mean it cannot access external data through an API provided by an external program. For example, iTunes has a COM-based API for accessing playlists, and here is an example of using it from C#. You'll need something which allows accessing COM objects from Java.
(Please note I know nothing about this topic, this is just what I found with a little searching...)
You need to know which data interfaces provides the application you want to connect to.
As an example, maybe the application writes files to disk or stores some info in a database.
Then with Java you can read files, query the database, use an API (web services, REST, etc..) and so on...
Related
I've been doing some programming in Java and some in C but now I need to sort of use both together.
Here's the situation, I'm using Hadoop/Hbase to process and store a lot of data but I'm using C/Cuda to do number crunching on the data. Is there a stable/mature/common way to take data (it's basically a log file) in Java and pass it to a C program, which C processes the data it stores it as a linked list that is then accessible by the Java app?
I might not be searching for the right thing, but so far I found JavaCPP, which is good but seems to involve both programs together. Because Java handles the data flow and C handles the processing of the data, I thought it might be better to keep them as independent programs that can communicate to each other as opposed to a single program that may become confusing. But I'm totally flexible so any suggestions/solutions are welcomed.
You may find it easier to keep the programs testable and clear if you leave them separate and then use a client-server approach, or simply choose a common file format and have the latter steps poll the output directory for new files to process.
To make it easier to define file formats across different languages, consider a package like Apache Thrift or Google Protocol Buffers.
Here what I have on the top of my head
1. run C program using command line from java app.
2. Use JNI/JNA
3. Implement your own "client-server" architecture. It sounds complicated but in some cases it may be the best and the simplest solution.
4. Communicate using Web service, SOAP, REST, whatever.
I hope this is helpful for the beginning.
You are welcome to ask more specific questions once you have.
I would like to know if there is any way to communicate with a running console program (preferably running on Linux / Debian) via PHP. I am currently trying to create a webinterface for a little (existing) console Java program and I have no idea if there is any way I could do this. Could I "inject" a piece of code, lets say, a remote control module, and then use this to "remote-control" the script via PHP?
(It would be great if the existing .jar file wouldn't be changed / just injection, no reprogramming)
I am grateful for every piece of advice!
If the running program has no communication interface, then you can't communicate with it. If it does however, then the answer very much depends on how the program receives external input.
If the program contains a network listening thread (daemon), then you can communicate with it on the loopback interface using CURL or raw sockets from PHP.
Other ways of communicating with the program would be to share access to a file (PHP writes the file, Java reads it) or via a database.
The database would be the best option - it is thread safe and both PHP and Java have excellent MySQL support (Java via JDBC).
If, however you do not need to actually interface with the running program only merely need to start/stop/restart it, you can do this with the system() function in PHP.
If the Java program just runs and outputs to console, then you can do it easily enough, something like this:
$output = system( "java com.yourcompany.package.RunnableClass" );
print $output;
Assuming that the user who is running PHP has access to the Java binary of course, and that you have permission to access the JAR file.
Accessing a running program is a bit more difficult. Most programs will not have this built in by default (nor should they - giving access to random external processes in many cases is not desirable). If it does, though, you are in good shape. If it doesn't, and you can change the Java code, then you're good. If not, then you may be out of luck.
If that is the case, another good approach might be to see what resources the Java code is accessing, and how it is accessing them. Then you can write something similar in PHP. Obviously this is not ideal as you'll be re-inventing the wheel, but if you need to get to the data or whatever it is, and can't use any of the approaches above, it will work.
I'm currently developing a GUI for a Java-application that I've created. I would like to keep the GUI in a separate process from the rest of the client. The rationale behind this is:
Reduced risk of crashing. E.g. a OutOfMemoryError in the GUI won't crash the rest of the client.
I get an API "for free". If I later on want to allow other people to programmatically access the client I can just let them use the same API that the GUI is using.
I'm writing the GUI in SWT and the client is created using IntelliJ. Since Eclipse has a lot better SWT-support it makes sense to keep them separate, so that I can use Eclipse for the GUI-code and IntelliJ for the rest.
My question is now: what technology should I use to expose the client's interface to the GUI? RMI is what came to mind first. However, that has the disadvantages of restricting the API to be Java only. I'm also not sure about how well suited RMI is for large scale deployment (e.g. how does it handle local firewalls?). However, I don't want to rule it out just yet.
I should also mention that I have some deployment-requirements as well:
Must be able to run as non-admin.
Must be able to handle restrictive local firewall-restrictions.
Deployment must be automatic (it's a large scale consumer-app) and work on Windows, Mac OS X and Linux.
Given these restriction what solution would you use?
I faced this same situation a while back, except that the back-end was in Python, and the GUI was in java.
Important points to consider:
how flexible and granular the interface between the GUI and the back-end needs to be. Do you want to be able to do one thing from the GUI? 5 different things? 10? 50? How tightly coupled is the GUI -- will it know about/be calling individual methods in the back-end?
how the output gets from the back-end to the GUI. Can it simply write to STDOUT or to temp files? Does it need something more elaborate?
the format of the output. Ideally, it should be easily parseable, which indicates XML or JSON may be your best bet.
You might find JSON-RPC useful: it's a standard for remote method calls to separate programs.
All in all, it's hard for me to say what would be best for you. I ended up avoiding RPC, and gave the back-end a simple command-line interface; output was written to temp files and STDERR, as JSON objects. I feel that this was a good decision because it kept the interface between the programs very simple and uncoupled.
Suppose i have one website with simple pages in php like
page1.php
page2.php
Now there is one page where i want some detailed functioning and i want to use python for that and it will look like
page3.py
and in other page i want to use java like
page4.jsp
Provided i have installed python , java on webserver.
Is it possible?
Yes. It's possible. Where you will find yourself in trouble is when you want to share server-side information among them (I.E. sessions).
Other than that, you can use (but I would advise against it) all languages you want on a website.
Yes, it is possible, but you definitely should NOT do it.
Communication between pages running different technologies will not be elegant, if for no other reason than the fact that you won't get a shared session pool. Session bridges are possible, but they are a pain to do.
I would say you are making a mistake if you can't just pick a single language for your core web layer.
Yes it is very possible, as long as the server can serve the files you want to use. If it doesn't have python, you can't use python.
It depends on the web server. Apache can do it. Just make sure you have the appropriate handler modules for each file type, and use the AddHandler configuration directive to map each type to the appropriate handler.
Also, to be pedantic, you can not only use all three of those, but you can actually integrate them at the session level, since all of those languages are available on the JVM. So, in one container you can run all of the PHP, Python, and Java code. You can share session state, reuse connections to the database (via server wide connection pools), leverage Java libs in your PHP and/or Python code, etc.
I'm not saying this will be "drag and drop" easy, but it is possible, and even practical if you need that kind of close integration (vs integration via a database or filesystem). There will likely be nuances in ensuring that the Python and PHP code runs properly on the Java implementations as well.
Short answer: Yes, many web servers can handle generating pages from multiple languages.
People are talking about session...
Almost all server side technologies today support custom session providers, where you can hook up some code to share you session between different HTTP modules and binders.
If you are starting to write a web site from scratch, and you need to write all of your code for yourself, than probably you will choose to do it in one programming language (only for your comfort of coding).
But... where it's all starting to change? When you want to mash-up some open source and community source code to make a web site. Let's say a store & community with ASP.NET to mix up with CRM like Sugar CRM (which is in PHP).
In that case you don't need any session sharing, just users sync procedure in the DB.
Also, if you choose IIS 7 (Windows Server) or Apache (using Mono project you can run ASP.NET on LAMP), you could run them both on the same machine.
And remember, the most important thing is TIME TO MARKET! So saving code time can be crucial for you success.
ENJOY!
I work for a PHP development company and all the time these ASP.Net companies come to US for whatever reason I've never understood. We build them forms in PHP usually dynamically pulling in the layout - sometimes hosted on a subdomain, sometimes hosted directly in IIS with the PHP module. Its very messy and bad, it can be done but I'd say avoid it.
You can use Apache Reverse Proxy to do it and session must be readable between programming languages. I use Go, NodeJS and PHP in one website. Session is saved in Postgresql. The hardest part is all programming that is used in your website can read session with same format and saved in same place. I have used github.com/yvasiyarov/php_session_decoder to read and save session with Go and save it in Postgresql so PHP can process that session
I am implementing a website using PHP for the front end and a Java service as the back end. The two parts are as follows:
PHP front end listens to http requests and interacts with the database.
The Java back end run continuously and responds to calls from the front end.
More specifically, the back end is a daemon that connects and maintain the link to several IM services (AOL, MSN, Yahoo, Jabber...).
Both of the layers will be deployed on the same system (a CentOS box, I suppose) and introducing a middle layer (for instance: using XML-RPC) will reduce the performance (the resource is also rather limited).
Question: Is there a way to link the two layers directly? (no more web services in between)
Since this is communication between two separate running processes, a "direct" call (as in JNI) is not possible. The easiest ways to do such interprocess communcation are probably named pipes and network sockets. In both cases, you'll have to define a communication protocol and implement it on both sides. Using a standard protocol such as XML-RPC makes this easier, but is not strictly necessary.
There are generally four patterns for application integration:
via Filesystem, ie. one producers writes data to a directory monitored by the consumer
via Database, ie. two applications share a schema or table and use it to swap data
via RMI/RPC/web service/any blocking, sync call from one app to another. For PHP to Java you can pick from the various integration libraries listed above, or use some web services standards like SOAP.
via messaging/any non-blocking, async operation where one app sends a message to another app.
Each of these patterns has pros and cons, but a good rule of thumb is to pick the one with the loosest coupling that you can get away with. For example, if you selected #4 your Java app could crash without also taking down your PHP app.
I'd suggest before looking at specific libraries or technologies listed in the answers here that you pick the right pattern for you, then investigate your specific options.
I have tried PHP-Java bridge(php-java-bridge.sourceforge.net/pjb/) and it works quite well. Basically, we need to run a jar file (JavaBridge.jar) which listens on port(there are several options available like Local socket, 8080 port and so on). Your java class files must be availabe to the JavaBridge in the classpath. You need to include a file Java.inc in your php and you can access the Java classes.
Sure, there are lots of ways, but you said about the limited resource...
IMHO define your own lightweight RPC-like protocol and use sockets on TCP/IP to communicate. Actually in this case there's no need to use full advantages of RPC etc... You need only to define API for this particular case and implement it on both sides. In this case you can serialize your packets to quite small. You can even assign a kind of GUIDs to your remote methods and use them to save the traffic and speed-up your intercommunication.
The advantage of sockets usage is that your solution will be pretty scalable.
You could try the PHP/Java integration.
Also, if the communication is one-way (something like "sendmail for IM"), you could write out the PHP requests to a file and monitor that in your Java app.
I was also faced with this problem recently. The Resin solution above is actually a complete re-write of PHP in Java along the lines of JRuby, Jython and Rhino. It is called Quercus. But I'm guessing for you as it was for me, tossing out your Apache/PHP setup isn't really an option.
And there are more problems with Quercus besides: the free version is GPL, which is tricky if you're developing commercial software (though not as tricky as Resin would like you to believe (but IANAL)) and on top of that the free version doesn't support compiling to byte code, so its basically an interpreter written in Java.
What I decided on in the end was to just exchange simple messages over HTTP. I used PHP's json_encode()/json_decode() and Java's json-lib to encode the messages in JSON (simple, text-based, good match for data model).
Another interesting and light-weight option would be to have Java generate PHP code and then use PHP include() directive to fetch that over HTTP and execute it. I haven't tried this though.
If its the actual HTTP calls you're concerned about (for performance), neither of these solutions will help there. All I can say is that I haven't had problems with the PHP and Java on the same LAN. My feeling is that it won't be a problem for the vast majority of applications as long as you keep your RPC calls fairly course-grained (which you really should do anyway).
Sorry, this is a bit of a quick answer but: i heard the Resin app server has support for integrating java and PHP.
They claim they can smash php and java together: http://www.caucho.com/resin-3.0/quercus/
I've used resin for serving J2ee applications, but not for its PHP support.
I'd be interested to hear of such adventures.
Why not use web service?
Make a Java layer and put a ws access(Axis, SpringWS, etc...) and the Php access the Java layer using one ws client.
I think it's simple and useful.
I've come across this page which introduces a means to link the two layers. However, it still requires a middle layer (TCP/IP). Moreover, other services may exploit the Java service as well because it accepts all incoming connections.
http://www.devx.com/Java/Article/20509
[Researching...]