Here I am - Dirk Scheffler - An Open Source Architect and Inventor

[tryptamic]

Hi quarkus community,

It is a pleasure to introduce myself to you. I am Dirk and I am an inventor, software architect and developer. I have experience with a quite some programming languages and survived in a proprietary company environment for the last 2 decades. In that company we developed a GenericModel technology for Java and Typescript that was recently open sourced. I was and still I am part of the core team concerned with invention, architecture and also implementation. The GenericModel technology could make an impact on the community after it was hidden in the proprietary context for so long. Quarkus seems to be a match to start that journey.

We love to see that quarkus strives for performance and impact. We believe that our technology could prepell the impact of quarkus even more.

I would love to get in contact with the core team and designers of quarkus to discuss the opportunity.

If you are interrested in the technology you may find some helpful initial information here:

• Introduction to the GenericModel Invention (PDF)
• Relevance for Distributed Computing (PDF)
• Github Organization of our Technology

[maxandersen]

Hi @tryptamic - thanks for reaching out - I did go and mark your two other posts as duplicates. one thread per topic is enough :)

I took a look on the links you shared and I'll just be very honest - I found it hard to grok what hiconic-os actually do and how it fits.

I tried follow the setup and guides but it just all felt very alien, complicated and very non-transparent - and I frankly don't feel comfortable running this on my machine not knowing what it does :)

If you could possibly give a simple explanation of what hiconic-os does and how it would/could related to Quarkus that would help :)

thanks

[tryptamic]

Hi @maxandersen, thank you for your honest reflection and I can understand the difficulties. So let me try it to give you some explanation here and please ask further question if the value seems still hidden.

hiconic-os is a codebase with a lot of code that evolved around a type-system extension to Java based on interface definitions that represent Java Beans (Pojos). That type-system is our invention and the core value of this codebase. It offers a way to describe models for business, services, configuration and any other purpose. The interfaces are automatically implemented by a runtime compiler using java bytecode instrumentation. This compiler also generates a lot of extra value in form of an elegant highspeed reflection and aspect oriented programming features. Especially the highspeed reflection strongly supports generic algorithms like in marshallers or cloning algorithms and many other stuff. In that sense you find fast marshallers for JSON and YAML in the codebase that would also prepell quarkus. I assume that quarkus relies on marhsallers based on slow Java Reflection. So the power of this typesystem is strong support for expressive access on properties as well as generic access on properties. In most systems one of these aspects is weak.

The codebase also contains build tooling written with that type-system and a distributed application platform with a module system also based on that type-system. There is also very powerful in-memory OODB using this technology in the codebase that even supports join queries and event sourcing. There is a service stack that is also used in the platform for modeled services. This service stack has a very fine way to define and expose services via web apis or message queues just by models of that type-system. One guy that worked with our platform and now with your system honoured your agility and mentioned that he loved the way our service stack works and that he misses that in quarkus. Also our build pipeline for Github was made with the service stack. Another value in the codebase is our wire library which is a very powerful IOC library that goes beyond spring in many ways and is a great basis for modular systems that allows modules to share their features via wire interface contracts. I think beside many others these are the core values that quarkus could profit from:

• interface based POJO type-system for models with highspeed reflection
• fast marshallers for JSON/YAML
• service stack based on service models for requests/responses and payload
• wire library for powerful IOC
• event-source in-memory OODB

All these features are coded with strong SOC in mind so that these features can be easily wired in new contexts. All these values and our experience could be used by quarkus to make an impact.

The getting started guide that you maybe saw lets you setup a development system based on our tech with wich you could also build models and modules for the platform I mentioned. But that is not required. It makes more sense to talk about the power of the libraries and how they could be harnessed by quarkus.

The alienation you had is understandable because that whole codebase evolved in a proprietary environment. But that alienation should not hinder us from sharing the value. We would be ready to adapt all possible aspects in order to move it into an impactful usage. All the libraries are exposed as maven artifacts that anyone can use.

In order to let you respond I don't dive deeper but rather let you drive the further direction. I certainly would also make sense to talk because that maybe could better transport the value

[maxandersen]

Thanks for providing some more context.

I still won't say I fully grok it but I don't like to be dismissive when I don't fully grok things :)

A few thoughts:

Where is the examplrary helloworld ?

Sounds like you describe something akin of protobuf in context of a declarative way of describing models for serilization ...but then you mention services/configuration and more ... can you possibly provide a simple example of how it looks compared to a quarkus or some other app? I tried finding like the helloworld quickstart we have (its not just println hello world but sets up a simple rest endpoint for example) but I did not suceed - all I found was very verbose/complex examples that didn't feel like it bring much developer joy?

Compilation vs runtime reflection

You mention a compiler but also efficient runtime reflection and aspect oriented programming ... dependent on what you've done here these feels like counter to Quarkus approach of doing as much as possible at build time and then at runtime limit reflection or at best completely remove it - can you elaborate a bit?

fast

you mention fast marshalling - got some numbers? tried to compare with quarkus qson?

[tryptamic]

Thank you for your feedback and continuation on discovery. I will try to respond to your points the best I can:

1. Hello world

In order to better approach you, we will build a little microservice REST endpoint that hosts an arbitrary service module of our kind and a concrete example service module along with its model. We plan to do the same case with quarkus to have some comparable scenario. That will take a little bit of time but it will best show the tech in the context of quarkus and alike. Until now we had a modular platform that comes with a reflected modelled configuration which has its own value but does not fit to best prove value for quarkus. Thus we want to show agility and the ability of the tech to adapt to scenarios with different accent or purpose by building this example. In a next step we would love to show how such a service can be very easily projected into a command line endpoint instead of a rest endpoint so that you see the portability aspect of the whole service approach. You could imagine a message queue based projection as well.

1.1 Comparison with protobuf

Marshalling/Serialization is just one of many interesting usecases for generic coding and its reflection requirements. Our goal was to refine what the Java community was using all the time in frameworks like hibernate, spring, velocity, serializers, etc. The refining happens on declaration level using interfaces that are open to multiple inheritance but also on reflection level where we want to be convenient, efficient and to the point. Lets say we turned a crude but omnipresent principle into its consequence and we discovered that from this refinement a new and more clear perspective on the separation of domain specific and domain agnostic coding arose. From that point on we touched many areas with that approach and could generate a lot of value. It would take some time to reflect/discover this value. So for the moment it may be better to not broaden the picture but remain on that inner most conclusion to understand its definitive impact. But one central conclusive value of this new type system approach is our approach to services based on models. This is definitly a value that quarkus should recognize early as it would justify the investment. The planned example should highlight this.

2. Compilation & Runtime Reflection & AOP

Our entity types are declared with interfaces that are POJOs. They are automatically implemented. This process could also be understood as compilation but implementation may be a better term here. This implementation is a very straight forward simple process as the implementation of getter/setter and reflection parts is very simple and short and repetitive. Bytecode generation at runtime is currently used in the Java scenario to generate this implementation. But the principle is not restricted to this way of runtime implementation/compilation. We used the same interface definition in a GWT environment and there we implemented the interfaces with Java source code generation at GWT compile-time. So it is important to see the idea of interface based declaration and automatic implementation rather than the time when this happens. In this sense it can be adapted to the requirements of a scenario like the GWT case shows.

The second thing is the reflection which is also a result of the automatic implementation. It needs to be distinguished from Java Reflection as it has to support a very limited set of features because entity types are a much more reduced principle compared to all purpose class reflection. The implementation of this reflection is straight forward just like the implementation of the entity types themselves. The whole purpose of this reflection is to support generic algorithms. While domain specific developers access entities via getter/setter a coder of a generic feature like cloning, marshalling, cross cutting concern (domain agnostic) can access entities via this reflection which has not the downside of the bloated and very indirect Java Reflection. Such domain agnostic algorithms are to find in any modern framework. It especially supports framework related aspects while the classic getter/setter access is for actual application building. The extra costs of having this reflection available is small due to its limited scope and context. As this reflection is part of the automatic implementation it can be generated at compile or runtime. If we find that the general approach is worthy and quarkus requires compile-time implementation that we could discuss to make the approach from our GWT compilation available for java in general. Most importantly I am sure that you want to keep this reflection feature once the importance for technologies like quarkus could be sufficiently transferred.

The AOP part is there to give the entity type implementations even more power to address another kind of genericity as it is achieved with plain reflection. We have 2 forms of AOP available that are of interest from quarkus perspective. One happens on the entities and the access routes of getters/setters. There are various usecases for this like ManipulationTracking which is very valuable for collecting incremental information about data change to support usecases like event-source databases. Another form of AOP happens on our service stack where we do not only have ServiceProcessors but also ServiceAroundProcessors, ServicePreProcessors and ServicePostProcessors. Based on the strong normalization of the function principle of ServiceProcessors the AOP variations of it are very powerful and easy to bring into the service stack. Both AOP form are not really a good candidate to things like AspectJ because it addresses AOP in a much more precise way and does not require further compilation technology.

3. Performance

As I don't know enough about qson and the way quarkus makes use of it I rather be hold back with my original claim. This claim was based on the assumption that a serialization framework is used that uses Java Bean Introspection for POJOs from Java which is based on expensive Java Reflection. The Bean access of Java is the crude solution for genericity on beans compared to our refined solution on that matter. Java Bean introspection is awkward and slow and also takes bootstrap time. So in order to get real data we could use the example from point 1 to make comparisions. We will have a model for the use case of this example and we will have to have it for quarkus and for our tech. We can then benchmark the situation.

I always offer a talk where we could elaborate the general purpose and importance of every aspect

[tryptamic]

Hi @maxandersen,

As promised, we created a modular platform called reflex for modeled microservices based on our core paradigms and technology to address the mentioned points.

• Hello World Web App with automatic REST endpoint
• Demo Web App with automatic REST endpoint using the demo-rx-module
• Demo CLI App with automatic CLI endpoint reusing the demo-rx-module
• simple validation crosscutting module
• README.md introductive documentation
• tools within our devrock sdk to create modules and apps

You can jump into it here: https://github.com/hiconic-os/hiconic.platform.reflex

We continue to work on reflex as our own feeling about this initiative is very good. Thanks to your trigger, reflex can show our paradigm much easier as our cortex platform which is way more reflected using deployment models but comes with a greater entry barrier and also is not suitable for small services.

[tryptamic]

@maxandersen did you see my post?