Re: Modeler (modest) ambition

Thanks for sharing and I agree.

I may try it one day, and maybe I'll change my opinion. Though I am =
still not convinced JavaFX is the way to go. So for now using the new =
superpowers to clean up the existing code base. Even if we decide to go =
JavaFX later, a unified architecture will be a much better starting =
point for such a migration.

My recent commits flood is the movement towards that goal :) Getting =
there, but hitting the 80/20 rule: the last 20% of functionality is =
taking 80% of the time, despite Claude. It can do massive refactorings =
but when instead of a single pattern, you are dealing with 6-8 =
variations for any given problem, it easily goes off the rails.=20

Andrus


> On May 2, 2026, at 10:01=E2=80=AFAM, Robert Zeigler =
<robert.zeigler-hCtwD0fs3SdWk0Htik3J/[email protected]> wrote:
>=20
> I haven=E2=80=99t done Java for a long while=E2=80=A6 and swing is =
probably not the best represented in LLM training data these days. But =
FWIW, I recently migrated some of our backend services from flask to =
fastapi with Claude, and while it wasn=E2=80=99t one-shot=E2=80=A6 it =
wasn=E2=80=99t far from it. I=E2=80=99ve also experimented with =
migrating some of our tornado-based services to fastapi, and they worked =
well, as well despite the frameworks being much more distinct than flask =
and fastapi  A migration from swing to electron would be more =
challenging I think, but migration to JavaFX might be possible, if you =
want to ditch swing. Not saying you should=E2=80=A6. Just saying=E2=80=A6 =
if you fire up a branch and give it a whirl, you might be surprised with =
how far it gets you.=20
>=20
> Robert
>=20
> Sent from my iPhone
>=20
>> On Apr 26, 2026, at 6:59=E2=80=AFPM, Andrus Adamchik =
<[email protected]> wrote:
>>=20
>> =EF=BB=BFI can tell one thing... While any serious Modeler work still =
requires effort and thinking (Claude or no Claude), fixing minor bugs =
that annoyed us for years doesn't. They are just one-shotted from a =
single prompt. The whole refactoring that I am currently doing only =
helps a human to understand suggested fixes. But the agent can do them =
over the dirty code just as efficiently :)
>>=20
>>=20
>>> On Apr 24, 2026, at 2:08=E2=80=AFPM, John Huss <[email protected]> =
wrote:
>>>=20
>>> Sounds great, I love these ideas!
>>>=20
>>>> On Mon, Apr 20, 2026 at 9: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
>>=20