JKI Blog

Why do we need dynamically typed JSON library in LabVIEW?

Aug 4, 2016 7:47:47 AM Published by Tomi Maila Leave a comment

We've all used JSON in our applications, to send messages over networks, to connect to REST APIs or to simply save configuration data to a disk. Over the past 10 years JSON has climbed to the most popular data exchange format replacing XML. Since LabVIEW 2013, there has been a native implementation of JSON shipping with LabVIEW. At JKI we are power users of LabVIEW and found the native JSON implementation often not meeting our needs. We came up with our own JSON library, the JKI JSON serialization library, that we just open sourced and made freely available to the LabVIEW community.

How does the JKI JSON serialization library differ from the LabVIEW native implementation of JSON? There are several differences, but the biggest difference is that the JKI JSON library is dynamically typed whereas the LabVIEW native serialization library is strongly typed. What I mean by this is that the native JSON library adapts to the type at edit time and does not accept LabVIEW variants as inputs. This would be a good thing if LabVIEW had an adaptive type system supporting generics. But it doesn't. As a result the LabVIEW native JSON library cannot be used as part of reusable code, where the reuse component is not aware at edit time what is the type of the data it needs to convert to JSON. Consider for example that you're trying to build some reusable code that receives log events from different components of the system, serializes them to JSON and sends them over the network to a log server. This trivial sounding task cannot be implemented with the LabVIEW native JSON library because the code serializing the events and sending them over the network does not know at edit time what is the type of the events it is going to receive from the system components. That's where JKI JSON library comes in.

Flatten To JSON String

 

The JKI JSON library accepts any LabVIEW data as an input at edit time, including variants. If it cannot flatten the provided data to JSON it generates a runtime error. The benefit of this approach is that now we can create reuse components that use JSON behind the scenes as a data exchange format that we can reuse in different applications and even within an application among different application components. Think for example the event log module we just talked about. With JKI JSON we can easily create a reusable component that accepts any LabVIEW data as an input and logs it over the network to a log server using JSON as a data exchange format. Or we can create a configuration file manager for our application that manages saving and loading JSON based configuration files without needing to know the exact format of the data structure that we will need to save and load at edit time of the configuration manager. These may not sound like big issues for very small applications but these become real issues for almost all system of just medium complexity.

Stay tuned for more posts on our open source JSON library. To download JKI JSON and our other toolkits visit our tools page.

JKI Tools for LabVIEW Developers

 

Tags: Applications, JSON, JSON Serialization, LabVIEW, open source

Subscribe to Email Updates

Recent Posts

Posts by Topic

see all