|
Replies:
25
-
Last Post:
Oct 12, 2008 7:18 PM
by: naftoligug
|
|
|
|
|
|
|
Mix and match to support Java 5 or 6
Posted:
Sep 12, 2008 11:02 AM
|
|
|
My understanding is that phonME Advanced has a class library that is equivalent to Java SE 1.4.2, and a VM that can read Java 5 bytecode.
Now, most of the difference between Java 1.4 and Java 6 is probably in pure Java. So my question is if it's possible to replace the rt.jar with a Java 5 or recompiled-to-java-5 Java 6 bytecode.
For example, is it possible to get the scripting package to work, or Swing?
|
|
|
|
|
|
|
Re: Mix and match to support Java 5 or 6
Posted:
Sep 12, 2008 11:53 AM
in response to: naftoligug
|
|
|
phonemeadvanced@mobileandembedded.org wrote:
> My understanding is that phonME Advanced has a class library that is equivalent to Java SE 1.4.2, and a VM that can read Java 5 bytecode.
> Now, most of the difference between Java 1.4 and Java 6 is probably in pure Java. So my question is if it's possible to replace the rt.jar with a Java 5 or recompiled-to-java-5 Java 6 bytecode.
> For example, is it possible to get the scripting package to work, or Swing?
Most of non-graphics parts of the Java SE 6.0 libraries are in Java, but
there have been changes to the language that require VM changes to
support (such as actually using Annotations, not just for loading in
classes w/Annotations). Also, it is not correct to assume that the
graphics part pf Java SE 5.0/6.0 is 100% Java, since the renderer is
tied to native graphics support. To port a graphics renderer that
supports Java SE 6.0 graphics (Swing, Java2D, etc.) is non-trivial.
So, because VM changes are needed and because there are native
dependencies in Java SE 6.0 (especially or graphics), it is not possible
to just replace the class libraries in phoneME Advanced to run the Java
SE 5.0 or 6.0 rt.jar.
It is however, very easy to get JavaScript scripting support by running
with Rhino on top of a CDC/Foundation Profile build of phoneME Advanced.
http://www.mozilla.org/rhino/
Hinkmond
---------------------------------------------------------------------
To unsubscribe, e-mail: advanced-unsubscribe@phoneme.dev.java.net
For additional commands, e-mail: advanced-help@phoneme.dev.java.net
|
|
|
|
|
|
|
|
|
Re: Mix and match to support Java 5 or 6
Posted:
Sep 12, 2008 12:37 PM
in response to: Hinkmond Wong
|
|
|
Yes, but can't the Swing packages from Java 5 or 6 run on top of the AWT renderer that's in phoneME? Is there anything in the Swing Java code that references a particular implementation?
|
|
|
|
|
|
|
|
|
Re: Mix and match to support Java 5 or 6
Posted:
Sep 12, 2008 12:48 PM
in response to: naftoligug
|
|
|
phonemeadvanced@mobileandembedded.org wrote:
> Yes, but can't the Swing packages from Java 5 or 6 run on top of the AWT renderer that's in phoneME? Is there anything in the Swing Java code that references a particular implementation?
>
No, unfortunately the Personal Profile AWT in phoneME Advanced is
directly ported on top of peer widgets (such Qt widgets: Button, Label,
TextField, etc.). There is no AWT renderer on phoneME Advanced.
Swing (for now) in Java SE 5.0 and 6.0 is tightly bound to the Java
class libraries it is built with. You cannot extract Swing by itself.
(It used to be a separate JAR file a long time ago, but not currently.
After JSR 277 there might be a way again, though)
Hinkmond
---------------------------------------------------------------------
To unsubscribe, e-mail: advanced-unsubscribe@phoneme.dev.java.net
For additional commands, e-mail: advanced-help@phoneme.dev.java.net
|
|
|
|
|
|
|
|
|
Re: Mix and match to support Java 5 or 6
Posted:
Sep 15, 2008 1:26 PM
in response to: Hinkmond Wong
|
|
|
> No, unfortunately the Personal Profile AWT in phoneME Advanced is
> directly ported on top of peer widgets (such Qt widgets: Button, Label,
> TextField, etc.). There is no AWT renderer on phoneME Advanced.
Would you be able to explain better what you mean? Do you mean that there are no Component.paint* methods to override?
Also, what about the scripting packages? If all of them are copied and referenced in the classpath would it work?
|
|
|
|
|
|
|
|
|
Re: Mix and match to support Java 5 or 6
Posted:
Sep 15, 2008 3:38 PM
in response to: naftoligug
|
|
|
I think what Hinkmond tried to explain is that AWT widgets are not painted or
rendered on a canvas. They make use of the platform specific widgets provided by a
native GUI library. This basically means that for each new backend AWT widgets
need to be mapped on their native counterparts. As Swing is not pure java code
that runs on top of AWT, I think that getting Swing to work on top of Personal Profile
will require more work than just adding some java classes/libraries to the classpath.
If AWT does not suite your needs, you may have a look at AGUI (JSR 209) or
LWUIT. However, I am not quite sure if there is already a CDC implementation
available for the latter.
Davy
|
|
|
|
|
|
|
|
|
Re: Mix and match to support Java 5 or 6
Posted:
Sep 15, 2008 4:02 PM
in response to: davyp
|
|
|
> I think what Hinkmond tried to explain is that AWT widgets are not painted or
> rendered on a canvas. They make use of the platform specific widgets provided by a
> native GUI library. This basically means that for each new backend AWT widgets
> need to be mapped on their native counterparts. As Swing is not pure java code
> that runs on top of AWT, I think that getting Swing to work on top of Personal Profile
> will require more work than just adding some java classes/libraries to the classpath.
>
> If AWT does not suite your needs, you may have a look at AGUI (JSR 209) or
> LWUIT. However, I am not quite sure if there is already a CDC implementation
> available for the latter.
>
> Davy
Sorry, I'm still not clear on the specifics.
There's nothing different in what you said from AWT in Java SE. Of course real widgets are implemented via their peers. But the base class, Component, should allow you to override paintComponent and call custom Graphics methods - can you not? Is that where the distinction between SE AWT and ME AWT?
Does phoneME Advanced have AGUI?
|
|
|
|
|
|
|
|
|
Re: Mix and match to support Java 5 or 6
Posted:
Sep 15, 2008 6:20 PM
in response to: naftoligug
|
|
|
phonemeadvanced@mobileandembedded.org wrote:
>
> Sorry, I'm still not clear on the specifics.
> There's nothing different in what you said from AWT in Java SE. Of course real widgets are implemented via their peers. But the base class, Component, should allow you to override paintComponent and call custom Graphics methods - can you not? Is that where the distinction between SE AWT and ME AWT?
>
Component in phoneME AWT does allow you to override paint() and call
your own Java methods. However, there are no Java methods in phoneME
that maps to anything other than default Java AWT methods (from Java SE
1.4.2 AWT)
In theory, you could override all the Component paint() methods to
create your own set of customized widgets. In practice, it is
non-trivial to do so.
Also, scripting will probably not work on phoneME, since phoneME class
libraries are Java SE 1.4.2 based and scripting probably has
dependencies on Java SE 5.0 (or higher) class libraries.
> Does phoneME Advanced have AGUI
No, unfortunately phoneME does not have AGUI (yet) because of 3rd party
encumbrances that keep it from being GPL'd.
Hinkmond
---------------------------------------------------------------------
To unsubscribe, e-mail: advanced-unsubscribe@phoneme.dev.java.net
For additional commands, e-mail: advanced-help@phoneme.dev.java.net
|
|
|
|
|
|
|
|
|
Re: Mix and match to support Java 5 or 6
Posted:
Sep 16, 2008 10:05 AM
in response to: Hinkmond Wong
|
|
|
> In theory, you could override all the Component paint() methods to
> create your own set of customized widgets. In practice, it is
> non-trivial to do so.
So isn't that exactly what Swing ('s relationship with AWT) boils down to - overriding paint* methods and implementing event handlers? Everything in between that's supplied by Swing is pure Java. Is there something I'm missing?
> Also, scripting will probably not work on phoneME,
> since phoneME class libraries are Java SE 1.4.2 based and scripting
> probably has dependencies on Java SE 5.0 (or higher) class
> libraries.
If it's classes like Enum, Iterable etc. couldn't they individually be copied into CVM's classpath?
As I mentioned, it seems that CVM was able to interpret 5.0 bytecode.
> No, unfortunately phoneME does not have AGUI (yet) because of 3rd party
> encumbrances that keep it from being GPL'd.
What would it take for an individual to get AGUI working for personal use?
|
|
|
|
|
|
|
|
|
Re: Mix and match to support Java 5 or 6
Posted:
Sep 16, 2008 7:57 PM
in response to: naftoligug
|
|
|
phonemeadvanced@mobileandembedded.org wrote:
>
> So isn't that exactly what Swing ('s relationship with AWT) boils
> down to - overriding paint* methods and implementing event handlers?
> Everything in between that's supplied by Swing is pure Java. Is there
> something I'm missing?
Yes, you're missing that Swing still has a native graphics renderer
underneath it. It can be a Windows graphics renderer or a X11 (X Window
System) renderer like you find in Java SE, or any of a number of other
renderers that map the Java graphics primitives that Swing calls in its
Java paint calls to the right native graphics calls. There is no such
renderer in phoneME.
Someone in theory could write a GPL open source clean-room implemented
Swing capable renderer for phoneME, but they would have to write it from
scratch and would need advanced knowledge to do so.
>> Also, scripting will probably not work on phoneME,
>> since phoneME class libraries are Java SE 1.4.2 based and scripting
>> probably has dependencies on Java SE 5.0 (or higher) class
>> libraries.
>
> If it's classes like Enum, Iterable etc. couldn't they individually be copied into CVM's classpath?
> As I mentioned, it seems that CVM was able to interpret 5.0 bytecode.
No, Java 5.0 bytecodes have a different major/minor version number
(49.0) and will give an Unsupported Class Version exception with the
current CVM in phoneME which works with version 48.0 and lower.
> What would it take for an individual to get AGUI working for personal use?
Since AGUI source code is not open sourced (because of 3rd party
encumbrances) it would be virtually impossible. However, if you did
have a year or more of full-time focus and had advanced experience in
Java ME library programming, in theory you could download the JSR 209
specification and clean-room implement the entire AGUI library solely
based on the javadoc descriptions. I would not recommend this, though,
since like many things what looks good in theory, is not practical to do
for real.
I'd suggest to look at LWUIT instead. All of the power of Swing/AGUI,
and is open sourced and works on phoneME Advanced:
https://lwuit.dev.java.net/
Hinkmond
---------------------------------------------------------------------
To unsubscribe, e-mail: advanced-unsubscribe@phoneme.dev.java.net
For additional commands, e-mail: advanced-help@phoneme.dev.java.net
|
|
|
|
|
|
|
|
|
Re: Mix and match to support Java 5 or 6
Posted:
Sep 18, 2008 11:25 AM
in response to: Hinkmond Wong
|
|
|
I really appreciate your taking so much time to read my questions and clarify the answers.
> Yes, you're missing that Swing still has a native graphics renderer
> underneath it. It can be a Windows graphics renderer or a X11 (X Window
> System) renderer like you find in Java SE, or any of a number of other
> renderers that map the Java graphics primitives that Swing calls in its
> Java paint calls to the right native graphics calls. There is no such
> renderer in phoneME.
But isn't that all considered a part of AWT? The Graphics class is in the java.awt package, isn't it?
Anyway, this: http://www.cs.kuleuven.be/~davy/phoneme/image/screenshot1.gif is graphics primitives, isn't it?
> Someone in theory could write a GPL open source clean-room implemented
> Swing capable renderer for phoneME, but they would have to write it from
> scratch and would need advanced knowledge to do so.
So here's my next question - well it's not a new question...
There is another open source GPL Java virtual machine for Windows Mobile, called Mysaifu. It runs Java 6 bytecode and the class library is derived from GNU Classpath. In other words, I think all the Win CE specific coding was done by Mysaifu's creator. It runs GNU CP Swing.
The major problem with it is that it does not have a JIT so it's slow to begin with, plus Classpath Swing is buggy anyway to my possibly mistaken understanding. The net result is that certain components, like JFileChooser and JTree, are extremely unresponsive.
And although it's very impressive, it is after all an individual's project and so it's not all that actively worked on.
So maybe one could take some classes or dlls from there?
>No, Java 5.0 bytecodes have a different major/minor version number
>(49.0) and will give an Unsupported Class Version exception with the
>current CVM in phoneME which works with version 48.0 and lower.
I must be mistaken, but I'm pretty sure I remember it working.
I wrote a little IDE to write Java programs on my phone, using SWT. The IDE ran on Mysaifu (so I could use generics etc. but also because it has a graphical launcher), but to compile it invoked ECJ (the eclipse compiler) in CVM - Mysaifu was way too slow. (To edit it invoked cke, a really neat programmer's editor - customizable syntax hilighting...)
Anyway, since Mysaifu did not support tracking an external process's standard out, I tried to see if CVM could run an external process, if I remember correctly. So I compiled a test class to run under CVM, and it said that the couldn't read class version 50.0 - ecj compiled for Java 6 by default. So I recompiled with -5 to generate Java 5 bytecode, and then it worked well enough to tell me that I was referencing a non-existent class. So I ended up finding out the command line to log ecj's output to a file, and loading that file in the compiler output tab... Maybe I'm confusing something...
> I'd suggest to look at LWUIT instead. All of the power of Swing/AGUI,
> and is open sourced and works on phoneME Advanced:
Does it have a tree component? Unless I'm confusing LWUIT with something else, I seem to recall that advanced components were in a extra third party package that was in development that would eventually be available for free for personal use.
Anyway what I really want to get working is SwingX ... 
|
|
|
|
|
|
|
|
|
Re: Mix and match to support Java 5 or 6
Posted:
Sep 19, 2008 9:19 PM
in response to: naftoligug
|
|
|
phonemeadvanced@mobileandembedded.org wrote:
> But isn't that all considered a part of AWT? The Graphics class is in the java.awt package, isn't it?
> Anyway, this: http://www.cs.kuleuven.be/~davy/phoneme/image/screenshot1.gif is graphics primitives, isn't it?
>
No, unfortunately the primitives found in AWT Graphics are not the same
as the ones that map Swing down to a native graphics toolkit or native
UI renderer. They are similar but not exact enough to port directly.
So, that's where the non-trivial work would be to map it that way. It's
been done before, but there is not a recent Java SE 6.0-based open
source version of that mapping available. So someone (you?) would have
first analyze the current requirements, come up with a design, then
finally clean-room implement a solution, which is altogether not advisable.
> So here's my next question - well it's not a new question...
> There is another open source GPL Java virtual machine for Windows Mobile, called Mysaifu. It runs Java 6 bytecode and the class library is derived from GNU Classpath. In other words, I think all the Win CE specific coding was done by Mysaifu's creator. It runs GNU CP Swing.
> The major problem with it is that it does not have a JIT so it's slow to begin with, plus Classpath Swing is buggy anyway to my possibly mistaken understanding. The net result is that certain components, like JFileChooser and JTree, are extremely unresponsive.
> And although it's very impressive, it is after all an individual's project and so it's not all that actively worked on.
> So maybe one could take some classes or dlls from there?
>
I don't know anything about Mysaifu, so I cannot comment.
> I must be mistaken, but I'm pretty sure I remember it working.
> I wrote a little IDE to write Java programs on my phone, using SWT. The IDE ran on Mysaifu (so I could use generics etc. but also because it has a graphical launcher), but to compile it invoked ECJ (the eclipse compiler) in CVM - Mysaifu was way too slow. (To edit it invoked cke, a really neat programmer's editor - customizable syntax hilighting...)
> Anyway, since Mysaifu did not support tracking an external process's standard out, I tried to see if CVM could run an external process, if I remember correctly. So I compiled a test class to run under CVM, and it said that the couldn't read class version 50.0 - ecj compiled for Java 6 by default. So I recompiled with -5 to generate Java 5 bytecode, and then it worked well enough to tell me that I was referencing a non-existent class. So I ended up finding out the command line to log ecj's output to a file, and loading that file in the compiler output tab... Maybe I'm confusing something...
>
I don't know what "recompiled with -5" means, so I cannot comment.
Maybe someone who knows Eclipse and/or Mysaifu can help answer your
question.
> Does it have a tree component? Unless I'm confusing LWUIT with something else, I seem to recall that advanced components were in a extra third party package that was in development that would eventually be available for free for personal use.
> Anyway what I really want to get working is SwingX ...
>
>
No, I don't think LWUIT has a Tree component, but many usability
engineers (human factor /human interface engineers) would argue you
really should not be using a Tree component on a small device with a
limited resolution screen.
With small devices, the desktop-orient UI toolkit represented by Swing
doesn't make all that much sense, since a desktop environment is very
different than a cell phone or PDA. Sometimes, it is better not to take
a UI model directly from the desktop to try to apply to small devices.
Hinkmond
---------------------------------------------------------------------
To unsubscribe, e-mail: advanced-unsubscribe@phoneme.dev.java.net
For additional commands, e-mail: advanced-help@phoneme.dev.java.net
|
|
|
|
|
|
|
|
|
Re: Mix and match to support Java 5 or 6
Posted:
Sep 22, 2008 2:43 PM
in response to: Hinkmond Wong
|
|
|
> No, unfortunately the primitives found in AWT Graphics are not the same
> as the ones that map Swing down to a native graphics toolkit or native
> UI renderer. They are similar but not exact enough to port directly.
Would you be able to be more specific - reference specific classes/methods as examples? Thanks!
> I don't know anything about Mysaifu, so I cannot comment.
Anyone?
Anyway, if it would work, since they're both GPL is there any reason not to incorporate his work into phoneME?
> So I recompiled with -5 to generate Java 5 bytecode, and
...
> I don't know what "recompiled with -5" means, so I cannot comment.
> Maybe someone who knows Eclipse and/or Mysaifu can help answer your question.
As I said, it's the option that specifies to generate 5.0 bytecode instead of Java 6 -- it's the like target option. Anyway, I guess I'll have to try it out again...
> No, I don't think LWUIT has a Tree component, but many usability
> engineers (human factor /human interface engineers)
> would argue you really should not be using a Tree component on a
> small device with a limited resolution screen.
>
> With small devices, the desktop-orient UI toolkit represented by Swing
> doesn't make all that much sense, since a desktop environment is very
> different than a cell phone or PDA. Sometimes, it is better not to take
> a UI model directly from the desktop to try to apply to small devices.
I agree, but there are always edge cases. In my case, I'm not developing some superb product to distribute worldwide, just personal coding. For example, the "pocket IDE" I mentioned, and testing/developing self-contained components away from the desktop computer.
Also, LWUIT is designed for all Java ME phones, some of them to which your argument possible applies more than a Windows Mobile device.
By the way if anyone is interested in the "IDE" to help compile Java on a phone, or to help develop it, let me know!
Again, I really appreciate your taking the time to answer my questions.
|
|
|
|
|
|
|
|
|
Re: Mix and match to support Java 5 or 6
Posted:
Sep 23, 2008 4:38 PM
in response to: naftoligug
|
|
|
phonemeadvanced@mobileandembedded.org wrote:
>> No, unfortunately the primitives found in AWT Graphics are not the same
>> as the ones that map Swing down to a native graphics toolkit or native
>> UI renderer. They are similar but not exact enough to port directly.
>>
> Would you be able to be more specific - reference specific classes/methods as examples? Thanks!
>
Yes, look inside these files for an example of the phoneME AWT drawing
primitives:
src/share/basis/classes/awt/qt/*.java
See the equivalent in the repo:
https://phoneme.dev.java.net/svn/phoneme/components/cdc/trunk/src/share/basis/classes/awt/qt/java/awt/
For example, look in QtImage.java and note native primitive graphics
method pDrawImage().
That AWT primitive method calls over to a native peer:
src/share/basis/native/awt/qt/QtImage.cpp
Seee equivalent:
https://phoneme.dev.java.net/svn/phoneme/components/cdc/trunk/src/share/basis/native/awt/qt/QtImage.cpp
which maps to a Qt native primitive called p.drawPixmap().
So, you see how AWT has a specific mapping from the QtImage.java AWT
peer Java class to a specific QtImage.cpp native Qt C++ function call in
order for AWT to draw an image file onto the screen.
The above shows how phoneME AWT is really "bolted" onto a native GUI
toolkit (like Qt). Swing is more abstract and is instead "bolted" onto
a Swing renderer which is not as deeply tied to a native toolkit (like
Qt above), instead it uses a different set of Java classes, packages,
abstractions and UI model in general to allow for more rendering
functionality to be done on the Java side instead of the native side.
You could try to unbolt one and bolt it to the other, but it would be
very mismatched (in levels of abstraction) and the effort to do
something like that would result in a low reward.
> Anyone?
> Anyway, if it would work, since they're both GPL is there any reason not to incorporate his work into phoneME?
>
I'd turn that around. Is there a good reason to spend the effort to
incorporate it into phoneME? I don't see much demand for it. If you
had 7 or 8 other developers also asking the same thing, then I would say
there might be a reason. But, it does not seem to be in high demand
currently.
But, as you point out, if you are doing this as an individual
investigation, that's fine since all the code is GPL and you can do
whatever type of development you'd like to explore and share with this
forum.
Buying back the code and incorporating into the phoneME main development
trunk would be a different issue, since there is limited resource to
help you do that. Feel free, though, to experiment with phoneME as you
see fit. Part of the benefits of open source projects like phoneME is
seeing all the new and interesting ways in which the phoneME code is
used and in ways that haven't been thought of yet.
Hinkmond
---------------------------------------------------------------------
To unsubscribe, e-mail: advanced-unsubscribe@phoneme.dev.java.net
For additional commands, e-mail: advanced-help@phoneme.dev.java.net
|
|
|
|
|
|
|
|
|
Re: Mix and match to support Java 5 or 6
Posted:
Sep 24, 2008 8:10 PM
in response to: Hinkmond Wong
|
|
|
I appreciate those details, but what I meant to ask is where specifically is Swing "bolted" to anything native, and not just sitting on top of whatever particular implementation AWT happens to be available.
In terms of the benefit of taking code from Mysaifu, for me I guess it's mainly to try Mysaifu AWT + Sun Java SE Swing, if that makes sense...
But the benefit for you is 1) if there's anything in AWT that you don't have working, maybe he has it; 2) do you have sound working? I think he officially does, although I didn't get it to work (may be due to lack of fluency in the APIs). He definitely has a dll for sound.
What did you mean by limited resources? Assistance, or capacity?
|
|
|
|
|
|
|
|
|
Re: Mix and match to support Java 5 or 6
Posted:
Sep 24, 2008 8:22 PM
in response to: naftoligug
|
|
|
phonemeadvanced@mobileandembedded.org wrote:
> I appreciate those details, but what I meant to ask is where specifically is Swing "bolted" to anything native, and not just sitting on top of whatever particular implementation AWT happens to be available.
>
Swing (in Java SE 6.0) is not just sitting on top of whatever particular
implementation of AWT is available. I'm not sure where you got this
idea from. There was a very old version of Swing (back in 1.2 I think)
that was like that and could sit on AWT, but is not that way anymore.
So, you might be mistakenly thinking of an obsolete version of Swing
that is not supported anymore.
> In terms of the benefit of taking code from Mysaifu, for me I guess it's mainly to try Mysaifu AWT + Sun Java SE Swing, if that makes sense...
> But the benefit for you is 1) if there's anything in AWT that you don't have working, maybe he has it; 2) do you have sound working? I think he officially does, although I didn't get it to work (may be due to lack of fluency in the APIs). He definitely has a dll for sound.
> What did you mean by limited resources? Assistance, or capacity?
>
No, unfortunately there's nothing from Mysaifu that is a big benefit for
phoneME currently (from your list above). By limited resources, I mean
there is not enough time that someone can spend on this issue to help
you, especially since there is not very much demand for it (only you so
far are interested in it). If you had more people interested in it,
perhaps you can form a developers group yourselves to work on the
changes needed to implement it?
Hinkmond
---------------------------------------------------------------------
To unsubscribe, e-mail: advanced-unsubscribe@phoneme.dev.java.net
For additional commands, e-mail: advanced-help@phoneme.dev.java.net
|
|
|
|
|
|
|
|
|
Re: Mix and match to support Java 5 or 6
Posted:
Sep 24, 2008 8:37 PM
in response to: Hinkmond Wong
|
|
|
Okay, I'm just asking where does it reference a native library?
By sitting on top of I just meant that it inherits from AWT Component and calls AWT methods, as opposed to whatever else it depends on besides AWT. That's what I'm asking - where are the dependencies outside of Swing itself and AWT located? I couldn't find any native functions declared in Swing.
|
|
|
|
|
|
|
|
|
Re: Mix and match to support Java 5 or 6
Posted:
Sep 24, 2008 9:01 PM
in response to: naftoligug
|
|
|
phonemeadvanced@mobileandembedded.org wrote:
> Okay, I'm just asking where does it reference a native library?
>
Sorry, you'd have to check yourself. I don't have a pointer or
reference to Swing source code, since our phoneME repository only has
Personal Profile and Personal Basis Profile (AWT) source code in it.
> By sitting on top of I just meant that it inherits from AWT Component and calls AWT methods, as opposed to whatever else it depends on besides AWT. That's what I'm asking - where are the dependencies outside of Swing itself and AWT located? I couldn't find any native functions declared in Swing
You might want to check with the OpenJDK forum. They might be able to
help better. Swing components (such as JButton, JLabel, etc.) do not
inherit from AWT.
Hinkmond
---------------------------------------------------------------------
To unsubscribe, e-mail: advanced-unsubscribe@phoneme.dev.java.net
For additional commands, e-mail: advanced-help@phoneme.dev.java.net
|
|
|
|
|
|
|
|
|
Re: Mix and match to support Java 5 or 6
Posted:
Sep 24, 2008 8:16 PM
in response to: Hinkmond Wong
|
|
|
P.S. I looked into the java 5 bytecode question again, and I didn't yet have anything running - there's an exception thrown which I didn't debug yet (java.sql.DriverManager getConnection(?) calling ditto.getCallingClassloader(?) or something like that creates an UnsatisfiedLinkError. But that means it's reading 5.0 class files. These class files are taken from the JDK 5. (Actually I extracted it from the MSI the installer creates using 7zip without actually installing it!) Am I crazy, or am I missing something? Or does it load the class but encounter incompatibility trouble later? 6.0 class files generate an error right away about invalid class version.
|
|
|
|
|
|
|
|
|
Re: Mix and match to support Java 5 or 6
Posted:
Sep 24, 2008 8:27 PM
in response to: naftoligug
|
|
|
phonemeadvanced@mobileandembedded.org wrote:
> P.S. I looked into the java 5 bytecode question again, and I didn't yet have anything running - there's an exception thrown which I didn't debug yet (java.sql.DriverManager getConnection(?) calling ditto.getCallingClassloader(?) or something like that creates an UnsatisfiedLinkError. But that means it's reading 5.0 class files. These class files are taken from the JDK 5. (Actually I extracted it from the MSI the installer creates using 7zip without actually installing it!) Am I crazy, or am I missing something? Or does it load the class but encounter incompatibility trouble later? 6.0 class files generate an error right away about invalid class version.
>
>
I don't know about ECJ, so I can't comment. You might want to ask an
ECJ support forum instead.
Hinkmond
---------------------------------------------------------------------
To unsubscribe, e-mail: advanced-unsubscribe@phoneme.dev.java.net
For additional commands, e-mail: advanced-help@phoneme.dev.java.net
|
|
|
|
|
|
|
|
|
Re: Mix and match to support Java 5 or 6
Posted:
Sep 24, 2008 8:33 PM
in response to: Hinkmond Wong
|
|
|
> I don't know about ECJ, so I can't comment. You
> might want to ask an
> ECJ support forum instead.
This has nothing to do with ecj. These are Sun Java SE 5 classes being interpreted by cvm (although I admit that the class that invokes them was compiled with ecj but that's not my point).
|
|
|
|
|
|
|
|
|
Re: Mix and match to support Java 5 or 6
Posted:
Sep 24, 2008 8:58 PM
in response to: naftoligug
|
|
|
phonemeadvanced@mobileandembedded.org wrote:
>> I don't know about ECJ, so I can't comment. You
>> might want to ask an
>> ECJ support forum instead.
>>
> This has nothing to do with ecj. These are Sun Java SE 5 classes being interpreted by cvm (although I admit that the class that invokes them was compiled with ecj but that's not my point)
Any Java SE 5 class that was compiled by javac (not ecj) will throw an
exception (Unsupported Class Version) when run with CVM (unless you use
the -source 1.4 -target 1.4 javac flags)
So, it's an ECJ-specific issue you are seeing.
Hinkmond
---------------------------------------------------------------------
To unsubscribe, e-mail: advanced-unsubscribe@phoneme.dev.java.net
For additional commands, e-mail: advanced-help@phoneme.dev.java.net
|
|
|
|
|
|
|
|
|
Re: Mix and match to support Java 5 or 6
Posted:
Sep 25, 2008 11:22 AM
in response to: Hinkmond Wong
|
|
|
Okay. I compiled and ran a test program that creates an Array<String>, populates it, and uses the enhanced for loop to print it. The ArrayList class is from Sun Java SE 5, so it was probably compiled with javac. I would attach the class file if there was a way to, but looking at it with a hex editor clearly shows class version 49:
00000000: ca fe ba be
00000004: 00 00 00 31 | . . . .
00000008: 00 4b 07 00 | . . . .
0000000c: 02 01 00 09 | . . . .
00000010: 54 65 73 74 | Test
.
:
(copied manually off pocket pc's screen)
Anyway, more importantly - it seems certain core classes are not read from the included rt.jar or from the boot classpath that I specify. Are the core classes built in? I'm using build 75 from Davy Preuveneers's site (I'm about to upgrade). Certainly some classes are swappable, but some don't seem to get picked up. How would I get around that?
(By the way, the problem with DriverManager was that the Sun implementation uses a native method to get the caller class loader. Apparently the Classpath implementation doesn't bother.)
Also, I assume that likewise there is no problem for the developer of Mysaifu to take code from phoneME. Am I correct?
Thanks!
|
|
|
|
|
|
|
|
|
Re: Mix and match to support Java 5 or 6
Posted:
Sep 25, 2008 5:11 PM
in response to: naftoligug
|
|
|
phonemeadvanced@mobileandembedded.org wrote:
> Okay. I compiled and ran a test program that creates an Array<String>, populates it, and uses the enhanced for loop to print it. The ArrayList class is from Sun Java SE 5, so it was probably compiled with javac. I would attach the class file if there was a way to, but looking at it with a hex editor clearly shows class version 49:
> 00000000: ca fe ba be
> 00000004: 00 00 00 31 | . . . .
>
Yes, that actually confirms that the class you dumped out above will not
work with CVM, but instead will throw an Unsupported Class Version
exception. CVM will only work with version 48.0 (Java SE 1.4.2-based)
class files or earlier.
> Anyway, more importantly - it seems certain core classes are not read from the included rt.jar or from the boot classpath that I specify. Are the core classes built in? I'm using build 75 from Davy Preuveneers's site (I'm about to upgrade). Certainly some classes are swappable, but some don't seem to get picked up. How would I get around that?
>
When you say "certain core classes", you are mistakenly referring also
to certain classes found in Java SE. There are Java SE classes that are
not allowed to run on Java ME CDC/Foundation Profile (phoneME Advanced)
on CVM. The real core classes of CDC/FndP are instead specified in JSR
219 and are already built into a phoneME Advanced CVM build of
CDC/FndP/Personal Basis Profile or Personal Profile (like what Davy P.
provides on WinMobile).
See:
http://java.sun.com/javame/reference/apis/jsr219/
and
http://java.sun.com/javame/reference/apis/jsr216/
So, technically, you are not supposed to add anything above and beyond
what you find in the above specifications. If you do try to add
anything to phoneME Advanced beyond what you find in the JSRs 219 and
216 specs, you may get (as intended) unexpected results with exceptions
thrown (which is what you see).
> (By the way, the problem with DriverManager was that the Sun implementation uses a native method to get the caller class loader. Apparently the Classpath implementation doesn't bother.)
> Also, I assume that likewise there is no problem for the developer of Mysaifu to take code from phoneME. Am I correct
phoneME is licensed under GPL. So, any developer anywhere can take and
use phoneME source code as they like, but must publicly make available
all of their source code changes, also under the GPL.
See:
https://mobileandembedded.dev.java.net/content/license.txt
Hinkmond
---------------------------------------------------------------------
To unsubscribe, e-mail: advanced-unsubscribe@phoneme.dev.java.net
For additional commands, e-mail: advanced-help@phoneme.dev.java.net
|
|
|
|
|
|
|
|
|
Re: Mix and match to support Java 5 or 6
Posted:
Oct 12, 2008 7:18 PM
in response to: Hinkmond Wong
|
|
|
Sorry for not replying sooner.
> Yes, that actually confirms that the class you dumped out above will not
> work with CVM, but instead will throw an Unsupported Class Version
> exception. CVM will only work with version 48.0 (Java SE 1.4.2-based)
> class files or earlier.
But that's exactly my point. I hear you loud and clear the it's not supposed to run. But it does!!
> When you say "certain core classes", you are
> mistakenly referring also
What I'm saying is that when I point the boot class path to a different location for classes like java.lang.Integer, it doesn't use the alternatives. Even renaming btclasses.zip does nothing. The question is how to supply alternative bootstrap classes.
|
|
|
|
|
|
|
|
|
Re: Mix and match to support Java 5 or 6
Posted:
Sep 26, 2008 10:48 AM
in response to: Hinkmond Wong
|
|
|
> No, I don't think LWUIT has a Tree component, but
> many usability
> engineers (human factor /human interface engineers)
> would argue you
> really should not be using a Tree component on a
> small device with a
> limited resolution screen.
>
> With small devices, the desktop-orient UI toolkit
> represented by Swing
> doesn't make all that much sense, since a desktop
> environment is very
> different than a cell phone or PDA. Sometimes, it is
> better not to take
> a UI model directly from the desktop to try to apply
> to small devices.
Hinkmond, this is a very good point and one that is not often enough mentioned when discussing Java on mobile devices. I often see this automatic assumption that Swing is "just better" than AWT. I'm not saying that AWT is good, but that Swing isn't necessarily better. I look forward to seeing LWUIT running on pMEA Personal.
|
|
|
|
|
java.net RSS
