Re: I18N on native (was:Re: [jira] Commented: (HARMONY-815) [classlib][nio] Refine implConfigureBlocking(boolean) method of DatagramChannel and SocketChannel.)
Hi Vladimir, Where exceptions should be thrown is a big question in this thread. Native code or Java code or mixed? Shall we avoid throwing all exceptions in Harmony native code? If all exceptions are thrown in java code, there is no need to involve any other I18N utilities (i.e. log4cXXX). Really appreciated if anyone could summarize the advantages and disadvantages of these two exeption-thrown ways (by native or java). Thanks! On 7/13/06, Vladimir Gorr [EMAIL PROTECTED] wrote: On 7/13/06, Jimmy, Jing Lv [EMAIL PROTECTED] wrote: Hi: I'd like to raise the topic on I18N of native code. As discussed about patch-815, we found there are exceptions thrown by native code with un-internationalized error message. To resolve this problem, there may be two solutions: 1) make native code return error code instead of throw exceptions, and let Java code deal with these errors. This seems pretty good, and also resolve such problems like 815, but require much more effort to refactor all native and Java codes. What's more, as some native methods do not return an integer at all, we may add an output parameter to them, at least for network-related luni/nio, there are about 10 methods like this. 2) As it is still easy for native code to call Java code, so rewrite error-message-lookup native method to lookup internationalized message, e.g., call MsgUtil.getString(). This refactor may be easy, but to JIRA-815 and other message-dependent Java code, it do no help. So it still requires other refactoring, e.g., return error code in some situation like suggested in (1). Indeed we need to i18d the native code to resolve this issue. I'd suggest to use the log4cxx resource bundle approach for doing this. This one can be suitable for both VMs API natives. I'm going to create new thread to discuss this approach. Thanks, Vladimir. Another solution can be: catch exceptions on Java code, replace its message, and throw out again, this may be too ugly, so I do not suggest so. Any suggestions? Thanks! -- Best Regards! Jimmy, Jing Lv China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Andrew Zhang China Software Development Lab, IBM
Re: I18N on native (was:Re: [jira] Commented: (HARMONY-815) [classlib][nio] Refine implConfigureBlocking(boolean) method of DatagramChannel and SocketChannel.)
Mikhail Loenko wrote: I suggest that we: 1) avoid throwing exceptions from native code I have no strong feelings yet which is better, to throw Exception in native codes directly or always to return error codes to Java. There are different styles in Java and C programming on error handling, C program generally return error codes and use output parameter if necessary, while Java codes generally separate normal return value and exceptional case. JNI is combined by Java and C, so there must be one side to violate the convention. Throwing exception in native codes makes the codes hard to understand or maintain, while returning error codes may introduce one more time error code conversions[1], further, sometimes not only error code but the error message generated by OS is useful. [1]check out the stack below, there are several error codes set needed: Java codes--platform indepdent native codes--portlib codes--system call 1. system call error codes, which is platform dependent 2. portlib error codes, which is platform independent 3. Java error codes, which is returned by JNI methods to Java, so it needs to be defined in in Java codes(i.e. in generated JNI header files) 4. Java Exception class 2) don't parse exception messages in the code (use subclasses of exceptions when necessary) Agree, String comparison is not good in many ways. Thanks, Mikhail 2006/7/13, Andrew Zhang [EMAIL PROTECTED]: On 7/13/06, Jimmy, Jing Lv [EMAIL PROTECTED] wrote: Hi: I'd like to raise the topic on I18N of native code. As discussed about patch-815, we found there are exceptions thrown by native code with un-internationalized error message. To resolve this problem, there may be two solutions: 1) make native code return error code instead of throw exceptions, and let Java code deal with these errors. This seems pretty good, and also resolve such problems like 815, but require much more effort to refactor all native and Java codes. What's more, as some native methods do not return an integer at all, we may add an output parameter to them, at least for network-related luni/nio, there are about 10 methods like this. May we add an output parameter errorCode in each method. 2) As it is still easy for native code to call Java code, so rewrite error-message-lookup native method to lookup internationalized message, e.g., call MsgUtil.getString(). This refactor may be easy, but to JIRA-815 and other message-dependent Java code, it do no help. So it still requires other refactoring, e.g., return error code in some situation like suggested in (1). Another solution can be: catch exceptions on Java code, replace its message, and throw out again, this may be too ugly, so I do not suggest so. Any suggestions? Thanks! -- Best Regards! Jimmy, Jing Lv China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Andrew Zhang China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Paulex Yang China Software Development Lab IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: I18N on native (was:Re: [jira] Commented: (HARMONY-815) [classlib][nio] Refine implConfigureBlocking(boolean) method of DatagramChannel and SocketChannel.)
On 7/13/06, Andrew Zhang [EMAIL PROTECTED] wrote: Hi Vladimir, Where exceptions should be thrown is a big question in this thread. Native code or Java code or mixed? Yes, I'm aware about this. However I'd prefer to have other subject for this thread :-). Thanks, Vladimir. Shall we avoid throwing all exceptions in Harmony native code? If all exceptions are thrown in java code, there is no need to involve any other I18N utilities (i.e. log4cXXX). Really appreciated if anyone could summarize the advantages and disadvantages of these two exeption-thrown ways (by native or java). Thanks! On 7/13/06, Vladimir Gorr [EMAIL PROTECTED] wrote: On 7/13/06, Jimmy, Jing Lv [EMAIL PROTECTED] wrote: Hi: I'd like to raise the topic on I18N of native code. As discussed about patch-815, we found there are exceptions thrown by native code with un-internationalized error message. To resolve this problem, there may be two solutions: 1) make native code return error code instead of throw exceptions, and let Java code deal with these errors. This seems pretty good, and also resolve such problems like 815, but require much more effort to refactor all native and Java codes. What's more, as some native methods do not return an integer at all, we may add an output parameter to them, at least for network-related luni/nio, there are about 10 methods like this. 2) As it is still easy for native code to call Java code, so rewrite error-message-lookup native method to lookup internationalized message, e.g., call MsgUtil.getString(). This refactor may be easy, but to JIRA-815 and other message-dependent Java code, it do no help. So it still requires other refactoring, e.g., return error code in some situation like suggested in (1). Indeed we need to i18d the native code to resolve this issue. I'd suggest to use the log4cxx resource bundle approach for doing this. This one can be suitable for both VMs API natives. I'm going to create new thread to discuss this approach. Thanks, Vladimir. Another solution can be: catch exceptions on Java code, replace its message, and throw out again, this may be too ugly, so I do not suggest so. Any suggestions? Thanks! -- Best Regards! Jimmy, Jing Lv China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Andrew Zhang China Software Development Lab, IBM
[drlvm] proposals for VM internationalization
Hi Harmony community.
I'd like to discuss with you a design for the VM native code
internationalization (attached below).
We'd like to consider this approach for the DRLVM first of all. However it
can be suitable for other parts of Harmony project I suppose.
Please let me know your opinions/objections.
Thanks,
Vladimir .
---
Internationalization design *1. Introduction*
The VM's output needs to be internationalized in order to provide localized
versions of our product.
The key idea is to use ResourceBundle class from apache log4cxx which allow
to store and effective use bundles with localized messages.
The document describes:
· ResourceBundle naming conventions for bundles with localized
messages.
· Structure of* *ResourceBundle file. MessageId (keys for
localized message in ResourceBundle) development guidelines.
· Requirements.
· How it works inside VM.
*Definitions: *
I18n – internationalization
L10n – localization
L7d – localized
*2. ResourceBundle naming conventions for bundles with localized messages. *
We offer to use ResourceBundle class from apache log4cxx as storage of
localized messages. At first time all Resourcebundles are files.
After VM starts, on VM's logging subsystem initialization stage, logging
system chooses appropriate set of ResourceBundles
according to values of environment variables: LC_ALL, LC_MESSAGES, and LANG.
Chosen ResourceBundles should be used for printing localized messages from
VM.
E.g. If the environment variable LANG is equal to ru_RU then the following
set of ResourceBundles should be used (see naming conventions below):
· java_ru_RU.properties
· java_ru.properties
· java.properties
Each file which presents ResourceBundle class should have the following
name:
*java_language_country_variant.properties *where:
_language is a language e.g. _ru (Russian language). It may be empty.
_country is a country e.g. _RU (Russian federation ). It may be empty.
_variant is a variant. It may be empty.
The main ResourceBundle file (with messages on English) should
be java.properties.
*3. Structure of ResourceBundle file. MessageId development guidelines. *
The structure of ResourceBundle file should be the following:
MessageId1=localized message1
MessageId2=localized message2
….
Where:
MessageId{i} – ASCII string on English language. It should consist of vm's
subcomponent name ( e.g. init, port, gc.) and short description of message.
E.g. init.help is localized help message from init subcomponent of VM.
Localized message{i} – localized message.
Localized message can contain parameters. E.g. localized message pattern:
This is message on English with two parameters: parameter number one – {0},
and parameter number two – {1}. We can print it again and in back order:
{1}, {0}. For the first parameter is equal to integer value 1
and the second is equal to string two the message for pattern above should
be:
This is message on English with two parameters: parameter number one – 1,
and parameter number two – two. We can print it again and in back order:
two, 1.
* *
*4. Requirements. *
- All localized messages may be printed through apache log4cxx logger.
- Parameters may be present in localized messages.
- VM-I18N subsystem should automatically detect user's locale
according to values of environment variables.
- Minimize performance impact.
Re: [classlib][nio][discussion] Implementation of java.nio.channels.spi.SelectorProvider.inheritedChannel()
Andrew Zhang wrote: Hello everybody, I plan to implement java.nio.channels.spi.SelectorProvider.inheritedChannel() method. Currently Harmony simply returns null. Spec doesn not specify how to detect inheritedChannel clearly, Returns the channel inherited from the entity that created this Java virtual machine. For example, on UNIX systems, the Internet services daemon (*inetd*) is used to start programs to service requests when a request arrives on an associated network port. In this example, the process that is started, inherits a channel representing a network socket. As my understanding, what inherited channel does is redirect socket to standard input. Therefore, my solution looks like following: Don't need to check the stdout? IIRC inetd redirects both. 1. get standard input file descriptor 2. assert the file descriptor. If it is a socket type descriptor, then returns a channel which wraps the descriptor. I also wrote some samples for ensuring my understanding. It seems OK on linux, but not the case on Window. RI always returns null on Windows (maybe because there is no service daemon program on Windows? or my understanding is totally wrong?) Any chance to get non-null value if inetd is dummied on Windows? Seems some Services for UNIX(SFU) is provided by MS with Windows server 2003, which can mimic the inetd behavior[1]. I'm not sure if it applies to WinXP, too. [1]http://www.microsoft.com/technet/interopmigration/unix/sfu/intdrutil.mspx Therefore, I want to hear suggestions from our community, espeically folks experienced in network! Many thanks in advance! Best regards, -- Paulex Yang China Software Development Lab IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][nio][discussion] Implementation of java.nio.channels.spi.SelectorProvider.inheritedChannel()
On 7/13/06, Paulex Yang [EMAIL PROTECTED] wrote: Andrew Zhang wrote: Hello everybody, I plan to implement java.nio.channels.spi.SelectorProvider.inheritedChannel() method. Currently Harmony simply returns null. Spec doesn not specify how to detect inheritedChannel clearly, Returns the channel inherited from the entity that created this Java virtual machine. For example, on UNIX systems, the Internet services daemon (*inetd*) is used to start programs to service requests when a request arrives on an associated network port. In this example, the process that is started, inherits a channel representing a network socket. As my understanding, what inherited channel does is redirect socket to standard input. Therefore, my solution looks like following: Don't need to check the stdout? IIRC inetd redirects both. Paulex, I don't thin it's necessary. Even if stdout/stderr are not redirected, RI still returns inherited channel as long as stdin is redirected on Linux. 1. get standard input file descriptor 2. assert the file descriptor. If it is a socket type descriptor, then returns a channel which wraps the descriptor. I also wrote some samples for ensuring my understanding. It seems OK on linux, but not the case on Window. RI always returns null on Windows (maybe because there is no service daemon program on Windows? or my understanding is totally wrong?) Any chance to get non-null value if inetd is dummied on Windows? Seems some Services for UNIX(SFU) is provided by MS with Windows server 2003, which can mimic the inetd behavior[1]. I'm not sure if it applies to WinXP, too. [1]http://www.microsoft.com/technet/interopmigration/unix/sfu/intdrutil.mspx Therefore, I want to hear suggestions from our community, espeically folks experienced in network! Many thanks in advance! Best regards, -- Paulex Yang China Software Development Lab IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Andrew Zhang China Software Development Lab, IBM
Re: [drlvm] proposals for VM internationalization
Hi, Vladimir
Log4c and log4cpp are both good tools, but if our requirements are just
message internationalization, maybe log4cxx is overkill? After all, as a
complete log framework, it provides supports to i18n, category, layout
And if we talk about ResourceBundle only, I'd suggest consider ICU4C as
a candidate, which provides many i18n features including
ResourceBundle[1] support to c as well as c++, and more important, it
has been included as Harmony dependencies.
Of course, if you think VM needs more complicated log mechanism support,
this will be another story.
[1]http://icu.sourceforge.net/apiref/icu4c/
Vladimir Gorr wrote:
Hi Harmony community.
I'd like to discuss with you a design for the VM native code
internationalization (attached below).
We'd like to consider this approach for the DRLVM first of all.
However it
can be suitable for other parts of Harmony project I suppose.
Please let me know your opinions/objections.
Thanks,
Vladimir .
---
Internationalization design *1. Introduction*
The VM's output needs to be internationalized in order to provide
localized
versions of our product.
The key idea is to use ResourceBundle class from apache log4cxx which
allow
to store and effective use bundles with localized messages.
The document describes:
· ResourceBundle naming conventions for bundles with localized
messages.
· Structure of* *ResourceBundle file. MessageId (keys for
localized message in ResourceBundle) development guidelines.
· Requirements.
· How it works inside VM.
*Definitions: *
I18n – internationalization
L10n – localization
L7d – localized
*2. ResourceBundle naming conventions for bundles with localized
messages. *
We offer to use ResourceBundle class from apache log4cxx as storage of
localized messages. At first time all Resourcebundles are files.
After VM starts, on VM's logging subsystem initialization stage, logging
system chooses appropriate set of ResourceBundles
according to values of environment variables: LC_ALL, LC_MESSAGES, and
LANG.
Chosen ResourceBundles should be used for printing localized messages
from
VM.
E.g. If the environment variable LANG is equal to ru_RU then the
following
set of ResourceBundles should be used (see naming conventions below):
· java_ru_RU.properties
· java_ru.properties
· java.properties
Each file which presents ResourceBundle class should have the following
name:
*java_language_country_variant.properties *where:
_language is a language e.g. _ru (Russian language). It may be empty.
_country is a country e.g. _RU (Russian federation ). It may be
empty.
_variant is a variant. It may be empty.
The main ResourceBundle file (with messages on English) should
be java.properties.
*3. Structure of ResourceBundle file. MessageId development
guidelines. *
The structure of ResourceBundle file should be the following:
MessageId1=localized message1
MessageId2=localized message2
….
Where:
MessageId{i} – ASCII string on English language. It should consist of
vm's
subcomponent name ( e.g. init, port, gc.) and short description of
message.
E.g. init.help is localized help message from init subcomponent of
VM.
Localized message{i} – localized message.
Localized message can contain parameters. E.g. localized message pattern:
This is message on English with two parameters: parameter number one
– {0},
and parameter number two – {1}. We can print it again and in back order:
{1}, {0}. For the first parameter is equal to integer value 1
and the second is equal to string two the message for pattern above
should
be:
This is message on English with two parameters: parameter number one
– 1,
and parameter number two – two. We can print it again and in back order:
two, 1.
* *
*4. Requirements. *
- All localized messages may be printed through apache log4cxx logger.
- Parameters may be present in localized messages.
- VM-I18N subsystem should automatically detect user's locale
according to values of environment variables.
- Minimize performance impact.
--
Paulex Yang
China Software Development Lab
IBM
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: I18N on native (was:Re: [jira] Commented: (HARMONY-815) [classlib][nio] Refine implConfigureBlocking(boolean) method of DatagramChannel and SocketChannel.)
Minor note: I havn't insisted that we *always* return error code rather than throw Exception, instead I suggest that we avoid throwing exceptions from native whenever possible. I thought that native calls that don't throw exceptions might be optimized by JIT. But it's only a guess, I leave it for JIT guys to comment. Thanks, Mikhail 2006/7/13, Paulex Yang [EMAIL PROTECTED]: Mikhail Loenko wrote: I suggest that we: 1) avoid throwing exceptions from native code I have no strong feelings yet which is better, to throw Exception in native codes directly or always to return error codes to Java. There are different styles in Java and C programming on error handling, C program generally return error codes and use output parameter if necessary, while Java codes generally separate normal return value and exceptional case. JNI is combined by Java and C, so there must be one side to violate the convention. Throwing exception in native codes makes the codes hard to understand or maintain, while returning error codes may introduce one more time error code conversions[1], further, sometimes not only error code but the error message generated by OS is useful. [1]check out the stack below, there are several error codes set needed: Java codes--platform indepdent native codes--portlib codes--system call 1. system call error codes, which is platform dependent 2. portlib error codes, which is platform independent 3. Java error codes, which is returned by JNI methods to Java, so it needs to be defined in in Java codes(i.e. in generated JNI header files) 4. Java Exception class 2) don't parse exception messages in the code (use subclasses of exceptions when necessary) Agree, String comparison is not good in many ways. Thanks, Mikhail 2006/7/13, Andrew Zhang [EMAIL PROTECTED]: On 7/13/06, Jimmy, Jing Lv [EMAIL PROTECTED] wrote: Hi: I'd like to raise the topic on I18N of native code. As discussed about patch-815, we found there are exceptions thrown by native code with un-internationalized error message. To resolve this problem, there may be two solutions: 1) make native code return error code instead of throw exceptions, and let Java code deal with these errors. This seems pretty good, and also resolve such problems like 815, but require much more effort to refactor all native and Java codes. What's more, as some native methods do not return an integer at all, we may add an output parameter to them, at least for network-related luni/nio, there are about 10 methods like this. May we add an output parameter errorCode in each method. 2) As it is still easy for native code to call Java code, so rewrite error-message-lookup native method to lookup internationalized message, e.g., call MsgUtil.getString(). This refactor may be easy, but to JIRA-815 and other message-dependent Java code, it do no help. So it still requires other refactoring, e.g., return error code in some situation like suggested in (1). Another solution can be: catch exceptions on Java code, replace its message, and throw out again, this may be too ugly, so I do not suggest so. Any suggestions? Thanks! -- Best Regards! Jimmy, Jing Lv China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Andrew Zhang China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Paulex Yang China Software Development Lab IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][nio][discussion] Implementation of java.nio.channels.spi.SelectorProvider.inheritedChannel()
Andrew Zhang wrote: On 7/13/06, Paulex Yang [EMAIL PROTECTED] wrote: Andrew Zhang wrote: Hello everybody, I plan to implement java.nio.channels.spi.SelectorProvider.inheritedChannel() method. Currently Harmony simply returns null. Spec doesn not specify how to detect inheritedChannel clearly, Returns the channel inherited from the entity that created this Java virtual machine. For example, on UNIX systems, the Internet services daemon (*inetd*) is used to start programs to service requests when a request arrives on an associated network port. In this example, the process that is started, inherits a channel representing a network socket. As my understanding, what inherited channel does is redirect socket to standard input. Therefore, my solution looks like following: Don't need to check the stdout? IIRC inetd redirects both. Paulex, I don't thin it's necessary. Even if stdout/stderr are not redirected, RI still returns inherited channel as long as stdin is redirected on Linux. OK, thank you. Another question(please forgive me, just for curious), how about only stdout is redirected? 1. get standard input file descriptor 2. assert the file descriptor. If it is a socket type descriptor, then returns a channel which wraps the descriptor. I also wrote some samples for ensuring my understanding. It seems OK on linux, but not the case on Window. RI always returns null on Windows (maybe because there is no service daemon program on Windows? or my understanding is totally wrong?) Any chance to get non-null value if inetd is dummied on Windows? Seems some Services for UNIX(SFU) is provided by MS with Windows server 2003, which can mimic the inetd behavior[1]. I'm not sure if it applies to WinXP, too. [1]http://www.microsoft.com/technet/interopmigration/unix/sfu/intdrutil.mspx Therefore, I want to hear suggestions from our community, espeically folks experienced in network! Many thanks in advance! Best regards, -- Paulex Yang China Software Development Lab IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Paulex Yang China Software Development Lab IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] proposals for VM internationalization
Vladimir Gorr wrote:
Internationalization design *1. Introduction*
...
The key idea is to use ResourceBundle class from apache log4cxx which allow
to store and effective use bundles with localized messages.
Why not use GNU gettext -- de facto standard i18n system on GNU/Linux systems?
I think the developers' API can be a designed to allow a wide range of
i18n implementations, just like we did with logging.
(* DRLVM logging system was designed in such a way, that its implementation
could be rewritten completely from scratch. It was in fact rewritten once
to use log4cxx. No client code modifications were required *)
I think we could devise a simple localization API, which even could be dummy
to get us started, like
8- vm/include/l10n.h
#define _(x) (x)
inline void init_l10n() {}
---
Scan over the DRLVM code, mark the translatable strings with _(),
and then evolve the l10n system independently of the development efforts.
MessageId1=localized message1
MessageId2=localized message2
Where:
MessageId{i} – ASCII string on English language. It should consist of vm's
subcomponent name ( e.g. init, port, gc.) and short description of message.
E.g. init.help is localized help message from init subcomponent of VM.
The gettext has an advantage, that the unlocalized messages are used as the
keys for the translation, thus, the developers do not need to care about
l10n at all.
On the other hand, in the system you propose, to create a message,
one will need to
1) come up with the message identifier
2) add the message identifier and it's unlocalized text to the resource file
and, most annoyingly,
3) consult resource file each time s/he wants to know, what message is printed,
because in most cases, the message key will bear no meaning.
(* Compare with the issue we've come across recently: SecurityException:
K00Ec *)
4) Add to this that most of the developers will not know where the localized
messages are kept,
and you'll get the situation when most of the messages are not localized in any
way.
With gettext, localizing for developers is as easy as putting _() around your
string message,
and leaving *everything* else up to the translators. Even the source code
scanning to extract
messages that need to be translated is done automatically with 'xgettext'.
Localized message can contain parameters. E.g. localized message pattern:
This is message on English with two parameters: parameter number one –
{0}, ...
with gettext, parameters in localized messages is a non-issue. You can use
printf
or cout with gettext without any restrictions. You even can teach your program
to use correct plurals.
(* In slavic languages, there is two kind of plurals: 2-4 is dual plural, 5-9
is multiple plural,
see the concrete example below *)
- All localized messages may be printed through apache log4cxx logger.
gettext's job is to translate strings, and then it's up to developer to choose
how to print the message, so this requirement is satisfied by gettext.
- Minimize performance impact.
Below is the simple example of using gettext in a toy application to count
apples:
---8--- apples.c
#include locale.h
#include libintl.h
#define _(String) gettext(String)
int main() {
bindtextdomain(apples, .);
textdomain(apples);
setlocale(LC_ALL, NULL);
printf(_(internationalized message\n));
{
int i;
for (i = 0; i 27; i++) {
printf(ngettext(%d apple\n, %d apples\n, i), i);
}
}
return 0;
}
---8---
The translators job then would be to fill in a template with translated
messages, like
--8 ru/LC_MESSAGES/apples.po
msgid internationalized message\n
msgstr русское сообщение\n
msgid %d apple\n
msgid_plural %d apples\n
msgstr[0] %d яблоко\n
msgstr[1] %d яблока\n
msgstr[2] %d яблок\n
---
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: I18N on native (was:Re: [jira] Commented: (HARMONY-815) [classlib][nio] Refine implConfigureBlocking(boolean) method of DatagramChannel and SocketChannel.)
On 7/13/06, Mikhail Loenko [EMAIL PROTECTED] wrote: Minor note: I havn't insisted that we *always* return error code rather than throw Exception, AFAIK, luni and nio modules always throw exception rather than return error code. instead I suggest that we avoid throwing exceptions from native whenever possible. I think impossible is nothing. :) All exception thrown by native code can be replaced by error code. Are there any exceptions? Of course, VM is not in the scope of this discussion. I thought that native calls that don't throw exceptions might be optimized by JIT. But it's only a guess, I leave it for JIT guys to comment. Thanks, Mikhail 2006/7/13, Paulex Yang [EMAIL PROTECTED]: Mikhail Loenko wrote: I suggest that we: 1) avoid throwing exceptions from native code I have no strong feelings yet which is better, to throw Exception in native codes directly or always to return error codes to Java. There are different styles in Java and C programming on error handling, C program generally return error codes and use output parameter if necessary, while Java codes generally separate normal return value and exceptional case. JNI is combined by Java and C, so there must be one side to violate the convention. Throwing exception in native codes makes the codes hard to understand or maintain, while returning error codes may introduce one more time error code conversions[1], further, sometimes not only error code but the error message generated by OS is useful. [1]check out the stack below, there are several error codes set needed: Java codes--platform indepdent native codes--portlib codes--system call 1. system call error codes, which is platform dependent 2. portlib error codes, which is platform independent 3. Java error codes, which is returned by JNI methods to Java, so it needs to be defined in in Java codes(i.e. in generated JNI header files) 4. Java Exception class 2) don't parse exception messages in the code (use subclasses of exceptions when necessary) Agree, String comparison is not good in many ways. Thanks, Mikhail 2006/7/13, Andrew Zhang [EMAIL PROTECTED]: On 7/13/06, Jimmy, Jing Lv [EMAIL PROTECTED] wrote: Hi: I'd like to raise the topic on I18N of native code. As discussed about patch-815, we found there are exceptions thrown by native code with un-internationalized error message. To resolve this problem, there may be two solutions: 1) make native code return error code instead of throw exceptions, and let Java code deal with these errors. This seems pretty good, and also resolve such problems like 815, but require much more effort to refactor all native and Java codes. What's more, as some native methods do not return an integer at all, we may add an output parameter to them, at least for network-related luni/nio, there are about 10 methods like this. May we add an output parameter errorCode in each method. 2) As it is still easy for native code to call Java code, so rewrite error-message-lookup native method to lookup internationalized message, e.g., call MsgUtil.getString(). This refactor may be easy, but to JIRA-815 and other message-dependent Java code, it do no help. So it still requires other refactoring, e.g., return error code in some situation like suggested in (1). Another solution can be: catch exceptions on Java code, replace its message, and throw out again, this may be too ugly, so I do not suggest so. Any suggestions? Thanks! -- Best Regards! Jimmy, Jing Lv China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Andrew Zhang China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Paulex Yang China Software Development Lab IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Andrew Zhang China Software Development Lab, IBM
Re: [drlvm] proposals for VM internationalization
On 7/13/06, Paulex Yang [EMAIL PROTECTED] wrote:
Hi, Vladimir
Log4c and log4cpp are both good tools, but if our requirements are just
message internationalization, maybe log4cxx is overkill? After all, as a
complete log framework, it provides supports to i18n, category,
layout
And if we talk about ResourceBundle only, I'd suggest consider ICU4C as
a candidate, which provides many i18n features including
ResourceBundle[1] support to c as well as c++, and more important, it
has been included as Harmony dependencies.
Of course, if you think VM needs more complicated log mechanism support,
this will be another story.
Yes, this is such case. I suppose some of us will want to read the debug
output from JIT
in the Chinese language. Why not? However you're right the ICU4C can be also
used for some cases.
Maybe it makes sense to combine these two mechanisms (one for user messages,
other for internal needs).
Just the log4cxx is used as logging system for DRLVM and we think a little
of efforts will need to internationalize
the native code in this case.
Thanks,
Vladimir.
[1]http://icu.sourceforge.net/apiref/icu4c/
Vladimir Gorr wrote:
Hi Harmony community.
I'd like to discuss with you a design for the VM native code
internationalization (attached below).
We'd like to consider this approach for the DRLVM first of all.
However it
can be suitable for other parts of Harmony project I suppose.
Please let me know your opinions/objections.
Thanks,
Vladimir .
---
Internationalization design *1. Introduction*
The VM's output needs to be internationalized in order to provide
localized
versions of our product.
The key idea is to use ResourceBundle class from apache log4cxx which
allow
to store and effective use bundles with localized messages.
The document describes:
· ResourceBundle naming conventions for bundles with localized
messages.
· Structure of* *ResourceBundle file. MessageId (keys for
localized message in ResourceBundle) development guidelines.
· Requirements.
· How it works inside VM.
*Definitions: *
I18n – internationalization
L10n – localization
L7d – localized
*2. ResourceBundle naming conventions for bundles with localized
messages. *
We offer to use ResourceBundle class from apache log4cxx as storage of
localized messages. At first time all Resourcebundles are files.
After VM starts, on VM's logging subsystem initialization stage, logging
system chooses appropriate set of ResourceBundles
according to values of environment variables: LC_ALL, LC_MESSAGES, and
LANG.
Chosen ResourceBundles should be used for printing localized messages
from
VM.
E.g. If the environment variable LANG is equal to ru_RU then the
following
set of ResourceBundles should be used (see naming conventions below):
· java_ru_RU.properties
· java_ru.properties
· java.properties
Each file which presents ResourceBundle class should have the following
name:
*java_language_country_variant.properties *where:
_language is a language e.g. _ru (Russian language). It may be
empty.
_country is a country e.g. _RU (Russian federation ). It may be
empty.
_variant is a variant. It may be empty.
The main ResourceBundle file (with messages on English)
should
be java.properties.
*3. Structure of ResourceBundle file. MessageId development
guidelines. *
The structure of ResourceBundle file should be the following:
MessageId1=localized message1
MessageId2=localized message2
….
Where:
MessageId{i} – ASCII string on English language. It should consist of
vm's
subcomponent name ( e.g. init, port, gc.) and short description of
message.
E.g. init.help is localized help message from init subcomponent of
VM.
Localized message{i} – localized message.
Localized message can contain parameters. E.g. localized message
pattern:
This is message on English with two parameters: parameter number one
– {0},
and parameter number two – {1}. We can print it again and in back order:
{1}, {0}. For the first parameter is equal to integer value 1
and the second is equal to string two the message for pattern above
should
be:
This is message on English with two parameters: parameter number one
– 1,
and parameter number two – two. We can print it again and in back order:
two, 1.
* *
*4. Requirements. *
- All localized messages may be printed through apache log4cxx logger.
- Parameters may be present in localized messages.
- VM-I18N subsystem should automatically detect user's locale
according to values of environment variables.
- Minimize performance impact.
--
Paulex Yang
China Software Development Lab
IBM
-
Terms of use :
Re: [drlvm] proposals for VM internationalization
Vladimir Gorr wrote:
On 7/13/06, Paulex Yang [EMAIL PROTECTED] wrote:
Hi, Vladimir
Log4c and log4cpp are both good tools, but if our requirements are just
message internationalization, maybe log4cxx is overkill? After all, as a
complete log framework, it provides supports to i18n, category,
layout
And if we talk about ResourceBundle only, I'd suggest consider ICU4C as
a candidate, which provides many i18n features including
ResourceBundle[1] support to c as well as c++, and more important, it
has been included as Harmony dependencies.
Of course, if you think VM needs more complicated log mechanism support,
this will be another story.
Yes, this is such case. I suppose some of us will want to read the debug
output from JIT
in the Chinese language. Why not?
Cool! You are right I do want to ;-) !
However you're right the ICU4C can be also
used for some cases.
Maybe it makes sense to combine these two mechanisms (one for user
messages,
other for internal needs).
Maybe, if the ICU4C usage can introduce less footprint/performance
impact to DRLVM in non-debug mode. (I have no idea about this actually,
just guess if ICU4C only cares about ResourceBundle while log4cxx has
much more things in its mind...)
Just the log4cxx is used as logging system for DRLVM and we think a
little
of efforts will need to internationalize
the native code in this case.
I see, this is what I expected, thank you to clarify this. :)
Thanks,
Vladimir.
[1]http://icu.sourceforge.net/apiref/icu4c/
Vladimir Gorr wrote:
Hi Harmony community.
I'd like to discuss with you a design for the VM native code
internationalization (attached below).
We'd like to consider this approach for the DRLVM first of all.
However it
can be suitable for other parts of Harmony project I suppose.
Please let me know your opinions/objections.
Thanks,
Vladimir .
---
Internationalization design *1. Introduction*
The VM's output needs to be internationalized in order to provide
localized
versions of our product.
The key idea is to use ResourceBundle class from apache log4cxx which
allow
to store and effective use bundles with localized messages.
The document describes:
· ResourceBundle naming conventions for bundles with localized
messages.
· Structure of* *ResourceBundle file. MessageId (keys for
localized message in ResourceBundle) development guidelines.
· Requirements.
· How it works inside VM.
*Definitions: *
I18n – internationalization
L10n – localization
L7d – localized
*2. ResourceBundle naming conventions for bundles with localized
messages. *
We offer to use ResourceBundle class from apache log4cxx as storage of
localized messages. At first time all Resourcebundles are files.
After VM starts, on VM's logging subsystem initialization stage,
logging
system chooses appropriate set of ResourceBundles
according to values of environment variables: LC_ALL, LC_MESSAGES, and
LANG.
Chosen ResourceBundles should be used for printing localized messages
from
VM.
E.g. If the environment variable LANG is equal to ru_RU then the
following
set of ResourceBundles should be used (see naming conventions below):
· java_ru_RU.properties
· java_ru.properties
· java.properties
Each file which presents ResourceBundle class should have the
following
name:
*java_language_country_variant.properties *where:
_language is a language e.g. _ru (Russian language). It may be
empty.
_country is a country e.g. _RU (Russian federation ). It may be
empty.
_variant is a variant. It may be empty.
The main ResourceBundle file (with messages on English)
should
be java.properties.
*3. Structure of ResourceBundle file. MessageId development
guidelines. *
The structure of ResourceBundle file should be the following:
MessageId1=localized message1
MessageId2=localized message2
….
Where:
MessageId{i} – ASCII string on English language. It should consist of
vm's
subcomponent name ( e.g. init, port, gc.) and short description of
message.
E.g. init.help is localized help message from init subcomponent of
VM.
Localized message{i} – localized message.
Localized message can contain parameters. E.g. localized message
pattern:
This is message on English with two parameters: parameter number one
– {0},
and parameter number two – {1}. We can print it again and in back
order:
{1}, {0}. For the first parameter is equal to integer value 1
and the second is equal to string two the message for pattern above
should
be:
This is message on English with two parameters: parameter number one
– 1,
and parameter number two – two. We can print it again and in back
order:
two, 1.
* *
*4. Requirements. *
- All localized messages may
Re: [drlvm] proposals for VM internationalization
In my opinion using the gettext() for the i18n goals will involve too big
re-factoring of source code.
I also disagree with the 'no-meaning' for message key. All we need is to
create the sensible ID for these messages.
*4) Add to this that most of the developers will not know where the
localized messages are kept,
and you'll get the situation when most of the messages are not localized in
any way.
*
I'm not sure the gettext() will eliminate this issue.
Thanks,
Vladimir.
On 7/13/06, Salikh Zakirov [EMAIL PROTECTED] wrote:
Vladimir Gorr wrote:
Internationalization design *1. Introduction*
...
The key idea is to use ResourceBundle class from apache log4cxx which
allow
to store and effective use bundles with localized messages.
Why not use GNU gettext -- de facto standard i18n system on GNU/Linux
systems?
I think the developers' API can be a designed to allow a wide range of
i18n implementations, just like we did with logging.
(* DRLVM logging system was designed in such a way, that its
implementation
could be rewritten completely from scratch. It was in fact rewritten
once
to use log4cxx. No client code modifications were required *)
I think we could devise a simple localization API, which even could be
dummy
to get us started, like
8- vm/include/l10n.h
#define _(x) (x)
inline void init_l10n() {}
---
Scan over the DRLVM code, mark the translatable strings with _(),
and then evolve the l10n system independently of the development efforts.
MessageId1=localized message1
MessageId2=localized message2
Where:
MessageId{i} �C ASCII string on English language. It should consist of
vm's
subcomponent name ( e.g. init, port, gc.) and short description of
message.
E.g. init.help is localized help message from init subcomponent of
VM.
The gettext has an advantage, that the unlocalized messages are used as
the
keys for the translation, thus, the developers do not need to care about
l10n at all.
On the other hand, in the system you propose, to create a message,
one will need to
1) come up with the message identifier
2) add the message identifier and it's unlocalized text to the resource
file
and, most annoyingly,
3) consult resource file each time s/he wants to know, what message is
printed,
because in most cases, the message key will bear no meaning.
(* Compare with the issue we've come across recently: SecurityException:
K00Ec *)
4) Add to this that most of the developers will not know where the
localized messages are kept,
and you'll get the situation when most of the messages are not localized
in any way.
With gettext, localizing for developers is as easy as putting _() around
your string message,
and leaving *everything* else up to the translators. Even the source code
scanning to extract
messages that need to be translated is done automatically with 'xgettext'.
Localized message can contain parameters. E.g. localized message
pattern:
This is message on English with two parameters: parameter number one �C
{0}, ...
with gettext, parameters in localized messages is a non-issue. You can use
printf
or cout with gettext without any restrictions. You even can teach your
program
to use correct plurals.
(* In slavic languages, there is two kind of plurals: 2-4 is dual
plural, 5-9 is multiple plural,
see the concrete example below *)
- All localized messages may be printed through apache log4cxx logger.
gettext's job is to translate strings, and then it's up to developer to
choose
how to print the message, so this requirement is satisfied by gettext.
- Minimize performance impact.
Below is the simple example of using gettext in a toy application to count
apples:
---8--- apples.c
#include locale.h
#include libintl.h
#define _(String) gettext(String)
int main() {
bindtextdomain(apples, .);
textdomain(apples);
setlocale(LC_ALL, NULL);
printf(_(internationalized message\n));
{
int i;
for (i = 0; i 27; i++) {
printf(ngettext(%d apple\n, %d apples\n, i), i);
}
}
return 0;
}
---8---
The translators job then would be to fill in a template with translated
messages, like
--8 ru/LC_MESSAGES/apples.po
msgid internationalized message\n
msgstr русское сообщение\n
msgid %d apple\n
msgid_plural %d apples\n
msgstr[0] %d яблоко\n
msgstr[1] %d яблока\n
msgstr[2] %d яблок\n
---
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] proposals for VM internationalization
Vladimir Gorr wrote: In my opinion using the gettext() for the i18n goals will involve too big re-factoring of source code. I also disagree with the 'no-meaning' for message key. All we need is to create the sensible ID for these messages. I think this is the case of good intentions, which pave the well-known road. As soon as the message key is *not* the thing that is printed, it is inevitable that the message sensible for one engineer, will have no meaning to the other. Do you think K00Ec is sensible? I think not. Do you think the developer had no chance to choose better key? IMHO, this kind of things must be *enforced*, for example, by making sure that the message key is printed in C locale (default case for most developers). *4) Add to this that most of the developers will not know where the localized messages are kept, and you'll get the situation when most of the messages are not localized in any way. * I'm not sure the gettext() will eliminate this issue. gettext effectively splits this issue into two *independent* tasks: - the task of the developer is to code - the task of the translator is to find translatable messages and translate them The greatest advantage of it is that developer do not need to care about translations, besides putting _() occasionally, and translators do not need to care about coding. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] proposals for VM internationalization
Vladimir Gorr wrote:
I'd like to discuss with you a design for the VM native code
internationalization (attached below).
...
Please let me know your opinions/objections.
To make my point clearer, I would repeat my suggestion.
0) Agree on a design decision that the message key
is the *unlocalized message itself*, rather some intermediary constant.
1) Start l10n with the below patch (untested)
2) Start marking localizable strings with _() in the DRLVM source code.
The interface is very simple and does not impose any restrictions.
3) Implement the localization in any way we like, be it icu4c, log4cxx
or gettext. Or may be even leave it configurable at compile time.
--- /dev/null
+++ b/vm/include/l10n.h
@@ -0,0 +1,8 @@
+#ifndef _L10N_H
+#define _L10N_H
+
+#define _(message) (message)
+
+void init_l10n();
+
+#endif // _L10N_H
diff --git a/vm/vmcore/src/init/vm_main.cpp b/vm/vmcore/src/init/vm_main.cpp
index 9db56e5..96e9a8c 100644
--- a/vm/vmcore/src/init/vm_main.cpp
+++ b/vm/vmcore/src/init/vm_main.cpp
@@ -42,6 +42,7 @@ #include dll_jit_intf.h
#include dll_gc.h
#include em_intf.h
#include port_filepath.h
+#include l10n.h
union Scalar_Arg {
int i;
@@ -283,6 +284,7 @@ static int run_java_shutdown()
void create_vm(Global_Env *p_env, JavaVMInitArgs* vm_arguments)
{
+init_l10n();
#ifdef PLATFORM_POSIX
init_linux_thread_system();
#elif defined(PLATFORM_NT)
diff --git a/vm/vmcore/src/l10n.cpp b/vm/vmcore/src/l10n.cpp
new file mode 100644
index 000..d9d380a
--- /dev/null
+++ b/vm/vmcore/src/l10n.cpp
@@ -0,0 +1,4 @@
+#include l10n.h
+
+void init_l10n() {
+}
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Breaking awt native build?
Geir Magnusson Jr wrote: Fair enough. If it's really only a few days, I have no objection, and if no one else has an objection, you might as well go for it. I hate seeing the build broken ever, but... Maybe the thing to do is send a separate mail w/ build broken for windows AWT natives or something, with the steps people can use to rollback and build if they must. I agree. Breaking it for a few days is ok to move on, provided it is clear how people can roll-back that work in progress and build it before the breakage. (Is this like pre-paid beer vouchers?) Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RESULT] of Re: [vote] acceptance of HARMONY-609 : AWT, Java2D, Swing TESTS
On 12 July 2006 at 20:00, Geir Magnusson Jr [EMAIL PROTECTED] wrote: +1 from geir, tim, george, mikhail, mark, stepan, No 0 or -1. Contribution open for integration :) I'll do the integration (after the natives) if no one else wants to do it. -Mark. geir Geir Magnusson Jr wrote: All is in order and in SVN for Harmony-609 wrt BCC and ACQ. Please vote to accept or reject this codebase into the Apache Harmony class library : [ ] + 1 Accept [ ] -1 Reject (provide reason below) Lets let this run a minimum of 3 days unless a) someone states they need more time or b) we get all committer votes before then. geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] using the harmony launcher
Andrey Chernyshev wrote: With some changes I was able to run the DRLVM with classlib's launcher. Here is what I did (you can see the experimental patch at http://issues.apache.org/jira/browse/HARMONY-857): - I have added JNI_CreateJavaVM declaration to jni.h (guess it will be the most appropriate place for it); - Added a simple implementations for JNI_CreateJavaVM and DestroyJavaVM based on the existing create_vm and detroy_vm functions in the vmcore/init submodule. - To make vmcore/init functions visible for vmcore/jni code, I have moved vmcore/init/init.h to vmcore/include; - In parse_arguments.cpp, I had to silently ignore the option _org.apache.harmony.vmi.portlib which is passed by the launcher to VM for some reason, causing the DRLVM to complain about unknown option. What is the purpose of that option, should I process it differently? After all, I was able to run the DRLVM under classlib's launcher on Windows with a command like: Java.exe -vm:vmcore -vmdir:. Hello and even was able to run Eclipse IDE with it. VM seems to exit cleanly and didn't report any error messages. Good work! Some of the remaining issues / observations are: (1) DRLVM startup is organized a bit differently compared to the classlib launcher startup, namely – the DRLVM after creating VM runs a special class called VMStart which is, in it's turn, asynchronously calling the main() method of the user application in a separate thread. When we go with the classlib's launcher, the main() method is executed in the same thread where the JavaVM is created. What are the caveats with that? I've had a look in the drlvm code, and I see what you mean - run_java_main is expecting to receive the class name as a parameter, then launch the VMStart class before running main(). It is standard practice for a Java launcher to call CreateJavaVM(), then carry out a findClass() and CallStaticObjectMethod() on the specified class and main method. However, the launcher does not necessarily have to run the main method first - anyone could write a custom launcher that calls a static runme() method first, or something similar, so the VM should not expect main() to be the first method called when launched from the invocation API. So, if I understand the drlvm code right, the call sequence on startup using the drlvm launcher is: drlvm launcher calls vm_main() vm_main() calls create_vm() (which is essentially CreateJavaVM) create_vm() completes and returns vm_main() calls run_main() run_main() calls run_java_main() run_java_main() creates the VMStart class and executes its start() method run_java_main() creates the specified class and runs its main() method When drlvm is launched using a generic launcher (such as the classlib launcher) the sequence would probably need to be either: launcher calls CreateJavaVM() CreateJavaVM() passes call to create_vm() create_vm() makes its usual calls, but also executes required VMStart code create_vm() and CreateJavaVM() both exit, returning control to the launcher or: launcher calls CreateJavaVM() CreateJavaVM() passes call to create_vm() create_vm() makes its usual calls and returns. A flag is set to indicate that VMStart still needs to be run. create_vm() and CreateJavaVM() both exit, returning control to the launcher launcher makes a call to run some Java code (possibly main method) drlvm picks up flag indicating VMStart needs to be executed and runs it before the specified class The first approach seems better to me, since it gets all of the vm initialization completed within the CreateJavaVM() call. Does this answer your question? Any other ideas? (2) If I pass a wrong app class name to the classlib launcher, drlvm reports class not found exception and then is crashed. This happens because the classlib launcher, once it fails to run the app class, reports an exception (with ExceptionDescribe) but doesn't clear it (doesn't call ExceptionClear). Then it immediately goes with DestroyJavaVM those current implementation in drlvm doesn't expect that there is some pending exception object in the TLS. Eventually, destroy_vm fails with assert in the class loading code while resolving VMStart class (VMStart holds the Java part of the shutdown method), because it mistakenly picks up the ClassNotFound exception object. It is remaining from unsuccessful attempt of classlib launcher to run the app's class main method. The question is, who's responsibility should be to clear the exception object in that case? I tend to think that classlib launcher should be doing this once it takes the responsibility to process the possible exceptions while running the app main class. Although the classlib launcher should probably tidy up after itself and call ExceptionClear, I don't believe that there is a spec requirement to clear pending exceptions before calling DestroyJavaVM. Therefore any launcher could call DestroyJavaVM with an exception pending, and drlvm would throw a ClassNotFound. IMHO drlvm should handle
Re: [drlvm] using the harmony launcher
Andrey Chernyshev wrote: With some changes I was able to run the DRLVM with classlib's launcher. Here is what I did (you can see the experimental patch at http://issues.apache.org/jira/browse/HARMONY-857): - I have added JNI_CreateJavaVM declaration to jni.h (guess it will be the most appropriate place for it); The existing jni.h in the HDK's jdk/include directory already has those definitions. The JNI function definitions are, of course, required by the class library / tooling code. We should probably just share one copy of that file. - Added a simple implementations for JNI_CreateJavaVM and DestroyJavaVM based on the existing create_vm and detroy_vm functions in the vmcore/init submodule. - To make vmcore/init functions visible for vmcore/jni code, I have moved vmcore/init/init.h to vmcore/include; - In parse_arguments.cpp, I had to silently ignore the option _org.apache.harmony.vmi.portlib which is passed by the launcher to VM for some reason, causing the DRLVM to complain about unknown option. What is the purpose of that option, should I process it differently? (see below) After all, I was able to run the DRLVM under classlib's launcher on Windows with a command like: Java.exe -vm:vmcore -vmdir:. Hello Cool, they should be -X options, I'll change it in the launcher when next in there. and even was able to run Eclipse IDE with it. VM seems to exit cleanly and didn't report any error messages. Some of the remaining issues / observations are: (1) DRLVM startup is organized a bit differently compared to the classlib launcher startup, namely – the DRLVM after creating VM runs a special class called VMStart which is, in it's turn, asynchronously calling the main() method of the user application in a separate thread. That's an interesting design choice. So it always runs the VMStart#start() method as soon as the VM is created? So how do you implement JNI_CreateJavaVM (which must not do that)? Our tools etc. will have custom launchers that run different classes in the o.a.h.tools package. When we go with the classlib's launcher, the main() method is executed in the same thread where the JavaVM is created. What are the caveats with that? Don't know, as you say the primordial thread does the JNI_CreateJavaVM then goes on to CallStaticVoidMethod on the target's main(). (2) If I pass a wrong app class name to the classlib launcher, drlvm reports class not found exception and then is crashed. This happens because the classlib launcher, once it fails to run the app class, reports an exception (with ExceptionDescribe) but doesn't clear it (doesn't call ExceptionClear). Then it immediately goes with DestroyJavaVM those current implementation in drlvm doesn't expect that there is some pending exception object in the TLS. We can fix this in the launcher if you want, but cannot promise that everyone else using the invocation API will do this for you. Eventually, destroy_vm fails with assert in the class loading code while resolving VMStart class (VMStart holds the Java part of the shutdown method), because it mistakenly picks up the ClassNotFound exception object. It is remaining from unsuccessful attempt of classlib launcher to run the app's class main method. The question is, who's responsibility should be to clear the exception object in that case? I tend to think that classlib launcher should be doing this once it takes the responsibility to process the possible exceptions while running the app main class. Ok, but I'd advise that the Destroy is made more robust too. (3) CreateJavaVM can only be called once for now – many internal data structures in DRLVM are kept as global variables (jni_env, java_vm, Global_Env e.t.c.). Therefore, it will be hard to organize the multiple instances of JavaVM unless all these things are encapsulated somewhere (into JNIEnv?). Too bad. (4) Launcher wants the vm dll in the default directory unless the option is specified. Should we realign the drlvm build output and move all dll's into the default subdir? I'll let the different Harmony VM folk argue about who should be the default ;-) I agree that it should no longer be the IBM VME. (5) What to do with the _org.apache.harmony.vmi.portlib option that launcher is offering to VM? So the laucher creates the portlib function table so it can do OS things (like write NLS messages, and open the VM DLLs etc), it then passes the portlib in to the VM as this argument. You can choose to ignore it, but since you are required to return a portlib from the VMI's GetPortLibrary call, you might as well just remember it. It would be more polite to remember the one you were given so that the caller can install their own portlib functions and have them back again onthe VMI calls. Most likely there are more issues that I'm overlooking at the moment. Please consider the suggested patch is a workaround to make the things working, I'm wondering if there is
Re: [classlib] HARMONY-88 misses source file for MockJavaBean2.class
Mikhail Loenko wrote: Hi George I did not know that. When I run ant test -Dtest.jre.home=... for some odd reason this test does not run at all. I'll try to figure out why. I completely agree that the test should pass on RI. I'll fix the test. The old version of the test copied files on the disk in many test methods. The new version does not, so it should be at least faster. Please let me know if for some reason you don't like custom classloader version Thanks, Mikhail Hi Mikhail, Thanks for looking into the matter of running the tests on the RI. That was my only concern really. Your alternative version of the test looks great to me. Best regards, George 2006/7/13, Geir Magnusson Jr [EMAIL PROTECTED]: George Harley wrote: Hi Mikhail, You are probably already aware of this but the tests that use the SerClassLoader custom class loader result in a StackOverflowError when run against the RI. The overridden implementation of findResource(String) calls getResource(String) which, according to the spec, may end up calling into findResource(String) and so on... Fixing up the original version of the BeanTest class (i.e. before revision 421204) is quite straightforward really. I'm happy to check it in but if you want to go with a custom class loader approach then that's equally fine IMHO. I just think that it would be nice though if the tests could be run on both Harmony and the RI. +1 What do you think ? Best regards, George Mikhail Loenko wrote: Hi George! HARMONY-88 contribution contains a file MockJavaBean2.bin that seems to be a binary representation of tests.api.java.beans.mock.MockJavaBean2 class in r406595 you have modifed BeansTest.java, for example Beans.instantiate(loader,tests.api.java.beans.mock.MockJavaBean2); was replaced with Beans.instantiate(loader,org.apache.harmony.beans.tests.java.beans.mock.MockJavaBean2); So that ClassNotFoundException is now thrown. Could you please provide sources for MockJavaBean2 so that the failure could be fixed? Thanks, Mikhail - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] proposals for VM internationalization
On 7/13/06, Salikh Zakirov [EMAIL PROTECTED] wrote:
Vladimir Gorr wrote:
I'd like to discuss with you a design for the VM native code
internationalization (attached below).
...
Please let me know your opinions/objections.
To make my point clearer, I would repeat my suggestion.
0) Agree on a design decision that the message key
is the *unlocalized message itself*, rather some intermediary constant.
1) Start l10n with the below patch (untested)
2) Start marking localizable strings with _() in the DRLVM source code.
The interface is very simple and does not impose any restrictions.
3) Implement the localization in any way we like, be it icu4c, log4cxx
or gettext. Or may be even leave it configurable at compile time.
There is an essential obstacle to use the *gettext* approach.
It's impossible to run VM on Windows platform if not to take into account
CYGWIN environment.
I'm not clear as well how we will merge the previous .po catalogs (already
translated) with new ones (when new strings to be added).
In any case, a manual work needs for doing this. IMO the gettext is very
convenient to generate the initial template of message catalogs.
However _() should be inserted for all strings (and then deleted?) to
achieve this. It involves too big efforts.
Therefore my preference is to use more universal approach, namely, ICU4C or
LOG4CXX or combination of them.
Any comments?
Thanks,
Vladimir.
--- /dev/null
+++ b/vm/include/l10n.h
@@ -0,0 +1,8 @@
+#ifndef _L10N_H
+#define _L10N_H
+
+#define _(message) (message)
+
+void init_l10n();
+
+#endif // _L10N_H
diff --git a/vm/vmcore/src/init/vm_main.cpp
b/vm/vmcore/src/init/vm_main.cpp
index 9db56e5..96e9a8c 100644
--- a/vm/vmcore/src/init/vm_main.cpp
+++ b/vm/vmcore/src/init/vm_main.cpp
@@ -42,6 +42,7 @@ #include dll_jit_intf.h
#include dll_gc.h
#include em_intf.h
#include port_filepath.h
+#include l10n.h
union Scalar_Arg {
int i;
@@ -283,6 +284,7 @@ static int run_java_shutdown()
void create_vm(Global_Env *p_env, JavaVMInitArgs* vm_arguments)
{
+init_l10n();
#ifdef PLATFORM_POSIX
init_linux_thread_system();
#elif defined(PLATFORM_NT)
diff --git a/vm/vmcore/src/l10n.cpp b/vm/vmcore/src/l10n.cpp
new file mode 100644
index 000..d9d380a
--- /dev/null
+++ b/vm/vmcore/src/l10n.cpp
@@ -0,0 +1,4 @@
+#include l10n.h
+
+void init_l10n() {
+}
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [legal] taking concurrency utils code into the project (Re: svn commit: r421111 [1/11] - in /incubator/harmony/enhanced/classlib/trunk/sandbox: ./ juc-proposal/ juc-proposal/concurrent/ juc-propos
Tim Ellison wrote: Magnusson, Geir wrote: Clearly this is a great example to use to discuss this aspect of our project. First, this is a not an unreasonable objection to prevent code from moving into classlib, but I still don't see why it can't sit in sandbox to help with discussion of the technical merits. We can resolve legal concerns in parallel. Does that work for you? I try to be reasonable g. Sure, if we can move it out of 'enhanced' and are not building it then it can be there for looking at. I'm not really worried about this, as it's not in any module, and it's in something called /sandbox, under a dir with proposal in it, on the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying 'Beware of the Leopard.' I can't believe anyone would claim we're making any warranty of provenance. I don't really see the benefit, or the consistency, as we don't have any paperwork for the binaries that we also have in enhanced, and some of the source in luni et al. However, maybe the solution is to just push this (and the other binaries) out of enhanced into standard to keep enhanced pure. Second, we can certainly make exceptions to the project guidelines for cases where we believe there are no risks to the project. In fact, we've done it before when we accepted the core classes from ibm, iirc. How so? The IBM core classes contribution came with a completed bulk contribution questionnaire from the code owner detailing the authorship and a software grant. If we can get those for the concurrent code then I'm happy. And not every author of that has an ACQ. The point is that we've made the decision that not all code in our repository must have an ACQ. We don't have any provenance information on the binaries that we have, for example. And remember, Doug isn't making a contribution, we're discussing electing to use his code. it just has the odd property that there isn't a jar. To that end, are you aware of any risks for taking this code, given its uniqueness and statements by its author? It is authors plural, right? That is my suggestion, that we get statements from the authors as we agreed in the project guidelines. We spent some time refining exactly what we needed to know in such a statement. It's a guideline. We can also decide, as we've done in the past, to accept code w/o statements from each author. Do you really want to reconsider that? As I wrote earlier, I have no reason to doubt that the authors' employers (who may have a claim on that work) knew what they were doing and were happy for that work to be out in public domain. So we should go and get the doc to show that is the case. How consistent do you need to be here? If letter-of-the-law, IBM owes us a bit of paperwork, and I don't know what to do about the binaries we have lying around. I don't really want to be consistent for consistent sake, simply because we can and have made rational, calculated decisions based on our understanding of risk factors so we can move the project forward. To me, the j.u.c code is a dependency, one that has no binary distribution. Our intent is to make no modifications - we're just compiling it. I don't see how our risk changes if we just distributed the same binary made from the same code. Finally, I've talked to doug, and will see if we can get at least a statement from him regarding authorship. Meaning a list of authors or the like? or a statement about the code he wrote? Either would be a good start. He is willing to write a note to us. But I'm not interested in playing fetch me a rock here, and want to boil the issue down into a reusable decision. I think this is an exceptional case. To me, as of now, I'm hoping this can be a simple dependency on external code that happens to be only available in source form. It is not a contribution that we'd mingle with our source and make derivative works from. So it's like any number of things we currently depend on, for which we have no provenance information, nor until now any indication that we needed it. So I can see two solutions (each with the assumption that we'll get the note from Doug, as I'm really interested in building this bridge and working with him and this code) : 1) Put the code and build script over in /standard (as well as our other dependencies). We'll still get that note from Doug, but changing the SVN URL appears to remove all currently unknown legal risk ;) and we can get back on the technical track here. 2) I can setup a sourceforge or codehaus project with the sole purpose of creating a binary. Then we depend on that in the same way we depend on other things. geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] proposals for VM internationalization
Salikh Zakirov wrote: Vladimir Gorr wrote: Internationalization design *1. Introduction* ... The key idea is to use ResourceBundle class from apache log4cxx which allow to store and effective use bundles with localized messages. Why not use GNU gettext -- de facto standard i18n system on GNU/Linux systems? I think the developers' API can be a designed to allow a wide range of i18n implementations, just like we did with logging. Isn't it under the GPL? - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] proposals for VM internationalization
I'll state the obvious... there is another thread going on about how do
to similar things with Classlib. Maybe you can find common ground for
message bundles and such...
geir
Vladimir Gorr wrote:
Hi Harmony community.
I'd like to discuss with you a design for the VM native code
internationalization (attached below).
We'd like to consider this approach for the DRLVM first of all. However it
can be suitable for other parts of Harmony project I suppose.
Please let me know your opinions/objections.
Thanks,
Vladimir .
---
Internationalization design *1. Introduction*
The VM's output needs to be internationalized in order to provide localized
versions of our product.
The key idea is to use ResourceBundle class from apache log4cxx which allow
to store and effective use bundles with localized messages.
The document describes:
· ResourceBundle naming conventions for bundles with localized
messages.
· Structure of* *ResourceBundle file. MessageId (keys for
localized message in ResourceBundle) development guidelines.
· Requirements.
· How it works inside VM.
*Definitions: *
I18n – internationalization
L10n – localization
L7d – localized
*2. ResourceBundle naming conventions for bundles with localized
messages. *
We offer to use ResourceBundle class from apache log4cxx as storage of
localized messages. At first time all Resourcebundles are files.
After VM starts, on VM's logging subsystem initialization stage, logging
system chooses appropriate set of ResourceBundles
according to values of environment variables: LC_ALL, LC_MESSAGES, and
LANG.
Chosen ResourceBundles should be used for printing localized messages from
VM.
E.g. If the environment variable LANG is equal to ru_RU then the
following
set of ResourceBundles should be used (see naming conventions below):
· java_ru_RU.properties
· java_ru.properties
· java.properties
Each file which presents ResourceBundle class should have the following
name:
*java_language_country_variant.properties *where:
_language is a language e.g. _ru (Russian language). It may be empty.
_country is a country e.g. _RU (Russian federation ). It may be empty.
_variant is a variant. It may be empty.
The main ResourceBundle file (with messages on English) should
be java.properties.
*3. Structure of ResourceBundle file. MessageId development guidelines. *
The structure of ResourceBundle file should be the following:
MessageId1=localized message1
MessageId2=localized message2
….
Where:
MessageId{i} – ASCII string on English language. It should consist of vm's
subcomponent name ( e.g. init, port, gc.) and short description of message.
E.g. init.help is localized help message from init subcomponent of VM.
Localized message{i} – localized message.
Localized message can contain parameters. E.g. localized message pattern:
This is message on English with two parameters: parameter number one –
{0},
and parameter number two – {1}. We can print it again and in back order:
{1}, {0}. For the first parameter is equal to integer value 1
and the second is equal to string two the message for pattern above
should
be:
This is message on English with two parameters: parameter number one – 1,
and parameter number two – two. We can print it again and in back order:
two, 1.
* *
*4. Requirements. *
- All localized messages may be printed through apache log4cxx logger.
- Parameters may be present in localized messages.
- VM-I18N subsystem should automatically detect user's locale
according to values of environment variables.
- Minimize performance impact.
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Breaking awt native build?
Tim Ellison wrote: Geir Magnusson Jr wrote: Fair enough. If it's really only a few days, I have no objection, and if no one else has an objection, you might as well go for it. I hate seeing the build broken ever, but... Maybe the thing to do is send a separate mail w/ build broken for windows AWT natives or something, with the steps people can use to rollback and build if they must. I agree. Breaking it for a few days is ok to move on, provided it is clear how people can roll-back that work in progress and build it before the breakage. (Is this like pre-paid beer vouchers?) Pretty much - he basically rents out a pub for us one night... geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[classlib] compatibility nuances
Hi, I have discovered we have small incompatibility in our java.lang.Class implementation. The order of elements returned by Class.getDeclaredMethods() differs from RI. The spec says here: The elements in the array returned are not sorted and are not in any particular order. But I already know one application that relies on this - this was one of java.beans test (already patched). I don't want to say this is somehow bad but still like to inform the community about this issue. Probably we need to rise non-bug differences JIRA? Thanks, -- Alexei Zakharov, Intel Middleware Product Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] compatibility nuances
I assume you mean [drlvm], since java.lang.Class in [classlib] is just a stub, right? Anyway, what would you say exactly? That our not in any particular order is different than the not in any particular order that the RI does? I'm not trying to make light of it, but it sounds like all is correct. geir Alexei Zakharov wrote: Hi, I have discovered we have small incompatibility in our java.lang.Class implementation. The order of elements returned by Class.getDeclaredMethods() differs from RI. The spec says here: The elements in the array returned are not sorted and are not in any particular order. But I already know one application that relies on this - this was one of java.beans test (already patched). I don't want to say this is somehow bad but still like to inform the community about this issue. Probably we need to rise non-bug differences JIRA? Thanks, - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] proposals for VM internationalization
On 7/13/06, Vladimir Gorr [EMAIL PROTECTED] wrote:
On 7/13/06, Salikh Zakirov [EMAIL PROTECTED] wrote:
Vladimir Gorr wrote:
I'd like to discuss with you a design for the VM native code
internationalization (attached below).
...
Please let me know your opinions/objections.
To make my point clearer, I would repeat my suggestion.
0) Agree on a design decision that the message key
is the *unlocalized message itself*, rather some intermediary
constant.
1) Start l10n with the below patch (untested)
2) Start marking localizable strings with _() in the DRLVM source code.
The interface is very simple and does not impose any restrictions.
3) Implement the localization in any way we like, be it icu4c, log4cxx
or gettext. Or may be even leave it configurable at compile time.
There is an essential obstacle to use the *gettext* approach.
It's impossible to run VM on Windows platform if not to take into account
CYGWIN environment.
I'm not clear as well how we will merge the previous .po catalogs (already
translated) with new ones (when new strings to be added).
In any case, a manual work needs for doing this. IMO the gettext is very
convenient to generate the initial template of message catalogs.
However _() should be inserted for all strings (and then deleted?) to
achieve this. It involves too big efforts.
Therefore my preference is to use more universal approach,
Agree.
namely, ICU4C or
LOG4CXX or combination of them.
As Paulex mentioned, it depends on the requirement.
If only for i18n, icu4c is prefered.
Otherwise, if grain control of logging is required, log4cxx may be the
choice.
Thanks!
Any comments?
Thanks,
Vladimir.
--- /dev/null
+++ b/vm/include/l10n.h
@@ -0,0 +1,8 @@
+#ifndef _L10N_H
+#define _L10N_H
+
+#define _(message) (message)
+
+void init_l10n();
+
+#endif // _L10N_H
diff --git a/vm/vmcore/src/init/vm_main.cpp
b/vm/vmcore/src/init/vm_main.cpp
index 9db56e5..96e9a8c 100644
--- a/vm/vmcore/src/init/vm_main.cpp
+++ b/vm/vmcore/src/init/vm_main.cpp
@@ -42,6 +42,7 @@ #include dll_jit_intf.h
#include dll_gc.h
#include em_intf.h
#include port_filepath.h
+#include l10n.h
union Scalar_Arg {
int i;
@@ -283,6 +284,7 @@ static int run_java_shutdown()
void create_vm(Global_Env *p_env, JavaVMInitArgs* vm_arguments)
{
+init_l10n();
#ifdef PLATFORM_POSIX
init_linux_thread_system();
#elif defined(PLATFORM_NT)
diff --git a/vm/vmcore/src/l10n.cpp b/vm/vmcore/src/l10n.cpp
new file mode 100644
index 000..d9d380a
--- /dev/null
+++ b/vm/vmcore/src/l10n.cpp
@@ -0,0 +1,4 @@
+#include l10n.h
+
+void init_l10n() {
+}
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Andrew Zhang
China Software Development Lab, IBM
Re: [classlib] compatibility nuances
On 7/13/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: I assume you mean [drlvm], since java.lang.Class in [classlib] is just a stub, right? Anyway, what would you say exactly? That our not in any particular order is different than the not in any particular order that the RI does? I'm not trying to make light of it, but it sounds like all is correct. IMHO, If Harmony VM could act the same as that of RI, the thing would be better. geir Alexei Zakharov wrote: Hi, I have discovered we have small incompatibility in our java.lang.Class implementation. The order of elements returned by Class.getDeclaredMethods() differs from RI. The spec says here: The elements in the array returned are not sorted and are not in any particular order. But I already know one application that relies on this - this was one of java.beans test (already patched). I don't want to say this is somehow bad but still like to inform the community about this issue. Probably we need to rise non-bug differences JIRA? Thanks, - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Andrew Zhang China Software Development Lab, IBM
RE: [classlib] compatibility nuances
-Original Message- From: Andrew Zhang [mailto:[EMAIL PROTECTED] Sent: Thursday, July 13, 2006 10:04 AM To: harmony-dev@incubator.apache.org; [EMAIL PROTECTED] Subject: Re: [classlib] compatibility nuances On 7/13/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: I assume you mean [drlvm], since java.lang.Class in [classlib] is just a stub, right? Anyway, what would you say exactly? That our not in any particular order is different than the not in any particular order that the RI does? I'm not trying to make light of it, but it sounds like all is correct. IMHO, If Harmony VM could act the same as that of RI, the thing would be better. I agree, but is their order predictable? geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] compatibility nuances
That our not in any particular order is different than the not in any particular order that the RI does? I'm not trying to make light of it, but it sounds like all is correct. Right, from the spec point of view everything is correct. But I'd like to say that our particular order differs from RI particular order (and such behavior conforms to spec). My next statement is: there are stupid apps that rely on the particular order returned by RI (regardless of spec). I know one already. The question is: should we care or not? 2006/7/13, Geir Magnusson Jr [EMAIL PROTECTED]: I assume you mean [drlvm], since java.lang.Class in [classlib] is just a stub, right? Anyway, what would you say exactly? That our not in any particular order is different than the not in any particular order that the RI does? I'm not trying to make light of it, but it sounds like all is correct. geir Alexei Zakharov wrote: Hi, I have discovered we have small incompatibility in our java.lang.Class implementation. The order of elements returned by Class.getDeclaredMethods() differs from RI. The spec says here: The elements in the array returned are not sorted and are not in any particular order. But I already know one application that relies on this - this was one of java.beans test (already patched). I don't want to say this is somehow bad but still like to inform the community about this issue. Probably we need to rise non-bug differences JIRA? Thanks, -- Alexei Zakharov, Intel Middleware Product Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm/mmtk] jitrino.jet write barrier initial implementaion
Weldon, Warning: unknown flag - jet::wb4j This warning means that the code for 'wb4j' switch processing is not on its place. Either the patch failed to apply, or jitrino.dll was not rebuild properly. Will rebuild help ? E.g. to remove build\win_ia32_msvc_debug\semis\vm\jitrino and then run build.bat -DCOMPONENTS=vm.jitrino ? -- Thanks, Alex Weldon Washburn wrote: On 7/10/06, Alex Astapchuk [EMAIL PROTECTED] wrote: Weldon, I just commited http://issues.apache.org/jira/browse/HARMONY-816 into JIRA. It contains the changes for Jitrino.JET: - magics support for MMTk - write barriers for Java for MMTk - a simple test to check the things are alive I followed the instructions in HARMONY-816. It runs hello world OK but errors out when I try the following: build\win_ia32_msvc_debug\deploy\jre\bin\ij.exe -Xem jet: -Xjit jet::wb4j test Warning: unknown flag - jet::wb4j java.lang.NullPointerException at test.test0(test.java:37) at test.main(test.java:26) Any suggestions would be appreciated. I will dig into the details tomorrow morning. By the way, I am using windows laptop for development. Perhaps the \: needs to be replaced with \; Thanks Weldon - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [classlib] compatibility nuances
-Original Message- From: Alexei Zakharov [mailto:[EMAIL PROTECTED] Sent: Thursday, July 13, 2006 10:19 AM To: harmony-dev@incubator.apache.org; [EMAIL PROTECTED] Subject: Re: [classlib] compatibility nuances That our not in any particular order is different than the not in any particular order that the RI does? I'm not trying to make light of it, but it sounds like all is correct. Right, from the spec point of view everything is correct. But I'd like to say that our particular order differs from RI particular order (and such behavior conforms to spec). My next statement is: there are stupid apps that rely on the particular order returned by RI (regardless of spec). I know one already. The question is: should we care or not? Can you figure out what their order is? If so, I'd use that since we are free to do what we want, and if someone does depende on this, it's one less change, and it's spec compliant. Geir 2006/7/13, Geir Magnusson Jr [EMAIL PROTECTED]: I assume you mean [drlvm], since java.lang.Class in [classlib] is just a stub, right? Anyway, what would you say exactly? That our not in any particular order is different than the not in any particular order that the RI does? I'm not trying to make light of it, but it sounds like all is correct. geir Alexei Zakharov wrote: Hi, I have discovered we have small incompatibility in our java.lang.Class implementation. The order of elements returned by Class.getDeclaredMethods() differs from RI. The spec says here: The elements in the array returned are not sorted and are not in any particular order. But I already know one application that relies on this - this was one of java.beans test (already patched). I don't want to say this is somehow bad but still like to inform the community about this issue. Probably we need to rise non-bug differences JIRA? Thanks, -- Alexei Zakharov, Intel Middleware Product Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] compatibility nuances
On 7/13/06, Magnusson, Geir [EMAIL PROTECTED] wrote: -Original Message- From: Alexei Zakharov [mailto:[EMAIL PROTECTED] Sent: Thursday, July 13, 2006 10:19 AM To: harmony-dev@incubator.apache.org; [EMAIL PROTECTED] Subject: Re: [classlib] compatibility nuances That our not in any particular order is different than the not in any particular order that the RI does? I'm not trying to make light of it, but it sounds like all is correct. Right, from the spec point of view everything is correct. But I'd like to say that our particular order differs from RI particular order (and such behavior conforms to spec). My next statement is: there are stupid apps that rely on the particular order returned by RI (regardless of spec). I know one already. The question is: should we care or not? Can you figure out what their order is? If so, I'd use that since we are free to do what we want, and if someone does depende on this, it's one less change, and it's spec compliant. +1. Do our best to comply with spec and follow RI :) Geir 2006/7/13, Geir Magnusson Jr [EMAIL PROTECTED]: I assume you mean [drlvm], since java.lang.Class in [classlib] is just a stub, right? Anyway, what would you say exactly? That our not in any particular order is different than the not in any particular order that the RI does? I'm not trying to make light of it, but it sounds like all is correct. geir Alexei Zakharov wrote: Hi, I have discovered we have small incompatibility in our java.lang.Class implementation. The order of elements returned by Class.getDeclaredMethods() differs from RI. The spec says here: The elements in the array returned are not sorted and are not in any particular order. But I already know one application that relies on this - this was one of java.beans test (already patched). I don't want to say this is somehow bad but still like to inform the community about this issue. Probably we need to rise non-bug differences JIRA? Thanks, -- Alexei Zakharov, Intel Middleware Product Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Andrew Zhang China Software Development Lab, IBM
Re: [drlvm] proposals for VM internationalization
Geir Magnusson Jr wrote: Salikh Zakirov wrote: Why not use GNU gettext -- de facto standard i18n system on GNU/Linux systems? Isn't it under the GPL? The runtime part (libintl) is LGPL, so it allows linking to non-GPL programs. The tools are indeed GPL, but Harmony project is not going either link with them. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [drlvm] proposals for VM internationalization
-Original Message- From: Salikh Zakirov [mailto:[EMAIL PROTECTED] Sent: Thursday, July 13, 2006 10:32 AM To: harmony-dev@incubator.apache.org Subject: Re: [drlvm] proposals for VM internationalization Geir Magnusson Jr wrote: Salikh Zakirov wrote: Why not use GNU gettext -- de facto standard i18n system on GNU/Linux systems? Isn't it under the GPL? The runtime part (libintl) is LGPL, so it allows linking to non-GPL programs. The tools are indeed GPL, but Harmony project is not going either link with them. Do you mean there won't be any runtime dependencies? We can't distribute LGPL-ed binaries. Geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] compatibility nuances
Can you figure out what their order is? If so, I'd use that since we are free to do what we want, and if someone does depende on this, it's one less change, and it's spec compliant. I would say it is in the definition order but some methods are placed in the begining of the list by no reason. Example of such methods: public static void main() public static Test suite() The only thing I can say with confidence - the order doesn't change from invocation to invocation. +1. Do our best to comply with spec and follow RI :) Yeah, probably a good idea. Any volunteers? :) 2006/7/13, Andrew Zhang [EMAIL PROTECTED]: On 7/13/06, Magnusson, Geir [EMAIL PROTECTED] wrote: -Original Message- From: Alexei Zakharov [mailto:[EMAIL PROTECTED] Sent: Thursday, July 13, 2006 10:19 AM To: harmony-dev@incubator.apache.org; [EMAIL PROTECTED] Subject: Re: [classlib] compatibility nuances That our not in any particular order is different than the not in any particular order that the RI does? I'm not trying to make light of it, but it sounds like all is correct. Right, from the spec point of view everything is correct. But I'd like to say that our particular order differs from RI particular order (and such behavior conforms to spec). My next statement is: there are stupid apps that rely on the particular order returned by RI (regardless of spec). I know one already. The question is: should we care or not? Can you figure out what their order is? If so, I'd use that since we are free to do what we want, and if someone does depende on this, it's one less change, and it's spec compliant. +1. Do our best to comply with spec and follow RI :) Geir 2006/7/13, Geir Magnusson Jr [EMAIL PROTECTED]: I assume you mean [drlvm], since java.lang.Class in [classlib] is just a stub, right? Anyway, what would you say exactly? That our not in any particular order is different than the not in any particular order that the RI does? I'm not trying to make light of it, but it sounds like all is correct. geir Alexei Zakharov wrote: Hi, I have discovered we have small incompatibility in our java.lang.Class implementation. The order of elements returned by Class.getDeclaredMethods() differs from RI. The spec says here: The elements in the array returned are not sorted and are not in any particular order. But I already know one application that relies on this - this was one of java.beans test (already patched). I don't want to say this is somehow bad but still like to inform the community about this issue. Probably we need to rise non-bug differences JIRA? Thanks, -- Alexei Zakharov, Intel Middleware Product Division -- Alexei Zakharov, Intel Middleware Product Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] proposals for VM internationalization
Vladimir Gorr wrote: Have you looked at the patch I've sent? It doesn't use gettext. It just proposes the way to move forward towards propertly localized DRLVM. I think we will be able to use ICU4C java-like localization in the following way: * extract localizable strings from .cpp files using xgettext * process resulting .po files and autogenerate resource bundles from them * use resource bundles for translation and distribution There is an essential obstacle to use the *gettext* approach. It's impossible to run VM on Windows platform if not to take into account CYGWIN environment. I do not insist on using gettext, but will answer just for the record: there exists a project to port libintl to native Windows using MinGW [1] I'm not clear as well how we will merge the previous .po catalogs (already translated) with new ones (when new strings to be added). Again, I do not insist on using gettext, however, gettext has the tool exactly for this task: msgmerge [2] However _() should be inserted for all strings (and then deleted?) to achieve this. It involves too big efforts. The effort could be big, but is needed for any localization system we use. The task to classify the messages to translatable (visible to user on a day-to-day basis) and non-translatable (internal errors and debug logging) is needed anyway, because we do not want to overload translators with useless work of translating every string in the project. IMHO, _() marker is visually the prettiest way mark localizable strings. (compared to // NON-NLS comments and resource bundle constants) Therefore my preference is to use more universal approach, namely, ICU4C or LOG4CXX or combination of them. I've looked through Log4cxx manual and haven't found anything concerning both localization and internationalization. By the way, DRLVM already uses Log4cxx. ICU4C provides both internationalization and localization services [3]. It's native system uses ResourceBundles and looks similar to Java localization system, and it suffers from the same drawback: the message keys are constants, which are never printed, but have to be defined and referenced in multiple places. The developer overhead to make a localizable message is as high as * define a new constant in some file * add a message to the default resource bundle and inolves editing multiple files. I have no doubt that this overhead significantly higher than putting three characters to mark the string in _() way. -- Salikh. [1] http://gnuwin32.sourceforge.net/packages/libintl.htm [2] http://www.gnu.org/software/gettext/manual/html_mono/gettext.html#SEC36 [3] http://icu.sourceforge.net/userguide/localizing.html - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[os] freebsd
Hello,
Some time ago I installed FreeBSD 6.1-RELEASE on my home computer and
tried to build original Harmony VM donation [1] + corresponding
classlib on it. In the end of the efforts I've managed to build it and
print something with '-?' argument, but unfortunately an attempt to
run 'Hello, world' app failed.
The algorithm was straighforward - when a compile error happened, I've
tried to fix it in a straightforward way just to make build pass this
stage, and I'm not surprised that the resulted VM doesn't work :)
Maybe the list of those changes will give an idea what things should
be modified to run Harmony on another platform.
Details:
- I've installed FreeBSD with complete sources (compat included).
- JRE was Diablo-JRE from [2].
- added packages (pkg_add -r) libiconv and libxml2
- linker complained about -ldl missing in many places - I've tried to
removed all -ldl entries but finally gave up and symlinked libdl.so
to libc.so
- replaced everywhere #include malloc.h with #include stdlib.h
- paths to some include files changed and some other includes changed, too
- replaced PTHREAD_MUTEX_RECURSIVE_NP with PTHREAD_MUTEX_RECURSIVE
(_NP stands for non-portable, so I believe it's not a big crime)
- mcontext_t has a slighly different structure, for example
uc_mcontext.gregs[REG_EAX] - uc_mcontext.mc_eax
- sigcontext has a slighly different structure, for example
sigcontext.edi - sigcontext.sc_edi
- flag for shmem SHM_HUGETLB is missing on FreeBSD - I've just removed it
- hysysinfo.c: changed hysysinfo_get_physical_memory to code taken from [3]
- hysock.c - undefined HAS_RTNETLINK, changed SOL_IPV6 to IPPROTO_IPV6
- hysock.h - undefined GLIBC_R and defined NO_R (maybe better solution
would be ORIGINAL_R and linking with lc_r)
changed
#define OS_IPV6_ADD_MEMBERSHIP IPV6_ADD_MEMBERSHIP
#define OS_IPV6_DROP_MEMBERSHIP IPV6_DROP_MEMBERSHIP
to
#define OS_IPV6_ADD_MEMBERSHIP IPV6_JOIN_GROUP
#define OS_IPV6_DROP_MEMBERSHIP IPV6_LEAVE_GROUP
- thrdsup.c - commented out _FPU_GETCW and _FPU_SETCW
- hysiglinux.c - changed sigvec signature
sigvec (int sig, const struct sigvec *invec, struct sigvec *outvec)
to
sigvec (int sig, struct sigvec *invec, struct sigvec *outvec)
- pdsimpl.c - removed option SO_BINDTODEVICE (changed to 0). As far as
I understand, code with that flag returns available network interfaces
- I believe there's a possibility to rewrite in in a FreeBSD way.
Threads are a big problem. On Linux pthread_t is an unsigned int, on
FreeBSD - pthread* .
So things like code from gc_v4.cpp :
for (unsigned int i = 0; i get_num_worker_threads() ; i++) {
// Point the GC thread to the GC object
_gc_threads[i] = new GC_Thread(this, i);
assert(_gc_threads[i]);
}
won't work. I've just added cast to pthread_t but obviously this is
not a proper solution.
After these modifications all modules compiled but linker complained
that some log4cxx functions with wchar_t couldn't be found. Adding
-DLOG4CXX_HAS_WCHAR_T=1 and -D__STDC_ISO_10646__=1 flags to log4xcc
compilation helped . After that ij compiled but attempt to run it
crashed on mutexes. Those calls to mutexes were in sections surrounded
with #if APR_HAS_THREADS and it's no wonder I've recompiled log4cxx
with -DAPR_HAS_THREADS=0 . After that ij finally printed the list of
its options given the -? argument.
I've tried to play with the code further trying to make it run 'Hello,
world' app but failed.
Hope it makes some sence.
[1] http://issues.apache.org/jira/browse/HARMONY-438
[2] http://www.freebsdfoundation.org/downloads/java.shtml
[3] http://lists.freebsd.org/pipermail/freebsd-hackers/2005-December/014733.html
--
Regards,
Anton Luht,
Intel Middleware Products Division
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] proposals for VM internationalization
Andrew Zhang wrote: Vladimir Gorr wrote: namely, ICU4C or LOG4CXX or combination of them. log4cxx is already used in DRLVM. It does not provide localization services. If only for i18n, icu4c is prefered. So, would the following solution be acceptable to all? 1 mark the localizable strings with _() in .cpp files 2 write a tool to extract localizable messages from .cpp files and autogenerate ICU4C .txt resource bundles. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] proposals for VM internationalization
Magnusson, Geir wrote: Do you mean there won't be any runtime dependencies? We can't distribute LGPL-ed binaries. In this case, libintl is definitely out of question. However, I like the simplicity of _() interface. I think we can use it with ICU4C too. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] proposals for VM internationalization
I don't know if this is being considered, but 1) Classlib has lots of java internationalization needs, and some native internationalization needs 2) DRLVM has lots of native internationalization needs, and some java needs (kernel classes). So it seems clear to me we need to at least try for a common approach. geir Salikh Zakirov wrote: Andrew Zhang wrote: Vladimir Gorr wrote: namely, ICU4C or LOG4CXX or combination of them. log4cxx is already used in DRLVM. It does not provide localization services. If only for i18n, icu4c is prefered. So, would the following solution be acceptable to all? 1 mark the localizable strings with _() in .cpp files 2 write a tool to extract localizable messages from .cpp files and autogenerate ICU4C .txt resource bundles. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] internationalization
Geir Magnusson Jr wrote: Alexey Petrenko wrote: Geir, I've reread your email in the morning :) Internationalization classes auto-generation is really good idea. We can apply it for method described here and for new Eclipse method. I'll settle for it being an idea. Not sure if it's a good one. Tim has been working in this area, and I'm interested to hear what he thinks. I'm inclined to agree -- though I haven't really got a good technical argument, so I'll admit to falling back onto gut feel on this one. Eclipse is going to be using lots of messages in the UI etc., whereas we are using them in exception strings -- I think it is a quite different usecase. Diverting from the 'normal' way of doing this with resource files without having a problem at the moment feels like a premature optimization to me (I know that's a bit woolly). I would like to avoid introducing new non-Java API dependencies between modules in order to achieve the internationalization if we can avoid it. Regards, Tim In the first case generator will insert correct resource bundle and package name. In the second one we can generate the supporting class from the resource bundle file. There will be 2 big differences between this two methods: 1. Initialization time: much faster for the first method 2. Run time access time: much faster for the second method So if we will have situation with the big resource file and small number of accesses to it then the first method will be faster. In the case with large number of accesses the second method will be more preferable. Can you quantify what much faster is for both cases? Probably we should think about using both methods depends on the purpose. For example. For UI application we have a huge number of messages which are widely used during normal run (menu items, user messages etc) and in this case the second method seems better. Otherwise for the code without user interaction the messages from the bundle will be mostly used as error messages for the throwing exceptions. We hope that exceptions will not happen very often. And we know that throwing an exception is rather long operation. So in this case the first method seems better. Hmm... It looks like I've found an argument for using traditional method in class library :) :) SY, Alexey 2006/7/11, Geir Magnusson Jr [EMAIL PROTECTED]: Tim Ellison wrote: Ilya Okomin wrote: I'd like to be a volunteer for that. I just started working in this area (for SQL), maybe that is what prompted you...g IMHO it's reasonable to use framework presented in luni module with some modifications. To avoid duplication of Msg class I'd suggest use slightly modified Msg class named let say o.a.h.luni.utils.ExtMsg. ExtMsg has the same methods as Msg, the difference is only these methods are non static, also specific external messages resource bundle will be initialized by name in the constructor. Each module will have class o.a.h.module.MsgUtils with static field 'msg' that is the instance of ExtMsg initialized with the name of the external messages resource bundle related to this module. Thus external message for e.g. security module could be obtained using next call: org.apache.harmony.security.internal.MsgUtils.msg.getString(security.1); I see your point, and considered doing it that way too. I'm not overly concerned about the duplication, they are trivial helper methods anyway, and we all know that singletons are evil ;-) I don't understand this, given you have one... And at last, place to keep resources with external messages I suppose to be o.a.h.module.internal. I went for o.a.h.module.internal.nls just to keep them tidy. If all these thoughts sounds reasonable, I'd like to implement framework mentioned above and send you a patch. The real work is going through and externalizing all the messages, and if I were to be really ambitious to add messages to all the exceptions that we throw that don't have anything right now. Patches are always welcome. We can work on that that as we finalize on the framework. Have you had any thoughts about a 'common' code set, that is copied and modified at build time, setting the right package name and bundle name by convention? That would remove the need to duplicate the code. geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use :
[drlvm] assorted bug fixes contribution for DRLVM
Hi, I would like to announce a contribution of assorted bug fixes and improvements to DRLVM on behalf of my colleagues and Intel corporation. The zip file with patches is attached to HARMONY-856. The bug fixes were developed simultaneously with the tedious process of preparing the original DRLVM contribution. Fixes are fairly widespread in the codebase, and result in some great stability improvements, such as running 24 hours straight with complicated workloads, like development in Eclipse. This contribution is somewhat lagging behind the time when the patches were developed due to the rigorous internal process of legal scanning of all code contributed by Intel. Nevertheless, this contribution moves us significantly forward in achieving the goal of publishing the backlog of DRLVM fixes. To make the review of changes more convenient, each change is accompanied with a detailed description. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] compatibility nuances
Alexei Zakharov wrote: I know one already. Go on, stop teasing, what is it? ;-) As others have said elsewhere, if you can determine the order, and we don't have to perform unnatural acts to make it the same, then no reason to be different just because we can. Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] assorted bug fixes contribution for DRLVM
Salikh, Thanks for this set of fixes. Though I understand that the changes are described in the zip, would it be possible for you to list/summarize some of the key changes in the submission on this thread? Thanks, Rana On 7/13/06, Salikh Zakirov [EMAIL PROTECTED] wrote: Hi, I would like to announce a contribution of assorted bug fixes and improvements to DRLVM on behalf of my colleagues and Intel corporation. The zip file with patches is attached to HARMONY-856. The bug fixes were developed simultaneously with the tedious process of preparing the original DRLVM contribution. Fixes are fairly widespread in the codebase, and result in some great stability improvements, such as running 24 hours straight with complicated workloads, like development in Eclipse. This contribution is somewhat lagging behind the time when the patches were developed due to the rigorous internal process of legal scanning of all code contributed by Intel. Nevertheless, this contribution moves us significantly forward in achieving the goal of publishing the backlog of DRLVM fixes. To make the review of changes more convenient, each change is accompanied with a detailed description. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] proposals for VM internationalization
Geir Magnusson Jr wrote: I don't know if this is being considered, but 1) Classlib has lots of java internationalization needs, and some native internationalization needs 2) DRLVM has lots of native internationalization needs, and some java needs (kernel classes). FWIW, I as far as I can figure from both [drlvm] and [classlib] discussions, the topic is *localization*, i.e. providing the user with the messages in native language of the user. Concerning *internationalization* Java code is internationalized by design, and DRLVM needs some fixes to achieve it, at least * accept non-ascii class names in locale-specific encoding For more information about i18n vs l10n, see http://www.w3.org/International/questions/qa-i18n - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] internationalization
Tim Ellison wrote: Geir Magnusson Jr wrote: Alexey Petrenko wrote: Geir, I've reread your email in the morning :) Internationalization classes auto-generation is really good idea. We can apply it for method described here and for new Eclipse method. I'll settle for it being an idea. Not sure if it's a good one. Tim has been working in this area, and I'm interested to hear what he thinks. I'm inclined to agree -- though I haven't really got a good technical argument, so I'll admit to falling back onto gut feel on this one. Eclipse is going to be using lots of messages in the UI etc., whereas we are using them in exception strings -- I think it is a quite different usecase. Diverting from the 'normal' way of doing this with resource files without having a problem at the moment feels like a premature optimization to me (I know that's a bit woolly). I would like to avoid introducing new non-Java API dependencies between modules in order to achieve the internationalization if we can avoid it. I'm a little confused because I think Alexey combined two ideas that can be treated separate, using eclipse technique, and using lightweight code generation to create your solution automatically. I believe that you are rejecting the Eclipse solution as we don't have the same resource message requirements that Eclipse does. Right? Separately from that, what do you think about the build-time code gen (i.e. simple template w/ package name replacement...) so that it's easy to modify and switch in the future? geir Regards, Tim In the first case generator will insert correct resource bundle and package name. In the second one we can generate the supporting class from the resource bundle file. There will be 2 big differences between this two methods: 1. Initialization time: much faster for the first method 2. Run time access time: much faster for the second method So if we will have situation with the big resource file and small number of accesses to it then the first method will be faster. In the case with large number of accesses the second method will be more preferable. Can you quantify what much faster is for both cases? Probably we should think about using both methods depends on the purpose. For example. For UI application we have a huge number of messages which are widely used during normal run (menu items, user messages etc) and in this case the second method seems better. Otherwise for the code without user interaction the messages from the bundle will be mostly used as error messages for the throwing exceptions. We hope that exceptions will not happen very often. And we know that throwing an exception is rather long operation. So in this case the first method seems better. Hmm... It looks like I've found an argument for using traditional method in class library :) :) SY, Alexey 2006/7/11, Geir Magnusson Jr [EMAIL PROTECTED]: Tim Ellison wrote: Ilya Okomin wrote: I'd like to be a volunteer for that. I just started working in this area (for SQL), maybe that is what prompted you...g IMHO it's reasonable to use framework presented in luni module with some modifications. To avoid duplication of Msg class I'd suggest use slightly modified Msg class named let say o.a.h.luni.utils.ExtMsg. ExtMsg has the same methods as Msg, the difference is only these methods are non static, also specific external messages resource bundle will be initialized by name in the constructor. Each module will have class o.a.h.module.MsgUtils with static field 'msg' that is the instance of ExtMsg initialized with the name of the external messages resource bundle related to this module. Thus external message for e.g. security module could be obtained using next call: org.apache.harmony.security.internal.MsgUtils.msg.getString(security.1); I see your point, and considered doing it that way too. I'm not overly concerned about the duplication, they are trivial helper methods anyway, and we all know that singletons are evil ;-) I don't understand this, given you have one... And at last, place to keep resources with external messages I suppose to be o.a.h.module.internal. I went for o.a.h.module.internal.nls just to keep them tidy. If all these thoughts sounds reasonable, I'd like to implement framework mentioned above and send you a patch. The real work is going through and externalizing all the messages, and if I were to be really ambitious to add messages to all the exceptions that we throw that don't have anything right now. Patches are always welcome. We can work on that that as we finalize on the framework. Have you had any thoughts about a 'common' code set, that is copied and modified at build time, setting the right package name and bundle name by convention? That would remove the need to duplicate the code. geir - Terms of use :
Re: [drlvm] proposals for VM internationalization
we stand corrected. Both need localization, and we should be able to find commonality in the approaches. geir Salikh Zakirov wrote: Geir Magnusson Jr wrote: I don't know if this is being considered, but 1) Classlib has lots of java internationalization needs, and some native internationalization needs 2) DRLVM has lots of native internationalization needs, and some java needs (kernel classes). FWIW, I as far as I can figure from both [drlvm] and [classlib] discussions, the topic is *localization*, i.e. providing the user with the messages in native language of the user. Concerning *internationalization* Java code is internationalized by design, and DRLVM needs some fixes to achieve it, at least * accept non-ascii class names in locale-specific encoding For more information about i18n vs l10n, see http://www.w3.org/International/questions/qa-i18n - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Commented: (HARMONY-815) [classlib][nio] Refine implConfigureBlocking(boolean) method of DatagramChannel and SocketChannel.
Andrew Zhang wrote:
How about design a subclass which extends from SocketException, looks like:
If you want to preserve the throwable type you could create a
o.a.h.luni.ErrorCodeException that has a errorCode field set by the
native, and then make that the cause of the SocketException.
The calling code would then do something like:
((ErrorCodeException)ex.getCause()).getErrorCode()
Just a thought.
Regards,
Tim
class SocketWithErrorCodeException extends SocketException {
SocketWithErrorCodeException (String message, int errorCode) {
super(message); this.errorCode = errorCode; }
private int errorCode;
public void get/setErrorCode() ;
}
Native code throws SocketWithErrorCodeException instead of SocketException
so that java code could process different error by invoking e.getErrorCode
().
Does that make sense?
Thanks!
On 7/13/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote:
I agree with the reason why (I think I understand it - you don't want to
rely on the result of getMessage() to determine the problem...)
Could you wrap the socket exception to carry a simple integer error code?
geir
Mikhail Loenko wrote:
-1 for applying the patch
Applying this patch means creating a hidden problem
Thanks,
Mikhail
2006/7/12, Jimmy, Jing Lv [EMAIL PROTECTED]:
Andrew Zhang wrote:
Hello Mikhail,
Please see my comments inline.
Thanks!
On 7/12/06, Mikhail Loenko [EMAIL PROTECTED] wrote:
2006/7/12, Andrew Zhang [EMAIL PROTECTED]:
Hi Mikhail,
It's a NON-NLS message.
Native code is designed in this way. Currently, Harmony socket
native
code
uses messages in SocketException to identify error type.
To avoid the confusion, two alternatives way I could image are:
1. Native code returns platform-independent error code.
2. Native code throws different exceptions, which are all
extended from
SocketException.
Anyway, as current Harmony native design, the message in
SocketException
thrown by native code is a NON-NLS string, that is to say, like
GET,POST
in http protocol. Unless we take a big change on native code
design, I
don't think the code is dangerous.
What's your opnion?
I like option #2.
I also prefer option1 and 2 to current native solution.
I don't think exception messages are the same as GET and
POST, we
agreed
that the messages are to be internationalized. I see that currently
not
all
the messages are internationalized but I think they will in the
future.
NO. Currently, exception message thrown by native code are used as
if error
code [1]. Please pay attention to netLookupErrorString function.
Harmony-815 patch is based on current Harmony native implemenation,
therefore, it should work well if design is not changed.
If we decide to adopt option 1, or 2, we have to re-design native
and java
interface,
and there are lots of native and java code to be changed.
How to design native interface is out of scope to this patch,
therefore, I
think a seperate JIRA or thread for socket native interface design
is more
suitable.
Of course, once decision is made, I'll volunteer to revise native
and java
code.
Yep, I also find this strange style of return value, I doubt if the
exception thrown in native may be an enhancement to code efficiency?
However to refactor this may be a heavy work, as much code follows
this
style, affects both luni and nio. I suggest apply this patch, and
leave
this work until Harmony begins i18n.
Does it make sense?
Thanks!
[1] native-src (nethelp.c)
void
throwJavaNetSocketException (JNIEnv * env, I_32 errorNumber)
{
jclass aClass;
/* the error message lookup should be done before the FindClass
call,
because the FindClass call
* may reset the error number that is used in hysock_error_message
*/
// !!! Here, error code is mapped to NON-NLS mesage.
char *errorMessage = netLookupErrorString (env, errorNumber);
aClass = (*env)-FindClass (env, java/net/SocketException);
if (0 == aClass)
{
return;
}
(*env)-ThrowNew (env, aClass, errorMessage);
}
char *
netLookupErrorString (JNIEnv * env, I_32 anErrorNum)
{
PORT_ACCESS_FROM_ENV (env);
switch (anErrorNum)
{
case HYPORT_ERROR_SOCKET_BADSOCKET:
return Bad socket;
case HYPORT_ERROR_SOCKET_NOTINITIALIZED:
return Socket library uninitialized;
case HYPORT_ERROR_SOCKET_BADAF:
return Bad address family;
case HYPORT_ERROR_SOCKET_BADPROTO:
return Bad protocol;
case HYPORT_ERROR_SOCKET_BADTYPE:
return Bad type;
case HYPORT_ERROR_SOCKET_SYSTEMBUSY:
return System busy handling requests;
case HYPORT_ERROR_SOCKET_SYSTEMFULL:
return Too many sockets allocated;
case
Re: [jira] Commented: (HARMONY-815) [classlib][nio] Refine implConfigureBlocking(boolean) method of DatagramChannel and SocketChannel.
I like this
Tim Ellison wrote:
Andrew Zhang wrote:
How about design a subclass which extends from SocketException, looks like:
If you want to preserve the throwable type you could create a
o.a.h.luni.ErrorCodeException that has a errorCode field set by the
native, and then make that the cause of the SocketException.
The calling code would then do something like:
((ErrorCodeException)ex.getCause()).getErrorCode()
Just a thought.
Regards,
Tim
class SocketWithErrorCodeException extends SocketException {
SocketWithErrorCodeException (String message, int errorCode) {
super(message); this.errorCode = errorCode; }
private int errorCode;
public void get/setErrorCode() ;
}
Native code throws SocketWithErrorCodeException instead of SocketException
so that java code could process different error by invoking e.getErrorCode
().
Does that make sense?
Thanks!
On 7/13/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote:
I agree with the reason why (I think I understand it - you don't want to
rely on the result of getMessage() to determine the problem...)
Could you wrap the socket exception to carry a simple integer error code?
geir
Mikhail Loenko wrote:
-1 for applying the patch
Applying this patch means creating a hidden problem
Thanks,
Mikhail
2006/7/12, Jimmy, Jing Lv [EMAIL PROTECTED]:
Andrew Zhang wrote:
Hello Mikhail,
Please see my comments inline.
Thanks!
On 7/12/06, Mikhail Loenko [EMAIL PROTECTED] wrote:
2006/7/12, Andrew Zhang [EMAIL PROTECTED]:
Hi Mikhail,
It's a NON-NLS message.
Native code is designed in this way. Currently, Harmony socket
native
code
uses messages in SocketException to identify error type.
To avoid the confusion, two alternatives way I could image are:
1. Native code returns platform-independent error code.
2. Native code throws different exceptions, which are all
extended from
SocketException.
Anyway, as current Harmony native design, the message in
SocketException
thrown by native code is a NON-NLS string, that is to say, like
GET,POST
in http protocol. Unless we take a big change on native code
design, I
don't think the code is dangerous.
What's your opnion?
I like option #2.
I also prefer option1 and 2 to current native solution.
I don't think exception messages are the same as GET and
POST, we
agreed
that the messages are to be internationalized. I see that currently
not
all
the messages are internationalized but I think they will in the
future.
NO. Currently, exception message thrown by native code are used as
if error
code [1]. Please pay attention to netLookupErrorString function.
Harmony-815 patch is based on current Harmony native implemenation,
therefore, it should work well if design is not changed.
If we decide to adopt option 1, or 2, we have to re-design native
and java
interface,
and there are lots of native and java code to be changed.
How to design native interface is out of scope to this patch,
therefore, I
think a seperate JIRA or thread for socket native interface design
is more
suitable.
Of course, once decision is made, I'll volunteer to revise native
and java
code.
Yep, I also find this strange style of return value, I doubt if the
exception thrown in native may be an enhancement to code efficiency?
However to refactor this may be a heavy work, as much code follows
this
style, affects both luni and nio. I suggest apply this patch, and
leave
this work until Harmony begins i18n.
Does it make sense?
Thanks!
[1] native-src (nethelp.c)
void
throwJavaNetSocketException (JNIEnv * env, I_32 errorNumber)
{
jclass aClass;
/* the error message lookup should be done before the FindClass
call,
because the FindClass call
* may reset the error number that is used in hysock_error_message
*/
// !!! Here, error code is mapped to NON-NLS mesage.
char *errorMessage = netLookupErrorString (env, errorNumber);
aClass = (*env)-FindClass (env, java/net/SocketException);
if (0 == aClass)
{
return;
}
(*env)-ThrowNew (env, aClass, errorMessage);
}
char *
netLookupErrorString (JNIEnv * env, I_32 anErrorNum)
{
PORT_ACCESS_FROM_ENV (env);
switch (anErrorNum)
{
case HYPORT_ERROR_SOCKET_BADSOCKET:
return Bad socket;
case HYPORT_ERROR_SOCKET_NOTINITIALIZED:
return Socket library uninitialized;
case HYPORT_ERROR_SOCKET_BADAF:
return Bad address family;
case HYPORT_ERROR_SOCKET_BADPROTO:
return Bad protocol;
case HYPORT_ERROR_SOCKET_BADTYPE:
return Bad type;
case HYPORT_ERROR_SOCKET_SYSTEMBUSY:
return System busy handling requests;
case HYPORT_ERROR_SOCKET_SYSTEMFULL:
return Too many sockets allocated;
case HYPORT_ERROR_SOCKET_NOTCONNECTED:
return Socket is not connected;
case HYPORT_ERROR_SOCKET_INTERRUPTED:
return The call was cancelled;
case HYPORT_ERROR_SOCKET_TIMEOUT:
return The operation timed out;
case
Re: [classlib][concurrent] java.util.concurrent module proposal
I think you may have inadvertently checked the code into the wrong location in SVN. Could you move it please? Thanks Tim Nathan Beyer wrote: -Original Message- From: Geir Magnusson Jr [mailto:[EMAIL PROTECTED] snip/ First problem is that you included CopyOnWriteArrayList.java, which is *not* a file we can take, as it's (c) Sun and under some unknown license. I've deleted it from SVN. Sorry, I completely overlooked that. Design - Most of the code is straight from Doug Lea and the JSR group. The only piece I've added are the service interfaces that the VM must implement and I've uplifted the original code, where necessary to utilize these VM service interfaces. I don't know what you mean by uplift - I'm guessing you mean how you modified to not use sun.com.Unsafe? I'd like to avoid modifying any of this code, and just using as is, meaning for now we implement sun.com.Unsafe and whatever else, and then lobby Doug to change to something neutral. We might be able to get away with using the jar that is found on his website (assuming we can get him to produce one w/o Sun code, which isn't the case now), which would further drive the requirement that we use the code unmodified. I'm fine with doing this, but I thought there might be a copyright issue with using the 'sun.misc.Unsafe' class name. Additionally, the interface would have to be reverse engineered from the source that uses it. There isn't a stub of it in the ViewCVS repository that can be seen. Also, the .class file is NOT included in any of the JARs on the site. Are we cool with doing this? Note, just implementing 'sun.misc.Unsafe' may not be enough, as it seems that some pieces of the code make assumptions about internals of other classes. For example, LockSupport [1] retrieves the Field 'parkBlocker' from java.lang.Thread, which is not part of the public contract. If we just want to stick to a pure compilation route, then I think we would likely have to get Doug, et al to adopt some VM agnostic APIs before we take this code. [1] http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/main/java/util/concu rrent/locks/LockSupport.java?rev=1.21only_with_tag=HEADcontent-type=text/v nd.viewcvs-markup snip/ Hm. Maybe I don't understand (there's other feedback about using an SPI earlier in the thread), but if we just implemented sun.misc.Unsafe, aren't we done? [SNIP] TODOs - snip/ * There are a LOT of changes, fixes and enhancements to the code at Doug Lea's site; consider what code we should additional take. Doug suggested we take HEAD, which would include changes for Mustang, but should be 100% compatible w/ Java 5. (And it doesn't really matter if we try and it's not true, as we aren't modifying any of his code, presumably.) I'd prefer to take HEAD myself and the code only uses JLS3, but there are dependencies on Java 6 APIs. For example, the ConcurrentHashMap uses the new AbstractMap.SimpleEntry class [1]. Also, there are a number of references to the new Arrays.copyXXX methods as well. Additionally, we talked about this a few times and I came away with that we should try to use the latest Java 5 tag [2][3][4]. Just as a reminder: there hasn't been a new tag since the JSR166_PFD tag (over 2 years old), so it's either that or HEAD + Harmony building some Java 6 APIs. Note, I'm perfectly fine with doing that as we'll need to do it eventually. [1] http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/main/java/util/concu rrent/ConcurrentHashMap.java?rev=1.91content-type=text/vnd.viewcvs-markup [2] http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200606.mbox/% [EMAIL PROTECTED] [3] http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200606.mbox/% [EMAIL PROTECTED] [4] http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200606.mbox/% [EMAIL PROTECTED] geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] assorted bug fixes contribution for DRLVM
Rana Dasgupta wrote: would it be possible for you to list/summarize some of the key changes in the submission on this thread? sure. The contributed patches fix * a couple of memory leaks in DRLVM * incorrect code for SWAP operation in Jitrino.JET * a number of bugs in kernel classes * bug in capabilities handling in JVMTI * several incorrect assertions More detailed information is provided in the patches themselves. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] assorted bug fixes contribution for DRLVM
Thanks Salikh -- just to make it clear I have classified the JIRA as a 'contribution' rather than a 'new feature'. Regards, Tim Salikh Zakirov wrote: Hi, I would like to announce a contribution of assorted bug fixes and improvements to DRLVM on behalf of my colleagues and Intel corporation. The zip file with patches is attached to HARMONY-856. The bug fixes were developed simultaneously with the tedious process of preparing the original DRLVM contribution. Fixes are fairly widespread in the codebase, and result in some great stability improvements, such as running 24 hours straight with complicated workloads, like development in Eclipse. This contribution is somewhat lagging behind the time when the patches were developed due to the rigorous internal process of legal scanning of all code contributed by Intel. Nevertheless, this contribution moves us significantly forward in achieving the goal of publishing the backlog of DRLVM fixes. To make the review of changes more convenient, each change is accompanied with a detailed description. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][concurrent] java.util.concurrent module proposal
Tim Ellison wrote: Geir Magnusson Jr wrote: Tim Ellison wrote: Geir Magnusson Jr wrote: Tim Ellison wrote: Nathan Beyer wrote: I've checked in my proposal for the java.util.concurrent module at https://svn.apache.org/repos/asf/incubator/harmony/enhanced/classlib/trunk/s andbox/juc-proposal. You didn't just check in a proposal, you also checked in Doug Lea et al's code. Nobody should commit other people's code into svn this way. The code is under public domain license, so there should be no problem doing it since Doug et al produce no builds, and they suggested we do this. (not trying to be provocative, just trying to understand) they = the concurrency authors? do this = produce builds or check the code into our repository? Did I get this right? Sorry - I missed this - they really was Doug, and do this is take the code. Checking it in simply is good practice for peace of mind. it's also in our sandbox, and we're not redistributing it yet. Was there a reason to create .../classlib/trunk/sandbox? wouldn't .../classlib/sandbox make more sense? We already had the sandbox under /trunk No we didn't. http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/sandbox/?view=logpathrev=42 Perhaps it was created in the trunk by mistake. Oh, right. Sorry - there was a sandbox in enhanced/trunk which is what I thought it was checked into... So does anyone object to the proposed code being moved out of the enhanced subtree while we stare at it, thereby preserving our definition of 'enhanced'. I sort of do because we are utterly inconsistent about this, but if you look at my other message, if we just shove this into /standard/ the whole problem seems to magically go away anyway, so go ahead. I see copying the code as a one-way operation. We can hope to track updates to the original code thoroughly, but I don't see any fixes made in Harmony making it back directly into Doug's repository. Why not? We just offer them to Doug, and he can accept or reject. It strikes me as a strange model. If there is a well-run, active project with compatible license elsewhere I'm struggling to see why we would not just join in there, and all enjoy the fruits of the combined work g. Maybe this was discussed as part of the suggestion from Doug? Doug just suggested that we'd be well served using his code since it's public domain and the definitive implementation. If there is a well-run, active project with compatible license elsewhere, please point it out. As far as I know, this is the only implementation out there, and is why it's taken and used by IBM, BEA, Apple and Sun in the same way we're proposing. (IBM does not source the code directly from there, but that is a different matter) Why not just enjoy the fruits of what's being offered as public domain by arguably the world's top expert on the subject? While we have lots of talent around here, I'd be very surprised if we could do better. No arguments from me, that was the point that I was making too. Let's work with that project where we need to do so, and take their code as a dependency for Harmony. That's what we're doing. Is there a reason why we want to fork this code? I'd rather we worked with Doug (contributing directly to his project to make it more widely usable etc). Tim, isn't this what we discussed? This isn't a fork in the community sense, it's what amounts to a read only copy of the code for purposes of building, but tracking what Doug does? We've been very clear about that. Do you think it is reasonable to work with that group to make the code usable by Harmony as well as Sun? Yes, of course, although it seems usable now... Not without the modifications that nathan has been working on. We want to avoid modifying their code. I guess the alternative is that we replicate Sun's internal APIs if we want to make the incoming code read-only (and presumably put it into the depends/ directory). I don't understand the bit about the depends directory, but yes, I think that using this code as-is would require us to implement sun.misc.Unsafe, and I do think it's a reasonable thing to suggest to Doug that a neutral package is chosen for this like org.apache.harmony.Unsafe :) Now we are talking ;-) In fact, if Sun want to publish the API I'm even prepared to give up the o.a.h. bit g That works for me too, although the joy of seeing harmony in a Sun VM package dep would be a hoot... snip * Determine the best place to integrate the TCK source, which is also available at Doug Lea's site. Are you serious? Why would we copy the TCK into Harmony too?! Because that isn't the TCK, but simply testcases? I haven't checked, I took Nathan at his word. They are labeled as TCK tests, but by definition, the TCK only comes from the Spec lead. http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/test/tck/ So from our POV, while this is code
Re: [classlib] compatibility nuances
Go on, stop teasing, what is it? ;-) Not a big deal, I have already mentioned it in my first mail. This is our java.beans tests. :-) The idea was if one person hit upon the idea of such tests then another person can similarly build a complete application based on the same precondition. 2006/7/13, Tim Ellison [EMAIL PROTECTED]: Alexei Zakharov wrote: I know one already. Go on, stop teasing, what is it? ;-) As others have said elsewhere, if you can determine the order, and we don't have to perform unnatural acts to make it the same, then no reason to be different just because we can. Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Alexei Zakharov, Intel Middleware Product Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] assorted bug fixes contribution for DRLVM
Tim Ellison wrote: Thanks Salikh -- just to make it clear I have classified the JIRA as a 'contribution' rather than a 'new feature'. Thanks, Tim. It was very awkward of me to file it as new feature. I have even managed to upload the file twice and could not delete it :) Salikh Zakirov wrote: Hi, I would like to announce a contribution of assorted bug fixes and improvements to DRLVM on behalf of my colleagues and Intel corporation. The zip file with patches is attached to HARMONY-856. ... - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[DRLVM] build fixes that allow normal single step debug of the Jitrino.JET write barrier patch
All,
The following build mods will create a drlvm binary that can be used
to debug the Jitrino.JET write barriers. Rather than make everyone
suffer through long email chains, Alex and I collaborated offline.
The mods to drlvm/trunk/build/build.bat:
--- build.bat (revision 421403)
+++ build.bat (working copy)
@@ -138,7 +138,7 @@
)
REM Note: vm.jitrino is always complied in release mode, otherwise it makes VM
debug too slow
-CALL %ANT_COMMAND% -f make/build.xml -Dvm.jitrino.cfg=release %*
+CALL %ANT_COMMAND% -f make/build.xml %*
GOTO THEEND
Mods to drlvm/trunk/build/make/components/vm/jitrino.xml
project name=vm.jitrino
-target name=init
+target name=init depends=common_vm
property name=build.depends
value=extra.apr,vm.vmcore,vm.encoder /
property name=outtype value=shared /
property name=libname value=jitrino /
@@ -48,7 +48,8 @@
patternset id=java.classes.pattern includes=empty_pattern/
!-- the compiler doesn't extend common compiler --
-compiler name=${build.cxx} id=cpp.compiler
+!-- compiler name=${build.cxx} id=cpp.compiler --
+compiler id=cpp.compiler extends=common.cpp.compiler
For some unknown reason, svn diff wants to report that every line has
changed in common_vm.xml. Probably something to do with carriage
return line feed. In any case the mods to
drlvm/trunk/build/make/targets/common_vm.xml. These are the same mods
that were reported in the email titled, [DRLVM] questions about
build.bat -DEBUILD_CFG=debug -DCXX=msvc. They are repeated here for
completeness:
- select os=win cxx=msvc
compilerarg value=/Od /
compilerarg value=/MTd /
compilerarg value=/D_DEBUG /
/select
A new svn update of both classlib and drlvm was downloaded this
morning. The above mods were applied. And, finally, a build.bat
-DEBUILD_CFG=debug -DCXX=msvc was run. The binary is now debuggable
with MS Visual Studio.
Question: Should the above be bundled up as a JIRA patch?
--
Weldon Washburn
Intel Middleware Products Division
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DRLVM] build fixes that allow normal single step debug of the Jitrino.JET write barrier patch
Weldon, Thanks. If jitrino building in debug mode was switched off to not make it crawl, is it an option to not apply these mods, but just leave this thread as a reference for people who need this? I am somehow being able to debug just fine with devenv ( but I don't use jitrino symbols ) without any change to common_vm.xml. Thanks, Rana - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Commented: (HARMONY-815) [classlib][nio] Refine implConfigureBlocking(boolean) method of DatagramChannel and SocketChannel.
On 7/14/06, Tim Ellison [EMAIL PROTECTED] wrote:
Andrew Zhang wrote:
How about design a subclass which extends from SocketException, looks
like:
If you want to preserve the throwable type you could create a
o.a.h.luni.ErrorCodeException that has a errorCode field set by the
native, and then make that the cause of the SocketException.
The calling code would then do something like:
((ErrorCodeException)ex.getCause()).getErrorCode()
Great! It includes error code, meanwhile, keeps all the information of the
original exception.
One more question: How to I18N exception message in this way? Leave it alone
or do it in native code?
Thanks!
Just a thought.
Regards,
Tim
class SocketWithErrorCodeException extends SocketException {
SocketWithErrorCodeException (String message, int errorCode) {
super(message); this.errorCode = errorCode; }
private int errorCode;
public void get/setErrorCode() ;
}
Native code throws SocketWithErrorCodeException instead of
SocketException
so that java code could process different error by invoking
e.getErrorCode
().
Does that make sense?
Thanks!
On 7/13/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote:
I agree with the reason why (I think I understand it - you don't want
to
rely on the result of getMessage() to determine the problem...)
Could you wrap the socket exception to carry a simple integer error
code?
geir
Mikhail Loenko wrote:
-1 for applying the patch
Applying this patch means creating a hidden problem
Thanks,
Mikhail
2006/7/12, Jimmy, Jing Lv [EMAIL PROTECTED]:
Andrew Zhang wrote:
Hello Mikhail,
Please see my comments inline.
Thanks!
On 7/12/06, Mikhail Loenko [EMAIL PROTECTED] wrote:
2006/7/12, Andrew Zhang [EMAIL PROTECTED]:
Hi Mikhail,
It's a NON-NLS message.
Native code is designed in this way. Currently, Harmony socket
native
code
uses messages in SocketException to identify error type.
To avoid the confusion, two alternatives way I could image are:
1. Native code returns platform-independent error code.
2. Native code throws different exceptions, which are all
extended from
SocketException.
Anyway, as current Harmony native design, the message in
SocketException
thrown by native code is a NON-NLS string, that is to say, like
GET,POST
in http protocol. Unless we take a big change on native code
design, I
don't think the code is dangerous.
What's your opnion?
I like option #2.
I also prefer option1 and 2 to current native solution.
I don't think exception messages are the same as GET and
POST, we
agreed
that the messages are to be internationalized. I see that
currently
not
all
the messages are internationalized but I think they will in the
future.
NO. Currently, exception message thrown by native code are used as
if error
code [1]. Please pay attention to netLookupErrorString function.
Harmony-815 patch is based on current Harmony native
implemenation,
therefore, it should work well if design is not changed.
If we decide to adopt option 1, or 2, we have to re-design native
and java
interface,
and there are lots of native and java code to be changed.
How to design native interface is out of scope to this patch,
therefore, I
think a seperate JIRA or thread for socket native interface design
is more
suitable.
Of course, once decision is made, I'll volunteer to revise native
and java
code.
Yep, I also find this strange style of return value, I doubt if the
exception thrown in native may be an enhancement to code efficiency?
However to refactor this may be a heavy work, as much code follows
this
style, affects both luni and nio. I suggest apply this patch, and
leave
this work until Harmony begins i18n.
Does it make sense?
Thanks!
[1] native-src (nethelp.c)
void
throwJavaNetSocketException (JNIEnv * env, I_32 errorNumber)
{
jclass aClass;
/* the error message lookup should be done before the FindClass
call,
because the FindClass call
* may reset the error number that is used in
hysock_error_message
*/
// !!! Here, error code is mapped to NON-NLS mesage.
char *errorMessage = netLookupErrorString (env, errorNumber);
aClass = (*env)-FindClass (env, java/net/SocketException);
if (0 == aClass)
{
return;
}
(*env)-ThrowNew (env, aClass, errorMessage);
}
char *
netLookupErrorString (JNIEnv * env, I_32 anErrorNum)
{
PORT_ACCESS_FROM_ENV (env);
switch (anErrorNum)
{
case HYPORT_ERROR_SOCKET_BADSOCKET:
return Bad socket;
case HYPORT_ERROR_SOCKET_NOTINITIALIZED:
return Socket library uninitialized;
case HYPORT_ERROR_SOCKET_BADAF:
return Bad address family;
case HYPORT_ERROR_SOCKET_BADPROTO:
return Bad
Re: [jira] Commented: (HARMONY-815) [classlib][nio] Refine implConfigureBlocking(boolean) method of DatagramChannel and SocketChannel.
On 7/14/06, Tim Ellison [EMAIL PROTECTED] wrote:
Andrew Zhang wrote:
How about design a subclass which extends from SocketException, looks
like:
If you want to preserve the throwable type you could create a
o.a.h.luni.ErrorCodeException that has a errorCode field set by the
native, and then make that the cause of the SocketException.
The calling code would then do something like:
((ErrorCodeException)ex.getCause()).getErrorCode()
Tim, I have a new question on your thought. :) If we throw
ErrorCodeException in native code, we have to catch the exception in java
code, and then get the cause, re-throw it. It will lose the advantange of
throwing exception in native code. Or am I wrong?
Just a thought.
Regards,
Tim
class SocketWithErrorCodeException extends SocketException {
SocketWithErrorCodeException (String message, int errorCode) {
super(message); this.errorCode = errorCode; }
private int errorCode;
public void get/setErrorCode() ;
}
Native code throws SocketWithErrorCodeException instead of
SocketException
so that java code could process different error by invoking
e.getErrorCode
().
Does that make sense?
Thanks!
On 7/13/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote:
I agree with the reason why (I think I understand it - you don't want
to
rely on the result of getMessage() to determine the problem...)
Could you wrap the socket exception to carry a simple integer error
code?
geir
Mikhail Loenko wrote:
-1 for applying the patch
Applying this patch means creating a hidden problem
Thanks,
Mikhail
2006/7/12, Jimmy, Jing Lv [EMAIL PROTECTED]:
Andrew Zhang wrote:
Hello Mikhail,
Please see my comments inline.
Thanks!
On 7/12/06, Mikhail Loenko [EMAIL PROTECTED] wrote:
2006/7/12, Andrew Zhang [EMAIL PROTECTED]:
Hi Mikhail,
It's a NON-NLS message.
Native code is designed in this way. Currently, Harmony socket
native
code
uses messages in SocketException to identify error type.
To avoid the confusion, two alternatives way I could image are:
1. Native code returns platform-independent error code.
2. Native code throws different exceptions, which are all
extended from
SocketException.
Anyway, as current Harmony native design, the message in
SocketException
thrown by native code is a NON-NLS string, that is to say, like
GET,POST
in http protocol. Unless we take a big change on native code
design, I
don't think the code is dangerous.
What's your opnion?
I like option #2.
I also prefer option1 and 2 to current native solution.
I don't think exception messages are the same as GET and
POST, we
agreed
that the messages are to be internationalized. I see that
currently
not
all
the messages are internationalized but I think they will in the
future.
NO. Currently, exception message thrown by native code are used as
if error
code [1]. Please pay attention to netLookupErrorString function.
Harmony-815 patch is based on current Harmony native
implemenation,
therefore, it should work well if design is not changed.
If we decide to adopt option 1, or 2, we have to re-design native
and java
interface,
and there are lots of native and java code to be changed.
How to design native interface is out of scope to this patch,
therefore, I
think a seperate JIRA or thread for socket native interface design
is more
suitable.
Of course, once decision is made, I'll volunteer to revise native
and java
code.
Yep, I also find this strange style of return value, I doubt if the
exception thrown in native may be an enhancement to code efficiency?
However to refactor this may be a heavy work, as much code follows
this
style, affects both luni and nio. I suggest apply this patch, and
leave
this work until Harmony begins i18n.
Does it make sense?
Thanks!
[1] native-src (nethelp.c)
void
throwJavaNetSocketException (JNIEnv * env, I_32 errorNumber)
{
jclass aClass;
/* the error message lookup should be done before the FindClass
call,
because the FindClass call
* may reset the error number that is used in
hysock_error_message
*/
// !!! Here, error code is mapped to NON-NLS mesage.
char *errorMessage = netLookupErrorString (env, errorNumber);
aClass = (*env)-FindClass (env, java/net/SocketException);
if (0 == aClass)
{
return;
}
(*env)-ThrowNew (env, aClass, errorMessage);
}
char *
netLookupErrorString (JNIEnv * env, I_32 anErrorNum)
{
PORT_ACCESS_FROM_ENV (env);
switch (anErrorNum)
{
case HYPORT_ERROR_SOCKET_BADSOCKET:
return Bad socket;
case HYPORT_ERROR_SOCKET_NOTINITIALIZED:
return Socket library uninitialized;
case HYPORT_ERROR_SOCKET_BADAF:
return Bad address family;
case
Re: [jira] Commented: (HARMONY-815) [classlib][nio] Refine implConfigureBlocking(boolean) method of DatagramChannel and SocketChannel.
Andrew Zhang wrote:
On 7/14/06, Tim Ellison [EMAIL PROTECTED] wrote:
Andrew Zhang wrote:
How about design a subclass which extends from SocketException, looks
like:
If you want to preserve the throwable type you could create a
o.a.h.luni.ErrorCodeException that has a errorCode field set by the
native, and then make that the cause of the SocketException.
The calling code would then do something like:
((ErrorCodeException)ex.getCause()).getErrorCode()
Tim, I have a new question on your thought. :) If we throw
ErrorCodeException in native code, we have to catch the exception in java
code, and then get the cause, re-throw it. It will lose the
advantange of
throwing exception in native code. Or am I wrong?
Hello Andrew,
You need not to throw ErrorCodeException in native code. You can just
create an instance of ErrorCodeException, and set the instance as the
cause of the SocketException which will be thrown in native code. :-P
Best regards,
Richard
Just a thought.
Regards,
Tim
class SocketWithErrorCodeException extends SocketException {
SocketWithErrorCodeException (String message, int errorCode) {
super(message); this.errorCode = errorCode; }
private int errorCode;
public void get/setErrorCode() ;
}
Native code throws SocketWithErrorCodeException instead of
SocketException
so that java code could process different error by invoking
e.getErrorCode
().
Does that make sense?
Thanks!
On 7/13/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote:
I agree with the reason why (I think I understand it - you don't want
to
rely on the result of getMessage() to determine the problem...)
Could you wrap the socket exception to carry a simple integer error
code?
geir
Mikhail Loenko wrote:
-1 for applying the patch
Applying this patch means creating a hidden problem
Thanks,
Mikhail
2006/7/12, Jimmy, Jing Lv [EMAIL PROTECTED]:
Andrew Zhang wrote:
Hello Mikhail,
Please see my comments inline.
Thanks!
On 7/12/06, Mikhail Loenko [EMAIL PROTECTED] wrote:
2006/7/12, Andrew Zhang [EMAIL PROTECTED]:
Hi Mikhail,
It's a NON-NLS message.
Native code is designed in this way. Currently, Harmony
socket
native
code
uses messages in SocketException to identify error type.
To avoid the confusion, two alternatives way I could image
are:
1. Native code returns platform-independent error code.
2. Native code throws different exceptions, which are all
extended from
SocketException.
Anyway, as current Harmony native design, the message in
SocketException
thrown by native code is a NON-NLS string, that is to say,
like
GET,POST
in http protocol. Unless we take a big change on native code
design, I
don't think the code is dangerous.
What's your opnion?
I like option #2.
I also prefer option1 and 2 to current native solution.
I don't think exception messages are the same as GET and
POST, we
agreed
that the messages are to be internationalized. I see that
currently
not
all
the messages are internationalized but I think they will in the
future.
NO. Currently, exception message thrown by native code are
used as
if error
code [1]. Please pay attention to netLookupErrorString function.
Harmony-815 patch is based on current Harmony native
implemenation,
therefore, it should work well if design is not changed.
If we decide to adopt option 1, or 2, we have to re-design
native
and java
interface,
and there are lots of native and java code to be changed.
How to design native interface is out of scope to this patch,
therefore, I
think a seperate JIRA or thread for socket native interface
design
is more
suitable.
Of course, once decision is made, I'll volunteer to revise
native
and java
code.
Yep, I also find this strange style of return value, I doubt if
the
exception thrown in native may be an enhancement to code
efficiency?
However to refactor this may be a heavy work, as much code follows
this
style, affects both luni and nio. I suggest apply this patch, and
leave
this work until Harmony begins i18n.
Does it make sense?
Thanks!
[1] native-src (nethelp.c)
void
throwJavaNetSocketException (JNIEnv * env, I_32 errorNumber)
{
jclass aClass;
/* the error message lookup should be done before the FindClass
call,
because the FindClass call
* may reset the error number that is used in
hysock_error_message
*/
// !!! Here, error code is mapped to NON-NLS mesage.
char *errorMessage = netLookupErrorString (env, errorNumber);
aClass = (*env)-FindClass (env, java/net/SocketException);
if (0 == aClass)
{
return;
}
(*env)-ThrowNew (env, aClass, errorMessage);
}
char *
netLookupErrorString (JNIEnv * env, I_32 anErrorNum)
{
Re: [classlib] compatibility nuances
Magnusson, Geir wrote: -Original Message- From: Alexei Zakharov [mailto:[EMAIL PROTECTED] Sent: Thursday, July 13, 2006 10:19 AM To: harmony-dev@incubator.apache.org; [EMAIL PROTECTED] Subject: Re: [classlib] compatibility nuances That our not in any particular order is different than the not in any particular order that the RI does? I'm not trying to make light of it, but it sounds like all is correct. Right, from the spec point of view everything is correct. But I'd like to say that our particular order differs from RI particular order (and such behavior conforms to spec). My next statement is: there are stupid apps that rely on the particular order returned by RI (regardless of spec). I know one already. The question is: should we care or not? Can you figure out what their order is? If so, I'd use that since we are free to do what we want, and if someone does depende on this, it's one less change, and it's spec compliant. As well as I know, the order is what the methods are declared in java source. (Cannot find any document currently ;-) ) Best regards, Richard Geir 2006/7/13, Geir Magnusson Jr [EMAIL PROTECTED]: I assume you mean [drlvm], since java.lang.Class in [classlib] is just a stub, right? Anyway, what would you say exactly? That our not in any particular order is different than the not in any particular order that the RI does? I'm not trying to make light of it, but it sounds like all is correct. geir Alexei Zakharov wrote: Hi, I have discovered we have small incompatibility in our java.lang.Class implementation. The order of elements returned by Class.getDeclaredMethods() differs from RI. The spec says here: The elements in the array returned are not sorted and are not in any particular order. But I already know one application that relies on this - this was one of java.beans test (already patched). I don't want to say this is somehow bad but still like to inform the community about this issue. Probably we need to rise non-bug differences JIRA? Thanks, -- Alexei Zakharov, Intel Middleware Product Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Richard Liang China Software Development Lab, IBM
Re: [DRLVM] build fixes that allow normal single step debug of the Jitrino.JET write barrier patch
On 7/13/06, Rana Dasgupta [EMAIL PROTECTED] wrote: Weldon, Thanks. If jitrino building in debug mode was switched off to not make it crawl, is it an option to not apply these mods, but just leave this thread as a reference for people who need this? Yes, of course. These mods are most relevant to debugging the write barrier, vmmagic, inlined object allocation kinds of functions. Once they are up and going, we probably won't use these build options. I am somehow being able to debug just fine with devenv ( but I don't use jitrino symbols ) without any change to common_vm.xml. This is good. Given a stable JIT, debugging VM code is basically orthogonal to the compiler. It is only stuff like stepping through write barrier generation and vmmagic where jitrino symbols come in handy. The rest of the time it makes sense to build the JIT in full optimize mode and the rest of DRLVM in debug mode when debugging VM code. Thanks, Rana - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Weldon Washburn Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Commented: (HARMONY-815) [classlib][nio] Refine implConfigureBlocking(boolean) method of DatagramChannel and SocketChannel.
On 7/14/06, Richard Liang [EMAIL PROTECTED] wrote:
Andrew Zhang wrote:
On 7/14/06, Tim Ellison [EMAIL PROTECTED] wrote:
Andrew Zhang wrote:
How about design a subclass which extends from SocketException, looks
like:
If you want to preserve the throwable type you could create a
o.a.h.luni.ErrorCodeException that has a errorCode field set by the
native, and then make that the cause of the SocketException.
The calling code would then do something like:
((ErrorCodeException)ex.getCause()).getErrorCode()
Tim, I have a new question on your thought. :) If we throw
ErrorCodeException in native code, we have to catch the exception in
java
code, and then get the cause, re-throw it. It will lose the
advantange of
throwing exception in native code. Or am I wrong?
Hello Andrew,
You need not to throw ErrorCodeException in native code. You can just
create an instance of ErrorCodeException, and set the instance as the
cause of the SocketException which will be thrown in native code. :-P
Oh... Got it! Thank you Richard!
I agree it works. :) But we still have to decide where to i18n the message,
native code or java code. Right?
Thanks!
Best regards,
Richard
Just a thought.
Regards,
Tim
class SocketWithErrorCodeException extends SocketException {
SocketWithErrorCodeException (String message, int errorCode) {
super(message); this.errorCode = errorCode; }
private int errorCode;
public void get/setErrorCode() ;
}
Native code throws SocketWithErrorCodeException instead of
SocketException
so that java code could process different error by invoking
e.getErrorCode
().
Does that make sense?
Thanks!
On 7/13/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote:
I agree with the reason why (I think I understand it - you don't
want
to
rely on the result of getMessage() to determine the problem...)
Could you wrap the socket exception to carry a simple integer error
code?
geir
Mikhail Loenko wrote:
-1 for applying the patch
Applying this patch means creating a hidden problem
Thanks,
Mikhail
2006/7/12, Jimmy, Jing Lv [EMAIL PROTECTED]:
Andrew Zhang wrote:
Hello Mikhail,
Please see my comments inline.
Thanks!
On 7/12/06, Mikhail Loenko [EMAIL PROTECTED] wrote:
2006/7/12, Andrew Zhang [EMAIL PROTECTED]:
Hi Mikhail,
It's a NON-NLS message.
Native code is designed in this way. Currently, Harmony
socket
native
code
uses messages in SocketException to identify error type.
To avoid the confusion, two alternatives way I could image
are:
1. Native code returns platform-independent error code.
2. Native code throws different exceptions, which are all
extended from
SocketException.
Anyway, as current Harmony native design, the message in
SocketException
thrown by native code is a NON-NLS string, that is to say,
like
GET,POST
in http protocol. Unless we take a big change on native
code
design, I
don't think the code is dangerous.
What's your opnion?
I like option #2.
I also prefer option1 and 2 to current native solution.
I don't think exception messages are the same as GET and
POST, we
agreed
that the messages are to be internationalized. I see that
currently
not
all
the messages are internationalized but I think they will in
the
future.
NO. Currently, exception message thrown by native code are
used as
if error
code [1]. Please pay attention to netLookupErrorString
function.
Harmony-815 patch is based on current Harmony native
implemenation,
therefore, it should work well if design is not changed.
If we decide to adopt option 1, or 2, we have to re-design
native
and java
interface,
and there are lots of native and java code to be changed.
How to design native interface is out of scope to this patch,
therefore, I
think a seperate JIRA or thread for socket native interface
design
is more
suitable.
Of course, once decision is made, I'll volunteer to revise
native
and java
code.
Yep, I also find this strange style of return value, I doubt if
the
exception thrown in native may be an enhancement to code
efficiency?
However to refactor this may be a heavy work, as much code
follows
this
style, affects both luni and nio. I suggest apply this patch, and
leave
this work until Harmony begins i18n.
Does it make sense?
Thanks!
[1] native-src (nethelp.c)
void
throwJavaNetSocketException (JNIEnv * env, I_32 errorNumber)
{
jclass aClass;
/* the error message lookup should be done before the
FindClass
call,
because the FindClass call
* may reset the error number that is used in
hysock_error_message
*/
// !!! Here, error code
RE: [classlib][concurrent] java.util.concurrent module proposal
Resulting actions: * Move code to the 'standard' folder? (I'll do this in the next few days if there aren't any complaints) * Continue with proposal code, create a prototype and try to work with the concurrency group. Any other major items? -Nathan -Original Message- From: Geir Magnusson Jr [mailto:[EMAIL PROTECTED] Sent: Thursday, July 13, 2006 12:03 PM To: harmony-dev@incubator.apache.org Subject: Re: [classlib][concurrent] java.util.concurrent module proposal Tim Ellison wrote: Geir Magnusson Jr wrote: Tim Ellison wrote: Geir Magnusson Jr wrote: Tim Ellison wrote: Nathan Beyer wrote: I've checked in my proposal for the java.util.concurrent module at https://svn.apache.org/repos/asf/incubator/harmony/enhanced/classlib/trunk /s andbox/juc-proposal. You didn't just check in a proposal, you also checked in Doug Lea et al's code. Nobody should commit other people's code into svn this way. The code is under public domain license, so there should be no problem doing it since Doug et al produce no builds, and they suggested we do this. (not trying to be provocative, just trying to understand) they = the concurrency authors? do this = produce builds or check the code into our repository? Did I get this right? Sorry - I missed this - they really was Doug, and do this is take the code. Checking it in simply is good practice for peace of mind. it's also in our sandbox, and we're not redistributing it yet. Was there a reason to create .../classlib/trunk/sandbox? wouldn't .../classlib/sandbox make more sense? We already had the sandbox under /trunk No we didn't. http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/san dbox/?view=logpathrev=42 Perhaps it was created in the trunk by mistake. Oh, right. Sorry - there was a sandbox in enhanced/trunk which is what I thought it was checked into... So does anyone object to the proposed code being moved out of the enhanced subtree while we stare at it, thereby preserving our definition of 'enhanced'. I sort of do because we are utterly inconsistent about this, but if you look at my other message, if we just shove this into /standard/ the whole problem seems to magically go away anyway, so go ahead. I see copying the code as a one-way operation. We can hope to track updates to the original code thoroughly, but I don't see any fixes made in Harmony making it back directly into Doug's repository. Why not? We just offer them to Doug, and he can accept or reject. It strikes me as a strange model. If there is a well-run, active project with compatible license elsewhere I'm struggling to see why we would not just join in there, and all enjoy the fruits of the combined work g. Maybe this was discussed as part of the suggestion from Doug? Doug just suggested that we'd be well served using his code since it's public domain and the definitive implementation. If there is a well-run, active project with compatible license elsewhere, please point it out. As far as I know, this is the only implementation out there, and is why it's taken and used by IBM, BEA, Apple and Sun in the same way we're proposing. (IBM does not source the code directly from there, but that is a different matter) Why not just enjoy the fruits of what's being offered as public domain by arguably the world's top expert on the subject? While we have lots of talent around here, I'd be very surprised if we could do better. No arguments from me, that was the point that I was making too. Let's work with that project where we need to do so, and take their code as a dependency for Harmony. That's what we're doing. Is there a reason why we want to fork this code? I'd rather we worked with Doug (contributing directly to his project to make it more widely usable etc). Tim, isn't this what we discussed? This isn't a fork in the community sense, it's what amounts to a read only copy of the code for purposes of building, but tracking what Doug does? We've been very clear about that. Do you think it is reasonable to work with that group to make the code usable by Harmony as well as Sun? Yes, of course, although it seems usable now... Not without the modifications that nathan has been working on. We want to avoid modifying their code. I guess the alternative is that we replicate Sun's internal APIs if we want to make the incoming code read-only (and presumably put it into the depends/ directory). I don't understand the bit about the depends directory, but yes, I think that using this code as-is would require us to implement sun.misc.Unsafe, and I do think it's a reasonable thing to suggest to Doug that a neutral package is chosen for this like org.apache.harmony.Unsafe :) Now we are talking ;-) In fact, if Sun want to publish the API I'm even prepared to
Re: [DRLVM] build fixes that allow normal single step debug of the Jitrino.JET write barrier patch
On the 0x1A6 day of Apache Harmony Weldon Washburn wrote:
All,
The following build mods will create a drlvm binary that can be used
to debug the Jitrino.JET write barriers. Rather than make everyone
suffer through long email chains, Alex and I collaborated offline.
Great! Good feature for JIT hackers!
Though, I would prefer to leave an option directly in SVN sources.
-Dvm.jitrino.cfg=debug -- for debug build
-Dvm.jitrino.cfg=release -- for most people (the default)
is that possible?
BTW, build.sh needs update too (I prefer to build on Linux:)
The mods to drlvm/trunk/build/build.bat:
--- build.bat (revision 421403)
+++ build.bat (working copy)
@@ -138,7 +138,7 @@
)
REM Note: vm.jitrino is always complied in release mode, otherwise it makes
VM
debug too slow
-CALL %ANT_COMMAND% -f make/build.xml -Dvm.jitrino.cfg=release %*
+CALL %ANT_COMMAND% -f make/build.xml %*
GOTO THEEND
Mods to drlvm/trunk/build/make/components/vm/jitrino.xml
project name=vm.jitrino
-target name=init
+target name=init depends=common_vm
property name=build.depends
value=extra.apr,vm.vmcore,vm.encoder /
property name=outtype value=shared /
property name=libname value=jitrino /
@@ -48,7 +48,8 @@
patternset id=java.classes.pattern includes=empty_pattern/
!-- the compiler doesn't extend common compiler --
-compiler name=${build.cxx} id=cpp.compiler
+!-- compiler name=${build.cxx} id=cpp.compiler --
+compiler id=cpp.compiler extends=common.cpp.compiler
For some unknown reason, svn diff wants to report that every line has
changed in common_vm.xml. Probably something to do with carriage
return line feed. In any case the mods to
drlvm/trunk/build/make/targets/common_vm.xml. These are the same mods
that were reported in the email titled, [DRLVM] questions about
build.bat -DEBUILD_CFG=debug -DCXX=msvc. They are repeated here for
completeness:
- select os=win cxx=msvc
compilerarg value=/Od /
compilerarg value=/MTd /
compilerarg value=/D_DEBUG /
/select
A new svn update of both classlib and drlvm was downloaded this
morning. The above mods were applied. And, finally, a build.bat
-DEBUILD_CFG=debug -DCXX=msvc was run. The binary is now debuggable
with MS Visual Studio.
Question: Should the above be bundled up as a JIRA patch?
--
Weldon Washburn
Intel Middleware Products Division
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Egor Pasko, Intel Managed Runtime Division
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Solution on Harmony-815 (was Re: [jira] Commented: (HARMONY-815) [classlib][nio] Refine implConfigureBlocking(boolean) method of DatagramChannel and SocketChannel.)
Hi folks,
I'd like to adopt Tim's suggestion to solve Harmony-815. It avoids message
comparison while keeps current luni native architecture.
Before I upload a new patch to JIRA, I want to hear more voices from
the community. Any better suggestions? Any comments?
Mikhail, what's your opnion? Do you think it makes sense?
Thanks in advance!
Best regards,
Andrew
On 7/14/06, Tim Ellison [EMAIL PROTECTED] wrote:
Andrew Zhang wrote:
How about design a subclass which extends from SocketException, looks
like:
If you want to preserve the throwable type you could create a
o.a.h.luni.ErrorCodeException that has a errorCode field set by the
native, and then make that the cause of the SocketException.
The calling code would then do something like:
((ErrorCodeException)ex.getCause()).getErrorCode()
Just a thought.
Regards,
Tim
class SocketWithErrorCodeException extends SocketException {
SocketWithErrorCodeException (String message, int errorCode) {
super(message); this.errorCode = errorCode; }
private int errorCode;
public void get/setErrorCode() ;
}
Native code throws SocketWithErrorCodeException instead of
SocketException
so that java code could process different error by invoking
e.getErrorCode
().
Does that make sense?
Thanks!
On 7/13/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote:
I agree with the reason why (I think I understand it - you don't want
to
rely on the result of getMessage() to determine the problem...)
Could you wrap the socket exception to carry a simple integer error
code?
geir
Mikhail Loenko wrote:
-1 for applying the patch
Applying this patch means creating a hidden problem
Thanks,
Mikhail
2006/7/12, Jimmy, Jing Lv [EMAIL PROTECTED]:
Andrew Zhang wrote:
Hello Mikhail,
Please see my comments inline.
Thanks!
On 7/12/06, Mikhail Loenko [EMAIL PROTECTED] wrote:
2006/7/12, Andrew Zhang [EMAIL PROTECTED]:
Hi Mikhail,
It's a NON-NLS message.
Native code is designed in this way. Currently, Harmony socket
native
code
uses messages in SocketException to identify error type.
To avoid the confusion, two alternatives way I could image are:
1. Native code returns platform-independent error code.
2. Native code throws different exceptions, which are all
extended from
SocketException.
Anyway, as current Harmony native design, the message in
SocketException
thrown by native code is a NON-NLS string, that is to say, like
GET,POST
in http protocol. Unless we take a big change on native code
design, I
don't think the code is dangerous.
What's your opnion?
I like option #2.
I also prefer option1 and 2 to current native solution.
I don't think exception messages are the same as GET and
POST, we
agreed
that the messages are to be internationalized. I see that
currently
not
all
the messages are internationalized but I think they will in the
future.
NO. Currently, exception message thrown by native code are used as
if error
code [1]. Please pay attention to netLookupErrorString function.
Harmony-815 patch is based on current Harmony native
implemenation,
therefore, it should work well if design is not changed.
If we decide to adopt option 1, or 2, we have to re-design native
and java
interface,
and there are lots of native and java code to be changed.
How to design native interface is out of scope to this patch,
therefore, I
think a seperate JIRA or thread for socket native interface design
is more
suitable.
Of course, once decision is made, I'll volunteer to revise native
and java
code.
Yep, I also find this strange style of return value, I doubt if the
exception thrown in native may be an enhancement to code efficiency?
However to refactor this may be a heavy work, as much code follows
this
style, affects both luni and nio. I suggest apply this patch, and
leave
this work until Harmony begins i18n.
Does it make sense?
Thanks!
[1] native-src (nethelp.c)
void
throwJavaNetSocketException (JNIEnv * env, I_32 errorNumber)
{
jclass aClass;
/* the error message lookup should be done before the FindClass
call,
because the FindClass call
* may reset the error number that is used in
hysock_error_message
*/
// !!! Here, error code is mapped to NON-NLS mesage.
char *errorMessage = netLookupErrorString (env, errorNumber);
aClass = (*env)-FindClass (env, java/net/SocketException);
if (0 == aClass)
{
return;
}
(*env)-ThrowNew (env, aClass, errorMessage);
}
char *
netLookupErrorString (JNIEnv * env, I_32 anErrorNum)
{
PORT_ACCESS_FROM_ENV (env);
switch (anErrorNum)
{
case HYPORT_ERROR_SOCKET_BADSOCKET:
return Bad socket;
case HYPORT_ERROR_SOCKET_NOTINITIALIZED:
return Socket
Re: [classlib][testing] excluding the failed tests
Vladimir Ivanov wrote: On 7/7/06, Tim Ellison [EMAIL PROTECTED] wrote: ... Currently I'm looking on the excluded TestCases and it requires more time than I expected. I'll prepare a report/summary about excluded TestCases at the end of this process. Hello Vladimir, How about the progress of your report/summary? ;-) As I'm implementing java.util.Formatter and java.util.Scanner, I'm also interested in the excluded tests in LUNI. Shall we create a wiki page to publish our status, so that other people in community can know what we're doing, and maybe we could attract more volunteers. ;-) Best regards, Richard. Thanks, Vladimir On 7/7/06, Tim Ellison [EMAIL PROTECTED] wrote: Vladimir Ivanov wrote: More details: it is org/apache/harmony/security/tests/java/security/SecureRandom2Test.java test. At present time it has 2 failing tests with messages about SHA1PRNG algorithm (no support for SHA1PRNG provider). Looks like it is valid tests for non implemented functionality, but, I'm not sure what to do with such TestCase(s): comment these 2 tests or move them into separate TestCase. Ideas? I'd prefer that we only use one mechanism for excluding tests, and today that is the excludes clause in the ant script. So I suggest that you do option (4) below. If there are really useful tests that are being unnecessarily excluded by being in the same *Test class, then you may want to consider moving the failing tests into SecureRandom3Test and excluding that -- but by the sound of it all SecureRandom tests will be failing. By the way, probably, it worth reviewing *all* excluded TestCases and: 1. Unexclude if all tests pass. 2. Report bug and provide patch for test to make it passing if it failed due to bug in test. 3. Report bug (and provide patch) for implementation to make tests passing, if it was/is bug in implementation and no such issue in JIRA. 4. Specify reasons for excluding TestCases in exclude list to make further clean-up process easier. 5. Review results of this exclude list clean-up activity and then decide what to do with the rest failing tests. I can do it starting next week. Do you think it worth doing? Thanks, Vladimir Sounds great, thanks Vladimir. Regards, Tim -- Tim Ellison ( [EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Richard Liang China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DRLVM] build fixes that allow normal single step debug of the Jitrino.JET write barrier patch
On 14 Jul 2006 09:47:14 +0700, Egor Pasko [EMAIL PROTECTED] wrote: On the 0x1A6 day of Apache Harmony Weldon Washburn wrote: All, The following build mods will create a drlvm binary that can be used to debug the Jitrino.JET write barriers. Rather than make everyone suffer through long email chains, Alex and I collaborated offline. Great! Good feature for JIT hackers! Though, I would prefer to leave an option directly in SVN sources. -Dvm.jitrino.cfg=debug -- for debug build -Dvm.jitrino.cfg=release -- for most people (the default) is that possible? Actually I did not think of trying -Dvm.jitrino.cfg=debug. Maybe it will work. BTW, build.sh needs update too (I prefer to build on Linux:) I am hoping someone will volunteer to try the linux build and figure out what needs to be changed. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][testing] excluding the failed tests
New page http://wiki.apache.org/harmony/Excluded_tests was added to WIKI (refered from http://wiki.apache.org/harmony/ClassLibrary). It would be good if before test investigation one would specify 'in progress, Name' near module name, showing it is under investigation being done by Name. Thanks, Vladimir On 7/14/06, Richard Liang [EMAIL PROTECTED] wrote: Vladimir Ivanov wrote: On 7/7/06, Tim Ellison [EMAIL PROTECTED] wrote: ... Currently I'm looking on the excluded TestCases and it requires more time than I expected. I'll prepare a report/summary about excluded TestCases at the end of this process. Hello Vladimir, How about the progress of your report/summary? ;-) As I'm implementing java.util.Formatter and java.util.Scanner, I'm also interested in the excluded tests in LUNI. Shall we create a wiki page to publish our status, so that other people in community can know what we're doing, and maybe we could attract more volunteers. ;-) Best regards, Richard. Thanks, Vladimir On 7/7/06, Tim Ellison [EMAIL PROTECTED] wrote: Vladimir Ivanov wrote: More details: it is org/apache/harmony/security/tests/java/security/SecureRandom2Test.java test. At present time it has 2 failing tests with messages about SHA1PRNG algorithm (no support for SHA1PRNG provider). Looks like it is valid tests for non implemented functionality, but, I'm not sure what to do with such TestCase(s): comment these 2 tests or move them into separate TestCase. Ideas? I'd prefer that we only use one mechanism for excluding tests, and today that is the excludes clause in the ant script. So I suggest that you do option (4) below. If there are really useful tests that are being unnecessarily excluded by being in the same *Test class, then you may want to consider moving the failing tests into SecureRandom3Test and excluding that -- but by the sound of it all SecureRandom tests will be failing. By the way, probably, it worth reviewing *all* excluded TestCases and: 1. Unexclude if all tests pass. 2. Report bug and provide patch for test to make it passing if it failed due to bug in test. 3. Report bug (and provide patch) for implementation to make tests passing, if it was/is bug in implementation and no such issue in JIRA. 4. Specify reasons for excluding TestCases in exclude list to make further clean-up process easier. 5. Review results of this exclude list clean-up activity and then decide what to do with the rest failing tests. I can do it starting next week. Do you think it worth doing? Thanks, Vladimir Sounds great, thanks Vladimir. Regards, Tim -- Tim Ellison ( [EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Richard Liang China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Solution on Harmony-815 (was Re: [jira] Commented: (HARMONY-815) [classlib][nio] Refine implConfigureBlocking(boolean) method of DatagramChannel and SocketChannel.)
Hi Andrew
this seems reasonable
Thanks,
Mikhail
2006/7/14, Andrew Zhang [EMAIL PROTECTED]:
Hi folks,
I'd like to adopt Tim's suggestion to solve Harmony-815. It avoids message
comparison while keeps current luni native architecture.
Before I upload a new patch to JIRA, I want to hear more voices from
the community. Any better suggestions? Any comments?
Mikhail, what's your opnion? Do you think it makes sense?
Thanks in advance!
Best regards,
Andrew
On 7/14/06, Tim Ellison [EMAIL PROTECTED] wrote:
Andrew Zhang wrote:
How about design a subclass which extends from SocketException, looks
like:
If you want to preserve the throwable type you could create a
o.a.h.luni.ErrorCodeException that has a errorCode field set by the
native, and then make that the cause of the SocketException.
The calling code would then do something like:
((ErrorCodeException)ex.getCause()).getErrorCode()
Just a thought.
Regards,
Tim
class SocketWithErrorCodeException extends SocketException {
SocketWithErrorCodeException (String message, int errorCode) {
super(message); this.errorCode = errorCode; }
private int errorCode;
public void get/setErrorCode() ;
}
Native code throws SocketWithErrorCodeException instead of
SocketException
so that java code could process different error by invoking
e.getErrorCode
().
Does that make sense?
Thanks!
On 7/13/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote:
I agree with the reason why (I think I understand it - you don't want
to
rely on the result of getMessage() to determine the problem...)
Could you wrap the socket exception to carry a simple integer error
code?
geir
Mikhail Loenko wrote:
-1 for applying the patch
Applying this patch means creating a hidden problem
Thanks,
Mikhail
2006/7/12, Jimmy, Jing Lv [EMAIL PROTECTED]:
Andrew Zhang wrote:
Hello Mikhail,
Please see my comments inline.
Thanks!
On 7/12/06, Mikhail Loenko [EMAIL PROTECTED] wrote:
2006/7/12, Andrew Zhang [EMAIL PROTECTED]:
Hi Mikhail,
It's a NON-NLS message.
Native code is designed in this way. Currently, Harmony socket
native
code
uses messages in SocketException to identify error type.
To avoid the confusion, two alternatives way I could image are:
1. Native code returns platform-independent error code.
2. Native code throws different exceptions, which are all
extended from
SocketException.
Anyway, as current Harmony native design, the message in
SocketException
thrown by native code is a NON-NLS string, that is to say, like
GET,POST
in http protocol. Unless we take a big change on native code
design, I
don't think the code is dangerous.
What's your opnion?
I like option #2.
I also prefer option1 and 2 to current native solution.
I don't think exception messages are the same as GET and
POST, we
agreed
that the messages are to be internationalized. I see that
currently
not
all
the messages are internationalized but I think they will in the
future.
NO. Currently, exception message thrown by native code are used as
if error
code [1]. Please pay attention to netLookupErrorString function.
Harmony-815 patch is based on current Harmony native
implemenation,
therefore, it should work well if design is not changed.
If we decide to adopt option 1, or 2, we have to re-design native
and java
interface,
and there are lots of native and java code to be changed.
How to design native interface is out of scope to this patch,
therefore, I
think a seperate JIRA or thread for socket native interface design
is more
suitable.
Of course, once decision is made, I'll volunteer to revise native
and java
code.
Yep, I also find this strange style of return value, I doubt if the
exception thrown in native may be an enhancement to code efficiency?
However to refactor this may be a heavy work, as much code follows
this
style, affects both luni and nio. I suggest apply this patch, and
leave
this work until Harmony begins i18n.
Does it make sense?
Thanks!
[1] native-src (nethelp.c)
void
throwJavaNetSocketException (JNIEnv * env, I_32 errorNumber)
{
jclass aClass;
/* the error message lookup should be done before the FindClass
call,
because the FindClass call
* may reset the error number that is used in
hysock_error_message
*/
// !!! Here, error code is mapped to NON-NLS mesage.
char *errorMessage = netLookupErrorString (env, errorNumber);
aClass = (*env)-FindClass (env, java/net/SocketException);
if (0 == aClass)
{
return;
}
(*env)-ThrowNew (env, aClass, errorMessage);
}
char *
Re: [classlib] compatibility nuances
On 7/14/06, Alexey Varlamov [EMAIL PROTECTED] wrote: 2006/7/14, Richard Liang [EMAIL PROTECTED]: Magnusson, Geir wrote: -Original Message- From: Alexei Zakharov [mailto:[EMAIL PROTECTED] Sent: Thursday, July 13, 2006 10:19 AM To: harmony-dev@incubator.apache.org; [EMAIL PROTECTED] Subject: Re: [classlib] compatibility nuances That our not in any particular order is different than the not in any particular order that the RI does? I'm not trying to make light of it, but it sounds like all is correct. Right, from the spec point of view everything is correct. But I'd like to say that our particular order differs from RI particular order (and such behavior conforms to spec). My next statement is: there are stupid apps that rely on the particular order returned by RI (regardless of spec). I know one already. The question is: should we care or not? Can you figure out what their order is? If so, I'd use that since we are free to do what we want, and if someone does depende on this, it's one less change, and it's spec compliant. As well as I know, the order is what the methods are declared in java source. (Cannot find any document currently ;-) ) IIRC, Sun and JRockit behave differently to this matter, JRockit's VM reports methods in reversed order. Besides, there are 2 APIs: getDeclaredMethods() and getMethods() - we should consider both if we really care. And detecting right order for the last is tedious - taking into account variety of heritable methods (declared directly, inherited from superclass(es), inherited from superinterface(s), inherited from superinterfaces of superclasses). I agree with this assertion. The implementation of kernel classes for DRLVM was clean room one. (I believe Alexey used it to test. *Or J9 nevertheless*? IMHO it needs to specify when same discussions start). We've knew nothing about the algorithms used by RI. All we knew is our implementation should correspond to the specifications and not break them. The case discussed here is such one in my opinion. Could you please give prove why the compatibility needs here? What RI should be used for this purpose if any? Thanks, Vladimir. I believe we need a bit stronger motivation for scratching this issue, than a blunt testcase - some real-world application. -- Regards, Alexey Varlamov Best regards, Richard Geir 2006/7/13, Geir Magnusson Jr [EMAIL PROTECTED]: I assume you mean [drlvm], since java.lang.Class in [classlib] is just a stub, right? Anyway, what would you say exactly? That our not in any particular order is different than the not in any particular order that the RI does? I'm not trying to make light of it, but it sounds like all is correct. geir Alexei Zakharov wrote: Hi, I have discovered we have small incompatibility in our java.lang.Class implementation. The order of elements returned by Class.getDeclaredMethods() differs from RI. The spec says here: The elements in the array returned are not sorted and are not in any particular order. But I already know one application that relies on this - this was one of java.beans test (already patched). I don't want to say this is somehow bad but still like to inform the community about this issue. Probably we need to rise non-bug differences JIRA? Thanks, -- Alexei Zakharov, Intel Middleware Product Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Richard Liang China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [os] freebsd
On 7/13/06, Anton Luht [EMAIL PROTECTED] wrote:
Hello,
Some time ago I installed FreeBSD 6.1-RELEASE on my home computer and
tried to build original Harmony VM donation [1] + corresponding
classlib on it. In the end of the efforts I've managed to build it and
print something with '-?' argument, but unfortunately an attempt to
run 'Hello, world' app failed.
The algorithm was straighforward - when a compile error happened, I've
tried to fix it in a straightforward way just to make build pass this
stage, and I'm not surprised that the resulted VM doesn't work :)
Maybe the list of those changes will give an idea what things should
be modified to run Harmony on another platform.
Details:
- I've installed FreeBSD with complete sources (compat included).
- JRE was Diablo-JRE from [2].
- added packages (pkg_add -r) libiconv and libxml2
- linker complained about -ldl missing in many places - I've tried to
removed all -ldl entries but finally gave up and symlinked libdl.so
to libc.so
- replaced everywhere #include malloc.h with #include stdlib.h
- paths to some include files changed and some other includes changed, too
- replaced PTHREAD_MUTEX_RECURSIVE_NP with PTHREAD_MUTEX_RECURSIVE
(_NP stands for non-portable, so I believe it's not a big crime)
- mcontext_t has a slighly different structure, for example
uc_mcontext.gregs[REG_EAX] - uc_mcontext.mc_eax
- sigcontext has a slighly different structure, for example
sigcontext.edi - sigcontext.sc_edi
- flag for shmem SHM_HUGETLB is missing on FreeBSD - I've just removed it
- hysysinfo.c: changed hysysinfo_get_physical_memory to code taken from
[3]
- hysock.c - undefined HAS_RTNETLINK, changed SOL_IPV6 to IPPROTO_IPV6
- hysock.h - undefined GLIBC_R and defined NO_R (maybe better solution
would be ORIGINAL_R and linking with lc_r)
changed
#define OS_IPV6_ADD_MEMBERSHIP IPV6_ADD_MEMBERSHIP
#define OS_IPV6_DROP_MEMBERSHIP IPV6_DROP_MEMBERSHIP
to
#define OS_IPV6_ADD_MEMBERSHIP IPV6_JOIN_GROUP
#define OS_IPV6_DROP_MEMBERSHIP IPV6_LEAVE_GROUP
- thrdsup.c - commented out _FPU_GETCW and _FPU_SETCW
- hysiglinux.c - changed sigvec signature
sigvec (int sig, const struct sigvec *invec, struct sigvec *outvec)
to
sigvec (int sig, struct sigvec *invec, struct sigvec *outvec)
- pdsimpl.c - removed option SO_BINDTODEVICE (changed to 0). As far as
I understand, code with that flag returns available network interfaces
- I believe there's a possibility to rewrite in in a FreeBSD way.
Threads are a big problem. On Linux pthread_t is an unsigned int, on
FreeBSD - pthread* .
So things like code from gc_v4.cpp :
for (unsigned int i = 0; i get_num_worker_threads() ; i++) {
// Point the GC thread to the GC object
_gc_threads[i] = new GC_Thread(this, i);
assert(_gc_threads[i]);
}
won't work. I've just added cast to pthread_t but obviously this is
not a proper solution.
After these modifications all modules compiled but linker complained
that some log4cxx functions with wchar_t couldn't be found. Adding
-DLOG4CXX_HAS_WCHAR_T=1 and -D__STDC_ISO_10646__=1 flags to log4xcc
compilation helped . After that ij compiled but attempt to run it
crashed on mutexes. Those calls to mutexes were in sections surrounded
with #if APR_HAS_THREADS and it's no wonder I've recompiled log4cxx
with -DAPR_HAS_THREADS=0 . After that ij finally printed the list of
its options given the -? argument.
I've tried to play with the code further trying to make it run 'Hello,
world' app but failed.
Hope it makes some sence.
Yep, it doesJ. Thanks for your efforts and letting us know about all
problems you faced with.
Sometimes even small fixes for the build system can be a cause of the big
issues to find not easily.
You've made a lot of things are not obvious at first glance and demand an
additional investigation.
In any case your information is very valuable.
Thanks,
Vladimir.
[1] http://issues.apache.org/jira/browse/HARMONY-438
[2] http://www.freebsdfoundation.org/downloads/java.shtml
[3]
http://lists.freebsd.org/pipermail/freebsd-hackers/2005-December/014733.html
--
Regards,
Anton Luht,
Intel Middleware Products Division
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
