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.
Related
We are currently using MICO to establish the communication between a server and a client, where the client is a simulator written in C++ and the server is a java program displaying an animation of what happens in the simulation. It seems that the developemt of MICO has slowed down to an almost halt and bugs that only allow us to hack around them (as we don't have the time to first figure out which parts of MICO are responsible for codegeneration and so on) keep us from making real progress.
So, does any one of you know of a good drop-in replacement? We would like to have the following:
The compiler can generate both C++ and Java-Code from the idl.
The project should still show considerable support.
The implementation should be open-sourced (GPL or BSD, or something alike), as we use our programs to teach students as well.
The migration from MICO should be as easy as possible. (This is not a hard requirement, but would be a good thing)
I found some other CORBA implementations, e.g. TAO, but I didn't find any of which I could
say that they are still supported. Correct me if I am wrong here.
The Free CORBA® Downloads page might be of interest to you.
Just naming:
orbit2 1, also pyorbit etc.
omniORB
TAO (has already been mentioned)
1 On my Ubuntu box, apt-rdepends -r liborbit2 returns 5530 lines...
I don't know where CORBA or MICO in particular has gone in the last 5 years, but back then a drop in replacement was not really possible, since differences between vendors where still there.
Not necessarily API differences (POA, etc.) but
in implementation behavior,
in custom extensions which were required to make it work in a real-world environment (threading, load balancing, security, etc.),
in how the development tools worked
and also about the whole deployment or runtime story.
We had Orbix ASP/2000/Whatever and ORBacus which were interchangeable having a small compatibility layer, some Makefile framework to hide differences in tools (e.g. the IDL compiler) and some scripts for wrapping ORB specific processes.
Unfortunately, ORBacus has long been bought by (then) IONA, which already make Orbix. IONA itself has been bought by someone else (I forgot). The original authors of ORBacus, plus some devs from IONA Orbix, changed their ways somewhat and produced Ice, which is not CORBA but somewhat alike - of course without the glitches ;-)
Concerning TOA, I think it would be the "best" choice concerning still being developed as it is driven by research on the Washington University. But last time I looked, they didn't have Java implementation but people seemed to use JacORB.
Maybe all this helps you little, unless it brings even more confusion :-)
TAO as C++ ORB is still actively supported and developed (see http://www.cs.wustl.edu/~schmidt/commercial-support.html). For Java I would propose JacORB.
On http://www.orbzone.org there is an overview of available corba implementations.
I have an existing library written in C# which wraps a much lower-level TCP/IP API and exposes messages coming down the wire from a server (proprietary binary protocol) as .NET events. I also provide method calls on an object which handles the complexities of marshalling convenient .NET types (like System.DateTime) down to the binary encodings and fixed-length structures that the API requires (for outgoing messages to the server). There are a fair number of existing applications (both internally and used by third parties) built on top of this .NET library.
Recently, we've been approached by someone who doesn't want to do all the legwork of abstracting the TCP/IP themselves, but their environment is strictly non-Windows (I assume *nix, but I'm not 100% sure), and they've intimated that their ideal would be something callable from Java.
What's the best way to support their requirements, without me having to:
Port the code to Java now (including an unmanaged DLL that we currently P/Invoke into for decompression)
Have to maintain two separate code-bases going forwards (i.e. making the same bug-fixes and feature enhancements twice)
One thing I've considered is to re-write most of the core TCP/IP functionality once into something more cross-platform (C / C++) and then change my .NET library to be a thin layer on top of this (P/Invoke?), and then write a similarly thin Java layer on top of it too (JNI?).
Pros:
I mostly spend my time writing things only once.
Cons:
Most of the code would now be unmanaged - not the end of the world, but not ideal from a productivity point of view (for me).
Longer development time (can't port C# sockets code to C / C++ as quickly as just porting to Java) [How true is this?]
At this point, the underlying API is mostly wrapped and the library is very stable, so there's probably not a lot of new development - it might not be that bad to just port the current code to Java and then have to make occasional bug-fixes or expose new fields twice in the future.
Potential instability for my existing client applications while the version they're running on changes drastically underneath them. (Off the top of my head I can think of 32/64 bit issues, endianness issues, and general bugs that may crop up during the port, etc.)
Another option I've briefly considered is somehow rigging Mono up to Java, so that I can leverage all of the existing C# code I already have. I'm not too clued up though on how smooth the developer experience will be for the Java developers who have to consume it though. I'm pretty sure that most of the code should run without trouble under Mono (bar the decompression P/Invoke which should probably just be ported to C# anyway).
I'd ideally not like to add another layer of TCP/IP, pipes, etc. between my code and the client Java app if I can help it (so WCF to Java-side WS-DeathStar is probably out). I've never done any serious development with Java, but I take some pride in the fact that the library is currently a piece of cake for a third-party developer to integrate into his application (as long as he's running .NET of course :)), and I'd like to be able to keep that same ease-of-use for any Java developers who want the same experience.
So if anyone has opinions on the 3 options I've proposed (port to Java & maintain twice, port to C and write thin language bindings for .NET and Java or, try and integrate Java and Mono), or any other suggestions I'd love to hear them.
Thanks
Edit: After speaking directly with the developer at the client (i.e. removal of broken telephone AKA Sales Department) the requirements have changed enough that this question no longer applies very well to my immediate situation. However, I'll leave the question open in the hopes that we can generate some more good suggestions.
In my particular case, the client actually runs Windows machines in addition to Solaris (who doesn't these days?) and is happy for us to write an application (Windows Service) on top of the library and provide a much more simplified and smaller TCP/IP API for them to code against. We will translate their simple messages into the format that the downstream system understands, and translate incoming responses back for them to consume, so that they can continue to interface with this downstream system via their Java application.
Getting back to the original scenario after thinking about this for a couple of weeks, I do have a few more comments:
A portable C-based library with different language bindings on top would probably be the way to go if you knew up front that you'd need to support multiple languages / platforms.
On *nix, can a single process host both a Java runtime and a Mono runtime simultaneously? I know in earlier versions of .NET you couldn't have two different .NET runtimes in the same process, but I believe they've fixed this with .NET 4? If this is possible, how would one communicate between the two? Ideally you'd want something as simple as a static method call and a delegate to raise responses with.
If there's no easy direct interface support between Java & Mono (methods & delegates, etc.), one might consider using something like ZeroMQ with Protocol Buffers or Apache Thrift as the message format. This would work in-process, inter-process and over the network because of ZeroMQ's support for different transports.
Spend more time getting the requirements nailed down before deciding on an implementation. Until you know what is required, you don't have any criteria for choosing between designs.
If it's a non-windows environment, it doesn't make sense to have .NET anywhere in there, for example.
If you need something that runs on the Java Virtual Machine but looks a lot like C#, you should check out Stab. This will not help you with P/Invoke and the like but you may find it less work to port your C# code to Java and maintain it.
You should look into Mono though. I expect that all your C# code would run unmodified (except the parts that touch the unmanaged DLL).
I have not used it but jni4net is supposed to allow calling .NET code from Java. If your clients want a Java interface, this may be a solution.
I use Mono on Linux and the Mac all the time even when .NET compatibility is not a priority. I like C# and the .NET libraries and prefer the CLR to the JVM. Mono is MIT/X11 licensed which means that you can use it commercially if you like. Unlike some others, I see no reason to avoid technology championed by Microsoft while favouring technology championed by Oracle and IBM.
Using Mono will not help you with the unmanaged bits, although you can still P/Invoke into a native DLL. You will just have to port that DLL yourself or find some equivalent.
You may also want to look into Mono Ahead of Time compilation.
Have you considered mono? It would most likely support your existing code in the non-windows environment. The trick would be calling it from java, but the mono folks might have something to help you out there, too.
This probably isn't the right solution in your case, but for completeness:
There are a few languages that can target both the JVM and .NET, in particular Ruby (JRuby and IronRuby) and Python (Jython and IronPython). Scala might eventually get there too, although right now the .NET version is a long way behind the JVM version.
Anyway, you could potentially rewrite your library in Ruby or Python and target both runtimes.
If what you really, really want is to be able to code in .NET and have it run on the JVM, you could check out Grasshopper (2015-09: link possibly dead). That is what it is designed to do.
I know the Mainsoft guys have been contributors to Mono over the years. If I remember correctly, they wrote the Visual Basic compiler for Mono.
There is also the C# to Java converter from Tangible. I have heard good things but I have never used it myself.
Also, it does not help your situation much but I should point out Mono for Android.
Mono for Android runs the CLR and the Dalvik VM in parallel. In other words, the C# code you wrote for Android can be calling into Java libraries (like the Android UI for example) and executing as a single app. You had asked about the ability to run .NET and Java code in the same process. Clearly, it can be done.
One thing I've considered is to re-write most of the core TCP/IP functionality once into something more cross-platform (C / C++) and then change my .NET library to be a thin layer on top of this (P/Invoke?), and then write a similarly thin Java layer on top of it too (JNI?).
That's a possibility. On the Java side, you should consider using JNA rather than JNI. (If you use JNI, the C / C++ code needs to be written to use JNI-specific signatures.)
Another possibility is to replace the proprietary binary protocol with something that "just works" with multiple programming languages. This is the kind of problem space where CORBA and similar technologies provide a good solution.
I am considering using GraphicsMagick (http://www.graphicsmagick.org/) in a Java project. Does anyone have any experience with this? Suggestions on how to get started? It seems like there isn't a native Java library so it may be a little more difficult.
Thanks!
We did our project with GraphicsMagick and Java, Q&A here obvious influence our decision. It's a long way but we eventually got it done. We tweaked both GraphicsMagick and im4java very hard to get the performance and reliability we want. Thought I should contribute back:
http://kennethxu.blogspot.com/2013/04/integrate-java-and-graphicsmagick.html
It's definitely possible. Take a look at IM4Java, a Java abstraction around the commandline interfaces of various ImageMagick like tools (including GM) that feels like a language binding. Very little documentation, but sufficiently simple. Obviously your images have to be accessible from the OS (e.g. not inside ResourceBundles).
Currently the only reasonable way to achieve this is by using the command line from Java (runtime.exec). You should use im4java to do this as suggested above. im4java will enable you to build up your "gm command" string using java method calls, it also provides a number of other useful features.
The big advantage of using this technique over actual language bindings is simplicity and reliability. Reliability is important especially if your Java app is running on a Java based server or servlet engine like tomcat. The reason being that a memory fault or other error while using language bindings could bring down the whole Java virtual machine.
I've got a medium sized (25k lines code, 25k lines tests) codebase in java, and would like to port it to run on a CLR as well as the JVM.
Only the main class, and a few testing utilities deal with the file system or OS in any way. The rest of the code uses the generic collections APIs extensively, java.util.regex, java.net (but not URL or URLConnection), java.io for charset encoding/decoding, java.text for unicode normalization, and org.w3c.dom for XML manipulation.
Is it possible to get most of the codebase compiling under both J# and Java, and then port the rest?
If so, what kind of pitfalls am I likely to run into?
thanks in advance,
mike
Check out IKVM: http://www.ikvm.net/
It allows you to run (specially compiled) Java code inside the .Net CLR.
Some of my colleages have used it successfully with a Java codebase of 1 million+ lines of code.
Pitfalls:
Anything like this scares the heck out of me. The number of really subtle bugs waiting to happen is huge.
J# only supports Java 1.1.4 AFAIK - goodbye generics etc.
Visual Studio 2008 doesn't support J# - basically it's a dead project.
I suspect that you'd actually find it simpler to rewrite it in C# (including learning C# if you don't already know it - it's a joy). You'll end up with a more idiomatically .NET-like library that way as well, if that's relevant: if you ever want another .NET developer to consume your code, they're likely to be far happier with a "pure" .NET project than one using J#.
The downside is that going forward, any changes would also need to be made in two places. There's certainly pain there, but I really think you'll have a better experience using "normal" .NET.
As Jon pointed out: J# is pretty dead.
Running your (normal) Java code on .NET using IKVM might be an alternative, 'though.
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