The best javascript engine ever — OZONE Asylum, home of the Mad Scientists

DHTML/Javascript

The best javascript engine ever

This page's ID: 28037

Edit Post

Who can edit a post?	The poster and administrators may edit a post. The poster can only edit it for a short while after the initial post.

Your User Name:
Your Password:
Login Options:	Remember Me On This Computer

Your Text: Insert Slimies » Insert UBB Code » Close Last Tag \| All Tags UBB Help	[quote] [b]_Mauro said:[/b] Well, astoundingly well, which puzzles me a bit. For instance, make sure you have a recent JVM, and google "jogl", then hit the demos, any of the demos, especially the one which integrates several openGL contexts in Java swing subwindows. Granted, the c components / Java components talk is controlled by the VM, but... what you have there is a Java class which will call the right dynamic library depending on the OS, and will talk through it to the gfx hardware using OpenGL 1.5 specs: it's stable as hell.[/quote]I don't doubt that, I've heard people with far more experience of graphics handling than I say JOGL is really good. (Graphics never were my thing...) JOGL is controlled by the Java garbage collector, but performs manual C style memory management for the OpenGL API, right? At least that's how I've gotten it explained to me. Now, I'm not saying COM couldn't be handled through a similar API in Java - and I think Mozilla has this problem mostly solved for Java interaction with XPCOM. However, the difference between JOGL in Java and COM in JScript is that there's no compatibility layer in between in the latter case. There's no wrapping of the COM object handling in a native object. If you attach a JScript event listener on a COM Element object, then you are adding a Function object from the JScript object space as a direct property on the Element object from the COM object space. As I understand it - and I admit I may very well have this wrong - in the JOGL case only the JOGL library directly interfaces with the OpenGL memory handling. All objects you as a user of that library handle are controlled by the Java garbage collector. Since the crossing of the object space border is so narrow, only the library code has to actually deal with that object space and thus the memory management is localised and references are easy to keep track of. But how do you deal with it when every other object you're handling is governed by another garbage collector, when that garbage collector uses refcounting and lacks cycle detector? How do you deal with it when it's not the Java DOM you're dealing with but an external DOM implementation? Again, I'm not saying Java couldn't deal with it better than JScript does today, I'm just saying that the solution to the problem is largely the same for both languages. Either you eliminate the object space crossings, or you make sure garbage collection with cycle detection works in all object spaces as well as across the border. Either one-GC-to-rule-them-all or many-GCs-all-cooperating. What you have in iew today is the many-GCs-not-fully-cooperating situation. If Microsoft ported iew to .NET, then they could go with the one-GC-to-rule-them-all solution, at the cost of backwards compatibility. Or they could just continue on with the current many-GCs-not-fully-cooperating solution and keep backwards compatibility, fixing host objects as they go by adding cycle detection in the iew hosted COM environment. Eventually they'll have fixed the entire browser host, then all you need to keep a watch out for is non-browser-host COM objects. [quote] And to be precise, and maybe give you a bit of a challenge and interesting paths to explore, there is no real "delete" operator or the likes in Java. In facts, destructionis almost never explicit in Java (ok, variables can be explicitely nulled out, the system gc can be tickled, etc.. but no real destruction occurs).[/quote]Yeah, it's one of the problem with the C# and Java memory management systems as I see it. Timely destruction, even if you have to make it explicit, should if you ask me be absolutely required of any exception based language. It's what makes the RAII design pattern possible. It's maybe not necessary for a language like JavaScript that doesn't even deal with threading, I/O, OS API calls or database integration in the most common host. But it does makes for very much more elegant error handling and rollback systems for those types of features than if the language lacks timely destruction. Oh, and if you noted - the [b]delete[/b] keyword in JavaScript has nothing to do with the same keyword in C/C++ either. The only thing it does is to remove a property from an object. Might not even do that, in the JScript engine I believe all it does is set the property to undefined and prevent enumeration by flagging the property as deleted. -- var Liorean = { abode: "[sigrotate][url]http://liorean.web-graphics.com/[/url]\|[url]http://codingforums.com/[/url]\|[url]http://web-graphics.com/[/url][/sigrotate]", profile: "[url]http://codingforums.com/member.php?u=5798[/url]"}; Loading...
Options:	Enable Slimies Enable Linkwords

« Backwards — Onwards »

Show Forum Drop Down Menu