[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
using fewer VMs in VE [wasRE: [ve-dev] Re: Future of VE]
|
Joe Winchester wrote:
>The implementation of the target VM code is such that it is possible to
have
>VE talk to JavaBeans that are instantiated inside the Eclipse VM,
rather than
>having to use a separate VM.
>This isn't used by the Swing/SWT VE implementation, however it is used
by
>some guys who did a bunch of work with having the VE working with
mobile
>MIDP stuff where they had the beans inside Eclipse itself.
I downloaded and trie the Nokia Carbide.ui IDE which is based on VE.
http://www.forum.nokia.com/carbide
>From what I saw by running it, it does not spawn a new VM for each new
editor.
They do not seem to edit Java, but instead some XML file.
So they may not have the rendering constraints.
Nevertheless if someone could reach out to Nokia and see if they could
be willing to help sustain VE that would be great!
>One idea we kicked around for ages but never finished off, was that the
VE would allow the option to run directly against the IDE's
>VM, perhaps via a preference where if the Java project's classpath
matched that of the IDE itself then this was the default option.
>Once we get a 3.3 codebase working maybe we should revisit this as an
option - if nothing else it means that user's first impression of
> VE will be faster, and then as that user becomes more complex in terms
of having separate targets and IDEs,
>they have the option of breaking the two apart but understand the
implications.
I think that would be a decent design.
My hunch is that most folks use the same VM version to run Eclipse and
to run all their projects.
And it could make the initial user expereince much simpler.
Rich Kulp replied:
>But be aware of real exposure with this.
>It works fine for a controlled project where the code being developed
is under strict controls,
>but if the code being developed has anything strange in it, it could
crash or lock up the Eclipse
>IDE. It could even call System.exit(), and that would work and Eclipse
would not get a chance
>to do any cleanup or save of state.
Very true. on the Syste.exit issue, we could work something such that
we flag as errors running some code that contains such instructions.
For the rest, I would see how this flies in the wild: we may be
overstaing the risks of that to happen. And Eclipse is fairly tolerant
to abrupt shutdowns and crashes in most case.
That could a risk we could live with, what do you think?
--
Cheers
Philippe
http://easyeclipse.org - http://phpeclipse.net - http://eclipse.org/atf
-----Original Message-----
From: ve-dev-bounces@xxxxxxxxxxx [mailto:ve-dev-bounces@xxxxxxxxxxx] On
Behalf Of Rich Kulp
Sent: Monday, September 17, 2007 6:52 AM
To: Discussions people developing code for the Visual Editor project
Subject: RE: [ve-dev] Re: Future of VE
Hi,
But be aware of real exposure with this. It works fine for a controlled
project where the code being developed is under strict controls, but if
the code being developed has anything strange in it, it could crash or
lock up the Eclipse IDE. It could even call System.exit(), and that
would work and Eclipse would not get a chance to do any cleanup or save
of state.
Thanks,
Rich
Joe Winchester <WINCHEST@xxxxxxxxxx>
Sent by: ve-dev-bounces@xxxxxxxxxxx
09/17/2007 05:47 AM Please respond to
Discussions people developing code for the Visual Editor project
<ve-dev@xxxxxxxxxxx>
Topombredanne@xxxxxxxxx, Discussions people developing code for the
Visual Editor project <ve-dev@xxxxxxxxxxx>
cc
SubjectRE: [ve-dev] Re: Future of VE
Hi Philippe,
>I am sure there have been excellent historical reasons, but in practice
>it makes VE really resource hungry and very hard to use. Revisiting
that
>with a new eye, with the newer and stabler VM is worth it.
The implementation of the target VM code is such that it is possible to
have VE talk to JavaBeans that are instantiated inside the Eclipse VM,
rather than having to use a separate VM. This isn't used by the
Swing/SWT VE implementation, however it is used by some guys who did a
bunch of work with having the VE working with mobile MIDP stuff where
they had the beans inside Eclipse itself.
One idea we kicked around for ages but never finished off, was that the
VE would allow the option to run directly against the IDE's VM, perhaps
via a preference where if the Java project's classpath matched that of
the IDE itself then this was the default option. Once we get a 3.3
codebase working maybe we should revisit this as an option - if nothing
else it means that user's first impression of VE will be faster, and
then as that user becomes more complex in terms of having separate
targets and IDEs, they have the option of breaking the two apart but
understand the implications.
Best regards,
Joe
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
3AU
_______________________________________________
ve-dev mailing list
ve-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ve-dev
