Hi, >Sure. I'm just questioning whether the benefits of a custom >implementation really are worth the time spent reinventing the wheel >and fixing all the inevitable bugs.
Yes. In fact, I believe it is actually much better to re-write the few JSON specific methods we need than trying to cobble together existing libraries with new code (trying to combine an existing JSON parser / builder with some self-written JSOP parser / generator), because that will inevitably lead to problems. It actually already does (see "TODO ugly hack", plus it's currently not possible to store the JSON as is without de-escaping). >My bigger concern here is that the JSON handling seems to be happening >at a way too low level. Yes, I'm working on this problem now. Please note it will still be necessary to parse the keys and some of the values. It is a low level to do that, and possibly we will end up replacing JSON with a binary format (such a BSON) if we find out it's really worth it (for performance or other reasons). But one advantage of using JSON (if nothing else) is that it's actually very easy to debug the code, which is very valuable at this stage. >both MicroKernelImpl >classes in o.a.j.mk and o.a.j.mk.mem duplicating pretty much the same >parsing and serialization logic. Can we refactor that code into a >single class/location? Sure, the plan is to merge that. I didn't want to overwrite Stefans code (at least not before I really understand it), that's why I didn't even try to merge things currently. Regards, Thomas
