Is java.lang.ref.* functioning in GWT? I come to an idea that
java.lang.ref.* is necessary to enable proper garbage collection while
implementing the Observer pattern in Model View Controller.
You can't use java.lang.ref on the client side, because JavaScript has no notion of weak, soft, or phantom references. You can however use the java.lang.ref package on the server.
If you need to release objects on the client side, it is best to do so by hand when they are no longer in use. If you need to also tell the server to release them, use an RPC call of some sort, and have the server release the data when the session expires (if you are not actually storing the data in the session).
> Is java.lang.ref.* functioning in GWT? I come to an idea that
> java.lang.ref.* is necessary to enable proper garbage collection while
> implementing the Observer pattern in Model View Controller.
I think that by implementing java.lang.ref.* in the client side
(translating to written by hand JavaScript code that adds and can
manages new type of object references) many people can avoid their own
implementation of object release algorithm used to classify the
significant (regular) and not significant (which do not require object
existance at all) object references.
On Nov 18, 2:27 pm, Jason Morris <lem...@gmail.com> wrote:
> You can't use java.lang.ref on the client side, because JavaScript has no notion of weak, soft, or
> phantom references. You can however use the java.lang.ref package on the server.
> If you need to release objects on the client side, it is best to do so by hand when they are no
> longer in use. If you need to also tell the server to release them, use an RPC call of some sort,
> and have the server release the data when the session expires (if you are not actually storing the
> data in the session).
> > Is java.lang.ref.* functioning in GWT? I come to an idea that
> > java.lang.ref.* is necessary to enable proper garbage collection while
> > implementing the Observer pattern in Model View Controller.- Hide quoted text -
On Wed, Nov 19, 2008 at 5:44 AM, Garo.Garabedyan <garabed...@gmail.com> wrote: > I think that by implementing java.lang.ref.* in the client side > (translating to written by hand JavaScript code that adds and can > manages new type of object references)
I sincerely doubt that is even possible, because:
> On Nov 18, 2:27 pm, Jason Morris <lem...@gmail.com> wrote: >> You can't use java.lang.ref on the client side, because JavaScript has no notion of weak, soft, or >> phantom references. You can however use the java.lang.ref package on the server.
The java.lang.ref.* classes work intimately with the JVM to give the user some insight into the memory management cycle. The Javascript "VM" doesn't allow that insight because there's no API for it. Someone with more theoretical background can correct me if I'm wrong, but I'm pretty sure the only way to implement java.lang.ref.* in the browser is to emulate a JVM in Javascript and run GWT on top of that. That would be an enormous undertaking and it would require rearchitecting and rewriting all of the client side infrastructure. In other words, I feel pretty safe saying "it ain't gonna happen".
I think that this is possible if you implement a JS code that behaves
like a java.lang.ref.* references between Java objects to be
translation to JS. And I think that this is not a heavy task to
produce a heavy environment. Something like pay-to-use feature.
JS code can be a mediator between objects and let them erase
references when the letter are not needed anymore. A change must be
made in Java-to-JavaScript compiler.
On Nov 19, 6:17 pm, "Ian Petersen" <ispet...@gmail.com> wrote:
> On Wed, Nov 19, 2008 at 5:44 AM, Garo.Garabedyan <garabed...@gmail.com> wrote:
> > I think that by implementing java.lang.ref.* in the client side
> > (translating to written by hand JavaScript code that adds and can
> > manages new type of object references)
> I sincerely doubt that is even possible, because:
> > On Nov 18, 2:27 pm, Jason Morris <lem...@gmail.com> wrote:
> >> You can't use java.lang.ref on the client side, because JavaScript has no notion of weak, soft, or
> >> phantom references. You can however use the java.lang.ref package on the server.
> The java.lang.ref.* classes work intimately with the JVM to give the
> user some insight into the memory management cycle. The Javascript
> "VM" doesn't allow that insight because there's no API for it.
> Someone with more theoretical background can correct me if I'm wrong,
> but I'm pretty sure the only way to implement java.lang.ref.* in the
> browser is to emulate a JVM in Javascript and run GWT on top of that.
> That would be an enormous undertaking and it would require
> rearchitecting and rewriting all of the client side infrastructure.
> In other words, I feel pretty safe saying "it ain't gonna happen".
On Thu, Nov 20, 2008 at 6:13 AM, Garo.Garabedyan <garabed...@gmail.com> wrote: > I think that this is possible if you implement a JS code that behaves > like a java.lang.ref.* references between Java objects to be > translation to JS. And I think that this is not a heavy task to > produce a heavy environment. Something like pay-to-use feature.
Yes, if you "implement a JS code that behaves like a java.lang.ref.* reference", then you've implemented java.lang.ref.* and the rest of your requests are trivial. Jason Morris and I have already tried to highlight the impossibility of implementing any such thing. The Javascript interpreter doesn't provide any hooks for doing what you're asking.
If you want to get all technical, Javascript is a Turing-complete language so you could, in principle, simulate an entire JVM and run .class files on top of that. Do so would be largely ludicrous--if you want to run Java in the browser, write an applet and run Java in the browser, don't reinvent the wheel badly.
Restricting ourselves to things that have a chance of being incorporated into GWT leaves us with the conclusion that java.lang.ref.* can't and won't be done.
> JS code can be a mediator between objects and let them erase > references when the letter are not needed anymore.
I don't understand what you mean here. Javascript code is nothing except a mediator between objects because Javascript is an object-oriented language. Every single Javascript program ever written and ever to be written will do nothing _except_ mediate objects. That doesn't give such programs some kind of magical ability to peer into the Javascript interpreter and divine when a particular reference is no longer needed.
> A change must be > made in Java-to-JavaScript compiler.
No, a change must be made in your design such that you no longer need or want java.lang.ref.* because the Java-to-Javascript compiler can't create features in the Javascript interpreter.
I think that mediation of objects by JS can be designed in such a way
to understand when a particular object (by the count of references to
it) is no longer needed to the rest objects.
http://www.slideshare.net/Adieu/advanced-javascript/
On Nov 20, 5:42 pm, "Ian Petersen" <ispet...@gmail.com> wrote:
> On Thu, Nov 20, 2008 at 6:13 AM, Garo.Garabedyan <garabed...@gmail.com> wrote:
> > I think that this is possible if you implement a JS code that behaves
> > like a java.lang.ref.* references between Java objects to be
> > translation to JS. And I think that this is not a heavy task to
> > produce a heavy environment. Something like pay-to-use feature.
> Yes, if you "implement a JS code that behaves like a java.lang.ref.*
> reference", then you've implemented java.lang.ref.* and the rest of
> your requests are trivial. Jason Morris and I have already tried to
> highlight the impossibility of implementing any such thing. The
> Javascript interpreter doesn't provide any hooks for doing what you're
> asking.
> If you want to get all technical, Javascript is a Turing-complete
> language so you could, in principle, simulate an entire JVM and run
> .class files on top of that. Do so would be largely ludicrous--if you
> want to run Java in the browser, write an applet and run Java in the
> browser, don't reinvent the wheel badly.
> Restricting ourselves to things that have a chance of being
> incorporated into GWT leaves us with the conclusion that
> java.lang.ref.* can't and won't be done.
> > JS code can be a mediator between objects and let them erase
> > references when the letter are not needed anymore.
> I don't understand what you mean here. Javascript code is nothing
> except a mediator between objects because Javascript is an
> object-oriented language. Every single Javascript program ever
> written and ever to be written will do nothing _except_ mediate
> objects. That doesn't give such programs some kind of magical ability
> to peer into the Javascript interpreter and divine when a particular
> reference is no longer needed.
> > A change must be
> > made in Java-to-JavaScript compiler.
> No, a change must be made in your design such that you no longer need
> or want java.lang.ref.* because the Java-to-Javascript compiler can't
> create features in the Javascript interpreter.
|
