Thread: RE: [java-gnome-hackers] String changes
Brought to you by:
afcowie
Menu
▾
▴
java-gnome-hackers
|
From: Jeffrey M. <Jef...@Br...> - 2003-03-20 12:43:10
|
My only concern is that this is a very significant change.
It will not be as simple as just regenerating the generated
code since I have made changes and optimizations to many
of the generated classes. Still, I think this is the right
thing to do. Perhaps we should divide this activity up
between several people to expedite the process.
-Jeff
-----Original Message-----
From: Mark Howard [mailto:mh...@ti...]
Sent: Wednesday, March 19, 2003 4:22 PM
To: jav...@li...
Subject: [java-gnome-hackers] String changes
Hi,
As discussed at the start of the year,
I'd like to make some big changes to the way we handle passing of
strings. The current code has major issues on some (non-Sun) Java
environments (when working with zero length strings) and also does not
take into account charset encoding.
These changes:
* use (*env)->GetStringUTFChars rather than
jint str_len = (*env)->GetArrayLength(env, str);
gchar* str_g = (gchar*)g_malloc(str_len + 1);
(*env)->GetByteArrayRegion(env, str, 0, str_len, (jbyte*)str_g);
str_g[str_len] = 0;
* Also call (*env)->ReleaseStringUTFChars(env, str, str_g);
- As far as I can see, the old code is wrong in that it should have
been calling ReleaseByteArrayElements when done
- please let me know if you don't agree with this.
The attached files demonstrate the changes I propose. Test.c shows both
the current and proposed methods
They can be executed using
gcc -c -g -O2 -fPIC Test.c -o Test.o -I/usr/include/gtk-2.0
-I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0
-I/usr/include/pango-1.0 -I/usr/include/freetype2
-I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include
gcc -g -O2 -fPIC -shared -o libTest.so Test.o -Wl,--export-dynamic
-lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lm
-lpangoxft-1.0 -lpangox-1.0 -lpango-1.0 -lgobject-2.0 -lgmodule-2.0 -ldl
-lglib-2.0 -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include
-I/usr/include/atk-1.0 -I/usr/include/pango-1.0 -I/usr/include/freetype2
-I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -Xlinker
--no-undefined
javac TestClass.java
LD_LIBRARY_PATH=. java TestClass
In my tests, the new code always also has improved performance (Java
1.4.1)
The changes would require regenerating all the generated code and
(hopefully semi-automatically) changing all calls to these.
Any comments?
--
.''`. Mark Howard
: :' :
`. `' http://www.tildemh.com
`- mh...@de... | mh...@ti... | mh...@ca...
|
|
From: Jeffrey M. <Jef...@Br...> - 2003-03-20 22:22:39
|
The manual approach does seem to be the least intrusive. I vote for this approach. -Jeff -----Original Message----- From: Tom Ball [mailto:Tom...@Su...] Sent: Thursday, March 20, 2003 12:17 PM To: java-gnome-hackers Subject: Re: [java-gnome-hackers] String changes The way strings are handled has been bothering me as well, most recently in finding that repeatedly calling TextBuffer.setText leaks native memory in a manner I haven't figured out yet. To clean it up, I modified the code in the same manner Mark described. Your point about not supporting charset encoding is an excellent one -- GNOME more than many projects is sensitive to internationalization issues, so we can't ignore this problem and stay in step with GNOME. Since Java and GTK already share the same internal String format, we will reduce the code overhead and improve compatibility with this change. At JavaSoft we used to call that sort of enhancement request a "no-brainer", in that it was a change even a clueless exec would approve. :-) Like Jeffrey, I'm nervous about regenerating the existing source files. By all means update the generator so that new files are created correctly, but most of your conversion impacts native code rather than the generated Java code. Since most of the conversion has to be done by hand any way, let's do it all by hand so each class can be converted individually to minimize breakage. Doing it piecemeal keeps the source base functional without anyone having to pull an all-nighter. To avoid duplication of effort, how about if we notify others before converting any major classes? I have TextBuffer half-done already, so unless there are objections, I'll finish it and put it back today. Tom On Wed, 2003-03-19 at 13:22, Mark Howard wrote: > Hi, > As discussed at the start of the year, > I'd like to make some big changes to the way we handle passing of > strings. The current code has major issues on some (non-Sun) Java > environments (when working with zero length strings) and also does not > take into account charset encoding. > > These changes: > * use (*env)->GetStringUTFChars rather than > jint str_len = (*env)->GetArrayLength(env, str); > gchar* str_g = (gchar*)g_malloc(str_len + 1); > (*env)->GetByteArrayRegion(env, str, 0, str_len, (jbyte*)str_g); > str_g[str_len] = 0; > * Also call (*env)->ReleaseStringUTFChars(env, str, str_g); > - As far as I can see, the old code is wrong in that it should have > been calling ReleaseByteArrayElements when done > - please let me know if you don't agree with this. > > > The attached files demonstrate the changes I propose. Test.c shows both > the current and proposed methods > They can be executed using > gcc -c -g -O2 -fPIC Test.c -o Test.o -I/usr/include/gtk-2.0 > -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 > -I/usr/include/pango-1.0 -I/usr/include/freetype2 > -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include > > gcc -g -O2 -fPIC -shared -o libTest.so Test.o -Wl,--export-dynamic > -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lm > -lpangoxft-1.0 -lpangox-1.0 -lpango-1.0 -lgobject-2.0 -lgmodule-2.0 -ldl > -lglib-2.0 -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include > -I/usr/include/atk-1.0 -I/usr/include/pango-1.0 -I/usr/include/freetype2 > -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -Xlinker > --no-undefined > > javac TestClass.java > LD_LIBRARY_PATH=. java TestClass > > In my tests, the new code always also has improved performance (Java > 1.4.1) > > The changes would require regenerating all the generated code and > (hopefully semi-automatically) changing all calls to these. > > Any comments? -- Tom Ball <Tom...@Su...> ------------------------------------------------------- This SF.net email is sponsored by: Tablet PC. Does your code think in ink? You could win a Tablet PC. Get a free Tablet PC hat just for playing. What are you waiting for? http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en _______________________________________________ java-gnome-hackers mailing list jav...@li... https://lists.sourceforge.net/lists/listinfo/java-gnome-hackers |
|
From: Mark H. <mh...@ti...> - 2003-03-21 12:29:40
|
On Thu, 2003-03-20 at 22:22, Jeffrey Morgan wrote: > The manual approach does seem to be the least intrusive. I > vote for this approach. I've created a file src/jni/TODO containing the names of the files which still need to be done. Please delete names from it when you've fixed them. I think just sending a mail to this list before you start work on a set of files would be the best way to avoid duplication. I'd like to start with gtk Label, Frame and Tree widgets. -- .''`. Mark Howard : :' : `. `' http://www.tildemh.com `- mh...@de... | mh...@ti... | mh...@ca... |
|
From: Tom B. <Tom...@Su...> - 2003-03-21 19:36:47
|
I'll finish up the GTK text widgets. I was holding back because Mark had recently made them functional (didn't want to step on his good work), but was shocked to find that the generator downcasts the returned gunichar from gtk_text_iter_get_char() as a jbyte. We might as well post a sign saying that only customers whose customer sets can be defined in seven bits need bother with our library! Oh, the horror... Tom |
|
From: Jeffrey M. <Jef...@Br...> - 2003-03-20 22:36:19
|
The changes were to remove warnings and bad casts that were in the generated C code. I probably changed about one third of the classes. It was much easier to do this than to get the generator to produce accurate code in each instance. -Jeff -----Original Message----- From: Mark Howard [mailto:mh...@ti...] Sent: Thursday, March 20, 2003 10:40 AM To: jav...@li... Subject: RE: [java-gnome-hackers] String changes On Thu, 2003-03-20 at 12:17, Jeffrey Morgan wrote: > My only concern is that this is a very significant change. > It will not be as simple as just regenerating the generated > code since I have made changes and optimizations to many > of the generated classes. Still, I think this is the right > thing to do. Perhaps we should divide this activity up > between several people to expedite the process. Yes, it is a significant change, but one I believe is worth it. In particular, it allows java-gnome to be used with many free JVM's, which I believe should be a goal of the project. Dividing the activity is a good idea, if people are able to. I think, however, that much of the work can be partially automated - most of the java calls to strings are done using getBytes() - we could do a big find & replace (with manual verification for each). Any other changes then required should show up as compile errors. By optimisations, do you mean changes in the BEGINNING OF GENERATED CODE section? If so, can you remember what you've changed (or could we regenerate the current code and test for changes?) The only such changes I've made is adding comments to the constants in some of the classes converted from enums. Enums won't be changed by this proposal, so we can ignore those in the update. We should also decide if there are any other changes which should be made to the code generator before going ahead. I can only think of two minor ones: - add a space in the comment for the start/end of generated code (so it doesn't confuse javadoc) - change generated enum integer constants to private (I have done this on the current code using a simple find/replace) Are there any changes in Gtk2.2 which might be worth looking at at this stage? I know it's API compatible with 2.0, but are there any additional functions? -- .''`. Mark Howard : :' : `. `' http://www.tildemh.com `- mh...@de... | mh...@ti... | mh...@ca... ------------------------------------------------------- This SF.net email is sponsored by: Tablet PC. Does your code think in ink? You could win a Tablet PC. Get a free Tablet PC hat just for playing. What are you waiting for? http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en _______________________________________________ java-gnome-hackers mailing list jav...@li... https://lists.sourceforge.net/lists/listinfo/java-gnome-hackers |
|
From: Jeffrey M. <Jef...@Br...> - 2003-03-21 15:54:08
|
I will work on the glib and gdk packages. -Jeff -----Original Message----- From: Mark Howard [mailto:mh...@ti...] Sent: Friday, March 21, 2003 7:29 AM To: jav...@li... Subject: RE: [java-gnome-hackers] String changes On Thu, 2003-03-20 at 22:22, Jeffrey Morgan wrote: > The manual approach does seem to be the least intrusive. I > vote for this approach. I've created a file src/jni/TODO containing the names of the files which still need to be done. Please delete names from it when you've fixed them. I think just sending a mail to this list before you start work on a set of files would be the best way to avoid duplication. I'd like to start with gtk Label, Frame and Tree widgets. -- .''`. Mark Howard : :' : `. `' http://www.tildemh.com `- mh...@de... | mh...@ti... | mh...@ca... ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ java-gnome-hackers mailing list jav...@li... https://lists.sourceforge.net/lists/listinfo/java-gnome-hackers |
|
From: Mark H. <mh...@ti...> - 2003-03-23 16:53:03
|
On Fri, 2003-03-21 at 15:29, Jeffrey Morgan wrote: > I will work on the glib and gdk packages. > -----Original Message----- > From: Mark Howard [mailto:mh...@ti...] > I'd like to start with gtk Label, Frame and Tree widgets. Sorry, I should have said I included glib.Value and Type as part of this. I've also done some of the other gtk widgets. I'd now like to start looking at the gnome widgets as I have a strong suspicion that this string issue is what's been causing so many problems for me. -- .''`. Mark Howard : :' : `. `' http://www.tildemh.com `- mh...@de... | mh...@ti... | mh...@ca... |
|
From: Jeffrey M. <ku...@zo...> - 2003-03-23 21:48:58
|
I have completed the glib, gdk, atk, and pango packages. -Jeff On Sun, 2003-03-23 at 11:52, Mark Howard wrote: > On Fri, 2003-03-21 at 15:29, Jeffrey Morgan wrote: > > I will work on the glib and gdk packages. > > -----Original Message----- > > From: Mark Howard [mailto:mh...@ti...] > > I'd like to start with gtk Label, Frame and Tree widgets. > > Sorry, I should have said I included glib.Value and Type as part of > this. > I've also done some of the other gtk widgets. > > I'd now like to start looking at the gnome widgets as I have a strong > suspicion that this string issue is what's been causing so many problems > for me. -- Jeffrey Morgan <ku...@zo...> |
|
From: Mark H. <mh...@ti...> - 2003-03-20 15:40:39
|
On Thu, 2003-03-20 at 12:17, Jeffrey Morgan wrote: > My only concern is that this is a very significant change. > It will not be as simple as just regenerating the generated > code since I have made changes and optimizations to many > of the generated classes. Still, I think this is the right > thing to do. Perhaps we should divide this activity up > between several people to expedite the process. Yes, it is a significant change, but one I believe is worth it. In particular, it allows java-gnome to be used with many free JVM's, which I believe should be a goal of the project. Dividing the activity is a good idea, if people are able to. I think, however, that much of the work can be partially automated - most of the java calls to strings are done using getBytes() - we could do a big find & replace (with manual verification for each). Any other changes then required should show up as compile errors. By optimisations, do you mean changes in the BEGINNING OF GENERATED CODE section? If so, can you remember what you've changed (or could we regenerate the current code and test for changes?) The only such changes I've made is adding comments to the constants in some of the classes converted from enums. Enums won't be changed by this proposal, so we can ignore those in the update. We should also decide if there are any other changes which should be made to the code generator before going ahead. I can only think of two minor ones: - add a space in the comment for the start/end of generated code (so it doesn't confuse javadoc) - change generated enum integer constants to private (I have done this on the current code using a simple find/replace) Are there any changes in Gtk2.2 which might be worth looking at at this stage? I know it's API compatible with 2.0, but are there any additional functions? -- .''`. Mark Howard : :' : `. `' http://www.tildemh.com `- mh...@de... | mh...@ti... | mh...@ca... |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X