Develop Reference

HTML/HTML5 website creating using Jodd(java) framework

I've been reading about Jodd(java) framework and it looks interesting to me. But I see that it seems to be jsp/servlet based. Can you develop strictly html/html5 dynamic website without jsps with it?

Absolutely. As you can see, in Jodd Madvoc you have this concept of Result : each (java) action returns it. Results are the one that defines how you are going to render the page. By default, there are JSP results, as this is a standard, right; but nothing stops you to simply have a i.e. Freemarker result or to use any other template engine. People are doing this often. Moreover, Results are made to be configured. See: http://jodd.org/doc/madvoc/results.html
Result does not need only to return HTML content. There is a JsonResult for example, or RawResult that can return a JSON or any string.
If you want REST-ish interface that only results with JSONs, you can do that as well, checkout: http://jodd.org/doc/madvoc/rest.html
Madvoc should be configurable enough to fit your needs. Just don't think of it as a 'solution-in-a-box', but a real framework, that you need to dig just a little, but you will find what you need :)

You can develop strictly html/html5 dynamic Websites without JSPs for sure, there are many ways to do it, but in my personal opinion, I believe that you can use AngularJS for your front-end development (HTML5/CSS3). This framework will allow you to implement all your client side without minor issues. It is based on HTML5, so no JSP files will be required. If you are used to MVC or MVVM, well this framework will allow you to work with any of these two approaches.
Dynamic Web Application? Need to show data from a database or store records? No problem, Angular supports AJAX calls to REST Web Services which you can implement with the programming language you feel more comfortable. If it is Java, then you can go for some REST Web Services using Jersey.
Hope this information is useful for you.
Happy coding.

How can I convert an Applets application into an Web application using JSP and Javascript?

I have a project that is built on Applets and that also comprises of Corba calls to backend (which is in C language). Now I need to remove Applets and convert it into JSP and Javascript combination. But the code seems to be complex as it also consist of backend calls. I am facing problem in figuring out what is to be converted in JSP and what in Javascript.
If I convert all the applet logic in Javascript, how will I pass the javascript data to the Java objects to pass it as input for corba calls.
I can't implement all the logic in JSP as the existing logic depends on the dynamic change of data by user.
I tried various links but couldn't find the proper solution to my problem.
I read somewhere that Google Web Toolkit (GWT) might help me converting Java Logic to Javascript, but couldn't figure out what exactly needs to be done for that.
Can anyone guide me how should I start and what exactly should I do to complete my project?

First the bad news. There is no generic and magic solution that can convert your legacy (as you are describing it) into modern n-tiers web application.
I can suggest you the following steps.
decide what kind of client and server side technologies you are going to use and learn them to become familiar enough to start coding.
learn your legacy code and re-design it. Decide which parts of the code must be re-written, what you can use as-is and what you have to change and/or re-package.
To choose client side technology try to search for "client side javascript frameworks" or something like this. Popularity of GWT that you mentioned is going down now. The most modern framework these days are AngularJS.
Concerning server side technologies I personally prefer Spring but you can take a look on Guice and EJB too. You can also implement whole server side as as collection of servlets. It is up to you.
Start learning this amazing world and come back with more concrete questions. Good luck.

Using Java as a backend and PHP as a front end

There are already a few posts on SO discussion whether this architecture is a good idea or bad idea. For many reasons within our company including the existing programming talent, we've decided to use Java for the backend and PHP for the front end. Our objective is something like...
Java - Models/Controllers
PHP - Views
We're working on building a prototype of the interaction between Glassfish and Apache. One thing we're still working on is when a user visits http://domain.com/login.html and they login, that login will be sent to the Glassfish controller which exists somewhere like /login.java. We can do that no problem, the trouble is getting the view to be rendered at that URL.
Has anyone does this with PHP or any other technologies?

Have you considered setting up a soap/rest server in java and having PHP talk to that? I imagine that would be much simpler than what you're trying to achieve.

I am sorry to bring this up but it seems like it would make things a lot simpler to stick with just one of these languages. If you are using PHP to add more logic into your view, it might be worth taking a look at Velocity. It allows you to access and create variables, iterate through lists, use conditionals, define macros, make method calls, etc. This seems like it might make things much cleaner. However, it is usually a good idea to try to keep as much logic out of your templates as possible.
If you would like to use PHP because that is what is required I would suggest taking a look at using web services to communicate. Take a look at Googles GSON library. It is really nice tool (on the java side) for mapping JSON Objects to your model (and vice versa).
On your front-end, it might also be worth taking a look at Backbone. It is a tool that makes it simple to mock up your model Objects and bind events to them, or add tie them directly to fields, etc.

I've had first hand experience at two companies that use the Java Service layer and PHP Client layer technology stack, although it was not used exclusively. To clearly separate the layers a well-defined JSON REST API was built so each layer had a contract it could code to.
The Java layer used SpringMVC in-between the persistence layer to generate JSON views with well-defined routes (i.e. URL structure) in order for the PHP layer to GET/PUT/POST/DELETE resources.
Regarding the login issue specifically, there were actually two Java services, one specifically for login/logout and the other for the regular backend.
When visiting /login which I assume would be a .php file. A submit of the login <form> to the "Login" service resulted in a session cookie being added but also an encrypted "user ID" cookie. The encrypted cookie could then be used to protect access to the Java Service layer for the product. Each REST request from PHP to Java would have access to the cookie, and the Java layer could then decrypt the "user ID" and respond to the PHP REST call if it was valid. The Java layer would then have access to the real user ID in order to return user-specific data from the persistent store.

GWT: working with JSON services

It's not a very concrete question. I created a simple project with a help of this tutorial, it's really fine. All the GWT code samples related to JSON I saw so far seem to work with a JSON (or immitate this work with some mock-up JSON), that is retrieved and processed in GWT. I'm a newbie in GWT, and I wonder, what are the cases of interacting with services that return JSON (services are mentioned in the same tutorial) and what are the pros and cons of such interaction.
I thought about two options (well, service is an overloaded term):
everything that is mentioned in these JSON GWT tutorials is about the third-party services, like GData and Yahoo! Web Services mentioned here, which would make sense, cause it's about retrieving some data and processing in the app,
and the second option is about services, that are created within the confines of a project (and, if there are some cases, and definitely there are some, my question is about them).
It's probably can't be fully explained in the answer, so a link (or a few) would be appreciated. Thanks in advance.

Your question is really quite generic. But here are some pointers:
JSON is just a data interchange format similar to XML or Protocol Buffers or some other proprietary format.
They are necessary in modern web applications because the UI is entirely controlled by the javascript code running in the browser.
However the data that a web application presents to the user usually resides on the backend. In order to get the data from the backend to the frontend you have to use some data interchange format like JSON or XML.
The advantage of JSON is, that is fairly efficient compared to XML and well accepted.
As you mentioned there are third party services that rely on JSON. These are very useful when you want to include the services in your applications.
The biggest advantage of applying this service oriented approach to your own project is that you decouple your components (frontend and backend). By doing this you achieve following things:
Make your services available to other (web-)applications and users because your service exposes a specific API/data exchange format that they can use.
Easily replace or add another frontend (for example create a desktop application in addition to your GWT application) that can work with your data (display or modify).

Create Exchange account from Java

I know there are multiple Java API to interface with MS Exchange, but it seems to me that no one that offers methods for mailbox creation. Does anyone know a way to do this?

I believe that you can do it using HtmlUnit API.
HtmlUnit is a "GUI-Less browser for Java programs". It models HTML
documents and provides an API that allows you to invoke pages, fill
out forms, click links, etc... just like you do in your "normal"
browser.
It has fairly good JavaScript support (which is constantly improving)
and is able to work even with quite complex AJAX libraries, simulating
either Firefox or Internet Explorer depending on the configuration you
want to use.
It is typically used for testing purposes or to retrieve information
from web sites.