make the build hints available

[ddyer0]

make the build hints actually used to make a binary available from that binary. According to claude, it's only
available in the simulator.

[shai-almog]

What?

[ddyer0]

it would be nice to see exactly what was used when pulling an old build from my archives, or anew build that needs vetting.

[shai-almog]

What archives?

[ddyer0]

i have dozens of past versions from points of stabiliyt,but only the build dates to link them
to your build versions. Going forward it would be nice to better.

[shai-almog]

These are versions you have locally on your machine? I'm struggling to understand how something like this would look in terms of Codename One usage.

[ddyer0]

when i release new versions, every week or two, I keep a debug build and the release build.
When something goes wrong I can refer back.

[shai-almog]

You can keep it with the codenameone_settings.properties matching that version.

[ddyer0]

that would provide information about what I thought, but not a out what was actually true.
Cases in point are the recent switch in the default for metal, and the important date when you switched on the parpavm update.

There have been other cases where you introduced a feature, or a bug, and it would have been useful to determine after the fact what releases were affected, or, working the other way, to see which release introduced a problem so that could be correlated with your commits.

[shai-almog]

Both won't work from our side. Build hints are pull. You can do codename1.arg.dave=true and it will work. The build hint only applies when a builder reads it. So you won't know if we used this or that. So whether metal is on or off you won't know and actually neither would we really. The version of the VM is just jars packaged into the build (which allows for versioned build too). No build hints apply unless it's a versioned build in which case...

The timing of a server updat and what exactly goes there is a bit more complex and probably won't help you much. You can use includeSource and keep the final result which will include most of what you need to know.

[ddyer0]

I guess my request is that you leave some forensic information that's automatically incorporated into your builds.

[shai-almog]

That's reasonable, we did have a versioning system in the past that included that information at the top of the log you'd print but that went stale. Build hints would be problematic within the binary as it might violate privacy and cause security issues. We could give them back to you as a release file, but you already have them so that would just be overhead. In the past we wanted to have a build "archive" tool that would let you keep builds with information of that type. But that was logistically problematic in terms of UX/management and benefit.

[ddyer0]

I also wish for some minimal stats on the heap status and garbage collection.
something like current heap size, heap size after collection, number of collections.

[shai-almog]

Well the build server can't offer that but we might be able to expose some VM metrics you can expose in your application UI.