Back to the future... java 1.4 re-integrated

I'm currently in the process of re-supporting java 1.4. So, retroweaver was my first choice, and it appears it works quite well (I've already been able to use pydev in 1.4, but some testing is still needed), so, next week (maybe monday), I'll probably release it.

Well integration from the retroweaver perspective is quite easy, but from the eclipse perspective it is quite horrible (not difficult, but horrible). This is mostly because of the runtime environment that eclipse has now, that for me, basically sucks...

What they did is create a classloader that gets only things that are in the plugin or in dependent plugins in the 'allowed' packages... the problem is that by doing that, they just cut off all the good 'reflection' things java provides (that are actually not quite so good, if compared to other languages, such as python).

This means many things:

1 - I just can't serialize anything that has some structure from another plugin if I'm not dependent on it' which basically does not allow for any serialization utilities... in my case I had a core package that had it, and I basically had to copy it to all the places that needed it... just the opposite of reuse hum???

2 - In the retroweaver case, initally, I just did a plugin, added it to my core plugin and re-exported its dependencies... pretty simple and elegant, right? Well, that's what I thought, untill I saw that it needs to be able to do a Class.forName after the bytecode enhancement, but for that to happen, the retroweaver plugin must be dependent on all the plugins that are dependent on it, because of the *&(^%$ eclipse runtime environment... so, I had to copy the retroweaver jar to each plugin and add it to each build, etc, etc... which basically is really, really ugly to me... as I said, just the opposite of reuse...

There are way to many use-cases for me to list, so, I'll stop rambling here... it's probably kind of late to complain about it... I do understand the problem the eclipse guys had, which is: people were using their not 'public' classes, but instead of just saying: don't use it, they just did a horrible implementation of a runtime environment (don't get me wrong here... eclipse has many great things, but on this, it just sucks)... That's what I love about python... everybody is grown up, so, if I say something is private, you can still see it, and even depend on it, but you're warned, it may not be there next time, or it might not have what you expect, so, just don't depend on it (we're all grown-ups, right?). By doing what they did, they don't really enforce anything, as bad programming can happen everywhere (just copy and paste from the private code), what they did was preventing really good programming from happening.

I think that if they really wanted to try to enforce something, they should have marked their things they didn't want anyone to use as private (and let it as public for default)... eclipse 2 was so much better at this...

Wow, big post...

Cheers,

Fabio