Hi all,
The real problem is that an approach that relies on lazy resolution of class references is not guaranteed to work according to the JVM Spec.
Please disregard this FUD of mine. Here's an excerpt from Chapter 8, The Linking Model [1], of the excellent Bill Venners' "Inside the Java Virtual Machine" (the most relevant part is in bold type):
Different implementations of the Java virtual machine are permitted to perform resolution at different times during the execution of a program. An implementation may choose to link everything up front by following all symbolic references from the initial class, then all symbolic references from subsequent classes, until every symbolic reference has been resolved. In this case, the application would be completely linked before its main() method was ever invoked. This approach is called early resolution. Alternatively, an implementation may choose to wait until the very last minute to resolve each symbolic reference. In this case, the Java virtual machine would resolve a symbolic reference only when it is first used by the running program. This approach is called late resolution. Implementations may also use a resolution strategy in-between these two extremes.
Although a Java virtual machine implementation has some freedom in choosing when to resolve symbolic references, every Java virtual machine must give the outward impression that it uses late resolution. No matter when a particular Java virtual machine performs its resolution, it will always throw any error that results from attempting to resolve a symbolic reference at the point in the execution of the program where the symbolic reference was actually used for the first time. In this way, it will always appear to the user as if the resolution were late. If a Java virtual machine does early resolution, and during early resolution discovers that a class file is missing, it won't report the class file missing by throwing the appropriate error until later in the program when something in that class file is actually used. If the class is never used by the program, the error will never be thrown.
Sorry about the confusion, and don't spread the FUD!
Thanks,
Vladimir
[1]
http://www.artima.com/insidejvm/ed2/linkmod.html
On Tue, Feb 9, 2016 at 4:07 PM, Vladimir Piskarev <pisv@xxxxx> wrote:
Hi Vlad,
Thanks for the input!
It seems I was not quite correct in interpreting the results of my experiments. My initial approach depends on lazy resolution of symbolic references and although it does work on a HotSpot VM, the JVM Spec apparently provides no guarantees about lazy resolution, so the code appears to be in violation of the spec. It's all too easy to be fooled by such things. I need to take a deeper look at this when I have some time, but the problem starts to look much harder than I initially thought.
An approach with "isolating" the dependency on o.e.core.resources in a separate layer, along the lines you have suggested, would come with a cost wrt additional complexity both in the framework and for model implementations and clients (more "parts and pieces" to be aware of).
Need to decide whether the increase in complexity would be worthwhile and, to begin with, if it's really a problem to be solved, given that the Eclipse IDE remains the main target for the foreseeable future. The proposed redesign around the model API is a much more pressing need now.
Best regards,
Vladimir
Hi!
Don't worry about late answers, it wasn't that late and it happens to everybody :-)
I see, so the two demo zips are not really related. That makes sense now.
If you find a way to abstract out o.e.core.resources, then it would be great. I suppose that the clients would need a way to know what APIs are available and in what form - maybe some kind of ISomethingExtension interfaces? I trust you with this, the Handly APIs are very clean!
regards,
Vlad
On Sun, Feb 7, 2016 at 9:14 AM, Vladimir Piskarev <pisv@xxxxx> wrote:
Hi Vlad,
Thanks for the feedback, and sorry for my delay in responding. My only (lame) excuse for not checking my mail earlier is that I got carried away with choosing and installing a Linux distro to revitalize my good old MacBook Pro.
I think that, basically, we have two problems on hand that could, and probably should, be treated as orthogonal: the one described in my original proposal for a new design around the model API and the other, of reducing dependencies, partly described here.
The previous newmodel.zip was in fact a bit incomplete in the sense that it was trying to deal only with the former problem and so just abstracted away the dependency on o.e.core.resources as a detail that was not deemed essential in the context of that consideration.
Those two problems are indeed quite orthogonal as can be illustrated by the fact that my findings regarding the latter problem could have been incorporated in the existing design as well as in the proposed new one. It was just a bit more convenient to me to investigate that problem and present the results within the framework of a simplified prototype. I'm sorry for the confusion this has probably caused.
Please also note that the Eclipse IDE, where the dependency on o.e.core.resources is a given, remains the primary "deployment target" for Handly. The goal here has just been to make this dependency optional, so the project could be used in other contexts such as Eclipse RCP or even plain Java applications. (The latter is possible by replacing the dependency on o.e.core.runtime with o.e.equinox.common, which doesn't require OSGi running.)
Speaking of these other contexts, a Handly-based model could be built on top of such diverse "resource models" as o.e.core.filesystem, java.nio.file, or even a custom datasource. I think we needn't "prescribe" in Handly what the "resource model" is in these contexts.
Hope this makes a bit more sense now.
Thanks,
Vladimir
Hi Vladimir,
I got some time to look at this, but I'm not sure I get it right (probably it's just a misunderstanding from my part): given your explanation I has assumed that the previous newmodel.zip would have a required dependency on o.e.c.resources, but it doesn't have one at all. Maybe newmodel.zip is incomplete?
How useful would be the model without references to resources? There has to be something that allows using files and such in a RPC. Would the o.e.c.filesystem be enough? It only depends on osgi bundles. (I admit I don't know much about the details)
best regards,
Vlad
On Fri, Jan 29, 2016 at 1:54 PM, Vladimir Piskarev <pisv@xxxxx> wrote:
Just to keep everyone informed,
I was experimenting for a while with whether the dependency on o.e.core.resources could be made optional, so that Handly could be used in Eclipse RCP applications (there appears to be some interest in this, see e.g. a blog comment [1]). First results are encouraging -- I think it would be quite easy to do, thanks to how the JVM works wrt class loading.
I have incorporated my findings into the new design prototype (see the newmodel2 project attached), although it could be implemented in the existing design too. For details, please see the "first strategy" test case (model.test.Test). When o.e.core.resources bundle is not resolved, only testFooElementDelta2 and testFooElementDelta3 tests fail (as expected), all other tests pass.
Best regards,
Vladimir
[1] https://pisv.wordpress.com/2015/01/19/on-m-theory-and-h-models-or-can-emf-fit-every-nail/
_______________________________________________
handly-dev mailing list
handly-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/handly-dev
_______________________________________________
handly-dev mailing list
handly-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/handly-dev
_______________________________________________
handly-dev mailing list
handly-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/handly-dev
_______________________________________________
handly-dev mailing list
handly-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/handly-dev
