We Keep Coding

Process communication in JAVA, JavaSpaces

Two Java programs have to communicate with each other, To do that I found two possibilities
Using Sockets
Using JavaSpaces
After looking into the description, I found out, that JavaSpaces is apparently the better solution. Sadly, I can't get it to run. Ever totourial roots me to another installation process, to other files and so on.... :(
How to install JavaSpaces, where to download them etc?
If someone offers me a better solution for it I'll be thankful to (JavaSpaces seems to be from 2005)
this are the websites I found so far:
http://www.jroller.com/matsh/entry/intreagued_by_javaspaces_try_blitz
(Installation description, not working...)
http://www.jini.org/wiki/Main_Page
(Download links are broken)
http://www.jarvana.com/jarvana/inspect/com/sun/jini/jini-starterkit/2.1/jini-starterkit-2.1.zip?folder=jini2_1/
(Download of jini starter kit)

For one quick start using GigaSpaces, a commercial JavaSpaces product (with a community edition available), see http://www.gigaspaces.com/wiki/display/XAP8/Data+Grid+Quick+Start
Also see http://replay.waybackmachine.org/20070202031207/http://www.theserverside.com/tt/articles/article.tss%3Fl%3DUsingJavaSpaces and http://www.theserverside.com/news/thread.tss?thread_id=42164 and http://www.enigmastation.com/?page_id=425
JavaSpaces is great, IMO (I'm biased, as I work for GigaSpaces... but then again, I work for GigaSpaces because I think the underlying technology is great.) - it's got a very simple API but the transaction model is actually pretty strong, and it's very fast. It's simpler and stronger than JMS, and has a simpler deployment/connection model.
If you're GigaSpaces-averse for some reason ("yikes, someone makes money from this") you can look into Blitz as well.

In Feb 2009 another user on SO mentioned, that GigaSpaces is a mature version of JavaSpaces.
Looking at that older question, I start believing that JavaSpaces is dead..!?

Have you considered also using something like RMI where it becomes transparent the fact that you are invoking a method on a remote system?
Or JMS where you just send and read messages -- and the infrastructure routes them to the right place/process?
Or how about another approach where you have a network cache (e.g. memcached) where both processes can put and get items to/from the cache -- thus allowing for inter-process communication to a certain extent?

Implement 3270 protocol in Java

I've got a big problem with IBM HACL for accessing a server which speaks 3270 protocol. The library keeps crashing, and our JNI wrapper is actually a bug-fixing layer for the poorly-implemented and poorly-documented library (and I suspect we have introduced new bugs with it too). Moreover, in our company, everybody knows Java, and could maintain the software if we didn't have the JNI-Layer and the IBM class library.
We have to use the C++ class library, because the IBM Java library is unusable: we get every non-printable character translated, and we lose all control characters along the way.
Now the question is: can we ditch this library and implement our solution in Java completely (we'd like to avoid using another library from another vendor)? Is the protocol well documented? Is the implementation of 3270-over-ssl really so complex?
Thanks.

https://www.rfc-editor.org/rfc/rfc1041
so i guess its documented (assuming i hit the right doc)
couldnt find a java implementation though, you'd need to code it over telnet, or maybe SSH

I am unfamiliar with the differences between 3270 and 5250 data streams, but there is a 5250 implementation in Java in the tn5250j project available from http://tn5250j.sourceforge.net/
It might be usable for you?
(also there is a 3270 screen scraping project at http://freehost3270.sourceforge.net/ but it appears to be abandoned).

freehost3270 doesn't look as abandoned as it might appear - CVS has changes from 2 years ago. There is always an arguement that good code won't need to be changed that often in any case if the requirements have not altered. There have been complimentary comments wrt to the codebase. If you don't particularly want to work with other vendors products then working with this code/project seems to be your best option.

Freehost is not good code. Do not even bother trying it. There is a reason that it seems dead. JIN TN3270 is better but is incomplete. Ideally you want to find the API that your company's Emulator software uses. I am still searching for one for ours.

Another option would be h3270. It is a Java front-end to the x3270 suite of tools.

Interfacing R to Java

Is rjava the only way to connect R to Java? I am asking because there is a disclaimer at the end of the web page:
This interface uses Java reflection
API to find the correct method so it
is much slower and may not be right
(works for simple examples but may not
for more complex ones). For now its
use is discouraged in programs as it
may change in the future.
This is slightly concerning. How do you address this issue? I know that Rweka has a self-contained interface, so I may look into that package, but maybe many R users have already gone through the pains.

It is not the only one as the Omegahat project also has the RSJava package. But as many of the other brilliant innovations from Omegahat (which practically speaking is really just Duncan Temple Lang), this one may not build as easily or reliably.
The rJava package on the other hand is used by almost thirty other packages
CADStat, Containers, Deducer, JGR,
RFreak, RImageJ, RJDBC, RLadyBug,
aCGH.Spline, ant, arulesNBMiner,
colbycol, cshapes, dynGraph, farmR,
gWidgetsrJava, glmulti,
helloJavaWorld, iplots, rSymPy, rcdk,
rcdklibs, scagnostics, spcosa, RKEA,
RWeka, Snowball, openNLP, wordnet
which I take as quite the endorsement.

I think that disclaimer only applies if you use the $ operator to access your java objects. As long as you stick with the .jcall function you won't incur the overhead.
In terms of experience using rJava, I've found it works exactly as advertised and for my package (farmR) it hasn't caused any performance problems. I don't make a huge number of calls into java though, and I haven't used any of the java GUI toolkits.

I am an Rweka user, and I can tell you it is amazingly quick, it outperforms weka alone, while using it's functions in the r environment. I think that the R package has a very special way to integrate inside the language java libraries, nevertheless these libraries need to be prepared to allow this. For being able to do a proper integration you will need to do an important amount of research in order to see how to make things fit properly. I recommend you to read the documentation that comes with R, which details which are the best practices for writing NEW LIBRARIES libraries.

Java and MSMQ

I was curious if anyone had any suggestions on a Java library that provides access to MSMQ? I've downloaded the trial of the J-Integra Java-COM library and have built and run their MSMQ example app, but I was curious if there were any good (free :)) alternatives. I've run across a few JNI implementations like jMSMQ and a few others, but I'd rather avoid JNI if possible.
We've also investigated some .NET<->JMS interop solutions like JNBridge (with ActiveMQ). I think our company has decided to centralize our queueing in MSMQ however, so that would be our ideal solution.
We are hoping to use WCF (netMsmq or msmqIntegration) on the .NET side. I'm a little concerned about how the java side will deal with the WCF messages (binary encoding), but there should be options there (customBinding with text encoding and MSMQ transport?), so I'm not too worried about that. Mostly worried about getting access to MSMQ in Java.
Our other option is to just put a thin web-service layer at the input end of each queue, and achieve interop that way. Performance is a little bit of a concern there, however.
Any suggestions? Thanks a lot for anyone's time.

As far as I understand J-Integra is the only pure Java implementation of MSMQ, ie this is the only alternative if you are not running on Windows. (Please let me know if there are other alternatives!)
Apache Camel and other uses JNI to access the Windows API (DLL files) which obviously means that is only works on Windows.
I am currently trying out the code provided here http://www.codeplex.com/MsmqJava which seems simple to use, but I'm not really sure how transactions work.

There is an open-source library on CodePlex: MsmqJava. Free.

You can also try the http://javamsmq.codeplex.com/ which is also provide a complete solution of MSMQ JAVA interoperability.As well this having Unicode ASCII all functionality.In other dll based open source having memory leakage problem like crashing of application.But this open source don't having any memory leakage problem.

I am author of jni4net, open source intraprocess bridge between JVM and CLR. It's build on top of JNI and PInvoke. No C/C++ code needed. I hope it will help you.

Update: This answer no longer applies per comment:
Camel msmq component is discontinued :
fusesource.com/forums/thread.jspa?messageID=6040
You might take a look at how Apache Camel does it: Apache Camel: msmq

Genericized commons collection

I'm astonished that the Apache Commons Collections project still hasn't got around to making their library generics-aware. I really like the features provided by this library, but the lack of support for generics is a big turn-off. There is a Lavalabs fork of Commons Collections which does support generics, which seems to claim backward compatibility, but when I tried updating to this version, my web application failed to start (in JBoss).
My questions are:
Whether anyone has successfully updated from Commons Collections to the fork mentioned above
If Commons Collections has any plans to add support for generics
BTW, I'm aware of Google collections, but am reluctant to use it until the API stabilises.
Cheers,
Don

Consider Google Collections. From their Javalobby interview:
[Google Collections is] built with Java 5 features: generics, enums, covariant return types, etc. When writing Java 5 code, you want a collections library that takes full advantage of the language. In addition, we put enormous effort into making the library complete, robust, and consistent with the JDK collection classes.

There are contributions. Checkout the jira's
There is also a JDK5 branch.
We do would like to add generics and update Commons Collections to 1.5 (and 1.6). The biggest problem is how to address backwards compatibility. And people have very different opinions there. For some of the Commons components the newer JDK almost asks for a rewrite for the new JDKs IMHO.
During ApacheCon I felt the urge across several people to get this moving though. It's just a big task.
Feel free to show up on dev#commons.apache.org
cheers,
Torsten

Given that the last word in Jakarta's own internal debate was in Dec 07, I would say that Apache will not embrace generics, leaving the field open for something Java5 friendly like Google Collections.

I say, bite the bullet and switch to google-collections, at least for new code.
I know you're concerned about stability, but the google-collections library is VERY close to stable for 1.0 release -- hang out on the dev list or watch their reported issues, they are already very very cautious about changes, especially breaking ones. Any incompatibilities between the current release and the (seemingly imminent) 1.0 final are going to be extremely tiny.
Also, if you're worried about stability, pick a version (e.g. the current one, 1.0 RC4), and... just don't upgrade. Sure, you won't get any new features, but commons-collections hasn't been updated in a meaningful way in several years, so are you really any worse off? At least you're frozen on something with generics and (IMHO) a much better API.

The general BC problem is that package org.apache.commons.collections has been renamed to org.apache.commons.collections15. I don't know the reason of this change. Try to rename it back, recompile the library and run your application again.
I have found this issue using Clirr tool on commons-collections-3.2.1.jar (from Apache) and collections-generic-4.01.jar (from Lavalabs).

I can't imagine what reason you can have to don't use google collections. It's quite simple to use that library.
For my work i use both, apache collections and google collections.
can you explain more about why you can't use google collections?
regards

There's a genericised port of Commons Collections 3.1 available here, which we've been using for a few years now. Does the job nicely, and since it's based strictly on the existing Commons source, it has a stable API.
It could use updating to conform to Commons Collections 3.2, though.

Have a read on the collection blog, it provide the completed understanding of the collection framework.
http://tech.konnectingtheworld.com/2010/09/a-note-on-java-collections/
If you feel that you query has not been answered, get in touch with me. I shall try to provide you the information as much as I can.