We Keep Coding

IVR Development in java

I'm going to develop an on-line IVR application using Java (without PBX).
In the software requirements there are some mathematical calculations and database communication which I prefer to implement on Java side.
As you know, different technologies are ready to integrate with Java, such as JTAPI, Zanzibar OpenIVR, Moho, VoiceXML, CCXML, Jive, Prophecy, Voicent, Voxeo etc.
Now the question is: What is the best solution? Which one is easiest to reach? Which one have the best efficiency? Do you recommend Open Source frameworks? Is there any Windows API for handling IVR systems?

If you're going to do VoiceXML with Java, you should take a look at Rivr, an open-source VoiceXML dialogue engine.
Rivr let you code your callflow naturally in the Java language. Thus you can reuse all the available Java tools (e.g. debugger, unit testing framework, coverage test tool) to develop the callflow. You also benefit from all your IDE features too (refactorings, source navigation, version control, etc).
The API is very simple. You can code a complete callflow with a single method. No need to define "states" or to manipulate templates or XML files.
Integration with server-side logic is trivial since you are only coding for the server side.

There is far too little information here to provide a direct answer, but I'll try to give you some basics.
The standards for IVR application development is VoiceXML for dialog (caller interaction) and CCXML for call control. The latter is not as commonly available. There are also numerous proprietary solutions. Your choice of an open standard versus a proprietary solution should be more about vendor/solution lock in. Even with the open standards, you'll likely use custom enhancements and have some amount of lock in, but portability will be easier. You can code directly to the telephony boards (challenging and usually poorly documented if you are someone new to telephony) or work with solutions that provide end to end capability. I find very few people porting IVR applications so I would focus on supportability of your application, features and ease of use in your decision.
Platform choices run the spectrum. You have premise (onsite) and hosted solutions. You mostly have high end enterprise solutions and low end solutions. There are very few middle ground solutions. Features (telephony and integration capabilities) vary dramatically.
From a telephony perspective, take nothing for granted. In particular, transfers. There are many ways to transfer a call. How it is done will be constrained by your connection. An analog line to the CO (phone company) can have multiple mechanisms and the one in place will typically be dictated to you. Not all telephony platforms will support what you need. Hangup detection, at least on analog lines, can also catch the novice out. Hosted solutions will typically allow you to avoid most of these problems. VoIP solutions are even more complicated due to compatibility between devices (yes there are standards, lots of them, with lots of optional parts and then there are custom flavors).
For windows specifically, you can use Lync, but it is complicated...though many of the solutions you will explore will be complicated.
In short, there is no best solution. Your knowledge of the technologies, requirements and budget are going to drive the decision. I've generally worked with enterprise IVRs in on premise and hosted configurations that are typically fronting large call centers. I have come in contact with many of the open source solutions. Anything on premise is likely to be complicated because of the system and telephony configuration. Hosted solutions have typically done most of that for you.

I know that those are "de jure standards". But you should also take Asterisk(with AGI/AMI) as a consideration for your project. If you decide to try Asterisk and Java, take a look of astivetoolkit.org it may be very helpful.

Ricky from Twilio here.
For me, picking the best tool for a particular problem is one of my favorite tasks a developer. One technique to figuring this out is blocking off a day and spending an hour or two with each potential option. A few question I'll typically explore:
Which tool is the easiest to get started with?
Which tool has the best documentation?
Which tool has an engaged community that I can learn from?
I'm sure there are a ton more questions depending on your scenario you'd want to explore (Does it fit within my budget? Can I use it with the technologies I already know and love?).
If you're looking at building an IVR, we have an API that could help. We just dropped some new tutorials including a non-trivial, production ready IVR application using Java.

Cross-platform (SE/Android compatible) Constructive Area Geometry toolkit for Java?

I'm currently working on a cross-platform application (actually a game using libgdx), and I need a constructive area geometry implementation for some algorithms.
The problem is that the Android API does not contain the java.awt.geom.Area implementation. It does contain the android.graphics.Region class 'though, which seems to be able to perform the same thing, meaning in this context defining polygons and then performing basic logical operation on their areas.
The solution seems to be to develop an adapter interface, and have each distribution (Java SE/Android) set the appropriate implementation at startup.
This is simple enough, but after some searching I'm baffled that I haven't yet encountered an implementation of the aforementioned solution.
My question is: is there, after all, a library that actually does already this, or, alternatively, another, easier solution to the problem, e.g. buried somewhere in the "common" Java API?

You might be able to use the code from the (now defunct?) Apache Harmony project's implementation of the java.awt.geom package: http://svn.apache.org/viewvc/harmony/enhanced/java/trunk/classlib/modules/awt/src/main/java/common/java/awt/geom/
I have no experience with this code, so I can't say if its complete or any good. Its also not clear how much additional code you would have to bring in to make this work ...

Android vs Blackberry development (reusable code?)

I know this question has come up in some form, one way or another. However, a lot of them are outdated, so I figured I'd ask again plus also ask the real reason for this question.
Both Android and BB development can be accomplished via Java, and while Android adds a lot of classes and functionality on top of the Java SDK, Blackberry seems to rely on Java's J2ME. If I write an application that targets both platforms, especially from a media playback perspective, how much code reuse can I expect between both platforms? For the record, a PhoneGap based app is not possible (esp due to BB's implementation of Webkit).

IMHO, don't expect to reuse tons of code. These are the areas where you probably can't share code: UI, network, security, regex, java 1.4+ classes.
Also, android doesn't need a self made eventing system. All activities can talk with each other, or you can use services... BlackBerry doesn't have any of this.
I've being working with these two platforms for a while, and I only share the idea... The implementation is almost specific for each one.

I work on a large app which shares common code across Android, BlackBerry, MIDP, and J2SE (i.e. Desktop Java). I would say that about 75% of the code on a given platform is common code.
Pros:
One lot of code to develop/test. This is a huge positive!
If you ever decide to port to other platforms, you've already done most of it.
Cons:
You're limited to java 1.3 compatibility in the common code (no annotations, collections, etc).
UI differences can be a pain, particularly with the different event models. MVC is your friend here - at least you can share the model!
You'll want to write wrapper classes for all the platform-dependent stuff which needs to interact with your common code. This is extra code which you wouldn't have to write if you weren't code sharing.
Whether it's going to be worth your while depends on a few things... I'd at least think about the following:
How large is the project? (Larger = more of a case for sharing code.)
How much of your core functionality is realistically going to be shareable? You mention media playback - if that's going to be 80% of your app's code then it's probably not worth the effort to set up shared code.
How familiar are you with the different platforms? (More familiar = more idea of the potential pitfalls = more likely to know which code should be shared and how to structure it.)

Android and Blackberry code can be reused. I have done it before and works beautifully. A few small differences do exist. I cant remember them all, but a few
Https / Http api calls are different. So you need to code them a bit differently for both.
Blackberry compiler does not like unused imports
Other than these, I think you will be ok. But yes, do give it a shot saves a lot of time.

Drop-in replacement for MICO Corba?

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.

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.