We Keep Coding

What is your recommended tool suite for internationalization of a complex multi-module java application? [closed]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 9 years ago.
Improve this question
I am currently doing an intership in a company and my task is to reevaluate the tool suite used to translate applications as it has become a problem internally. I've looked everywhere on the web and my conclusion is there is just no proper documented end to end workflow for this type of task, so I am asking the community to help me understand what they have seen in the field.
Our current flow looks like this:
java, properties files and resource bundles in the code
custom made tool to extract keys from code based on classes. bit clunky, as it uses class loading and therefore has many practical constraints
custom made web tool to do translations and handle code revisions
Here are some constraints and improvements we're looking towards:
we'd like for external translators to help us for additional languages our company cannot handle
we would like to add metadata to translation keys, such as validation flags, categorization data and description data, something not handled by properties files
we're going to have external translators and would wish to be able to use standards where possible to properly integrate with their tools
Here's what I've found on the web:
GNU Gettext's plural handling and context messages are nice. However, our existing code is written using keys and would not work with writing plain english messages in the code.
XLIFF provides means to have all the extra metadata we would like to add. However, all existing tools are either incomplete, buggy, or costly. Many of the tools add their own metadata which complicates working with XLIFF.
Pootle pretty much does what our custom made web tool does except fails to work on multiple Git branches.
Weblate, which is similar to Pootle, has the ability to work on multiple Git branches. However, updating a project with many languages and many translations takes time. It fails to meet our needs of continuous development.
So what is your recommended tool suite for internationalization of a complex multi-module java application?

Gettext (.po) is possible by a two stage key: key -> English, English as key. Disambiguation can be done with the original key. The original key can be preserved.
Gettext seems to be more extensively used than XLIFF - but I may be wrong meanwhile.
Web interfaces are fine - as a secondary tool. Translation agencies will complain when offered such a thing.
I cannot stress sufficiently that the delivery of the text is very important, to prevent that every translator has to do extra work. Almost the same text that might be united is such an example. A Translation Memory might give a fuzzy translation, but it is better to do processing by someone dedicated, before delivering things to translate. Also things like "Select from the menu 'Process thumbleweed'" and "Process thumbleweed" could well need a translation responsible person, to have coherent translations. XLIFF might offer more technicalities, but in general I think it is best to let an experienced developer ensure, develop this process. A common glossary of specific terms.
Also being able to have the application switch between showing a specific language and the key "[key]".

How about Tapiji? Not sure if it will meet all your requirements, but it is a time saver. If you are using Eclipse, or can use it, it might be worth a look. From the site:
The implemented editor is based on the Babel Messages Editor Resource-Bundle editor, which considers the whole Resource-Bundle as the object under modification instead of a single property file. Furthermore, a Resource-Bundle view adds rich functionality for browsing resources and directly comparing different languages. In parallel, RCP and RAP based stand-alone applications enable the translation of resources without the need of programming skills.

Weblate indeed is not the fastest tool for import (but there are many improvements in the upcoming 1.6 release), but there are several hints in the documentation how to improve this. Have you tried those?

Java-based CMS with RESTful service / API to access content [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
For those who might vote to close this question due to "not constructive - As it currently stands, this question is not a good fit for our Q&A format." - Would be great if you would suggest where should I post this question (https://softwareengineering.stackexchange.com/ ? or any CMS-focused forum?)
Similar questions have been asked before:
https://stackoverflow.com/questions/918722/java-or-php-for-homegrown-cms
https://stackoverflow.com/questions/4005811/is-there-a-good-cms-for-java
https://stackoverflow.com/questions/8298790/java-web-cms-recommendations
https://stackoverflow.com/questions/4837502/recommendations-for-a-lightweight-java-web-cms
https://stackoverflow.com/questions/1939238/can-you-recommend-an-easy-to-use-easy-to-develop-cms
All of them are a few years old, so I am wondering if there are new recommendations / discussions around this.
Some background: We are a Java shop, we create / maintain websites for our clients, our tech stack are Java, Spring, SQL, JSP, HTML5, JQuery, Tomcat, JBoss, Maven, etc ... the usual stuff. So far in terms of "content" we either put it in some properties file read in by the JSP for copies (eg. description of product X) or back-end service that provide dynamic content (eg. what's the current value of product X).
Now we are rethinking our approach to managing content because we are managing more and more properties for the client with the same content (eg. a website, mobile website, mobile app, etc), so we definitely want to avoid having multiple copies of the same content spread around.
A few things I am particularly looking for:
Java-based (because we are Java shop: 1) more expertise in handling Java-based stuff and 2) avoid introducing another tech to the stack)
Extensibility / customization. Need to be able to customize the CMS (which is why we want to stick within our Java expertise) so that it can be extended to connect with other web services to consume content, etc.
Focus on content - we need clear separation between content vs UI-render, going back to what we are looking for where we will need to deliver the content into separate properties.
RESTful service / API to access the content - same as above. We need the content to be accessible directly as a JSON / JSON-P /. XML feed.
Need to have a decent UI to work with and the more intuitive the better for business user because some of our client that might be moved to the platform will likely want to be manage their own content
Multilingual support
Open source / low cost
So far, several options that I have are:
Adobe CQ - Looks to be the most ideal solution, but unfortunately it's cost prohibitive
Hippo CMS - Looks to fit what we are looking for, I am unsure of how well it's documented, tutorial / how-tos seems to be quite sparse, their market share seems to be bigger in Europe than in North America.
Liferay - More focused as "portal" as opposed to CMS providing content
Alfresco - More focused on "documents"
dotCMS - Like Hippo CMS, seems like this one might fit our needs.
Magnolia CMS - Looks around the same alley as dotCMS and Hippo as well. From the comments I've seen seems like they are more focused on a single website and not clean separation between content vs UI.
I personally don't have much direct experience working with CMS before.
Your thoughts / comments on each of the options above, or if you have other solutions in mind not mentioned here, would be greatly appreciated! One of my challenge is that we need to make a really sound decision because whichever path we decide to go down with, we would likely be stuck with it, decision is not something that can easily be discarded and start over.

Personally I have some experience with Hippo and a lot with dotCMS. I do know a little about Alfresco, Liferay and Magnolia but I have not worked with them before. I have no experience whatsoever with Adobe CQ, because I never took the time investigating. This is because of the high costs being a no go for many of our clients. Alfresco is indeed a better solution if you're looking for an online document management system, which I think you aren't. You are right about Hippo, Magnolia and dotCMS being somewhat similar, which isn't that strange because they try to solve the same problem: being an Enterprise class Java based Web Content Management System. They focus heavily on managing the content which can be used in pages that are also manageable with the CMS.
To be honest: I have a bias towards dotCMS because I have worked with the systems a lot and know much about it. I thought I'd explain why it works for us so you can take that into consideration. I work in a Java shop that does a lot of middleware development for its clients using JBoss and the whole EE stack. We connect old (Cobol) and new systems together and put a shiny new web interface on top of that middleware that targets both admins and consumers. To be able to create these interfaces we need a CMS that does a few things well:
Java based (because we're a Java shop this enables us to have the same people work on the CMS and the middleware)
Horizontal scalable to tens of servers without too much hassle. In the classic case when scaling out to multiple servers the database and the assets folder are shared between the nodes. This could be a problem when you have many nodes, but in practice it's not such a big issue because most of the load will hit the index and not the db or the disk. In 2.5 and up dotCMS offers a "share nothing" mode where each node has its own database and assets folder, but this does requires you to use an additional (read: licensed) authoring server that pushes the content to each of the nodes. I have not played with this setup myself, but it sounds promising, especially because each node can be a simple and cheap box that only uses postgresql / mysql and tomcat and because there is no single point of failure anymore. In the classic case if the shared assets folder or the db would die all nodes would be down as well, except when you cluster the db and the disk as well which is expensicv to do. With this "share nothing" setup this is no longer the case. As I said: I have no experience with this, but it sounds like it might work.
Admin interface usable by both power users and non techie people (clients). Not everybody is "good with computers", but they too need to be able to manage the content (very often these people work in the marketing department of our clients). dotCMS offers ways to create admin interfaces that show only a few of the functionalities dotCMS offers. This prevents them for having to understand the whole system which speeds up training and acceptance.
Structured content. This is biggie. We want to be able to define many types of content all with a fixed set of fields, just like a database table. All without having to rebuild or restart the system. The people that would define content based on this structure (the name dotCMS uses for these types) cannot enter invalid data because the system protects against that. This makes building websites so much more future proof and convenient. Especially for developers.
Focus on content first. The first months that we used dotCMS we actually only used dotCMS for managing the content itself and exposing that through JSON API's. We did not use CMS features like defining templates and creating pages. This works fine and sounds like the stuff you're looking for. dotCMS has a JSON/XML Webservice that returns content based on queries. We use this a lot in almost all our projects, see here for more info: http://dotcms.com/docs/latest/ContentAPI. Using dotCMS itself for the whole frontend is also a possibility. Especially with the Spring controllers that it supports and the CSS-framework agnostic new template designer it is a nice way to build systems that require more than just some content.
Multilingual. dotCMS offers a few ways to do this. You can create content in all languages that you need, even non textual content such as images. Because of the "content first" approach many things are content in dotCMS , and can be treated as such, including creating a version for each language that you need.
Open source. dotCMS offers a community version that we use most of the time. Only for the pro features like load balancing, using oracle for the database, etc, a paid version is necessary. And even then the costs are manageable. See http://dotcms.com/products/editions/ for more details about this.
Internal caching mechanism. Because of the high load some of the sites we have build need caching. DotCMS uses the Google Guava for their caching which works pretty well.
Extendability, also a biggie. We needed to be able to extend the functionality of dotCMS for obvious reasons. DotCMS used to only offer an old school way of doing plugins that is kinda ugly and is based on an ant script that overwrites the dotCMS classes with your own. It works fine, but I always feel dirty after writing such a plugin. However since version 2 they offer an OSGi based plugin framework that is pretty sweet and much more developer friendly. It went out of beta in the 2.5 version. We're planning to port all of our plugins to the new framework.
Multi host. We need to be able to host multiple sites within the same CMS. DotCMS provides this natively. It's also a nice way to share common stuff between multiple hosts which we use a lot.
Of course there are also down sides. Here are a few:
Web CMSes like dotCMS store its content in a database and the assets as files on the disk. This makes versioning and synchronizing between different servers a pain in the butt. Starting from the 2.5 version dotCMS offers synchronizing tools that enable you to push content from one environment (for instance UAT) to another (for instance PROD), which helps. But not being able to checkout a single version of the content from something like GIT or SVN is very annoying. Especially since we as Java developers are accustomed to things like automated testing in a continues integration environment. Of course you can store the database as a SQL statement and the assets directory but that's slow and not so "nice". But then again all systems that store state in a database have this flaw.
DotCMS takes some time to learn. It's not a small CMS like Wordpress that you'll understand in one afternoon. It has many features and is very powerful, but you'll most likely need a day or so to understand the dotCMS way and then another couple of days to understand all the API's. I do encourage you to first read some docs and tinker with it before building a real production site: many ways lead to Rome, but some of them consist out of quicksand. :)
DotCMS is RAM hungry. To keep things fast it cached everything, so if you have a lot of content it will eat away at the RAM you have available. You can tweak this but it's easier to just give it enough RAM we have found.
Not all configurations of WebDAV + editing client are compatible with dotCMS. For instance on a mac I have found that you best use Cyberduck as a WebDAV client and Aptana as a text editor. Other setups do freaky things that dotCMS does not like much. You got to play a little to find out what the best setup is for you. I did find that if you file a bug on their github they get it fixed in the next release. They told me that WebDAV is hard to get right because it's not a fixed standard which I understand but it can still be a pain in the butt.
If you want to learn dotCMS read their -not so bad- documentation: http://dotcms.com/docs/latest/TableOfContents and also take a look at their demo site (http://dotcms.com/products/demo/). In the demo site you'll find examples of all the concepts that dotCMS offers. Oh and check out our own free dotCMS plugins as well. Especially the JavaScript and CSS minifier is very handy: http://geekyplugins.com/.
Hope this helps a little. Let me know if you want to know more.

Disclaimer: I work for Hippo, so I'll try to only answer with facts and not opinion :-)
Hippo is fully Java based, front end is language independent, but geared towards JSP or Freemarker, optionally you can use a REST-interface and use whatever.
Many plugins are created and collected at the Hippo forge.
Content-centric design has been a staple of Hippo development, should pose no issue.
Yes, by default all JCR calls are available. Apart from that you are able to define your own REST interface to suit your needs, example in the demo, documented here.
I dare say yes, in my experience most non-tech users find the interface easy to understand.
Multilingual is easy, part of the default multi-channel setup.
The community edition (which is complete, no bait-and-switch) is open source, there is some enterprise functionality behind a proprietary license. The license also opens up support avenues, besides the Google Group and Stack Overflow.
Now, on your comment about the documentation being incomplete, let me offer my opinion:
You are right, the documentation is an ongoing struggle. Most stuff is documented, but is hard to find. We are working on improving the overviews, introductions and tutorials, but we are obviously not done yet. If you can't find anything, usually the community is able to help and point you in the right direction.

.Net vs Java Jobs [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
When I do a job search for a .Net developer it's all mostly the same stuff .Net, ASP, SQL Server, CSS, Javascript, AJAX, and maybe C#. Whereas with Java you may have to have Java, Sturts, Spring, JSF, EJB, a RDMB, Eclipse RCP, CSS, Javascript, AJAX, Rest, any number of specific Java APIs. Is it easier to be a .Net developer since the technologies are so focused? Or does it just seem that way?

It's different, rather than easier.
The reason the Java jobs are listed against frameworks is becuase Java has tons of frameworks and design patterns ready to be used to make things easier to maintain. The design patterns and frameworks are starting to appear more in .NET now too, so expect to see jobs changing to look more like those Java jobs.
There are just as many patterns and practices in both worlds - but they are more established in the Java community (the Java employer will push them onto you, you will find yourself pushing your .NET employer).
Largely, Java vs .NET is syntax. Do either (do both!). But be aware of the patterns and frameworks as they'll really help you to write better code.

I'm a C# developer, believe me, there are more choices in Java than in .Net. The obvious advantage in .Net, though, is that in any job you land uses the same IDE (Visual Studio) and (in most cases) uses the latest .Net framework (except for maintaining legacy apps). There may be some subtle differences in different employers such as them using Enterprise Libraries, MVC versus Forms, WPF, etc.; But if you're a seasoned C# developer, you can adapt easily depending on your fundamentals.
Some developers in my field who did not learn any other programming languages tend to be lazy and simply drag-n-drop objects to accomplish tasks 80% of the time (some of them even believe that object-oriented programming is simply code with objects). If you are familiar in C++ or any C based language, you will definitely have the upper hand but that is not a requirement.
I'd suggest learn the best programming practices, never put all your eggs in one basket (even though god did that to us men), and be open to other languages other than C#. If you learn one C-based language, learning other major languages won't be as hard rather than starting with VB.Net.
Either way, both of them are well paying jobs and you won't regret if you choose either one.
my 2 cents.

Yes, with Java you have web frameworks like JSF, Struts, Struts2, Wicket, SpringMVC, Stripes, Tepestry, Facelets .. just to name a few. Every company is using different frameworks, so if you change job you will learn new frameworks. And its only web framework, what about persistance ? JDBC, Hibernate, JDO, iBatis. Who can name 5 mocking frameworks for Java? Who have used 5 different application servers? What about databases? Ive even used Informix and Teradata. I think all .NET is using Sql Server and its easier to learn one database well.

Please don't forget about the following .NET technologies: Win.Forms, Silverlight, WCF, WPF, WWF... There are still a lot of learning in .NET outside of web development. It is not easy to be a senior .NET developer, at least not much easier then Java. However, IMHO it is easier to start in .NET when you have no past development experience.

In Java world, you develop with technologies from many communities, in .NET world, you only work on technologies from Microsoft. In my opinion Java developers are more free in terms of choices of technologies, but sometimes it also brings you problems. :)

Java itself has more fields coming into it; I mean, Java developers have now more opportunities than any other technologies in the market. They are being hired at attractive compensations to develop different java-based applications, software and games etc. It will continue to be increased in future as well. Just stick with JAVA :)

Let's line up the technologies you mention (and some you don't). This will necessarily be somewhat imprecise so will be a nitpickers paradise :)
.NET Java The overall encompassing technology
ASP Struts A Web development framework
JSF
(.NET BCL?) Spring An application development framework
EJB
SQL Server an RDBMS A database
(VS) Eclipse An IDE
CSS, Javascript, AJAX, REST are all technologies common to both stacks.
The technology concepts you have to learn are the same whatever stack you choose - it's just the names are different. The .NET ones will all be 'Microsoft Blah Blah Blah', whereas the Java ones will all have funky cool names...

Something else important to consider is that you can get "branded" as a .NET or Java developer midway into your career. At that point, it becomes more difficult to switch, since (understandably) you have less experience in the one you didn't choose. Thus far, I have been alternating, but that comes with its own set of problems where you have gaps in experience with new libraries/frameworks on each side.
Any other thoughts on the pros/cons of developing Java vs. .NET? For instance, what types of companies, cultures, pay, etc?
For me, it seems like .NET tends to be in more established companies whereas Java is used by a lot of startups (given the low cost entry and open source libraries available). The pay is comparable, but .NET seems a little higher. Java development might be a little more fun given that you get to play with new frameworks more often and aren't as restricted to specific paradigms.

In talking with my .Net pals, it seems like getting started on something pretty standard is easier, because most people do things the Microsoft way. Java's large number of choices means you have to pick libraries and toolkits at many different levels. The upside for Java is that when the official or common way doesn't suit you, there are a lot more options available.
In practice, I don't think it makes much difference. Any single Java shop will generally settle on one particular thing. E.g., Struts or Spring or JSF, not all three. Hibernate or Ibatis or pure JDBC, not all three. So I think there's about the same amount of stuff to learn, in that whether you're using a Java stack or a .Net one, you're still solving roughly similar problems.

How do I best catch up with the latest developments in java? [closed]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a book, tool, software library, tutorial or other off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 8 years ago.
Improve this question
I am applying for a job as java developer. I programmed some hobby apps in java until 2001, after that I have mostly worked in c++ and other languages. Meanwhile, it feels like java has grown a lot, and there are all kinds of acronyms (EJB, spring, etc) unknown to me.
Where can I find a concise, clear explanation of the recent (5 years) development of java? What are key elements to understand?

2001? Wow, times have changed. That was what? Java 1.3?
Firstly, language features:
Generics: Java added generics in the 5.0 release in 2004, basically as syntactic sugar to stop you do all those casts from Objects out of collections;
Annotations: also in Java 5. Used extensively in persistence frameworks, Spring and elsewhere;
Typesafe enums: Java 5 added an enum type, which is basically a class (sort of);
Concurrency: Java 5 added extensive concurrency utils so multithreading has changed a lot; and
Asserts: a highly underused language feature added in Java 1.4. If enabled when you run your program, assets can check for various conditions and bomb out if they aren't true. The fact that you can turn them on or off when you run your program is great for diagnostics.
Thing is though, the above aren't even the big changes. In the early part of this decade, Java underwent radical architectural and philosophical changes.
Back in 2001 the big things were EJB, Swing and servlets/JSP. None of them really are anymore (at least not directly).
Proably the biggest thing to happen in Java (since its inception imho) is Spring and Spring really became big about 5 years ago. Spring is a lightweight container that also seeks to hide implementation differences between different providers and APIs. The biggest thing about Spring however is the principle of "inversion of control" or "dependency injection". The idea is that classes ("beans") are assembled from an external config ("application context").
A typical pattern in the earlier J2EE days was the Service Locator. It's now viewed largely as an anti-pattern. Basically you'd see code like this:
public MyClass() {
this.dataMember = ServiceLocator.locate("some service");
}
If you go around advocating this sort of approach these days you will be viewed as an anachronism, a rank amateur, a crackpot or some combination of the three.
Dependency injection, in its simplest form, will instead inject the necessary behaviour into classes without regard for the actual implementation. This kind of separation is deceptively powerful and a profound shift that Sun (still) hasn't really caugh tup with. It also greatly enhances unit testing.
Swing is still around but not so big anymore. Sun released JavaFX as a Flash competitor and applet replacement in recent months. I personally don't think it has much of a future (as Joel put it in his recent podcast, Java on the desktop is basically dead) but others will disagree.
EJB was big in 2001. Not so much anymore. It was (correctly) viewed as a nightmare of XML configuration, differences in application servers that made them largely non-portable (or non-trivially portable if you prefer) and they're such a heavyweight solution (pre-3.0) that they don't really have that many applications.
EJB 3.0 has taken a much more Spring-like approach of dependency injection (sort of) and annotations of POJOs (plain old Java objects).
Servlets and JSP were big in 2001. Struts began then or soon thereafter and was big until a few years ago. It's now been surpassed by other more modern Web frameworks (like Struts 2--no real relation to STruts 1 despite the name--Spring MVC, Seam and so on).
The big thing these days--not just in Java--is of coruse the Web and RIAs. Flash/Flex and Javascript/HTML/CSS (plus frameworks) rule the roost here these days (and yes theres GWT but it has a small following).
Weblogic and Websphere aren't as big as they were in 2001. JBoss still has a lot of momentum but my appserver of choice these days is Sun's Glassfish v2 or v3 Prelude.
IDEs have also changed. JBuilder was big in 2001. Now there are only really three: Eclipse, Netbeans and IntelliJ (probalby in that order of popularity but my preference is IntelliJ, which is also the only commercial one of the bunch).

I strongly encourage you to read blogs. That's usually the best way to get up to speed.
https://stackoverflow.com/questions/48701/what-is-the-best-blog-for-java-development
Plus look at this SO thread:
Learning Java

Subscribe and listen to The Java Posse podcast.

cletus gave an astonishing answer, but I have to strongly disagree with
Java on the desktop is basically dead
In fact, it is more than alive :] Eclipse IDE is far more than just a developer tool. Check out SWT/JFace/Eclipse RCP framework at eclipse.org - with it, you can build applications like Eclipse yourself. Text editors, graphical diagram editors, modelling tools, reports.. I can't keep up with Eclipse technologies myself... some of them have made it into Spring and are even planned in next Java version to be supported natively (modules like OSGi). Forget Swing, desktop apps these days are being developed in RCP way.
Some info can be found at http://wiki.eclipse.org/index.php/Rich_Client_Platform and eclipse zone at dzone.com.
Java now has support for JavaScript by default and aditionally a number of languages like python, ruby etc. have been "ported" to its ecosystem as Jython, JRuby. There is also a new language called groovy and its flagship project grails (which uses Spring and Hibernate).
GWT (Java to JavaScript converter + set of widgets) is gaining attention. There is even an emergent project called Eclipse RAP that aims to bring RCP stuff into the web.
Apart from JBoss and Glassfish, you may be interested in Jetty - an extremely lightweight yet powerful alternative.

Best solution for migration from Oracle Forms 6i to the web? [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I work in an Oracle shop. There's a toolset that consists of roughly 1000 Oracle Forms (using the Forms builder from 6i, early 90's software) with Oracle 10g on the back end. It's serving roughly 500 unique people a month, with 200 concurrent connections at any given time during the work day.
Obviously this is something that needs to be addressed to get rid of the Forms runtime and move to a web based solution. The tools need to be accessed from Windows, Linux, various UNIX's, VMS and Solaris.
What options out there exist that would be feasible to migrate to? Not only does it need to be feasible for migration but the development will need to be done by 8 or so engineers who support the tool set (and many of which who would prefer to stay put and not modernize this tool set).
Oracle offers a few solutions that convert Oracle Forms into a crappy Java Applet (it's a very terrible temporary solution).
My solution of choice has been migrating to Ruby on Rails (which I'm a big proponent of Rails) but this will involve a learning curve (which we'll hit with any solution) for other developers. Also, the other difficulty in this is converting some very complex forms to HTML forms.
Has anyone tackled such a solution? Are there any packages offered by anyone outside of Oracle?
Any specific Java Web frameworks?
Would GWT, jQuery UI, ExtJS or any other JavaScript UI frameworks offer the rich user experience needed?
.NET is a consideration but a last resort (mostly because of license costs, there's no room in the budget in addition to what we're paying for Oracle licenses).

That's exactly what I am currently doing using...
Oracle Application Express
The learning curve is much smaller than most web-based alternatives for Forms developers, as all the code is in PL/SQL (unless you start getting fancy with Javascript, which you can). Also, in the latest release of Application Express (3.2), there is a tool to convert Forms applications to Apex.
It comes free with Oracle versions since 9.2.

I'll +1 for Oracle Application Express -- I think that there are some significant advantages in your situation.
Free licensing
It may bean attractive option to the current staff, if they are Oracle bigots like me.
It's 100% web, and in 11g doesn't even require a web tier.

A really late answer, but relevant. The upcoming V3.2 release of Oracle Application Express adds an Oracle Forms migration tool, which you might find improves your productivity even further.

You should check out this site http://www.forms2net.com/ it's Migration Tool of Oracle Forms to .Net. It's pretty good stuff!

In The Netherlands QAFE ( http://www.qafe.com ) is becoming a populair alternative. They have been around for a couple of years now, serving companies outside Europe as well.
Their claim to fame
Automatically convert and reuse 60-70% of the code
Apply filterrules to make the output cleaner (remove all no longer applicable / needed code). A new feature to improve the quality of the output code.
Use the output and edit/run directly in QAML Builder
Provide your styling (by means of CSS)
Bulk process Forms after a ruleset is defined
Forms Analysis for a better impact analysis
Render to any web technology you want (also to yet to be developed technologies) without the hassle - because the presentation layer is separated from the 'logic'
I work for the company that developed this platform so do not take my word for it, try it yourself and let me know what you think; I think these guys made the best package outside of Oracle.

Oracle maintains a list of vendors who all specialize in doing exactly what you need to do.
This is a very common and popular topic due to the large installed base of Oracle Forms. If you do a simple Google search there are lots of accounts of making this transition.
In my personal experience, we had luckily structured our Oracle Forms applications to have nice PL/SQL APIs. It was simple to re-use all the existing PL/SQL in our transition to J2EE, which we did manually. It sounds like you have too many Forms to do that efficiently, though.

Oracle Migration Assistant is free. It pretty much does exactly what PITSS does for the Migration. PITSS offers some neat things that can be used going forward, which will justify the cost. But if it's a Forms Migration you need, Migration Assistant does the same job.
But if you do purchase PITSS, you could easily write a script to rename a set of forms to something repeatable and write a log of what the names where. Load under names like 1.fmb, 2.fmb, etc. Perform the changes. Then rename them back using another log file that references the log file. Then repeat for another set of forms. Could save you thousands per 100 forms.
And the reports migration is a waste of time. You will have to open each form anyway and reposition fields, especially on the parameter form. That's all you would have to do without the PITSS tool.

Try contacting the folks at ATX about this: http://www.atxtechnologies.co.uk/java/forms2java/. J2EE Java plus Adobe Flex means that the licensing is probably free (unless you want Flash Builder as well). If it's like Forms2Net, the conversion rate will be fairly high and you'll get good quality Java code afterwards.

Hi i have done a similar work using GWT/springs/ORMS combination, the results are fantastic ,how ever it also depends on the complexity of business process mine was a very very complex business process, what i did was segragate all the layers and treat each layer as a service , in the process i made an application which every one goes wow and at the same time is eligible for many certifications , but if you want to do it more faster and not change the front end u can use exodus
cheers
vasem
vasem_want#yahoo.co.uk

I have found that PITSS.CON, developed by PITSS ( http://www.pitssamerica.com ) is the best out there Oracle Forms Migration. Instead of doing this manually, where you can spend up a few months with a couple hundred forms or a couple years with over a thousand, PITSS.CON, enables one to migrate from any 2.3 to 10g in a matter of days. Its unbelievable what this tool can do.

Hi I work for PITSS (pitssamerica.com), and I want to elaborate on what gwoods1412 stated. You can migrate from any version of Oracle Forms 2.3, 3.0, 4.0, 4.5, 5.0, 6i, or 9i to 10g. The tool also migrates your Oracle Reports, and we have a solution to cure the issue with using the Reports parameter form. Oracel Forms and Reports 10g is a Web Based Solution, so you don't have to bite off the expense of a migration to another platform.
APEX is free to use, but it isn't free to migrate to. And the migration tool only extracts the fields (items), it does not take the Business Logic. So you are not getting your real investment out of your forms, you are getting a query and field description.
If you use a tool like PITSS.con, you will be testing you application on the web in a few days. Your developers will be working on other projects, and all will be right in the world. Oh yeah, you can interoperate with APEX, ADF, Java, .NET, etc once you are in 10g too. That means new development can be done in a new toolset. You start a gradual methodical migration to a new technology. Pretty nice to not have a huge launch party in two years when you can have one this month.
And APEX isn't really an enterprise solution. Here's a quote from David Peake who is Oracle APEX Product Manager:
"One of my key goals is to not over sell APEX conversion capabilities and ensure that attendees understand that converting Forms requires significant investment and is not going to be easy, no matter what tool you are converting to."
I stole that quote from Grant Ronald's (Oracle Fusion Middleware Product Manager ) blog which can viewed at Grant's Blog

You really need to check out the Forms Conversion utility from TurboEnterprise. I do not use Oracle Forms but a friend of mine has used their software to covert Oracle Forms and he loves it. They also have a free version on their website too i think. www.turbo-enterprise.com