Playing with Executor - The Executor framework

Transform sequential loop into a parallel

If the iterations of the loop are independent and we don’t need to wait for all of them to complete before proceeding, we can use an Executor to transform a sequential loop into a parallel one as shown below.

Public void SequentialLoop(List elements) {

  for (Element e : elements)

      process(e);

}

public void processLoopInParallel(Executor exec, List elements) {

  for (final Element e : elements)

      exec.execute(new Runnable() {

          public void run() { process(e); }

      });

}

The second loop will return more quickly, since all the task are queued to the Executor, rather than waiting for them all to complete.

If you want to submit a set of tasks and you want to retrieve the results as they become available, you can use a CompletionService

void solve(Executor e, Collection> solvers)

     throws InterruptedException, ExecutionException {

       CompletionService ecs

           = new ExecutorCompletionService(e);

       for (Callable s : solvers)

           ecs.submit(s);

       //retrieve completed task results and use them  

       int n = solvers.size();

       for (int i = 0; i < n; ++i) {

           Result r = ecs.take().get();

           if (r != null)

               use(r);

       }

   }

The advantage of using CompletionService is that it always returns the first completed result. In this way, we ensure that we are not waiting for tasks to complete and those uncompleted tasks are running in the background

If you want to submit a set of tasks and wait for them all to complete, you can use ExecutorService.invokeAll

XSLT Processing with JDK 1.6 and Xalan 2_7_1

This small post is regarding the changes that is require, if we want to upgarde xalan-java version to 2.7.1 to work compatible with JDK1.6.

Xalan-Java is an XSLT processor for transforming XML documents into HTML, text, or other XML document types.

The issues that need to fix while upgrade XSL to work with JDK 1.6 and Xalan 2.7.1 will be discussed here and in this post we will look in to sample examples that help us to create XSL’s to work compatible with these new version.

Please note that the problems identified here work well with JDK 1.5. Therefore, these changes require only, if we want our XSL to parse successfully with JDK 1.6.

xsl:import

This element must appear as the first child node of xsl:stylesheet or xsl:transform. It should not appear in the end or middle of the stylesheet. Otherwise it throws exception

“Error! xsl:import is not allowed in this position in the stylesheet!”

xsl:template

xsl:template must either have name or match attribute. If the name attribute is omitted then there must be a match attribute.

For example, the code

     
     -- 

throw exceptions

“Fatal Error! java.lang.RuntimeException: ElemTemplateElement error: xsl:template requires either a name or a match attribute.”

The below code will execute successfully.

     
     -- 

xsl:value-of

xsl:value-of cannot be enclosed under xsl:text.

For example, the code

will throw exception

“Error! xsl:value-of is not allowed in this position in the stylesheet!”

The code can directly used to extract the value to output stream.

Use StringBuffer/StringBuilder in XSL

Use StringBuffer/StringBuilder in XSL
XSL Code such as

throw exception

java.lang.IllegalArgumentException: argument type mismatch and

java.lang.NullPointerException

The reason is that the
org.apache.xalan.extensions.MethodResolver picks a method whose argument types are not converted properly. This was noticed in the new versions of JVM due to the order at which they return all methods available for a given class and the issue is still not resolved yet.
Further information can be refer to

http://issues.apache.org/jira/browse/XALANJ-2374
http://issues.apache.org/jira/browse/XALANJ-2315

I have replaced StringBuilder with Map to correctly transform the XSL.

XSL DTMNodeIterator

Consider the following XSL.

   
      , CASE WHEN . 
                                
       IS NULL THEN                           
   
   
      ,
      .
   

                                      

  
         select="java:containsKey($processedMap, $temp_core_alias_value)"/>
      
         Value exist in Map =           
          
      

At this point, we might expect java:containsKey($processedMap,$temp_core_alias_value) to return true and the output of the above as “Value exist in Map = Test Value” But when transform using Xalan-Java 2.7.1, the Map return false and therefore no output appear.

The reason is that the evaluating expression for the temp_core_alias_value variable would return
org.apache.xml.dtm.ref.DTMNodeIterator@e020c9 and therefore, the contains method of the Map would always return false regardless of the key present.

We can transform DTMNodeIterator to normal String form by concatenate an empty string with temp_core_alias_value variable like the following

Adding this line right before put in to the Map would result in the normal expected output.