I don't know many embedded devices, that would be controlled by BACnet, that are even capable of running a 64-bit JAVA VM. So why make a reference implementation in JAVA?
For our purposes this is impracticably non-useful. Sorry.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Often, the primary goal of a “reference implementation” is to be correct in its behavior, and equally, to be easily understandable and fixable by a community if it is found to be not correct. It is a “known good” against which other implementations are to be measured. In many cases then, it is only a secondary goal that it be a “starting point” for vendors‘ implementations.
This balance of priorities can be seen in the extensive and verbose logging that is done by this implementation. That large amount of that code would be undesirable in an embedded implementation. Additionally, the reference implementation has the ability to “misbehave” and do non-conformant things that make it a helpful testing tool, but would be of no use for a real product. It is also scriptable in Python for development of tests that can be edited and injected “live” while it is running. Even the Java code can be recompiled and injected live into a running system, even a remote system on another device, for fixing bugs on the fly without shutting down. The power of the Java runtime environment enables all this magic! I love C (for thirty years), and still think it is absolutely the approptiate choice for some designs, but this kind of magic is a huge boost to productivity if your environment supports it.
In short, the "reference implementation" is an easilly debuggable framework for a variety of purposes. It was developed to be flexible and useful, not necessarily small.
That said, it runs just fine on an old $30 Raspberry Pi. And not only as a node. It’s been tested as a hub with 100 simultaneous connections, with the full logging and testing capabilities remotely accessible through the network. The JVM's compilation to native code it pretty amazing.
While it may not be common today for every controller to be as powerful as a Raspberry Pi, it is known that there are vendors that produce embedded controllers, some as small as VAV controllers, that run their BACnet stacks in Java. So it is not theoretical that the reference implementation could actually be used as a “starting point” for actual products, and we have heard that it has been, actually.
If you are familiar with modern Java, you can tell that the style of code is deliberately not modern (limited to Java 8), using none of the new constructs that have been added in recent years that could make the code harder to understand or harder to port. There is an occaisional lambda thrown in, but there are easy workarounds for languages that don't support that. As it is, it was very easy to take something like TestHub.java and rewrite it in Python (as was done for one of the webinars). The style was intended to be easily ported to any garbage collecting language like C#, Python, or JavaScript/TypeScipt, and it uses an event loop design that can work in any environment or OS.
Even though you don't see a lot of chatter here in this forum (most conversations are held in the various BACnet mailing lists), I have been pleased to see how many folks have used the reference implementation as part of the development of their products, either directly or as a testing tool. That was the intention of its development and I'm glad that it has been of service to the BACnet community.
Last edit: Dave Robin 2022-05-31
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I don't know many embedded devices, that would be controlled by BACnet, that are even capable of running a 64-bit JAVA VM. So why make a reference implementation in JAVA?
For our purposes this is impracticably non-useful. Sorry.
Often, the primary goal of a “reference implementation” is to be correct in its behavior, and equally, to be easily understandable and fixable by a community if it is found to be not correct. It is a “known good” against which other implementations are to be measured. In many cases then, it is only a secondary goal that it be a “starting point” for vendors‘ implementations.
This balance of priorities can be seen in the extensive and verbose logging that is done by this implementation. That large amount of that code would be undesirable in an embedded implementation. Additionally, the reference implementation has the ability to “misbehave” and do non-conformant things that make it a helpful testing tool, but would be of no use for a real product. It is also scriptable in Python for development of tests that can be edited and injected “live” while it is running. Even the Java code can be recompiled and injected live into a running system, even a remote system on another device, for fixing bugs on the fly without shutting down. The power of the Java runtime environment enables all this magic! I love C (for thirty years), and still think it is absolutely the approptiate choice for some designs, but this kind of magic is a huge boost to productivity if your environment supports it.
In short, the "reference implementation" is an easilly debuggable framework for a variety of purposes. It was developed to be flexible and useful, not necessarily small.
That said, it runs just fine on an old $30 Raspberry Pi. And not only as a node. It’s been tested as a hub with 100 simultaneous connections, with the full logging and testing capabilities remotely accessible through the network. The JVM's compilation to native code it pretty amazing.
While it may not be common today for every controller to be as powerful as a Raspberry Pi, it is known that there are vendors that produce embedded controllers, some as small as VAV controllers, that run their BACnet stacks in Java. So it is not theoretical that the reference implementation could actually be used as a “starting point” for actual products, and we have heard that it has been, actually.
If you are familiar with modern Java, you can tell that the style of code is deliberately not modern (limited to Java 8), using none of the new constructs that have been added in recent years that could make the code harder to understand or harder to port. There is an occaisional lambda thrown in, but there are easy workarounds for languages that don't support that. As it is, it was very easy to take something like TestHub.java and rewrite it in Python (as was done for one of the webinars). The style was intended to be easily ported to any garbage collecting language like C#, Python, or JavaScript/TypeScipt, and it uses an event loop design that can work in any environment or OS.
Even though you don't see a lot of chatter here in this forum (most conversations are held in the various BACnet mailing lists), I have been pleased to see how many folks have used the reference implementation as part of the development of their products, either directly or as a testing tool. That was the intention of its development and I'm glad that it has been of service to the BACnet community.
Last edit: Dave Robin 2022-05-31
Thank you for the detailed reply. That was very helpful.
--Rick