Roadmap to JUnion 1.2.x: Info, features, bugs

[TehLeo]

General information about this project on its website.

Status of JUnion 1.2.2:

JUnion 1.2.2 EA (Early-Access) is now available here

List of changes:

• can allocate struct arrays on heap, off-heap, stack, the syntax uses annotation, eg:

Vec3[] arr = new Vec3[10]; //default currently allocates on heap
Vec3[] arr = new @Heap Vec3[10];
Vec3[] arr2 = new @Direct Vec3[10];
Vec3[] arr4 = new @DirectBuffer Vec3[10];
Vec3[] arr5 = new @Stack Vec3[10];
Vec3[] arr7 = new @Heap(ArrayType.Byte) Vec3[10]; //underlying data is Java byte[] array

• the underlying storage can be retrieved as Java array/Buffer with Mem.getJavaArray(arr) and Mem.getJavaBuffer(arr)
• added StructType class, which can be used to find information about a struct
• added StructList, which serves as a resizable struct array, it stores its elements as data not as references (not yet finished)
• Array allocation is done through ArrayAllocator interface and can be customized by the user if needed
• Bridge interface serves as the link between the application and ram. The default bridge interface DefaultBridge uses Unsafe to read and write memory.
• added MemInit class which stores related settings, such as setting the bridge interface, allocator interface to use, etc.

Left to do:

• create detailed test cases
• finish writing StructList collection
• add collection which stores references to structs instead of the data, eg. RefList
• add various utility methods to Mem class
• expand StructType, ideally add reflective access to struct types
• Allow specifying byte order for struct types (currently all are native-order)
• Allow specifying unaligned access for struct types (currently all use aligned access)

What can be done:

• for java 9+ can implement VarHandleBridge, which will use var handles instead of Unsafe

JUnion 1.2.2 brings almost complete redesign of the system. The result of which will be support to allocate struct types on both Java heap and off-heap. Since many APIs require the data to be present in either a primitive array or a java.nio.Buffer, if JUnion did not support modifying either as a struct, then the programmer would have to resort to copying the data to suitable format, which would result in diminishing or completely negating the benefits gained from using struct types. By being able to allocate struct types with a backing primitive array or Buffer or off-heap this can be resolved.

In JUnion 1.2.1 and before, an allocated struct array implemented automatic memory management. During finalization of a struct array, the underling memory was freed. Indexing into the struct array resulted in returning pointer to the struct as a native address represented by type 'long'. To keep using the returned pointer it was necessary to keep a strong reference to the allocated stuct array, because otherwise the GC can finalize it and the memory will be freed. In JUnion 1.2.2, this problem has been addressed by representing struct pointers as 'long' and a reference to struct array.

One of the common data structures is an ArrayList which supports resizing. A support for resizable collection is planned.

JUnion 1.2.1 pre-release is out.
This topic is to present the status of JUnion 1.2.1.
You are welcome to post feature requests / report bugs.
The plan is to accomplish the tasks below(some or all), and release JUnion 1.2.1 iteratively as features/fixes are completed. Later, after some proper tests, the new version will be added to maven, etc.

Current features are listed at https://tehleo.github.io/junion/features.html

Planned features:

• - multidimensional arrays

Fixes/Other:

• - fix path issue
• - fix class fields & initializers are not compiled with junion
• - fix increment/decrement operators on fields in a struct
• - fix assignment operators on fields in a struct
• - update eclipse ASTParser to JLS12

Tests:

• - check support with Java 11
• - check if java modules work correctly

[jDekx]

As 1.2.1 is out, will you publish this version to the maven repostory? Thanks.

[TehLeo]

Hi, version 1.2.1 is indeed out, but as a pre-release. Since, version 1.2.2 will be shortly out, I will publish to maven, once I also wrote test cases. Also version 1.2.2 is now optimized for Java 9+ as well.