<AWT Dev> Accessing internal packages in JDK 9
mik3hall at gmail.com
Tue Jul 28 21:21:51 UTC 2015
> On Jul 27, 2015, at 3:15 PM, Simon Nash <simon at cjnash.com> wrote:
> It is hard to provide a definitive list of all the internal packages that
> I need because the list tends to grow each time I use additional Swing
> functionality in my application.
This does remind me of some code I had a while back.
I was looking for a Save option for my Swing application on OS X for the Aqua L&F.
I was a little familiar with serialization at the time and it would of been nice if this just could of just been usable for this function.
Aqua was not serializable.
I wrote a custom ObjectInputStream and a custom ObjectOutputStream that would make substitutions for classes that weren’t serializable.
The substitutes wouldn’t restore the objects on the unmarshall but instead would construct new instances, via reflection I think, been a bit.
I got this working for my application as it was.
Of course, any changes to the gui uncovered new internal Swing platform specific code that I hadn’t mapped substitutes for.
So as you mentioned very breakable and brittle. I think I remember using that very word years back. Brittle.
What I thought you would probably need would be a more automated tool that could map and generate suitable substitutes for the entire api.
Would be nice huh? Make virtually any code serializable and less brittle than serialization itself since you wouldn’t be restoring some possibly out of date version but instead constructing a new instance with the latest version of the class. Subtle differences between the old and new versions would probably still have weird side-effects sometimes.
Never wrote that though.
The other mega-meta tool I never really completed was one to automatically generate native bindings. Based off of Apple’s old JDirect. Put even more time into that one but without a really comprehensive tool it was impossible to keep up on all the native api’s. Another maintenance nightmare.
(Another might of been writing my own zip filesystem. Not quite as mega-meta, but it worked in a slightly limited way, not all java.io classes implemented, until class loader changes in Java 6 broke it. I based my own little IDE off of it. javac worked fine with it to compile directly to zip files.)
Ah, messing with that code was good times.
I see you moved this to jigsaw. Seems like the dependency and other tools might be along these same mega-meta lines and be something you can use. Maybe I’ll revisit mine sometime with them, they might just make that work?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the awt-dev