JBuilder under QNX RTP.

Hello,

I wish to develop in Java on Neutrino 2.1 but I’ m forced to use Visual Age
Micro Edition
on Windows to make the source code. I would rather prefer to use JBuilder 4.
Does anybody believe Linux JBuilder can be ported under QNX RTP ??
Does QNX will add some RAD for java development ( except IBM Visual Age ).

Thanks .
Vincent.

“Vincent Celerier” <vcelerier@logisonic.fr> wrote in message
news:99s959$sjk$1@inn.qnx.com

Hello,

I wish to develop in Java on Neutrino 2.1 but I’ m forced to use Visual
Age
Micro Edition
on Windows to make the source code. I would rather prefer to use JBuilder
4.
Does anybody believe Linux JBuilder can be ported under QNX RTP ??
Does QNX will add some RAD for java development ( except IBM Visual Age ).

Do you have the source for Jbuilder ? If it is an X app, then it certainly
wouldn’t hurt to try a port, it might “just work”.

Also, since Java is designed to be portable, I find it a little odd that
VAME (which is written in Java) can’t run under the nto jvm (isn’t Java
supposed to be Write Once Run Anywhere ?).

Rennie

“John Doe” <john@csical.com> wrote in message
news:99thk2$r4c$3@inn.qnx.com

“Vincent Celerier” <> vcelerier@logisonic.fr> > wrote in message
news:99s959$sjk$> 1@inn.qnx.com> …
Hello,

I wish to develop in Java on Neutrino 2.1 but I’ m forced to use Visual
Age
Micro Edition
on Windows to make the source code. I would rather prefer to use
JBuilder
4.
Does anybody believe Linux JBuilder can be ported under QNX RTP ??
Does QNX will add some RAD for java development ( except IBM Visual
Age ).

Do you have the source for Jbuilder ? If it is an X app, then it
certainly
wouldn’t hurt to try a port, it might “just work”.

Also, since Java is designed to be portable, I find it a little odd that
VAME (which is written in Java) can’t run under the nto jvm (isn’t Java
supposed to be Write Once Run Anywhere ?).

There is Java and Java2 and then Personal Java and then Personal Java Micro
Edition. Thankfully, there’s no Microsoft Java anymore :wink:

OTI stuff is Personal Java and to run an IDE you usually need full Java or
Java2.

  • igor

VAME uses a proprietary UI layer (not AWT) which is not yet shipping on
Photon. Trust me, you wouldn’t want to run an IDE under AWT … Swing
maybe, with the current crop of extremely fast processors, but you’d still
have those niggling non-platform-ish behaviours that would bug the crap out
of you.

Patrick_Mueller@oti.com



“John Doe” <john@csical.com> wrote in message
news:99thk2$r4c$3@inn.qnx.com

“Vincent Celerier” <> vcelerier@logisonic.fr> > wrote in message
news:99s959$sjk$> 1@inn.qnx.com> …
Hello,

I wish to develop in Java on Neutrino 2.1 but I’ m forced to use Visual
Age
Micro Edition
on Windows to make the source code. I would rather prefer to use
JBuilder
4.
Does anybody believe Linux JBuilder can be ported under QNX RTP ??
Does QNX will add some RAD for java development ( except IBM Visual
Age ).

Do you have the source for Jbuilder ? If it is an X app, then it
certainly
wouldn’t hurt to try a port, it might “just work”.

Also, since Java is designed to be portable, I find it a little odd that
VAME (which is written in Java) can’t run under the nto jvm (isn’t Java
supposed to be Write Once Run Anywhere ?).

Rennie

Actually, we have many flavors of Java available. Stuff smaller than CLDC,
up to basically JDK 1.2.2 missing some of the trimmings (Java2d, Swing).
Our IDE can run, on Windows and Linux, under a >= 1.2.2 JDK or under the
1.3+ J9 VM.

Patrick_Mueller@oti.com



“Igor Kovalenko” <kovalenko@home.com> wrote in message
news:99u6h5$2hc$1@inn.qnx.com

“John Doe” <> john@csical.com> > wrote in message
news:99thk2$r4c$> 3@inn.qnx.com> …

“Vincent Celerier” <> vcelerier@logisonic.fr> > wrote in message
news:99s959$sjk$> 1@inn.qnx.com> …
Hello,

I wish to develop in Java on Neutrino 2.1 but I’ m forced to use
Visual
Age
Micro Edition
on Windows to make the source code. I would rather prefer to use
JBuilder
4.
Does anybody believe Linux JBuilder can be ported under QNX RTP ??
Does QNX will add some RAD for java development ( except IBM Visual
Age ).

Do you have the source for Jbuilder ? If it is an X app, then it
certainly
wouldn’t hurt to try a port, it might “just work”.

Also, since Java is designed to be portable, I find it a little odd that
VAME (which is written in Java) can’t run under the nto jvm (isn’t Java
supposed to be Write Once Run Anywhere ?).


There is Java and Java2 and then Personal Java and then Personal Java
Micro
Edition. Thankfully, there’s no Microsoft Java anymore > :wink:

OTI stuff is Personal Java and to run an IDE you usually need full Java or
Java2.

  • igor

I saw a graphical demo running on the RPX Lite red boxes in
the QNX training room (I believe running the OTI Java).
(Runs a mockup of a fancy radio UI)
If not AWT, what graphical interface would that be using?

If one had to have AWT (existing application), any idea when
this would be available?

With AWT, what level of processor would one be needing
(in the x86 world)? And with Swing?

Thanks in advance for the info

Patrick Mueller wrote:

VAME uses a proprietary UI layer (not AWT) which is not yet shipping on
Photon. Trust me, you wouldn’t want to run an IDE under AWT … Swing
maybe, with the current crop of extremely fast processors, but you’d still
have those niggling non-platform-ish behaviours that would bug the crap out
of you.

For QNX 6, Photon 2, we have AWT available. AFAIK, this level of os/photon
is only available for x86, not ppc (or any other platform). Our version of
AWT for Photon requires a wad of C code that should be able to compile
anywhere QNX 6, Photon 2 is available. You can actually download the x86
bit from www.embedded.oti.com; look for the “Personal Configuration”, along
with the runtimes for qnx/x86.

We can make AWT for any other platform (ppc,sh?,mips,etc) available as soon
there is a QNX 6 and Photon 2 that can run on that platform.

With AWT, what level of processor would one be needing
(in the x86 world)? And with Swing?

Good question.

Swing, well, we haven’t really stepped up to actually say we support Swing
yet. There are some bugs in our AWT we need to fix; and we don’t really
have a licensing story. Our VM, base class libs, and AWT are completely
‘independently developed’, and don’t require a Sun license for your
customers to use. We don’t have our own Swing though. It’s really too big
to be something that we would expect our customers to use, so we haven’t
embarked on the ‘independently developed’ path for Swing yet. So, to run it
at all, you’ll need to go to the Sun web site, and download it, and agree to
their license. And you want Swing 1.1.1 for JDK 1.1, not Swing for a JDK >
1.1. This is because the Swings for > JDK 1.1 (ie, >= JDK 1.2) require the
java2d APIs, which we also don’t support in our AWT (I’ll be kind and just
say it’s too damn big :slight_smile:.

For us Swing is a test-case, and not something we would recommend to
customers. For the moment, anyway.

Swing is quite large also. Both code size and ram usage. It requires AWT,
so take what I say next, and add a few more megabytes to code and ram usage.

Now to AWT. AWT is also unfortunately quite large. Both in terms of code
size and ram usage. Code size is something like ~2M of classes and a ~400K
…so. AWT was designed to be easy for programmers to use, as opposed to a
good performer and ram user. The lack of a threading model in AWT means
that we have to do lots of cross-threaded stuff under the covers. Typical
AWT applications depends on ‘finalization’ to clean up their garbage, which
causes lots of transient garbage, holding onto os resources like GCs,
images, etc longer than you should. There is also a built-in image caching
scheme that has no API, so basically a lot of your images get cached, even
if you just use them once and then never again.

It’s not something >I< would want to deploy on, unless I had lots of RAM
available. One of our customers is shipping with 64M RAM and 32M flash. Of
course it also completely depends on what you want to do with it.

Processor choice is largely orthogonal. Unless you are doing some fancy
image filtering stuff, or your own complex crunching, AWT performance will
scale like any other app. Customer above runs on a 300Mz MediaGX, and I
think the performance is perfectly acceptable.

If not AWT, what graphical interface would that be using?

Besides AWT, we also have a product called MicroView, which is a
bitmap-based UI toolkit. The use is to do panel/console-type displays. It
has some widgety things in it, but it’s really designed to do UIs that look
like a hardware surface, or do branding for your UI. It runs on a lot more
platforms that AWT does. No doubt this is what you saw, if it was running
the J9 VM.

We are going to have a few more UI options available in the next few months

In the meantime, visit www.embedded.oti.com for more info on what we are
shipping today …

Patrick_Mueller@oti.com



“Alex” <acellarius@systems104.co.za> wrote in message
news:3AEF1BA1.EBF2DB30@systems104.co.za

I saw a graphical demo running on the RPX Lite red boxes in
the QNX training room (I believe running the OTI Java).
(Runs a mockup of a fancy radio UI)
If not AWT, what graphical interface would that be using?

If one had to have AWT (existing application), any idea when
this would be available?

With AWT, what level of processor would one be needing
(in the x86 world)? And with Swing?

Thanks in advance for the info

Patrick Mueller wrote:

VAME uses a proprietary UI layer (not AWT) which is not yet shipping on
Photon. Trust me, you wouldn’t want to run an IDE under AWT … Swing
maybe, with the current crop of extremely fast processors, but you’d
still
have those niggling non-platform-ish behaviours that would bug the crap
out
of you.

Thanks for a complete answer!

One more-for level of processor I was thinking along the line
of MHz e.g. Would a Pentium 166 run “ok”, given it had enough
RAM & Flash? What would be the recommended minimum in the x86 sphere?

Patrick Mueller wrote:

For QNX 6, Photon 2, we have AWT available. AFAIK, this level of os/photon
is only available for x86, not ppc (or any other platform). Our version of
AWT for Photon requires a wad of C code that should be able to compile
anywhere QNX 6, Photon 2 is available. You can actually download the x86
bit from > www.embedded.oti.com> ; look for the “Personal Configuration”, along
with the runtimes for qnx/x86.

We can make AWT for any other platform (ppc,sh?,mips,etc) available as soon
there is a QNX 6 and Photon 2 that can run on that platform.

With AWT, what level of processor would one be needing
(in the x86 world)? And with Swing?

Good question.

Swing, well, we haven’t really stepped up to actually say we support Swing
yet. There are some bugs in our AWT we need to fix; and we don’t really
have a licensing story. Our VM, base class libs, and AWT are completely
‘independently developed’, and don’t require a Sun license for your
customers to use. We don’t have our own Swing though. It’s really too big
to be something that we would expect our customers to use, so we haven’t
embarked on the ‘independently developed’ path for Swing yet. So, to run it
at all, you’ll need to go to the Sun web site, and download it, and agree to
their license. And you want Swing 1.1.1 for JDK 1.1, not Swing for a JDK
1.1. This is because the Swings for > JDK 1.1 (ie, >= JDK 1.2) require the
java2d APIs, which we also don’t support in our AWT (I’ll be kind and just
say it’s too damn big > :slight_smile:> .

For us Swing is a test-case, and not something we would recommend to
customers. For the moment, anyway.

Swing is quite large also. Both code size and ram usage. It requires AWT,
so take what I say next, and add a few more megabytes to code and ram usage.

Now to AWT. AWT is also unfortunately quite large. Both in terms of code
size and ram usage. Code size is something like ~2M of classes and a ~400K
.so. AWT was designed to be easy for programmers to use, as opposed to a
good performer and ram user. The lack of a threading model in AWT means
that we have to do lots of cross-threaded stuff under the covers. Typical
AWT applications depends on ‘finalization’ to clean up their garbage, which
causes lots of transient garbage, holding onto os resources like GCs,
images, etc longer than you should. There is also a built-in image caching
scheme that has no API, so basically a lot of your images get cached, even
if you just use them once and then never again.

It’s not something >I< would want to deploy on, unless I had lots of RAM
available. One of our customers is shipping with 64M RAM and 32M flash. Of
course it also completely depends on what you want to do with it.

Processor choice is largely orthogonal. Unless you are doing some fancy
image filtering stuff, or your own complex crunching, AWT performance will
scale like any other app. Customer above runs on a 300Mz MediaGX, and I
think the performance is perfectly acceptable.

If not AWT, what graphical interface would that be using?

Besides AWT, we also have a product called MicroView, which is a
bitmap-based UI toolkit. The use is to do panel/console-type displays. It
has some widgety things in it, but it’s really designed to do UIs that look
like a hardware surface, or do branding for your UI. It runs on a lot more
platforms that AWT does. No doubt this is what you saw, if it was running
the J9 VM.

We are going to have a few more UI options available in the next few months

In the meantime, visit > www.embedded.oti.com > for more info on what we are
shipping today …

Patrick_Mueller@oti.com

“Alex” <> acellarius@systems104.co.za> > wrote in message
news:> 3AEF1BA1.EBF2DB30@systems104.co.za> …
I saw a graphical demo running on the RPX Lite red boxes in
the QNX training room (I believe running the OTI Java).
(Runs a mockup of a fancy radio UI)
If not AWT, what graphical interface would that be using?

If one had to have AWT (existing application), any idea when
this would be available?

With AWT, what level of processor would one be needing
(in the x86 world)? And with Swing?

Thanks in advance for the info

Patrick Mueller wrote:

VAME uses a proprietary UI layer (not AWT) which is not yet shipping on
Photon. Trust me, you wouldn’t want to run an IDE under AWT … Swing
maybe, with the current crop of extremely fast processors, but you’d
still
have those niggling non-platform-ish behaviours that would bug the crap
out
of you.

Certainly it will run, but how fast is anyone’s guess.

We actually one VM for nto 386 and a different one for nto >= 486. We make
use of some 486 feature in the >= 486 VM. So, we should run on fairly ‘old’
x86 boxes, again, speed being the big question.

Patrick_Mueller@oti.com



“Alex” <acellarius@systems104.co.za> wrote in message
news:3AF03B41.9E0D6917@systems104.co.za

Thanks for a complete answer!

One more-for level of processor I was thinking along the line
of MHz e.g. Would a Pentium 166 run “ok”, given it had enough
RAM & Flash? What would be the recommended minimum in the x86 sphere?

Patrick Mueller wrote:

For QNX 6, Photon 2, we have AWT available. AFAIK, this level of
os/photon
is only available for x86, not ppc (or any other platform). Our version
of
AWT for Photon requires a wad of C code that should be able to compile
anywhere QNX 6, Photon 2 is available. You can actually download the
x86
bit from > www.embedded.oti.com> ; look for the “Personal Configuration”,
along
with the runtimes for qnx/x86.

We can make AWT for any other platform (ppc,sh?,mips,etc) available as
soon
there is a QNX 6 and Photon 2 that can run on that platform.

With AWT, what level of processor would one be needing
(in the x86 world)? And with Swing?

Good question.

Swing, well, we haven’t really stepped up to actually say we support
Swing
yet. There are some bugs in our AWT we need to fix; and we don’t really
have a licensing story. Our VM, base class libs, and AWT are completely
‘independently developed’, and don’t require a Sun license for your
customers to use. We don’t have our own Swing though. It’s really too
big
to be something that we would expect our customers to use, so we haven’t
embarked on the ‘independently developed’ path for Swing yet. So, to
run it
at all, you’ll need to go to the Sun web site, and download it, and
agree to
their license. And you want Swing 1.1.1 for JDK 1.1, not Swing for a
JDK
1.1. This is because the Swings for > JDK 1.1 (ie, >= JDK 1.2) require
the
java2d APIs, which we also don’t support in our AWT (I’ll be kind and
just
say it’s too damn big > :slight_smile:> .

For us Swing is a test-case, and not something we would recommend to
customers. For the moment, anyway.

Swing is quite large also. Both code size and ram usage. It requires
AWT,
so take what I say next, and add a few more megabytes to code and ram
usage.

Now to AWT. AWT is also unfortunately quite large. Both in terms of
code
size and ram usage. Code size is something like ~2M of classes and a
~400K
.so. AWT was designed to be easy for programmers to use, as opposed to
a
good performer and ram user. The lack of a threading model in AWT means
that we have to do lots of cross-threaded stuff under the covers.
Typical
AWT applications depends on ‘finalization’ to clean up their garbage,
which
causes lots of transient garbage, holding onto os resources like GCs,
images, etc longer than you should. There is also a built-in image
caching
scheme that has no API, so basically a lot of your images get cached,
even
if you just use them once and then never again.

It’s not something >I< would want to deploy on, unless I had lots of RAM
available. One of our customers is shipping with 64M RAM and 32M flash.
Of
course it also completely depends on what you want to do with it.

Processor choice is largely orthogonal. Unless you are doing some fancy
image filtering stuff, or your own complex crunching, AWT performance
will
scale like any other app. Customer above runs on a 300Mz MediaGX, and I
think the performance is perfectly acceptable.

If not AWT, what graphical interface would that be using?

Besides AWT, we also have a product called MicroView, which is a
bitmap-based UI toolkit. The use is to do panel/console-type displays.
It
has some widgety things in it, but it’s really designed to do UIs that
look
like a hardware surface, or do branding for your UI. It runs on a lot
more
platforms that AWT does. No doubt this is what you saw, if it was
running
the J9 VM.

We are going to have a few more UI options available in the next few
months

In the meantime, visit > www.embedded.oti.com > for more info on what we are
shipping today …

Patrick_Mueller@oti.com

“Alex” <> acellarius@systems104.co.za> > wrote in message
news:> 3AEF1BA1.EBF2DB30@systems104.co.za> …
I saw a graphical demo running on the RPX Lite red boxes in
the QNX training room (I believe running the OTI Java).
(Runs a mockup of a fancy radio UI)
If not AWT, what graphical interface would that be using?

If one had to have AWT (existing application), any idea when
this would be available?

With AWT, what level of processor would one be needing
(in the x86 world)? And with Swing?

Thanks in advance for the info

Patrick Mueller wrote:

VAME uses a proprietary UI layer (not AWT) which is not yet shipping
on
Photon. Trust me, you wouldn’t want to run an IDE under AWT …
Swing
maybe, with the current crop of extremely fast processors, but you’d
still
have those niggling non-platform-ish behaviours that would bug the
crap
out
of you.