Posted by
Kenneth Sloan-2 on
Oct 27, 2017; 5:30am
URL: http://imagej.273.s1.nabble.com/PolygonRoi-getContainedPoints-tp5019614p5019620.html
Curtis-
Thanks for the pointer. In the last hour, I think I’ve verified that my problems have to do
with keeping a private copy of ij.jar.
I’m on the road tomorrow, but have some free time over the weekend.
My problem is that I’m supporting a fair number of legacy java plugins written by a long
string of students over the years. I have “retired”, which essentially means that
student support has disappeared and there is now ONE programmer on staff (that would be me).
Oh yeah…most of my “customers” use Macs (as do I) - but a couple of very important
collaborators use WinDoze machines. I have only a virtual PC, which I *only* use to make the final
compile to distribute .jar files for PC users.
So…I’ve tried to keep it simple by cutting and pasting and following the (not always
perfect) decisions made over the last 10 years by that long string of students… One of
thoses decisions was “ant”. I have no idea if it’s a good solution - but I’m reasonably
competent at editing build.xml files and following along blindly. Except for the
times when things like the cached ij.jar file leap up and bite me.
I suppose I need to bite the bullet and pick a new development/distribution environment.
I can leave the stable plugins in the old system, and build new plugins in
a brand new environment.
Oh yeah…did I mention that I have EMACS in my fingers and develop most of my stand-alone Java programs
using the old faithful “javac *.java”? 20 years ago I was a makefile wizard, but no longer.
So…I find myself stuck between two worlds. I have never warmed up to modern IDE’s - but
that’s probably based on lots of bad experiences with very early attempts. In most of my (non-ImageJ)
Java development I’m a big fan of lots and lots of sharing and duplication of SOURCE code.
90% of the code in my projects is code that I have written - and it is all always subject to
constant tweaking - even at the cost of multiple versions. When I re-use other people’s code
I always prefer SOURCE code that I can modify to suit my needs.
Time to learn a few new tricks, perhaps.
Anyway - I think we’ve solved my API problems. In the short term, I’m happy with my workaround.
It actually looks like one of those methods which is simple for the user to write, and therefore
doesn’t really need to be cluttering up the API. It was only a few lines of code, which I was
prepared to write…until I chanced to see the getContainedPoints() listed in the API. That
looked like it would save me a half an hour. Didn’t turn out that way. But - no harm.
The plugin under development is working and ready for customer testing. I have two more on
the drawing board.
I’ll probably try to “fix” the current development environment (but only minimally)
- and then bite the bullet and start doing all new development in a new environment.
So - here are the constraints:
a) the editor *must* be EMACS
b) final products are .jar files for Mac (all testing done here) and WinDoze (delivery only)
c) just for grins…some of my “customers” use things like TrakEm, which they claim imposes
restrictions on exactly what version of Java they can have installed on their machines.
I don’t know how real these constraints are, but “the customer is always right”
d) we’re talking relatively small programs - a few hundred lines of code at the most.
e) Java only - no “scripting language of the month”, please.
I’ll check out your suggestion. I appreciate the help.
--
Kenneth Sloan
[hidden email] <mailto:
[hidden email]>
Vision is the art of seeing what is invisible to others.
--
ImageJ mailing list:
http://imagej.nih.gov/ij/list.html