-->Java Native I/O

Major Design Decisions

Separate Definition of Data Type and View
General concept now differentiates between a data type definition in terms of a Java class, which resembles a C struct, and a view type, which provides methods to access the C struct in a ByteBuffer.
Static Code Generation Integrated in IDE
To improve user experience, dynamic code generation has been replaced by static code generation integrated with the IDE.
Generated Code of StructViews
A view contains the following methods.

Still Existing Gotchas and Issues (i.e. TODOs)

Struct Type Declaration
In the current version, there are some constraints on structs, which conflict with ease of use in general, and integration of types, declared in thirdparty libraries.
  1. No Inheritance: Inheritance would require the generator to either create views with similar inheritance structure or consider the inherited member fields to be 'inlined' in the declared struct type.
  2. Public Members Only: This was mainly driven by the fact, that private members require the use of the Java reflections API or the non-standard Unsafe interface to modify them. This either generates more processing effort, or may lead to incompatibilities. Technically, private members can still be supported through those APIs if the users wants it, which will be most likely the case in future.
  3. Public Static Member Classes: As well as member fields, member classes need to be accessible (public). They also need to be static, because instances of non-static classes (structs) declared inside of a struct type, have a reference on the instance of the outer class.
  4. Issues with Unions: There is no corresponding type construct in Java, which makes it hard to declare unions without running into issues. Obviously, this is no issue for the generation of a view, but the use of the corresponding Java type beyond just its use as declaration of the struct type, is getting questionable. Maybe a declared Union should be a kind of view itself, which has methods to access data through one of the types declared in the union, but in fact accesses all members when using any setter method. Also, currently every view contains a method get() and a method set() with no parameters, which refers to an instance of the entire struct. This would make no sense in case of unions.
View Implementation
  1. Nested Views: A view for a struct which contains nested structs as members, currently holds references on instances of corresponding views in member fields, as explained above. This should be replaced by calling static methods of those views instead, providing the buffer and offset of the required data in parameters, but I don't see a valid solution to the issue mentioned in the previous section. I actually wonder, if those view objects, which are instantiated with the view itself, will be in the same page (virtual memory) and thus have similar cache efficiency as passing parameters via stack, because the view object will be referenced anyways and thus its page will be in the TLB already.
  2. Views for Arrays: For arrays with a structured component type (e.g. Struct[]) the view currently dynamically instantiates a view instance to encode/decode the array elements on demand. This can also be solved via static methods instead, or with member fields for each of those types.
  3. Code Efficiency: Generated code is not well optimised by now. Just a reminder.
  4. User Implemented Views: The code generator considers user implemented code when provided through an annotation of the respective member field. This feature is not final yet and was mainly introduced to support problematic types such as Java boolean, which does not have a defined size in memory, or Strings, which require to determine its size based on a null terminator and consideration of different character encodings or all the boxed types which are classes representing scalar types etc.. There can be standard views for certain types but actually its a bit questionable whether it is worth the effort to implement them. I'd rather provide tools to ease implementation of those views.
IDE Integration
Currently there is a basic implementation of a plugin for Eclipse. It is basic in the sense that it does not use the abstract syntax tree features of Eclipse JDT and therefore lacks support for marking errors in the code of a struct type declaration (e.g. in the editor). If possible, the code generator will be integrated deeper, but still kept independent to allow its use as standalone tool (e.g. command line or Ant Task) and integration with other IDEs.