Showing posts with label java. Show all posts
Showing posts with label java. Show all posts

Sunday, February 16, 2014

Java Method Concurrency

I suppose I never quite understood how concurrency works with method calls, where one method is shared among threads. With objects I think I have a clearer picture.

Basically, however, I separate methods in terms of concurrency into:
  1. Stateless method
    Any method that does not try to modify any shared state.  This ensures parallel calls to this method from multiple threads remain parallel.  This is regardless of the method ownership, whether it is bound to a class-instance (object) or to a class (static), or even to an enum.  I enjoy immutable programming (to extreme points) so this is naturally my first choice.
  2. Stateful method
    This type of method normally deals with object locking, objects that serve as states and are shared among callers.  Without locking, state is indeterminate, and thus renders the purpose of state sharing useless.  Execution of this method, therefore, is bound to be sequential to the order the state lock is acquired and released.  With locking, this falls into a synchronized method (below).  Otherwise it is just not the best practice.
  3. Synchronized method
    An overly generalized category for this type of method execution, but anyway.
    A method, whether wholly synchronized or having a synchronized statement, is bound to be sequentially invoked to the order its lock is acquired and released.  It is not possible for two invocations of synchronized methods on the same object to interleave [Synchronized Methods].  A regular method made synchronized will mean it is bound to its owning object instance.  In the case of a static synchronized method, the thread acquires the lock for the class object associated with the class, simulating the same behaviour as class instance-bound methods.
I would expect differences to some degree for applications running on a container using proxies to facilitate managed beans, EJB, or Spring DI.

Tuesday, August 21, 2012

Around the Web

Sometime ago I checked out different approaches to web application development (in my free time.)  With Python I explored the Pyramid framework as well as Django.  With Scala I did Lift.  And lastly I explored JSF using Groovy as a replacement for Java.

Actually I was quite overwhelmed with Python.  It's not difficult to write anything in Python. 
However, to write good code in Python it should take considerably more effort and more thorough understanding of the language.  I stumbled across a lot of metaprogramming then.  I think it grossly difficult to feel secure because, with metaprogramming alongside dynamic typing, most of your application's survival depends on the condition of your gestalt.

Scala lifts much of that mental burden off me I should think.  I like Lift.  I could do more in Lift in the future.  :)

Groovy is, as I probably wrote in my previous post, somewhat in the middle when it comes to typing--a degree of static as well as dynamic typing.  It saves a lot of time and code lines.  In a way it intuitively guides me to write better code.  There can be a lot of metaprogramming too in Groovy, but it's not a show stopper.  You don't necessarily have to understand it to write good code.  Though it's pretty easy (I think compared to that in Python).  It would be much better if Java EE and relevant stuff were tailored to fit Groovy more.  And better IDE support.  And a way to filter exception stack traces (Seam Catch maybe?).