Topics and trends related to the Java ecosystem with occasional random rants.

  • Sun
    November 5, 2012

Sprinkle Some Magik on that Java Virtual Machine

James Connors
Principal Solutions Consultant

GE Energy, through its Smallworld subsidiary, has been providing geospatial software solutions to the utility and telco markets for over 20 years.  One of the fundamental building blocks of their technology is a dynamically-typed object oriented programming language called Magik.  Like Java, Magik source code is compiled down to bytecodes that run on a virtual machine -- in this case the Magik Virtual Machine.

Throughout the years, GE has invested considerable engineering talent in
the support and maintenance of this virtual machine.  At the same time
vast energy and resources have been invested in the Java Virtual
Machine. The question for GE has been whether to continue to make that
investment on its own or to leverage massive effort provided by the Java
community? Utilizing the Java Virtual Machine instead of maintaining its
own virtual machine would give GE more opportunity to focus on
application solutions.  

At last count, there are dozens, perhaps hundreds of examples of programming languages that have been hosted atop the Java Virtual Machine.  Prior to the release of Java 7, that effort, although certainly possible, was generally less than optimal for languages like Magik because of its dynamic nature.  Java, as a statically typed language had little use for this capability.  In the quest to be a more universal virtual machine, Java 7, via JSR-292, introduced a new bytecode called invokedynamic.  In short, invokedynamic affords a more flexible method call mechanism needed by dynamic languages like Magik.

With this new capability GE Energy has succeeded in hosting their Magik environment on top of the Java Virtual Machine.  So you may ask, why would GE wish to do such a thing?  The benefits are many:

  • Competitors to GE Energy claimed that the Magik environment was proprietary.  By utilizing the Java Virtual Machine, that argument gets put to bed.  JVM development is done in open source, where contributions are made world-wide by all types of organizations and individuals.
  • The unprecedented wealth of class libraries and applications written for
    the Java platform are now opened up to Magik/JVM platform as first
    class citizens.
  • In addition, the Magik/JVM solution vastly increases the developer pool to include the 9 million Java developers -- the largest developer community on the planet.
  • Applications running on the JVM showed substantial performance gains, in some cases as much as a 5x speed up over the original Magik platform.
  • Legacy Magik applications can still run on the original platform.  They can be seamlessly migrated to run on the JVM by simply recompiling the source code.
  • GE can now leverage the huge Java community.  Undeniably the best virtual machine ever created, hundreds if not thousands of world class developers continually improve, poke, prod and scrutinize all aspects of the Java platform.  As enhancements are made, GE automatically gains access to these.
  • As Magik has little in the way of support for multi-threading, GE will benefit from current and future Java offerings (e.g. lambda expressions) that aim to further facilitate multi-core/multi-threaded application development.
  • As the JVM is available for many more platforms, it broadens the reach of Magik, including the potential to run on a class devices never envisioned just a few short years ago.  For example, Java SE compatible runtime environments are available for popular embedded ARM/Intel/PowerPC configurations that could theoretically host this software too.
As compared to other JVM language projects, the Magik integration differs in that it represents a serious commercial entity betting a sizable part of its business on the success of this effort.  Expect to see announcements not only from General Electric, but other organizations as they realize the benefits of utilizing the Java Virtual Machine.

Join the discussion

Comments ( 12 )
  • guest Tuesday, November 6, 2012

    I can't help but notice the similarities between Magik and Ruby.

  • Frisian Tuesday, November 6, 2012

    So basically their software runs faster and on more platforms. Their VM development is done by someone else for free. They even get additional features (multi-threading) for free. Doesn't sound altruistic for me.

    Now let's hope they also contribute to the JVM.

  • Alexander J Turner Wednesday, November 7, 2012

    Yes - they very much do contribute to the JVM. I have been working with this team (last week - sob - after 18 fabulous months) and they/we contribute via the mail list, bug submission and to the conferences. Also, work on JVM-8/Mac testing. I personally have written up a lot of what has been learned about high speed JNI (which is used a lot to talk to pre-existing database and geometry libraries) and intend to continue to write up more.

    - AJ

    Dr Alexander J Turner

  • guest Wednesday, November 7, 2012

    This is a very good move for GE. The Magik programming language is very similar to Java, syntax differences aside, and although Magik is predominantly interpretted (rather than compiled) which is good for debugging and rapid development, it is inherently slower than a compiled solution - like Java.

    If GE can indeed take Magik code and compile it up into Java, then that's a very cool way to get into speeding up processing, multi-threading, and making things a lot more portable. Kudos.

  • Alexander J Turner Wednesday, November 7, 2012


    The compiler does not convert Magik to Java. It compiles Magik to bytecode. The performance benefits you suggest are available though. The biggest challenge in achieving high performance form a dynamic dispatch language like Magik on the JVM is to ensure that call sites do not become mega morphic and then when they do the dispatch code is as fast as possible.

    Cheers - AJ

  • guest Friday, November 9, 2012

    I hope GE will go on the way to finally support its Smallworld products on JAVA technology and let Magik just for legacy concerns.

    It's a benefit for companies looking for professionals because no one knows about Magik, but there is a lot of experts and professionals working on JAVA everywhere.

    It's a benefit for programmers because instead of learning a weird technology like Magik no used anywhere except for Smallworld, they can improve their curriculum with a JAVA technology widely recognized and in demand.

  • guest Friday, January 11, 2013

    Very good news. Is there any announcement about this from the GE side?

    Has anybody tested the JVM on a smallworld deployment?



  • Jim Connors Friday, January 11, 2013

    GE has announced this effort to its customers and partners at the GE Digital Energy conferences in Portugal, Australia, New Zealand and Americas throughout last year. They will be making announcements on the first product release based on this work a bit later this year.

    In terms of testing the JVM on a Smallworld deployment, yes, GE has been working with Smallworld product portfolio for the entire duration of the project, in particular Core Spatial Technology, which is the foundational component of their technology stack.

  • guest Monday, January 21, 2013

    I've been using Magik for over 20 years, never had to complain about it. Great language. Shame it wasnt made public earlier, as it would probably have caught like Java, Python or Ruby did.

    It is indeed closer to Python and Ruby than it is to Java. Now it is strange to me hearing that Magik is interpreted. Magik is compiled into pseudo-code, just like Java is, and also works on a (Magik) virtual machine.

    The interactive Magik terminal compiles (just in time) and executes code. Code then resides in memory as VM code, not as original Magik language. Hence the distinction with an interpreted language.

    Now yes, the port to JVM will allow simpler integration of existing Java capabilities into existing Magik apps.

    But Magik will definitely stay an interesting language for those who know it.

    The downside is for old Magik programmers who will no more have an edge with this special rare skill. But I suppose that's the way it goes :)

  • guest Friday, April 19, 2013

    I too have been a Magik developer for over 20 years and I am delighted by this development as it will open the way for Smallworld to be deployed on as many platforms as supported by the JVM. But I am always taken aback by references to Magik programmers having an edge with special rare skills. A programming language is just a set of instructions and once you know one well, learning another is relatively straight forward. The actual rare and special skill is the knowledge of Smallworld libraries and specific domain knowledge be that Telco, Utility, Landbase, etc. So don't expect a sudden rush of great Smallworld programers coming from the Java community. They will come but they will have to do their internship like the rest of us.

  • guest Thursday, June 20, 2013

    Does it mean that finally Emacs will go to the place where it should? ... to the garbage, and we can expect to be able to program in a professional manner with professional tools like Eclipse or Netbeans ?

    Like another user said in this forum, Magik can stay just for legacy purpose, but GE should move to 21 century and perform a full integration with JAVA, not only the JVM but the language and framework as well.


  • Guest Wednesday, November 1, 2017
    Smallworld magik, or GE magik as it has become, brings its own benefits to the marketplace irrespective of Java. Since it well supports Long Transaction Databases and is tailored nicely towards GIS applications, it has, amongst a plethora of other applications, a place of its very own. GE have taken a risk by investing in moving to JVM and it will pay off. The days of COBOL calling FORTRAN and providing Objects for Magik, are long gone. That happened when we had little else. JVM is here today and GE are, I think, wise.
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.