RomRaider

OK, poking my head around in the logger dir tonight and I see XYZConnection XYZConnectionImpl

This in itself is maybe just slightly bad taste, but, the trouble is, there isn't one interface and N implementations, there is an interface per implementation. This kinda defeats the purpose of interfaces. They all look to be the same, though, so far at least, so it should be easy to fix. I might make that one of the first things that I attack when I start actually coding. Just noting it here so that I don't forget.

I spoke too soon, only a few have this, others don't have it at all. Still, there are at least three duplicate file sets there. The connections are also identical, not just the interfaces. I need to dig more before posting :-)

Dale, something you can just start doing, as you go, put the final keyword in front of virtually everything you can. Local vars included. If something is assigned only once and then read thereafter, make it final. With a thousand changes like that, there will be a measurable performance improvement. Just start coding that way, though, no need to go hunting for instances :-)

That I do try and do wherever feasible.

Good to hear! :-)

Disconnect doesn't. And by that I mean, if the connection is trying to open/initiate/etc (i chose innovate) then it will keep trying irrespective of disconnect clicks/selects.

OK, logger thing = plugins dir doesn't have plugins, it just has class names. That can be done without a directory by reflection, or possibly even more simply. If we do it really nicely, it could literally be a plugin arch where you say "open new plugin" and user just finds their jar that they built, and RR loads it and scans the classpath and lists it as an option in a panel. Then stuff could be selected/deselected etc without a directory driving it.

OK, we need more organised handling of plugins. We need external ones to be stand alone, and not require a subaru connection. We need more control over what runs/what doesn't, and what gets what device/port. Currently the subaru stuff is greedy and also doesn't handle disconnect well. I guess it's time to start making some actual changes to the source to facilitate more generic use of the app.

Disconnect "button" disconnects the ECU connection but does not disconnect the plugin connections. To stop a plugin connection you need to un-select that External Sensor to tear down it's connection. Something I haven't yet fixed. And I agree the plugin stuff needs work.
OK, everything needs work...

Why not start from scratch

Well, it would certainly be easier to gut it for my purposes, but I'd prefer to try and offer some benefit to you lot in the process :-)

Step by step :-)

Once I get into the sources and start making changes, expect some to be fairly drastic. In a lot of cases it'll be "works the same, less lines, cleaner, more flexible" etc. IE, no change, just source churn.

In other cases, like the logging plugins, the semantics and operation need work.

Speaking of which. Please start thinking about more user feedback. I mean, instead of logging stuff (only) display it (and log it too, if you must). Let the user know what is going on where possible. I'm just saying think about it. Not do anything. I see a lot of "i have an issue" - "record a log" - "here's the log" - "this is wrong". It'd be nicer if the app just said to the user "this is wrong", would save you time too :-)

Fred.

A lot of classes have a lot of class variables and a lot of functions that have no argument and return nothing. This is effectively global variable use and bad for (i hope) obvious reasons. We should aim to avoid that in future and rework existing stuff to not work that way. It's also not very unit testable. Unit testing drives good (or at least better) code structure, so once I have it mavenised I'll likely start by doing a bit of refactoring and adding a few tests.

It confuses me at times too.