Smallworld 5 Builds


Magik on java does not support magikc files any longer. You cannot create or read them (though reading them would be great for backward compatibility). Also the concept of images are no longer valid.

So how do you start a Smallworld session in 5.x? Well there is some documentation about it, but basic idea is that you start a registered magik session. This is defined typically in a register.magik file that is inside a module inside a config product. It is referenced from the gis_aliases file that you point to.

By "default" when you start the session, the magik code will be loaded based on what products/modules you have defined in the registered magik session. This is good for development, but is slow. And if you are a 3rd Party vendor, you would need to release the source code.

To speed things up, you can compile magik files into JARs. These typically are created when doing compile_all_modules() on the selected product. Also you can save the serialization information using save_serialised_module_definitions(0 on the product.

Be aware, JAR and SER files take precedent over any changes to MAGIK or DEF files. Just like an image, you would need to reload the magik files if there were any changes after the image was built. So for equivalency, the JAR/SER files can be thought of as the old image.

Magik Sessions

The Magik_Session object defines what methods and functionality is loaded when the Magik/Java virtual machine is started.

Add Products Property

The :add_products property is a collection of symbols or strings. The functionality differs based on the type of the element.

  • Symbol - Will load the product that is defined by the environment value_DIR or as defined in the LAYERED_PRODUCTS file
  • String (full path) - The complete path to the product.def file.
  • String (relative path) - The relative path is appended to the directory of the configuration module the session references.

These elements are passed to smallworld_product.add_product().


JARs are Locked

There is no out of the box redirection like the MSF files had. The JARs are locked when a Smallworld session is running. You must exit all sessions prior to rebuilding JAR files…

Symbolic libs Link

I was successfully able to recompile JAR files for custom methods when sessions were running. Here are the steps to do this

  1. Create a target libs folder in the product directory. I use a time stamp like libs_2001201542.
  2. Goto the product folder. If running basic command shell and building from network drives, you can use the pushd command to get to network product folder. (PowerShell may allow you directly)
  3. using mklink create a symbolic link. eg, mklink /d libs .\libs_2001201542
      • You will need to do this with elevated privileges. eg, powershell -command "Start-Process cmd -ArgumentList '/c "%~dp001_mklinks.bat" %TIMESTAMP%' -Verb runas" I use the mklink command within the 01_mklinks.bat file.
      • You will want to make the symbolic link relative so the installation can run on local, mapped, and network folders.
  4. Compile your JARs as you would normally.
  5. When you need to recompile, just call rmdir on the libs folder and create a new target folder and symbolic link.

When "copying" a directory with a symbolic link in it, the result will have a empty libs directory. You should verify that link is still exists or you need to recreate it.

Note Symbolic links require special permissions to be used. That's right "used", unlike UNIX where symbolic links are a standard way of life, Windows will block this functionality to non-admin users. See . There is a "developers" mode option as discussed here: .

Environment Variable Module Version

Another option to the JAR locking problem is to update the version number of the modules you are compiling. The version number is part of the JAR file name. This may be a pain to update many module.def files. So here is an option.

The attached magik file, env_versioned_module.magik, allows you to replace the version number within the module.def with an environment such as %MOD_VER%. You can set that environment when building the JARs and when you are ready, just redefine the environment for the users. You can reference the module version the same way in the requires section of other module.def. Note this file requires the fcsi_core module which is attached to Smallworld 5 Debugging Tips.

I include the env_versioned_module.magik and the fcsi_method_manip.magik (part of fcsi_core module) in the config product that defines the magik sessions. This ensures the code is loaded prior to the module.def files being read.

Creating JAR for a Specific module

Since Smallworld doesn't send the code and I couldn't get any timely info from the help desk or second line support, I poked around and developed the following code to compile one module to a JAR without needing to load all your modules in the product. This specifically helped me to compile several of the 172 modules I have as they were reviewed/fixed for Smallworld 5.


The patch (now known as hotfix) scheme has changed in SW5. Before the patches were in a <product_dir>\source\patches_rel folder. Now all hotfixes for a product are loaded from the <product_dir>\hotfixes folder.

The file prefix is now 'h'. And you need a hotfix version number. So I use something like the following: h20011401_0_fcsi.magik. 200114 is YYMMDD. 01 is patch sequence. 0 is the version. fcsi is company initials.

Within the hotfix h20011401_0_fcsi.magik file, I declare the patch as sw!declare_patch(20011401, "0_fcsi", "A fix")

Note if you use something like _01_fcsi in the file name, the declare version needs to be "1_fcsi". The '01' is converted to a number '1'.


Releases 5.0 -> 5.1.5
For those of you who use load_file_stop() to prevent magikc files from being created, you cannot use this concept in Smallworld 5 within modules that are delivered as JAR files. For out of the box functionality, a load_file_stop() will stop the creation of the JAR file all together. I have used the copy method functionality to copy the magik_rep.do_load_file() functionality to capture the "error" condition raised. However, no matter what I tried, the file would still not be put into the JAR file. If you have a JAR file it is the only thing loaded, the module does not try to load anything else. This means the file with the load_file_stop() would never be loaded.

The only work around is separating the code out some how. I typically used this functionality to deliver magik source files as examples for my customers when appropriate. Other uses would be to stop adding methods if at certain releases. These concepts must be re-worked to provide JAR files and files that are delivered in magik format.

Specialized Loading

I needed the ability to load certain magik files based on Smallworld versions. This is especially relevant between versions 4 & 5. One thing that is new with SW5 is the fact you JAR compile the modules. To do that the code is actually compiled. Typical installations are an all or none option of JAR compiling methods within a product.

Here are a few ways of having magik files loaded based on the version.

  • You can use module versions or separate your code into different modules. This requires you to define the module and version differently throughout your build. So you may need to have a "master" module.def that defines all the modules loaded for version 4.3 and another for 5.1. This is extra upkeep where you will need to load specific modules/versions based on your target build. Although, this would probably be a small and manageable list to maintain.
  • Within the magik files being loaded from a JAR you can load the magik files using the load_file() procedure and providing the magik file to load. A good way of identify the magik file to load is to use the dynamic !module_file! that is set when the JAR file is read into the session. Example:
folder << system.pathname_up(!module_file!.as_charvec())
magik_file << system.pathname_down(folder ,"specific_file.magik")

Method Finder Mapping

You can map the location of source files so that the method finder can jump to the appropriate code. This is especially good for when a JAR file is delivered but only certain source files are delivered in a separate directory. You can use method_finder.add_mapping("NAME_OF_ENV").

Start Up Times

SW5 start up times are slow… What can be done to speed them up????

Theory 1

For those battling with start up times with Smallworld 5, here's an theory someone my want to investigate…

From my experiences, when the sw5 session starts, it basically does a build to load all the magik (in form of java class) code as it used to occur when you built images pre 5.

What would happen if you didn't load all the modules during session start up, but had a "loader" object that you could call that would load the module when something is executed the first time.

For example the case tool… Having available by default is good for developers, but when you do it will load the case modules during start up. Would it speed up things that when I start an application, the first thing it does is load the modules for that application if they haven't been loaded?

So the initial start up wouldn't load the case modules. only when you load the case tool would it load the case modules…

This could be expanded to other things also… Like the case data model objects… Only when you open a case SOC/SOM will it load the case object module…

Just some thoughts… I'm not doing stuff on SW5 right now, so I figure I would propose the idea and have someone else develop something if they have time…

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License