RSS 2.0
Sign In
# Tuesday, September 22, 2009

Suppose you have a library, which is out in the production and is used by many clients. At the same time the library evolves: API is extended, bugs are being fixed, code becomes faster and cleaner, bla bla bla...

At some point you're fixing some important bug that's been hiding for a long time in the bowels of your library. You're happy that you've spotted it before clients got into troubles. You're notifying all the clients that there is an important fix, and that they need to update the library.

What do you think you hear in return?

Well, we're not perfect, there are bugs in our software. We and our clients realize this. Nothing will eliminate bugs to creep into a code from time to time.

That's a train of thought of a particular client:

We agree that there is a bug and that it has to be fixed. We, however, want to touch the library in a minimal way, as who knows what other new bugs had they introduced, so let's ask them to fix this particular bug in our version of the library.

That's fair from the client's perspective. They don't want better code, they just want that particular bug fixed!

For us, however, this means branching some old version of the library, fixing bug and supporting this branch for the particular client. It's fair to expect similar position from each client, thus should we create and support library branches per client, and branch a main branch for a new client only?

For us (Arthur and Vladimir) it looks as enormous waste of resources. We (our company) should either hire more and more scaled people or experience gradual slowdown of support and development.

Our answer could be obvious if not position of top managers who value client relations so much that they easily promise whatever client wishes. No arguments that latest version is better tested, more conforming to specifications, more reliable, faster and so on are accepted. The main argument against our position is that the client's applications run in the production, and no new potential bugs are acceptable.

Here is our dilemma: we neither can convince the client (more precisely our managers) that we're right, nor are convinced with their arguments...

Tuesday, September 22, 2009 8:16:11 AM UTC  #    Comments [3] -
Thinking aloud
# Wednesday, September 9, 2009

Recently we have seen a blog entry: "JSF: IDs and clientIds in Facelets", which provided wrong implementation of the feature.

I'm not sure how useful it is, but here is our approach to the same problem.

In the core is ScopeComponent. Example uses a couple of utility functions defined in Functions. Example itself is found at window.xhtml:

<html xmlns=""
      <ui:repeat value="#{ex:sequence(5)}">
        <f:subview id="scope" binding="#{ex:scope().value}">
          #{}, #{scope.clientId}
        <f:subview id="script" uniqueId="my-script"
          binding="#{ex:scope().value}" myValue="#{2 + 2}">
          , #{}, #{script.clientId},

Update: ex:scope() is made to return a simple bean with property "value".

Another useful example:

<f:subview id="group" binding="#{ex:scope().value}">
<h:inputText id="input" value="#{}"/>
<script type="text/javascript">
var element = document.getElementById('#{group.clientId}:input');

Wednesday, September 9, 2009 11:39:14 AM UTC  #    Comments [1] -
JSF and Facelets | Tips and tricks

In the section about AJAX, JSF 2.0 spec (final draft) talks about partial requests...

This sounds rather strange. My perception was that the AJAX is about partial responses. What a sense to send partial requests? Requests are comparatively small anyway! Besides, a partial request may complicate restoring component tree on the server and made things fragile, but this largely depends on what they mean with these words.

Wednesday, September 9, 2009 5:54:38 AM UTC  #    Comments [0] -
JSF and Facelets | Tips and tricks
# Saturday, August 29, 2009

Recently we were disputing (Arthur vs Vladimir) about the benefits of ValueExpression references in JSF/Facelets.

Such dispute in itself presents rather funny picture when you're defending one position and after a while you're taking opposite point and starting to maintain it. But let's go to the problem.

JSF/Facelets uses Unified Expression Language for the data binding, e.g.:

<h:inputText id="name" value="#{}" />


<h:selectBooleanCheckbox id="selected" value="#{customer.selected}" />

In these cases value from input and check boxes are mapped to a properties name, and selected of a bean named customer. Everything is fine except of a case when selected is not of boolean type (e.g. int). In this case you will have a hard time thinking on how to adapt bean property to the jsf component. Basically, you have to provide a bean adapter, or change type of property. Later is unfeasible in our case, thus we're choosing bean adapter. More than that we have to create a generic solution for int to boolean property type adapter. With this target in mind we may create a function receiving bean and a property name and returning other bean with a single propery of boolean type:

<h:selectBooleanCheckbox id="selected"
  value="#{ex:toBoolean(customer, 'selected').value}" />

But thinking further the question appears: whether we can pass ValueExpression by reference into a bean adapter function, and have something like this:

<h:selectBooleanCheckbox id="selected"
  value="#{ex:toBoolean(byref customer.selected).value}" />

It turns out that it's possible to do this kind of thing. Unfortunately it requires custom facelets tag, like this:

<ex:ref var="selected" value="#{customer.selected}"/>

<h:selectBooleanCheckbox id="selected"
  value="#{ex:toBoolean(selected).value}" />

Implementation of such a tag is really primitive (in fact it mimics c:set tag handler except one line), but still it's an extension on the level we don't happy to introduce.

This way we were going circles considering pros and cons, regretting that el references ain't native in jsf/facelets and weren't able to classify whether our solution is a hack or a neat extension...

P.S. We know that JSF 2.0 provides solution for h:selectBooleanCheckbox but still there are cases when similar technique is required even there.

Saturday, August 29, 2009 1:11:26 PM UTC  #    Comments [0] -
JSF and Facelets | Tips and tricks
# Friday, August 21, 2009

We always tacitly assumed that protected modifier in java permits member access from a class the member belongs to, or from an instance of class's descendant. Very like the C++ defines it, in fact.

In other words no external client of an instance can directly access a protected member of that instance or class the instance belongs to.

It would be very interesting to know how many people live with such a naivete, really!

Well, that's what java states:

The protected modifier specifies that the member can only be accessed within its own package (as with package-private) and, in addition, by a subclass of its class in another package.

If one'll  think, just a little, she'll see that this gorgeous definition is so different from C++'s and so meaningless that they would better dropped this modifier altogether.

The hole is so huge that I can easily build an example showing how to modify protected member of some other class in a perfectly valid way. Consider:

package com.mypackage;

import javax.faces.component.Hack;
import javax.faces.component.UIComponentBase;

import javax.faces.event.FacesListener;

public class MyClass
   public void addFacesListener(
     UIComponentBase component,
     FacesListener listener)
     Hack.addFacesListener(component, listener);


package javax.faces.component;

import javax.faces.event.FacesListener;

public class Hack
   public static void addFacesListener(
     UIComponentBase component,
     FacesListener listener)

An example is about to how one adds custom listener to an arbitrary jsf component. Notice that this is not assumed  by design, as a method addFacesListener() is protected. But see how easy one can hack this dummy "protected" notion.

Update: for a proper implementation of protected please read Manifest file, a part about package sealing.

Friday, August 21, 2009 12:25:59 PM UTC  #    Comments [0] -
JSF and Facelets | Tips and tricks
# Thursday, August 20, 2009

Just in case, if you don't know what JSON stands for - it's JavaScript Object Notation.

You may find a plenty of JSON implementations in java, so we shall add one more idea. Briefly, it's about to plug it into xml serialization infrastructure JAXB. Taking into account that JAXB now is an integral part of java platform itself, benefits are that you can transparently use the same beans for xml and JSON serialization.

What you need to do is only to provide JSON reader and writer under the hood of XMLStreamReader and XMLStreamWriter interfaces.

In spare time we shall implement this idea.

Thursday, August 20, 2009 6:28:37 AM UTC  #    Comments [0] -
Tips and tricks
# Wednesday, August 19, 2009

If you by chance see lines like the following in your code:

private transient final Type field;

then know, you're in the trouble!

The reason is simple, really (provided you're sane and don't put field modifiers without reason). transient assumes that your class is serializable, and you have a particular field that you don't want to serialize. final states that the field is initialized in the constructor, and does not change the value for the rest life cycle.

This way if you will serialize an instance of class with such a field, and then deserialize it back, you will have the field initialized with null, and no way to have another value there.

P.S. That's what we have found in our code recently:

private transient final Lock sync = new ReentrantLock();

Wednesday, August 19, 2009 4:44:42 AM UTC  #    Comments [0] -
Tips and tricks
# Monday, August 10, 2009

Well, we ain't a top news trackers, so only today have found that Micro Focus has acquired Borland.

Once, we were a great supporters of their C++ and Pascal software, but then something has changed. Was it an inspiration that had left them or something else?

Anyhow, their products will live for a long time, but that's a very different kind of life, similar to a lot of COBOL.

Monday, August 10, 2009 4:25:15 AM UTC  #    Comments [0] -

# Thursday, August 6, 2009

Forthcoming update of C++ standard will not include concepts!

This the major backoff is very unfortunate, in my opinion, for C++'s future. Anyhow, there is a strong reasoning behind the decision. WG experienced the lack of resources, and a threatening amount of open questions and inconsistencies related to concepts.

Besides, there is no proper and up to date C++ compiler implementing the feature, which made impossible to verify ideas. All that might delay the C++0x standard up to 2012 or even 2015.

As result WG's decided to move concepts out of scope of the nearest update.

I hope very much that concepts will follow soon after the standard.

Read more at: What Happened in Frankfurt?

Thursday, August 6, 2009 1:45:45 PM UTC  #    Comments [0] -

# Tuesday, July 28, 2009
A week ago my brothers had returned from their journey to France. They have brought a reproduction of one of remarkable and meaningful images. The title on it can be used as our motto.
Tuesday, July 28, 2009 8:23:28 AM UTC  #    Comments [0] -

# Thursday, July 23, 2009

Interestingly enough that a google search for "coolgen java bean generation" leads to our site.

That's a good starting point, as we support such conversions. We, however, suggest to follow to BluePhoenix location. That's where the bosses live. :-)

Thursday, July 23, 2009 6:22:12 PM UTC  #    Comments [0] -

# Monday, July 20, 2009

Generics in C# look inferior to templates (especially to concepts) in C++, however now and then you can build a wonderful pieces the way a C++ profi would envy.

Consider a generic converter method: T Convert<T>(object value).

In C++ I would create several template specializations for all supported conversions. Well, to make things harder, think of converter provider supporting conversion:

public interface IConverterProvider
  Converter<object, T> Get<T>();

That begins to be a puzzle in C++, but C# handles it easily!

My first C#'s implementation was too naive, and spent too many cycles in provider, resolving which converter to use. So, I went on, and have created a sofisticated implementation like this:

  private IConverterProvider provider = ...

  public T Convert<T>(object value)
    var converter = provider.Get<T>();

    return converter(value);


public class ConverterProvider: IConverterProvider
  public Converter<object, T> Get<T>()
    return Impl<T>.converter;

  private static class Impl<T>
    static Impl()
      // Heavy implementation initializing converters.
      converter = ...

    public static readonly Converter<object, T> converter;

Go, and do something close in C++!

Monday, July 20, 2009 7:18:51 AM UTC  #    Comments [0] -
Tips and tricks
# Friday, July 10, 2009

Living in Israel, moving almost exclusively in a car I would not experience what I've seen today in metro of Paris.

On the Ranelagh station an old woman has entered the train. She's in her mid seventies. Once, she was beautiful. She still is! Colors and features are faded but her dressing and posture are still elegant. But what's struck me most are her eyes. Well, they ain't beautiful anymore. I've read a sadness there.

I think she will probably live ten or even twenty years more, but she would give them up just for one year to be younger.

Friday, July 10, 2009 1:58:27 PM UTC  #    Comments [0] -

# Monday, June 29, 2009

If you have a string variable $value as xs:string, and want to know whether it starts from a digit, then what's the best way to do it in the xpath?

Our answer is: ($value ge '0') and ($value lt ':').

Looks a little funny (and disturbing).

Monday, June 29, 2009 6:00:28 AM UTC  #    Comments [0] -
Tips and tricks | xslt
# Wednesday, June 24, 2009

In our project we're generating a lot of xml files, which are subjects of manual changes, and repeated generations (often with slightly different generation options). This way a life flow of such an xml can be described as following:

  1. generate original xml (version 1)
  2. manual changes (version 2)
  3. next generation (version 3)
  4. manual changes integrated into the new generation (version 4)

If it were a regular text files we could use diff utility to prepare patch between versions 1 and 2, and apply it with patch utility to a version 3. Unfortunately xml has additional semantics compared to a plain text. What's an invariant or a simple modification in xml is often a drastic change in text. diff/patch does not work well for us. We need xml diff and patch.

The first guess is to google it! Not so simple. We have failed to find a tool or an API that can be used from ant. There are a lot of GUIs to show xml differences and to perform manual merge, or doing similar but different things to what we need (like MS's xmldiffpatch).

Please point us to such a program!

Meantime, we need to proceed. We don't believe that such a tool can be done on the knees, as it's a heuristical and mathematical at the same time task requiring a careful design and good statistics for the use cases. Our idea is to exploit diff/patch. To achieve the goals we're going to perform some normalization of xmls before diff to remove redundant invariants, and normalization after the patch to return it into a readable form. This includes:

  • ordering attributes by their names;
  • replacing unsignificant whitespaces with line breaks;
  • entering line breaks after element names and before attributes, after attribute name and before it's value, and after an attribute value.

This way we expect to recieve files reacting to modifications similarly to text files.

Wednesday, June 24, 2009 11:40:32 AM UTC  #    Comments [0] -
Tips and tricks | xslt
<September 2009>
Total Posts: 387
This Year: 3
This Month: 0
This Week: 0
Comments: 1289
Locations of visitors to this page
The opinions expressed herein are our own personal opinions and do not represent our employer's view in anyway.

© 2024, Nesterovsky bros
All Content © 2024, Nesterovsky bros
DasBlog theme 'Business' created by Christoph De Baene (delarou)