Hi all, As part of my initiative to update the SPI to a version without Netty and without third party dependencies, I just pushed an addition of a new code-generator.
Right now the logic code for all drivers is disabled as porting the drivers comes at a later stage of the migration. However I used them as a test-suite for the new code generator. The main difference: It’s not based on FreeMarker, but JavaPoet. Please have a look. It’s not very less complex however (I guess the task of generating code for industrial parsers/serializers might simply not be a trivial task 😉) The ones who had a look at the buffers part of my last bigger update, will see that I no longer have byte-order enums. This is because both the byte-orders as well as the encodings are extendable. So in theory a driver can bring his own byte-order (Like the Modbus) and reference that from mspec. So I needed to change some of the mspecs (In general it’s just switching from an enum byte order reference to a string and updating some of the encoding names (like „UTF-16“ to „UTF16“. Also does the new code generator and buffer API support separate encoders for signed-integer, unsigned-integer, floating point, string, … If you use „encoding“ this just applies to all 4 and should be avoided for anything by non-complex fields. I know this currently would break compatibility with all other languages. I have this on my plan for after my holiday (It’s on a separate branch anyway … so no worries). You now have more than 2 weeks before I’ll have the next block available, so feel free to review. Keep in mind … reviewing fundamental things far down the road would really suck for me, so please: If you’re planning on reviewing, do it in the next 10 or so days. Chris
