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.

I'm trying to pick a framework for a product I'm about to build, and so far I'm leaning toward Nagare... Any thoughts?

http://www.nagare.org/
As far as the type of product and framework usage, think something like Facebook (it's not exactly a social network, but close enough for evaluation in this context).
Basically, I'm just looking for something robust, scalable, easy to work with (small learning curve is a plus), compatible with older browsers, and well integrated with other technologies (e.g. Postgres, unless there's a compelling case to be made for Cassandra?).
Other frameworks/tools I've looked a bit at or been recommended:
Google Web Toolkit + Server-side Java
Django
Ruby on Rails
ASP.NET + Mono? (I know...)
PHP/Perl/BBQ
I don't have a whole lot of experience with Web frameworks, so no matter what we end up choosing (whether I've mentioned it or not) I'll be learning something new. Any thoughts or recommendations? Anyone have any experience with Nagare (or Pyjamas)?

I would suggest Django + Pinax. Both are robust and have less learning curve (if you have familiarity with Python).
This should have you a social network up & running within a day or two.
For the front-end use the usual suspects. javascript, css, html. I believe there are some terrific libraries for javascript.

As the lead developer of Nagare, I really encourage you to try it in real on your product, which is the best way to see how Nagare is truely different than the others frameworks like Django, Pylons or Flask. Nagare is components oriented (it shares the same components model than Seaside) and its set of advance features like direct callbacks registration, stateful components, Ajax without to write any Javascript code or the use of continuations makes a Web application looks like a desktop one. In fact we have often found that developers like you, without prior Web experiences, can be quicker to get Nagare because they have nothing to "unlearn".
Talking about reliability, scabability and compatibility, you can check some of our important projects in production today.
For more info, don't hesitate to ask and share your experiences with us.

How do I decide between a using a Swing GUI or a light-weight web client for the user front end of my Java application?

I always seem to have this internal struggle when it comes to user interface. I build up an application "engine" and tend to defer user interface to after I get my algorithms working. Then I go back and forth trying to decide how to let a user interact with my program. Personally, I'm a fan of the command line, but I can't expect that of my users generally.
I really like what's possible in the browser in the age of web 2.0 and ajax. On the other hand it's not so hard to make a Swing front-end either, and you can generally count on a more consistent presentation to the user (though using a good javascript framework like YUI or jQuery goes a long way toward normalizing browsers).
Clearly both approaches have their merits and drawbacks. So, what criteria / parameters / situations should lead me to use a lightweight (e.g. web-based) GUI? What criteria / parameters / situations should lead me to use a heavier (e.g. Swing-based) GUI?
It is not my intent to start a flame war, merely interested in the community's constructive/objective opinions.
Edit #1
In light of the first few responses, I would like to clarify that I would like to deploy my application regardless, not host it on some internet server necessarily. So I would have to deploy with a light-weight web-server infrastructure a la Jetty/Tomcat or similar.

It depends on the application and this is essentially a usability driven question (though there are considerations like data storage and platform requirements). Think of the pros and cons.
Pros of a lightweight Web UI:
Ease of distribution
Platform independent
Ease of maintenance
Cons of a lightweight Web UI:
Less environmental control
Markup standards vary between browsers
Requires a web server and everything that goes with it
Pros of an executable UI
More environmental control (i.e.: full screen applications, etc)
Not necessarily subject to latency and outages
Cons of an executable UI
Pushing updates may be more difficult
Requires installation
Potential platform requirements (frameworks, packages, etc)
Potentially requires knowledge of advanced networking topics (web services, etc)

One small factor you may want to consider is that the user will have go through some type of installation (albeit minimal) if you distribute a swing application.
Also a web application will allow you to accurately track the usage of your application (via google analytics or something similar). Not sure if that's a concern but it may be useful to you in the future.

If it is a client-server application I would normally go for a web frontend for the application.
You will save yourself of countless problems with things like installed JRE versions, distributing upgrades, application permissions, disappeared shortcuts...

You need to break the requirements of the application down to decide this...
Do the users have Java of sufficient version installed? It will need to be, to run a Swing GUI.
Do you have a web server?
Do you need the flexibility of a Swing GUI or the accessibility of the web interface?
Is Java Webstart and option, if so, you can distribute a Swing GUI via the web.
Does your application perform extensive calculations or processing? If so, a client app may be the answer.
There are a million questions such as these. I would suggest a brain storming session and keeping track of all the pros and cons of each, adding a point score, than throwing it all away and going with your gut feeling :)

If you anticipate there being frequent updates to the app then web based may be better since the user would not have to update the client or install a new client containing the updates.
If you think that the user may need the ability to use the app while not conencted to the internet then swing would be better.
Just two things off the top of my head.

Think about the users and use cases of your project.
Do users expect to have access to it when they're disconnected from the Internet (for example, on an airplane or in a coffee shop with no Internet access)? Use Swing.
Do you want users to be able to access the same tool from different computers (for example, both at work and at home)? Use a web UI.
Also consider whether the user needs to save and load data, and whether the tool produces data files that some might consider sensitive (if so, storage on the web might be an issue).

Do make a quick guess I often try to ask myself/customers if the application has a high "write" demand.
For a mostly read-only application a thin-client solution is perfectly well suited.
But if a lot write actions are needed then a swing desktop application has more flexibility.
Personally I always prever a swing desktop application. It can easily deployed using Java Webstart.

Not knowing anything about your application I can not give the best recommendation possible. However I can state from personal/professional experience that installing an application on clients machines is a LOT more of a pain in the ass than it seems.
With AJAX/web you really only have to worry about supporting like three browsers. Installation messes/updates are only felt once when you deploy the product to the web server.
With like a stand-along Swing app, you get to deal with the really really big mess that is installing the application onto unknown systems. This mess was so bad that things like AJAX were really pushed along to make web apps behave/feel like a real native app.

Multiplayer browser game [Java]

I've been developing a small card game which is called "Tarneeb". The game itself looks like Bridge card game but with different rules. Anyway, i finished the entire game as a standalone desktop application using Java 6. This is a picture of the game. Anyway, i now need to transform that into a web app with multiplayer capabilities, so the users can for an example make a new room and join existing rooms where the game is played.
Unfortunately, I have no idea on networking in Java but i searched quite a lot and i found some other Java products that may help me (JavaFX, JSP, GlassFish) but i still couldn't figure out what i exactly needed to accomplish my task. All i need right now is the direction to head to and i will do my research and hopefully learn the new skills needed.

Other answers have already pointed you to some resources.
But the biggest problem you will likely have is that it is usually impossible (or extremely time consuming up to a complete rewrite) to "add" multiplayer capabilities afterwards if you didn't plan the architecture accordingly.

As you might have a lot of interaction and a lot of updates which I should - correct me if I'm wrong - be at the client as fast as possible, I'd suggest having a look at Cometd which keeps the http connection open to each client and pushes the updates from the server to the client. If you're using jetty as webserver (and thus its "continuations") it's even highly scalable.

The thing is, there isn't one standard way of doing this which you need to read up on.
How do you want to implement this web application? As an applet? Using standard web pages? As a web start application which people have to download?
The last option would allow you to re-use most of your existing code. If you go with that option it may be worth you looking into RMI as that will probably fit in with your existing architecture.
But otherwise, as S.Lott pointed out, you need to go and learn how to make web applications before doing anything else. Those tutorials would be a good start, also you should definitely learn (X)HTML, JavaScript, and a Java web technology such as JSPs, JSF, or Struts. Exactly what you need will depend on your requirements, without more details it's diffiult to recommend one.

First, learn what a "web site" and "web application" are.
Do the tutorials: http://java.sun.com/developer/onlineTraining/index.jsp
Watch the Glassfish Tutorials: http://java.sun.com/javaee/overview/screencasts.jsp
Once you've done all the tutorials, you will have built a web application.
After you've built the tutorial web application, you can build your web application.

Web apps are very badly suited for the kind of realtime interaction you have in a card game. Yes, it can be done, but it will involve dirty hacks and you'll always have problems with high latency and broken connections. And of course you'll have to completely rewrite most of your app.
If there a possibility of running the game as a Java applet? That would make your job much easier (enable much more reuse) and the end result more usable.

There is no way to port a client based app into a web app quickly. Depending on how you want to go about it, it sounds like you either need to pursue a JSP/Javascript solution or a JavaFX solution. JavaFX actually allows for smoother (smoother than JSP/Javascript, but still going to take more than an afternoon =D ) porting of client based apps, but it has a steeper learning curve than JSP/Javascript technology in general. An interesting note here is that JavaFX isn't just a web app language. If you had coded your initial client based app in JavaFX, you would have about 50% of the work done.
JavaFX

Use Java NIO, it is quite simple and if you will grasp the basics, there would be no real need in all these countless libraries... or anyway you would know their internals. One of the important things however, mentioned here already, is that the game structure has to be adapted for networking from the start. It may be a complete rewrite in the worst case. Basically, you will have to create clients database, socket connections, and from the server side, every connection (represented by a SelectorKey object), should be encapsulated into an object, representing a "joined client". Then read/write operations would be performed to the key's socket. But there is more. The server will have to be the center of your application link, so that you will have to develop an entire network messages protocol for your game (over TCP, there is no need in UDP in this kind of game). Also - read more about the protocols (TCP/UDP/sockets, ethernet), the more you read - the better.
Also! Pay attention to the HTML5 websockets stuff. It is a great thing!!!

Adventures of a Web Programmer in Applicationland (or, Practical Java Help Needed)

Alright, so I am a compsci college student who, being in college, has not branched out towards a certain specialization yet. I have been programming since I was a young teenager, certainly know my stuff - well versed in about eight different languages as well as compsci theory, etc. In addition, I have about four years of web programming (PHP mainly) behind me, having started freelance work in that area since web 2.0 became hot.
My summer job now as an intern of sorts is to write an application for an industrial, not software-related startup. This application will be used to manage production lines and logistics flow. I have chosen Java for my language because I don't want to shoot myself in the foot.
I am well-versed in the syntax of Java, in its data structures, language theory, and such, but I have absolutely no idea where to start. I can picture the program perfectly in my mind, I understand the problem clearly and got the solution's theory nailed. Namely, I have no idea what libraries to use, and am scared that they won't be well documented.
Here are some general outlines of what I'm going to make:
Two applications, one server and one
client (of which there will be many
copies).
The server and clients obviously will
communicate via (I don't know).
Both the server and the client
software will have GUIs.
The server software will have to
query a MySQL database.
The client software must be 'live' in
the sense that the GUI updates when a
change is made to the database. This
is one of the reasons why it can't be
a web application.
I'm not even sure if a framework is right for me or not. I've used MVC tons of times in my web freelance work, but I dont know how that will translate for desktop applications.
In short, I'm looking for the right libraries for the job, as well as advice on whether or not I should use a framework (and if so, which). Thanks.

This is a summer intern job? To be honest, this sounds more like a major project if you ask me. You say the start-up is not software related? Who came up with this idea? Do they have any idea of the (huge) scope that something like this might actually entail?
The business of software development is something quite different to language syntax and libraries. It's about requirements gathering, defining a spec, writing code, ensuring quality of that code, having it tested and so on. These are not things an intern should reasonably be expected to pick up. For something like this you should be under more experienced supervision, someone you can learn from, someone who has done this before.
That being said, unless there's a really good reason, I would probably do such a thing as a Website rather than a desktop app. Desktop apps are a lot more complicated in many ways. You need to code both a client and a server. Communication is a bit trickier. You have to worry about the issue of maintaining state in multiple applications, how to handle updates being pushed around and so on.
In short, it's a big job. Even a Web site is a big job but a lot of these issues go away. You could do this with Java. I've certainly coded my fair share of Java Websites but PHP might be a far simpler bet.
Also, desktop development on Java is, well, torture. Swing is (imho) tried and true but also incredibly painful to develop in. Other desktop libraries (eg Netbeans RCP, Eclipse SWT) are more modern but have other idiosyncrasies.
Desktop remoting libraries include things like Spring remoting, even Web services and other things like Burlap. For the server side, I'd be using either Tomcat or an application server (Glassfish is my preferred choice), servlets and Spring. Persistence can be done via Hibernate or Ibatis (or lots of other options).
But honestly, the desktop option is so much more complex than a Web-based one. You'd probably get a lot more done faster using PHP + jQuery + MySQL.
If you are doing this keep it as absolutely simple as possible. Try to define the absolute minimum you need to initially deliver and do that. Once someone has that they'll then have a better idea of what works for them and what doesn't. Basically it's easier to refine something that already exists vs define something that doesn't.

I recommend that you only build a web application. A web application can be 'live' in the sense you are describing it by using AJAX. It would be much easier to build just one thing. If you also want to have a rich client, then you need to build the UI in a technology you are not familiar with (like Swing or SWT) and design/implement the communication mechanism.
Have a look at Hibernate (ORM tool) and Spring (IoC framework). They have a somehow steep learning curve, but they will make your life easier at the long run. For the UI part perhaps JSF is easier for a beginner.
As a last note, I think you have an over-ambitious plan. What you are describing is not an easy project and requires expertise with a lot of technologies. Do not try to do everything in one shot.

Java Desktop 6 (JRE)
JDBC (built-in in any JRE)
MySQL JDBC drivers (freely downloadable)
for communication you have several choices: RMI (built-in) however this days I recommend
learning something like Java Web Services (JAX-RS)

Libraries?
JDBC for the database. You may want to look at ORM mechanisms like Hibernate
I would recommend the Apache Commons libraries for all your utility work (handling files, IO etc.). There's a lot of stuff there to save you reinventing the wheel.
A standard logging framework like Log4j will allow you to log in lots of different ways, filter your logs and plug into monitoring solutions easily.
You don't say whether browser-based solutions are acceptable for the client/server GUI, and that decision will drive a lot of the further architecture.
If you're looking at browser-based solutions, then I would advise a grounding in servlets regardless of any framework you ultimately choose (no doubt a lot will be recommended here).
By this stage it's getting to be a major project. Perhaps you need to concentrate on getting the fundamentals (client/server functionality) working, and worry about the GUI later. Otherwise it's a huge amount of work (and GUI work can draw an enormous amount of time).

Just one nitpicking:
Both the server and the client software will have GUIs.
I advice you to have a headless (in awt parlance) server, with an administration GUI, not a GUI-server.

Well this can go as wild as you can think of or you can go and do KISS.
If you would like something that is really simple (as in not using any frameworks):
* In the server side you can use RMI. This server side will use plain JDBC to connect to your MySQL database. But some said that this is kind of old, so if you want to get funky you can try JAX-RS which can return a JSON objects/XML to your client.
* Your client can be made using Swing (assuming you are developing desktop) or Servlet + JSP (assuming you are developing webapp) and connect to your server by calling the RMI objects/JSON objects/XML that is exposed by the server.
If you would like to get nasty which will help you in terms of code maintainability you might want to plug-in Spring + Hibernate into this application.
Good luck!