php^java — corporate adoption

–my own theory
For now, java looks like longer-living than php but so did perl vs python, so did apple vs PC java/C++ have more /depth/ than php, perl, python — more to learn, more to explore, but that’s because developers contributed to them and put them to many many uses. java is now used to solve bigger problems than php, but in an earlier era of java vs c++, java was only for applets. things could change fast once developers gather around php. Look at linux vs Solaris.

PHP could expand to embrace java features. Look at mysql vs oracle, c# vs java, or java vs c++.
The big power groups:
– open source developers,
– corporate backers like IBM, Oracle
– high-profile adopters,
– other software supporting each other

rule@try-catch-finally execution order–after catch block

— In the absence of finally —
[ try3 = try block in unfinished method #3 on call stack ]

When catch3a (among catch3b, 3c) is triggered by a *propagated* exception pe,

* we know (since it’s propagated) that try3 must have called a try4 which threw pe, and
* we know that upon catch3a completion, the statements following catch3a run, not those following catch4

What if there’s a finally? Finally can easily derail this rule. Let’s hope that finally doesn’t use exit-type or throw.

rule@try-catch-finally execution order — cover-up

throw
-> catch?
-> finally
-> propagate
-> catch?
-> finally
-> propagate

Upon throw, jvm tests the innermost catches. Before propagating, the innermost finally runs. See P475 [[ thinking in java ]].

Propagating = searching for a catch at the next level.

In fact, finally has the capability to cover up the uncaught and to-be-propagated exception. See P477 [[ thinking in java ]]. Similar to a county communist official coverying up a murder case scheduled for escalation. This is the only guy we know with the power to cover up a murder case.

Q: if a finally says “return”, will the method return normally, leaving the uncaught exception covered up?
A: I think so. see earlier blogs.

jdbc conn pool — swimming pool

there’s some logic/intelligence involved in pool growth/shrinking, conn reclaim … That logic is somehow provided by the servlet container, within the same JVM. I think it’s provided by the “swimming pool manager”.

“container-managed conn pooling” is a common phrase. Servlet Container maintains a pool of connection objects — each a chunk of memory.

A primitive implementation is a hashmap in the container’s memory, A hashmap of physical (ie in-memory) PooledConnection objects.


“swimming pool manager” is a boundless (can’t bypass) wall between the servlets and the pool of PooledConnection objects, and exposes to the servlets essentially 2 methods — getConnection() and closeConnection() . Not sure about the method names. Reacting to these calls, the swimming pool manager hands out or reclaims a “physical” connection from the servlet to the pool.

“swimming pool manager” is the single “spokesman” and single point of access of the pool.

“swimming pool manager” is request-driven. I think a class will “send it a message” by calling poolManager.getConnection() or poolManager.closeConnection()

In Weblogic, a swimming pool manager (the hashmap of conn objects) may need 2 helpers — dataSource and a pool driver.
* i think u need to specify the driver in your jdbc calls
* You can choose to use dataSource when obtaining a connection from the swimming pool manager.

perl constructor

constructors can be named “new” or something else like “spawn” or “new2”, but probably never identical to the classname. From now, let’s assume it’s “new”.

A constructor is technically just another class[1] method. Technically the only(??) difference I can see is the last “return bless..” statement.

[1] A perl constructor is usually a class method, seldom an instance method.

rule#55@try-catch-finally execution order–suspension

“exit-type statements (exit, return, break or continue…. ) in a catch{} are /suspended/ until finally runs its course.”

think of catch{} as a naughty kid. jvm will let catch{} run its course right before catch{} attempts to exit the try-catch-finally. At that point, finally{} takes over. As a good care-taker, finally{} usually [1] keeps the “exit-plan” of catch{}.

[1] see other posts on this execution order.

Q: How about a throw instead of an exit-type?
A: “If a try block throws an exception and the catch block propagates the exception (throws it again), the finally clause will still execute. If the finally clause executes a return statement, it overides (covers up) a thrown exception so the exception will not be thrown; instead the return will occur.”

A: look at the java precisely example 90

Q: what if finally /attempts to/ override that exit-type statement?
A: it will prevail.

A: look at the java precisely example 90

struts vs spring, component-by-component

http://www.devx.com/Java/Article/29208/0/page/2

1) Struts Actions Are Roughly Spring Controllers

Actions are abstract classes (extends Action@@) and Controllers are interfaces. In order to be configured as a Spring MVC controller, an object would need only to implement the following method:

ModelAndView handleRequest (HttpServletRequest request, HttpServletResponse response); # pushmail

the simplest intermediary transition step from Struts to Spring is to rewrite Actions so they implement the Controller interfaces and reuse the existing code. This allows incremental removal of all the Struts dependencies while the application remains operational.

Some of the supplied Controllers match the more specialized Struts Actions with which you may be familiar. For instance, if you use DispatchActions, MultiActionControllers and the more elaborate AbstractWizardFormControllers will be helpful. About a dozen different Controller implementations come with Spring MVC, so it is well worth exploring their purposes and how they can replace your Struts mechanisms.

2) ActionForwards -> ModelAndView

closest component in Spring MVC to ActionForward is the ModelAndView interface. Spring Controllers return implementations of the ModelAndView interface, which, like a Controller, can be custom implemented. Or, if appropriate, you can use the ModelAndView implementations supplied by Spring MVC.

As the name implies, ModelAndView objects have Model and View components. Model components contain the business object to be displayed via the View component. ModelAndView implementations may not have any Model components included. They may simply forward into some form of an actual View component (JSP, XSLT, Tiles, HTML, XML, etc.). As with Controller implementations, I strongly recommend researching Spring MVC-supplied implementations of the Model and View interfaces and View Resolvers.

*) afbean (actionForm beans) have no direct counterpart

*) spring taglig is much smaller than struts 4 taglibs (html, logic, bean ….)

*) loginAction.java -> loginController.java

*) struts “action path=..” -> simpleUrlMapping to map a request URL to loginController

*) struts “forward name=..” -> viewResolver to translate a logical view name to a URL

*) struts-config.xml -> yourDisplatcher-servlet.xml (WAC4DS) + auxiliary config files

*) execute() -> handleRequest()

java always pass-by-value

A ref-type argument is passed by value — a copy of the remote-control, pointing to the same object

Once you point “critique_arg” to a new object, this method loses contact with the original critique object ] the caller method.

private boolean recordFault(Critique critique_arg, String brokenSlot){
String message = “Required slot ” + brokenSlot.toUpperCase() + ” missing.”;
critique_arg = new Critique(Critique.Severity.Critical, 0, slot, Critique.Type.ORDER);

By the way, the original object will get garbage collected if the variable in the caller method also gets assigned a new object.