Skip to main content

TOM.Java - Now with Generics Support

What kept me busy lately (apart from my insane work load)? Adding 'generics' support to the TOM.Java API.

I was blogging a few weeks ago about a pet project of mine -- the Java Mediator for SDL Tridion Templating. In that post I was very enthusiastic about JNI4NET bridge between Java and .NET and namely about ProxyGen -- the tool that actually generates both Java and C# proxy classes. For what it is, ProxyGen is a great tool, but it's really a Java 1.4 tool -- namely, it does not support generics. Luckily, it is open source, so anybody can modify it...

However, the problem for me was my own learning curve. ProxyGen is in fact a code generator written in C# using CodeDom, which builds a class model (from JARs and DLLs) using reflection, and finally generates C# and Java code from this model.

I won't go into the ProxyGen details here (if you want more details, I posted more details on jni4net Google group).

Anyway, with this (partial) support for generics in TOM.Java, I am able to use Java counterparts for the main generic collections from C# (and the other way around for that matter - from Java collections to C# collections). The following type mappings are available:

java.util.Map<K, V>System.Collections.Generic.IDictionary<K, V>

The methods using generics delegate their calls to the non-generic native counterparts (as originally designed by ProxyGen). What I did was basically deal with the conversion from generic to non-generic and back. The delegate methods are suffixed with the name of the Java collection they are a generic for.

Example: Package.GetEntries() returns a C# IList of KeyValuePairs of string and Item objects.
Original signature:

IList<KeyValuePair<string, Item>> GetEntries()

ProxyGen generates a Java native proxy method with signature:

public native system.collections.IList GetEntries()

If I were to use this method I would have to use the IEnumerator iterator like this (and that does not support Java for-each loops):

for (IEnumerator enumerator = _package.GetEntries().GetEnumerator(); enumerator.MoveNext();) {
    KeyValuePair kvp = (KeyValuePair) enumerator.getCurrent();
    system.String key = (system.String) kvp.getKey();
    Item value = (Item) kvp.getValue();
    System.out.println(String.format("\tKey: %s\tValue: %s", key, value.GetAsString()));

Next to this, my enhancement to ProxyGen now generates a delegate that accepts generics

java.util.List<mitza.jni4net.wrapper.KeyValuePair<system.String, tridion.contentmanager.templating.Item>> GetEntriesList()

So the loop-above can be rewritten Java-style with for-each:

for (KeyValuePair<system.String, Item> kvp : _package.GetEntriesList()) {
        String.format("Key: %s Value: %s", kvp.getKey(), kvp.getValue().GetAsString()));

Other examples:

for (ComponentPresentation cp : page.getComponentPresentationsList()) {
    Component component = cp.getComponent();
    ComponentTemplate componentTemplate = cp.getComponentTemplate();
    System.out.println(String.format("CP: Component: '%s' %s + Component Template: '%s' %s",
        component.getTitle(), component.getId(), componentTemplate.getTitle(), componentTemplate.getId()));

for (VersionedItem item : page.GetVersionsIterable()) {
    System.out.println(String.format("Version: %s User: %s Date: %s",
        item.getVersion(), item.getRevisor().getTitle(), item.getRevisionDate()));


Unknown said…
A great job. Could you upload your modified proxygen.exe with partial support Generics ? i want to try it on my dll. tks you
Mihai Cădariu said…
They are available at
Unknown said…
This comment has been removed by the author.
Unknown said…
Hello, it's done with proxygen to generate many proxies file for jvm and clr folder. But the building after that does not work. As the proxygen generates many wrongs name file javas such as abc`, etc.. and many errors in .cs files suchs as @__DiscreteMembershipFunction<>, etc.. Can you help me to fix it ?
Unknown said…
This comment has been removed by the author.

Popular posts from this blog

Toolkit - Dynamic Content Queries

This post if part of a series about the  File System Toolkit  - a custom content delivery API for SDL Tridion. This post presents the Dynamic Content Query capability. The requirements for the Toolkit API are that it should be able to provide CustomMeta queries, pagination, and sorting -- all on the file system, without the use third party tools (database, search engines, indexers, etc). Therefore I had to implement a simple database engine and indexer -- which is described in more detail in post Writing My Own Database Engine . The querying logic does not make use of cache. This means the query logic is executed every time. When models are requested, the models are however retrieved using the ModelFactory and those are cached. Query Class This is the main class for dynamic content queries. It is the entry point into the execution logic of a query. The class takes as parameter a Criterion (presented below) which triggers the execution of query in all sub-criteria of a Criterio

A Implementation - Custom Binary Publisher

The default way to publish binaries in DD4T is implemented in class DD4T.Templates.Base.Utils.BinaryPublisher and uses method RenderedItem.AddBinary(Component) . This produces binaries that have their TCM URI as suffix in their filename. In my recent project, we had a requirement that binary file names should be clean (without the TCM URI suffix). Therefore, it was time to modify the way DD4T was publishing binaries. The method in charge with publishing binaries is called PublishItem and is defined in class BinaryPublisher . I therefore extended the BinaryPublisher and overrode method PublishItem. public class CustomBinaryPublisher : BinaryPublisher { private Template currentTemplate; private TcmUri structureGroupUri; In its simplest form, method PublishItem just takes the item and passes it to the AddBinary. In order to accomplish the requirement, we must specify a filename while publishing. This is the file name part of the binary path of Component.BinaryConten

Scaling Policies

This post is part of a bigger topic Autoscaling Publishers in AWS . In a previous post we talked about the Auto Scaling Groups , but we didn't go into details on the Scaling Policies. This is the purpose of this blog post. As defined earlier, the Scaling Policies define the rules according to which the group size is increased or decreased. These rules are based on instance metrics (e.g. CPU), CloudWatch custom metrics, or even CloudWatch alarms and their states and values. We defined a Scaling Policy with Steps, called 'increase_group_size', which is triggered first by the CloudWatch Alarm 'Publish_Alarm' defined earlier. Also depending on the size of the monitored CloudWatch custom metric 'Waiting for Publish', the Scaling Policy with Steps can add a difference number of instances to the group. The scaling policy sets the number of instances in group to 1 if there are between 1000 and 2000 items Waiting for Publish in the queue. It also sets the