Nashorn Bug..

June 18, 2014


Excited as anyone would be of a newer, performant, cleaner engine Nashorn was something to look forward. Nice to play with moving on from Rhino. But one bug that is annoying and would love to get a fix for fast is its handling of large hierarchy of classes / or large number of methods in the Java class a script calls into. A hack works.. but need better way forward / affirmation on this..

“Step two translates the AST/IR into byte code via the ASM library. ASM emits the actual byte codes to form a script class”



          new MyClass().invokeAnyMethod()  // method on its super class which is Abstract

In this the MySuperClass has invokeAnyMethod() defined viz: MySuperClass should be having a hierarchy of classes that put together have say 6000+ methods.  (The #invokeAnyMethod() then has statements that invokes a method(s) on its super classes, a simple method that returns “hello world” or simple calc on its immediate attributes does not suffice )

In the

JavaAdapterBytecodeGenerator.<init> ( constructor ) .. it does the following:

     gatherMethods(superClass); // this reaps all the methods of the super class MySuperClass of 6000+ methods..



     generateConstructors(); which in turn invokes the following:


private void generateOverridingConstructor(final Constructor<?> ctor, final boolean fromFunction) {

… //this has a loop through all the methods gathered..

for (final MethodInfo mi : methodInfos) {

… which goes on to emit the code bytecodes for the firstMethod of the ClassWriter ( cw ) property

with iteration over 6000+ methods it easily exceeds the 64K bytecode limit of JDK VM method byte code size..

which then gloriously fails as:


java.lang.RuntimeException: Method code too large!



           at jdk.nashorn.internal.runtime.linker.JavaAdapterBytecodeGenerator.createAdapterClassLoader(

*******  Hack in at :

public static TypeBasedGuardingDynamicLinker getLinkerForClass(Class<?> clazz) {

   return linkers.get(clazz); // need to check on why NashornBeansLinker for specific cases..


// If it returns a NashornBeansLinker that then goes through the chain to dump the ClassWrter creates an issue, for simple methods it returns a BeanLinker and runs fine..  maybe nice to get a hang of it here..

private static GuardedInvocation getSamTypeConverter(final Class<?> sourceType, final Class<?> targetType) throws Exception {

// If source type is more generic than ScriptFunction class, we’ll need to use a guard

final boolean isSourceTypeGeneric = sourceType.isAssignableFrom(ScriptFunction.class); // make this false for such cases… and it works fine.. for the basic tests..


 * I have not as yet plumbed as much of the Nashorn logic in this.. why dig through and create a ClassWriter byte code cache (NashornAdaptor to the super class ) when it can probably make a proxy for the Java object and simply let the message be invoked as normal Java method and marshal the result back as per Nashorn semantics.. I am sure there are good reasons, need to plumb it thoroughly before I comprehend it..

*  Now the other concern is org.objectweb.asm.** is used in other packages viz: Groovy / Spring.. et als as  now will this create a conflict is also to be plumbed and ensure classpath loaders honor the segregation properly Groovy still uses a very old asm 4.0 jar.





Pharo is a Smalltalk dialect

April 29, 2014


“Invent the future” a resonating statement that we can only be inspired by. There are thousands of more ideas, works that continually inspires us all. Inspiration drives the creation of something new.  Pharo Smalltalk begins with something that existed, but is a new avatar and will probably head to be the best dialect of Smalltalk.

Pharo Smalltalk has begun to establish roots in the minds of so many more engineers/ developers and become more relevant for its use in enterprise application space. The inspiration for its changes from the base of Smalltalk emanate and will continue to be influenced from various sources. Smalltalk is not defined rigorously to be the one published and controlled by one corporation but by the tenets that have held sway and inspired a Java, Ruby and others in their development.

* Image based environment

* IDE, inspectors, debuggers and many other tools as part of its development environment

* Dynamic typed, garbage controlled

* Primarily single inheritance structure

* VM that is rooted in the Blue book, but evolved over time and will continue to evolve even further

* Meta programming capabilities

Many other features add unto the perception of Smalltalk in our mind, not the differences in:

* Morphic UI vs MVC UI or any others

* Platform independent or only single OS focussed ( viz: Dolphin / Smalltalk MT et als.. )

* Ideas and concepts viz: spoon, traits, scratch et als

* Git / SVN filtree rather than MC backed SCM

…… or any other minor changes…

Each dialect will spawn a host of new ideas and will enrich the Smalltalk community. Pharo Smalltalk does currently give a great thrust in that direction and it will be for the greater good to continue to do so say for next few years more before there is a feel that it has diverged far out of its Smalltalk origins to be labelled anything but Smalltalk in its heart and soul, wrapped as it may be that differently

The end goal should not drive an image campaign, the product should be built and shaped to be perfect and the ultimate tool for its use. People as they adopt will shape its image and perception to their benefit and its growth.

Like Steve Jobs,  focus in doing the best with the platform, contributing the best to the platform in whatever way it enables enterprise to adopt and use it forever with guarantees of:

* VM being absolutely rock stable, perfect in its execution of all operations

* Growing body of tools, capabilities, libraries et als

* Interoperability with what exists in simple and fail safe manner.

* Newer exciting projects that it spawns inspires others to try their works on it..

Much more that is already been done over the past 4 years and is expected ahead…

Relabelling Pharo Smalltalk to anything but as a dialect of Smalltalk, I believe is nothing short of denying its own origins for now. Let it mature and diverge enough to be relabelled.



Inspired by a blog from a much admirable Smalltalker:




Interesting Tech Reading List

April 25, 2014

Databases: NewSQL vs NoSQL vs OldSQL


including the comments

good start to concurrency is here:




Typically I would read through Caching and Transactions in conjunction with concurrency control to relook at an architecture / design of a system.

 Java EE 7 :

DZone RefCardz:

❱❱ API for WebSocket
❱❱ Batch Applications
❱❱ API for JSON Processing
❱❱ Concurrency Utilities
❱❱ JMS 2.0
❱❱ JSF 2.2…

Java 8:


Compatability Issues for Java 7 to Java 8 migration:



TDD And Unit Tests:



specially the summary resonates


specially MockFor and “as Class” class instance generation…





Pharo 2.0 Released

March 18, 2013

Post your comments…


On Mon, Mar 18, 2013 at 3:42 PM, Marcus Denker <> wrote:

We are proud to announce the release of Pharo 2.0!

You can find information about Pharo at:

About this release
All in all, there were over 1600 issues treated in the issue tracker
and 1350 improvements integrated into 2.0.

Major framework changes too:

– Spec
– Widget enhancements
– Layout improvements/cleanups
– Keybindings
– New icons (famfam)
– Growl style notifications
– Revamp progress bar

Developer tools

– Nautilus browser
– Critics browser
– Improved version diff browsing
– Spotlight
– Revamp Code Completion and smart chars
– Interactive navigation using ctrl/cmd+click over classes/methods
– Shout themes
– Andreas profiler


– Update Zinc
– Zodiac (SSL)


– System Announcer
– RPackage replacing PackageInfo
– Command line tools / Headless mode
– Native boost
– Update Ring metamodel
– Fuel serializer
– Freetype fonts


– DateAndTime refactoring
– Updated FileSystem and replaced FileDirectory


– Latests cog builds
– SSLPlugin
– FilePlugin enhancements
– SocketPlugin fixes
– Included libraries: freetype2, cairo


– FileDirectory removed (replaced by FileSystem)
– SmartRefStream and ReferenceStream removed (replaced by Fuel)
– PackageInfo deprecated (replaced by RPackage)


– Zeroconf scripts
– Continuous Integration for every aspect of our release process.


2013 – 2014 Smalltalk Looks up..

March 14, 2013

I guess through 2013 – 2014 we should have a cleaner, resurgent Smalltalk looking at through the clouds into many enterprise desks.

This is cool: bit heretic for the usual client side developer

Great Potential to on the client side.. Will try to have an internal server with some tangible utility stuff in it.

You can try out the browser built in. .. and the code for from Amber is also available as contributed package elsewhere..

Slow progress, but hopefully when it gets done..for v1.0 , probably mid of next year, it will be one great tool for Smalltalk on JVM


Lastly the creaking out of old and bring in the new:

The 2.0 breaks new grounds in a new , cleaner , freeware Smalltalk almost perfect for enterprise works. Guess 3.0 by next year will lop off the remaining rough edges too.


I will try and come out with in-works multi-world tablet IDE beta on top of 2.0 free time permitting…


This is close to what I will have, but cool in aesthetics and nice stuff built out of Pharo by I would say a non-core developer but a biologist..!





Pharo 2.0 Morphic View and TabbedPane IDE

February 26, 2013

Its been  a year since I have talked of this..

With Pharo 2.0 in imminent release status, I think its best to refactor the packages and make them available for all to try and use.

Just load two packages from :

* PharoMorphicView-Core

* PharoMorphicView-TabbedPane

On a workspace execute:

  PharoTabbedPaneIDE reinitializeAndOpen

For Pharo Morphic View: Ref

Also the PharoMorphicView-Core-Examples and Tests package to see all variations of the MorphicView framework.


Pharo TabbedPane IDE

Pharo TabbedPane IDE

Pharo Morphic View Example

Pharo Morphic View Example

Why is India an exciting place for future research

December 15, 2012

In lighter vein, without a whiff of anything more toxic than curd-rice, post a short  bout of viral …!


Quantum Physics is many decades old, but is considered on the verge ( in the range of next couple of centuries, if not within one ) of providing big breakthroughs in computing [1] and communications [2]

From Wikipedia on Quantum Chaos [3]:

“The correspondence principle states that classical mechanics is the classical limit of quantum mechanics. If this is true, then there must be quantum mechanisms underlying classical chaos”

Classical Chaos as in a nation state, encompassing all spheres of political, technical , sociological and even sports realms, yet retain a state of tense equilibrium ( howsoever uncertain in heisenberg’s sense, it is ) is epitomized in India..!!.. 

Given that most Indians easily comprehend chaos and order from chaos more naturally than any other nationality, I am sure should in the future times, give the greatest fillip, if supported well, to have an ability to harness Quantum theories aka chaos principle effectively in developing cutting edge technology/ applications world will come to use in the centuries to come..







I do believe there is lot more to all the links above, that can tie lot of loose ends between physics and metaphysics and ferevently hope helps more tangibly in forseeable future.