separating applications into separate deployment units is a sensible best practice.
We have used
separate business domain object into separate modules. These jars are usually include POJOs but are also EJB jars for legacy reasons.
What gets included in the domain modules?
Domain interfaces and implementations:
Data access objects
Domain Services.
For EJB 2.1 projects this would include all of the usual suspects
Entity bean interfaces, primary keys, home interfaces, implementations.
Session bean interfaces, home interfaces, implementations.
If we were being just and proper we would have created additional jars just for the interfaces for use by remote clients, local clients, deployment implmentation and finally common crap
Leading to something like domain1-remote.jar, domain1-local.jar, domain1-ejb.jar, domain1-common.jar
domain1-remote.jar would depend on domain1-common.jar
domain1-local.jar would depend on domain1-common.jar
domain1-ejb.jar would depend on domain1-remote.jar, domain1-local.jar and also domain1-common.jar transitively.
The typical POJO-based module is much less complicated. But, the same segregation of artifacts can also be employed. Most developers would agree that extractin interfaces for all POJOs is extream and not worth the effort. But, many developers would also agree that a swing client that only utilizes POJOs that are serialized and transfered from a remote process should not have the classes the POJOs associated DAOs.
All of this separation is neat and tidy for sure but it slows down the rapid realization of new functionality in a working application.... or does it.
Is there a way to keep all of the modularization and still have a change in an entity bean interface quickly reflected (after a page refresh for example)?
I am not aware of a way to include an EJB implementation and deployment configuration as part of a simple WAR. If this assumption it accurate. a web application utilizing EJB 2.1 a minimum of two modules in required.
On the other hand, Spring+Hibernate web application could easily be developed and deployed in a single war.
The question of the degree of modularization is often answered with yet another question... "Do you need to reuse the (business domain) modules across several applications". This is an import factor to determine but I do not agrree with the assertion that this a single determining factor.
Converting numbers between bases:
To convert an integer from any base to decimal use the polynomial method.
To convert an integer from decimal to any other base use the remainder method.
The calculated remainders start at the least significant.
Two's complement represents negative numbers by complementing the positive binary representation of the number and adding one.
One's complement represents negative numbers by simply by complementing the positive binary representation.
Java encodes integral types in two's complement.