Re: Modeler (modest) ambition

> Gave the updated CM a quick tour and it looks good so far. I'll do a =
bit
> more testing later.

Thanks Mike!

> When you talked about Java 21 on User, you weren't kidding. I had Java =
25
> and it will not build with it. Had to re-install 21 to try it.

This is due to Gradle. My next suggestion was to discontinue Gradle =
plugin support. Probably need to post this on user@.

> Seems the model files upgrade is still done on the filesystem instead =
of in
> memory, so you have to revert 4.x model files (hopefully you have them =
in
> Git/etc) after loading into 5.x CM. Is there a reason the upgrades =
aren't
> done in-memory so you don't mangle the original version?

Yes - a technical difficulty of keeping track of what needs to happen on =
save later (like deleting some leftover files, etc.). This is not =
insurmountable, but version-control based rollback option looked =
sufficient, so we never bothered to address it (this behavior existed =
across all versions IIRC).

Andrus


> On May 13, 2026, at 10:46=E2=80=AFAM, Michael Gentry =
<[email protected]> wrote:
>=20
> Hi Andrus,
>=20
> Gave the updated CM a quick tour and it looks good so far. I'll do a =
bit
> more testing later.
>=20
> Two notes:
>=20
> When you talked about Java 21 on User, you weren't kidding. I had Java =
25
> and it will not build with it. Had to re-install 21 to try it.
>=20
> Seems the model files upgrade is still done on the filesystem instead =
of in
> memory, so you have to revert 4.x model files (hopefully you have them =
in
> Git/etc) after loading into 5.x CM. Is there a reason the upgrades =
aren't
> done in-memory so you don't mangle the original version?
>=20
> Thanks,
> mrg
>=20
>=20
> On Mon, Apr 20, 2026 at 10:24=E2=80=AFAM Andrus Adamchik =
<[email protected]>
> wrote:
>=20
>> So I feel like the advent of agentic coding opens up new =
possibilities for
>> CayenneModeler. While some want you to think you can simply prompt =
Claude
>> to "Rewrite CayenneModeler in JavaFX" (or Electron or JetBrains =
Compose
>> Multiplatform), still with our limited resources, building and =
supporting
>> an entirely new thing is realistically out of reach.
>>=20
>> But I think we can take the current Swing app to a new level by =
augmenting
>> our rusty Swing skills with AI. A few of my experiments adding this =
or that
>> UI piece were mostly successful. A few idea on top of my mind:
>>=20
>> 1. A built-in MCP server for DB Import and CGen. This is to close the =
loop
>> on agentic coding, allowing to use both of these tools from an agent =
CLI.
>> (The MCP idea was what prompted me to look into this to begin with)
>> 2. Fix table editors UX (selections conflicting with cell editors)
>> 3. Write unit tests
>> 4. Modernizing L&F. Not sure how far we can get while staying in =
Swing,
>> but worth a try. Looking at FlatLaf lib, which is a successor of =
JGoodies
>> that we already use
>> 5. Implement dozens of small usability features (such as showing =
currently
>> selected Obj|DbEntity in tab view headers, etc.)
>>=20
>> My first pass (about 70% done) was not anything visual, but rather
>> refactoring the existing messy code to rid it of various =
architectural
>> experiments accumulated over the years (such as auto-bindings) and =
unifying
>> the MVC structure to be as close as possible to vanilla Swing. =
Ironically,
>> Claude was not that helpful in this process. It was good old IDE
>> refactoring, manually going through hundreds of files chasing dead =
code and
>> inconsistencies.
>>=20
>> Anyways, just putting this on the radar.
>>=20
>> Andrus