Tags Archiv für 'Java'

Autocasting in Java — An approach

I’m just wri­t­ing some Java code and for the thousand-​and-​first time there is some­thing like

public void someMethod(AnyType a) {
 if (a instanceof DerivateOfAnyType) {
  DerivateOfAnyType d=(DerivateOfAnyType)a;

Even though these-​days Java has Gene­rics, Anno­ta­ti­ons and that other cool stuff, you still have need for such casts, and I’m pretty sure that if you replace „Any­Type” with „Object”, you’ll find such occur­ren­ces also in your code (if you are a Java programmer).

Every time I write such stuff, I think for mys­elf: „Why does that Java com­pi­ler not per­form the cast on its own?” I mean: After suc­cess of an „instan­ceof” check, I can be sure that the object is an instance of the type in ques­tion. Why do I have to exp­li­citly name that again. The code would become much more rea­da­ble and not more con­fu­sing if it were chan­ged into

public void someMethod(AnyType a) {
 if (a instanceof DerivateOfAnyType) {
  a.someMethodOfDerivate(); // ((DerivateOfAnyType)a).someMethodOfDerivate();

Sear­ching with google quickly lead me to blog entry of Ste­phen Cole­bourne who had pre­ci­sely this idea more than five years ago. The dis­cus­sion in the com­ments of that arti­cle showed two problems:

  1. It can be ambi­guous to call the auto-​derivated class by its old name („a” in the example). The pro­po­sed solu­tion was to define an exp­li­cit new name wit­hin the instan­ceof state­ment:

    public void someMethod(AnyType a) {
     if (a instanceof DerivateOfAnyType as d) {
  2. Even using this syn­tax, there is more space for ambi­gui­ties. Exam­ples were
    boolean b=(a instanceof DerivateType as d);
    if (a instanceof Type1 as t1 || a instanceof Type2 as t2).
    For this pro­blem, the dis­cus­sion ended inconclusively.

After having read that, I’ve ela­bo­ra­ted that auto-​casting stuff a bit. The exam­ples from above are a bit patho­lo­gic. Nor­mally, the whole instan­ceof stuff is only for one type and only wit­hin an if-​construct. So, it all comes down to a syntactic-​sugar thing preven­ting the only sen­si­ble cast from being writ­ten down exp­li­citly. Which brought me to this rule set:

  • The „instan­ceof” ope­ra­tor is exten­ded by an (optio­nal) „as” part. So, it is legal to write a instanceof TypeB as b.
  • An instan­ceof ope­ra­tor exten­ded this way crea­tes a new name „b” for the object instance refe­renced by „a” which refe­ren­ces the same instance auto­ma­gi­cally as being of class „TypeB”
  • The new name „b” is only avail­able wit­hin the block bound to the state­ment with the exten­ded instan­ceof declaration.
  • The exten­ded instan­ceof syn­tax is only allo­wed wit­hin a con­junc­tive non-​negating logi­cal expression.
  • Fur­ther­more, it is only allo­wed if it is the only „instan­ceof” state­ment wit­hin the logi­cal expression.

These defi­ni­ti­ons would make the auto-​casting unam­bi­gious by restric­ting it to the actual nee­ded case. Things like „if (a!=null && a instanceof B as b)” or „while (a instanceof B as b)” would still be pos­si­ble while „if (!(a instanceof B as b))” or „if (a instanceof B as b || a instanceof C as c)” would not. To me, it seems as if this defi­ni­tion of an exten­ded instan­ceof ope­ra­tor would solve the annoy­ing cas­ting syn­tax of these-​days Java in this case while avo­iding all the patho­lo­gi­cal cases descri­bed in the blog arti­cle and its dis­cus­sion men­tio­ned above. Futher­more, note that all the usual rules for cas­ting and assin­ging new con­tent to varia­ble names still apply. So, when wri­t­ing some­thing like „a=new TypeA()”, it would create a new object and leave „b” poin­ting to the old object. In the same way, b=new TypeB() would create a new object just as it would if „b” was decla­red in these-​days Java with the exp­li­cit cast at the begin­ning of the „if” block.

Of course, all of this only is true if I do not miss some­thing in my con­clu­si­ons. But if this works out, I think it would be a nice little exten­sion to the Java syn­tax which era­diac­tes a rather cum­ber­some short­co­m­ing in the syn­tax. And, of course, it is all compiler-​only. Anyone kno­wing how to write a JSR?

Jython memory leak/​Out Of Memory problem

Note: This arti­cle has been unpublis­hed for quite some time. It’s main parts date back to Decem­ber 2007. The­re­fore, if some ver­sion num­ber seem to be out­da­ted — I am refer­ring to the state it had back those days.

We have a Java app­li­ca­tion with embed­ded Jython script­ing engine. The Jython scripts do mass com­pu­ta­ti­ons on data sets. So far, we had 3000 – 4000 data sets in one chunk maxi­mum. Now, a new cust­o­mer starts and will have 8000 and more data sets.

„No big deal,” I thought. And star­ted the test run one day before our cust­o­mer will have the whole thing run­ning on the pro­duc­tion sys­tem for the first time. Com­pu­ta­tion starts: 1000… 2000… 3000… 4000… 5000… bang „Out of memory. You should try to increase heap size”. The ser­ver app­li­ca­tion halts com­ple­tely and wit­hout any fur­ther warning.

I’m a bit sho­cked. The big pro­blems always arise at place where one would defi­ni­tely not expect them. I start cir­cum­ven­tion attempts: Split­ting the run into smal­ler chunks — does not work. Reinitia­li­zing the Jython environ­ment perio­di­cally — makes things worse. Repla­c­ing our rather out­da­ted (but other­wise func­tio­nal) Jython 2.1 with the then-​current Jython 2.2.1 — does not mat­ter. I do not seem to have a chance to cycle more than about 5200 times through the script before I catch an „Out of memory” situa­tion — or have to restart the whole ser­ver process.

Weird. What should I tell the cust­o­mer? „Well, you can­not run your com­pu­ta­ti­ons in one step. Start with the first half, then call us, we will restart the ser­ver, then do the second half.” ??? Not a really pro­fes­sio­nal way of doing things. Even more sur­pri­sing, loo­king at the memory situa­tion with Runtime.freeMemory() and fri­ends shows that there is no shor­tage of memory at all. Actually, when the app­li­ca­tion cras­hes, it has used not more than 600 MB out of 2048 MB heap space and more than 50 MB are mar­ked as „free”. This is not pre­ci­sely what I would sum­ma­rize as „out of memory”…

Finally, poking Google once more brings the solu­tion. I find an arti­cle about just a simi­lar pro­blem. For­t­u­na­tely, it has a solu­tion and even explains what’s going on: Jython has an inter­nal map­ping of PyXXX wrap­pers to Java objects. The default con­fi­gu­ra­tion uses nor­mal refe­ren­ces which makes these map­pings resis­tant to gar­bage collec­tion. Due to mecha­nisms I do not fully under­stand, this leads to enor­mous growth of the map­ping set and finally an out-​of-​memory-​situation with the inter­nal resource management.

For­t­u­na­tely, the solu­tion is as sim­ple as put­ting a


some­where in the code before the Jython sub­sys­tem is initia­li­zed. Then, the inter­nal table is built with weak refe­ren­ces and sud­denly, ever­y­thing runs smoothly. The 8000 data sets are no pro­blem any more and I can deli­ver the app­li­ca­tion as expec­ted. Lucky me.

There is only one ques­tion remai­ning: What kind of para­psy­cho­lo­gi­cal abi­li­ties are deve­l­o­pers expec­ted to have to find such a solu­tion wit­hout having the luck to find an arti­cle descri­bing this. And: Why the heck does Jython not use weak refe­ren­ces as default? I could not find any pro­blems or even speed penalties.