Re: [announce] New Apache Harmony Committer : Paulex Yang
Congratulations Paulex! -Mark. On 16 July 2006 at 19:35, Geir Magnusson Jr [EMAIL PROTECTED] wrote: Please join the Apache Harmony PPMC in welcoming the project's newest committer, Paulex Yang. Mark has demonstrated the elements that help build a healthy community, namely his ability to work together with others, continued dedication to the project, an understanding of our overall goals of the project, and a really unnatural and probably unhealthy focus on nio :) We all continue to expect great things from him. Mark, as a first step to test your almighty powers of committership, please update the committers page on the website. That should be a good (and harmless) exercise to test if everything is working. Things to do : 1) test ssh-ing to the server people.apache.org. 2) Change your login password on the machine as per the account email 3) Add a public key to .ssh so you can stop using the password 4) Change your svn password as described in the account email At this point, you should be good to go. Checkout the website from svn and update it. See if you can figure out how. Also, for your main harmony/enhanced/classlib/trunk please be sure that you have checked out via 'https' and not 'http' or you can't check in. You can switch using svn switch. (See the manual) Finally, although you now have the ability to commit, please remember : 1) continue being as transparent and communicative as possible. You earned committer status in part because of your engagement with others. While it was a have to situation because you had to submit patches and defend them, but we believe it is a want to. Community is the key to any Apache project. 2)We don't want anyone going off and doing lots of work locally, and then committing. Committing is like voting in Chicago - do it early and often. Of course, you don't want to break the build, but keep the commit bombs to an absolute minimum, and warn the community if you are going to do it - we may suggest it goes into a branch at first. Use branches if you need to. 3) Always remember that you can **never** commit code that comes from someone else, even a co-worker. All code from someone else must be submitted by the copyright holder (either the author or author's employer, depending) as a JIRA, and then follow up with the required ACQs and BCC. Again, thanks for your hard work so far, and welcome. The Apache Harmony PPMC - 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: [announce] New Apache Harmony Committer : Paulex Yang
Congratulations Paulex! On 17.07.2006, at 01:35, Geir Magnusson Jr wrote: Please join the Apache Harmony PPMC in welcoming the project's newest committer, Paulex Yang. Mark has demonstrated the elements that help build a healthy community, namely his ability to work together with others, continued dedication to the project, an understanding of our overall goals of the project, and a really unnatural and probably unhealthy focus on nio :) We all continue to expect great things from him. Mark, as a first step to test your almighty powers of committership, please update the committers page on the website. That should be a good (and harmless) exercise to test if everything is working. Things to do : 1) test ssh-ing to the server people.apache.org. 2) Change your login password on the machine as per the account email 3) Add a public key to .ssh so you can stop using the password 4) Change your svn password as described in the account email At this point, you should be good to go. Checkout the website from svn and update it. See if you can figure out how. Also, for your main harmony/enhanced/classlib/trunk please be sure that you have checked out via 'https' and not 'http' or you can't check in. You can switch using svn switch. (See the manual) Finally, although you now have the ability to commit, please remember : 1) continue being as transparent and communicative as possible. You earned committer status in part because of your engagement with others. While it was a have to situation because you had to submit patches and defend them, but we believe it is a want to. Community is the key to any Apache project. 2)We don't want anyone going off and doing lots of work locally, and then committing. Committing is like voting in Chicago - do it early and often. Of course, you don't want to break the build, but keep the commit bombs to an absolute minimum, and warn the community if you are going to do it - we may suggest it goes into a branch at first. Use branches if you need to. 3) Always remember that you can **never** commit code that comes from someone else, even a co-worker. All code from someone else must be submitted by the copyright holder (either the author or author's employer, depending) as a JIRA, and then follow up with the required ACQs and BCC. Again, thanks for your hard work so far, and welcome. The Apache Harmony PPMC - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] smime.p7s Description: S/MIME cryptographic signature
Re: [announce] New Apache Harmony Committer : Paulex Yang
Congratulations Paulex! :) Geir Magnusson Jr wrote: Please join the Apache Harmony PPMC in welcoming the project's newest committer, Paulex Yang. Mark has demonstrated the elements that help build a healthy community, namely his ability to work together with others, continued dedication to the project, an understanding of our overall goals of the project, and a really unnatural and probably unhealthy focus on nio :) We all continue to expect great things from him. Mark, as a first step to test your almighty powers of committership, please update the committers page on the website. That should be a good (and harmless) exercise to test if everything is working. Things to do : 1) test ssh-ing to the server people.apache.org. 2) Change your login password on the machine as per the account email 3) Add a public key to .ssh so you can stop using the password 4) Change your svn password as described in the account email At this point, you should be good to go. Checkout the website from svn and update it. See if you can figure out how. Also, for your main harmony/enhanced/classlib/trunk please be sure that you have checked out via 'https' and not 'http' or you can't check in. You can switch using svn switch. (See the manual) Finally, although you now have the ability to commit, please remember : 1) continue being as transparent and communicative as possible. You earned committer status in part because of your engagement with others. While it was a have to situation because you had to submit patches and defend them, but we believe it is a want to. Community is the key to any Apache project. 2)We don't want anyone going off and doing lots of work locally, and then committing. Committing is like voting in Chicago - do it early and often. Of course, you don't want to break the build, but keep the commit bombs to an absolute minimum, and warn the community if you are going to do it - we may suggest it goes into a branch at first. Use branches if you need to. 3) Always remember that you can **never** commit code that comes from someone else, even a co-worker. All code from someone else must be submitted by the copyright holder (either the author or author's employer, depending) as a JIRA, and then follow up with the required ACQs and BCC. Again, thanks for your hard work so far, and welcome. The Apache Harmony PPMC - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Oliver Deakin IBM United Kingdom Limited - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [announce] New Apache Harmony Committer : Paulex Yang
Congratulations! :) 2006/7/17, Oliver Deakin [EMAIL PROTECTED]: Congratulations Paulex! :) Geir Magnusson Jr wrote: Please join the Apache Harmony PPMC in welcoming the project's newest committer, Paulex Yang. Mark has demonstrated the elements that help build a healthy community, namely his ability to work together with others, continued dedication to the project, an understanding of our overall goals of the project, and a really unnatural and probably unhealthy focus on nio :) We all continue to expect great things from him. Mark, as a first step to test your almighty powers of committership, please update the committers page on the website. That should be a good (and harmless) exercise to test if everything is working. Things to do : 1) test ssh-ing to the server people.apache.org. 2) Change your login password on the machine as per the account email 3) Add a public key to .ssh so you can stop using the password 4) Change your svn password as described in the account email At this point, you should be good to go. Checkout the website from svn and update it. See if you can figure out how. Also, for your main harmony/enhanced/classlib/trunk please be sure that you have checked out via 'https' and not 'http' or you can't check in. You can switch using svn switch. (See the manual) Finally, although you now have the ability to commit, please remember : 1) continue being as transparent and communicative as possible. You earned committer status in part because of your engagement with others. While it was a have to situation because you had to submit patches and defend them, but we believe it is a want to. Community is the key to any Apache project. 2)We don't want anyone going off and doing lots of work locally, and then committing. Committing is like voting in Chicago - do it early and often. Of course, you don't want to break the build, but keep the commit bombs to an absolute minimum, and warn the community if you are going to do it - we may suggest it goes into a branch at first. Use branches if you need to. 3) Always remember that you can **never** commit code that comes from someone else, even a co-worker. All code from someone else must be submitted by the copyright holder (either the author or author's employer, depending) as a JIRA, and then follow up with the required ACQs and BCC. Again, thanks for your hard work so far, and welcome. The Apache Harmony PPMC - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Oliver Deakin IBM United Kingdom Limited - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Alexey A. Petrenko 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] using the harmony launcher
Andrey Chernyshev wrote: On 7/13/06, Oliver Deakin [EMAIL PROTECTED] wrote: Andrey Chernyshev wrote: SNIP! 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. I also like the first approach, it would be strange behavior for JNI CallXMethod to run the calls in a separate thread if some special flag is found. Does this answer your question? Any other ideas? I don't think there is an issue with not running of certain parts of VMStart: one can divide it into 3 different parts: - initialization; - running main() method of the user app (in a separate thread) - shutdown. The code for VMStart's init() and shutdown() is equally run regardless of whether drlvm is started with it's own or classlib launcher. The difference is only in running the user app main() method. Classlib launcher calls it directly, through JNI, while the drlvm's launcher wraps it into the run() method and always runs in a separate thread. I suspect there could be some difference in the classloader's used for the user app code, perhaps the drlvm classloading experts could give some more details. If we separate initialisation and execution of the main() method in VMStart so that CreateJavaVM works, is there actually a need to keep the main() method execution in there? I can't think of a reason to launch the main() method in a separate thread (perhaps, as you suggest, some drlvm experts can help with this one) - if there is no reason to do this, then I would probably suggest either altering the drlvm launcher to use a more conventional launcher approach (CreateJavaVM followed by CallStaticMethod) or abandoning the drlvm launcher in favour of the classlib one. Either way, I think the start() method in VMStart could probably be removed. Thanks, Andrey. (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 the fact that an exception already exists on entering DestroyJavaVM, and clear it before trying to resolve the VMStart class. Yes, this sounds reasonable. Then, what should be the expected behavior for DestroyVM in case it finds pending exception, should it silently ignore it, or report a warning or what? JNI spec doesn't seem to specify these details. Agreed, the JNI spec isn't too clear on this matter. In JNI, handling of uncaught exceptions is expected to be done by the developer (ie using ExceptionOccurred, ExceptionDescribe, ExceptionClear) rather than the VM. This leads me to think that if any exceptions have not been cleared by the JNI code before DestroyJavaVM() is called, then the developer will expect the VM to just silently ignore them and carry on shutting down. So, IMHO one of the first things that should be done after entering DestroyJavaVM is to check for pending exceptions, and clear them if they're going to interfere with the shutdown sequence. I've just created a simple launcher that: - creates a Java VM - invokes the main method of a class that throws a RuntimeException - calls DestroyJavaVM without clearing the pending exception Both the RI and IBM VMs exit without any complaints, so I think that drlvm should match this behaviour also. Regards, Oliver (3) CreateJavaVM can only be called once
Re: [announce] New Apache Harmony Committer : Paulex Yang
Congratulations, Paulex! You're my role-model. ;-) Geir Magnusson Jr wrote: Please join the Apache Harmony PPMC in welcoming the project's newest committer, Paulex Yang. Mark has demonstrated the elements that help build a healthy community, namely his ability to work together with others, continued dedication to the project, an understanding of our overall goals of the project, and a really unnatural and probably unhealthy focus on nio :) We all continue to expect great things from him. Mark, as a first step to test your almighty powers of committership, please update the committers page on the website. That should be a good (and harmless) exercise to test if everything is working. Things to do : 1) test ssh-ing to the server people.apache.org. 2) Change your login password on the machine as per the account email 3) Add a public key to .ssh so you can stop using the password 4) Change your svn password as described in the account email At this point, you should be good to go. Checkout the website from svn and update it. See if you can figure out how. Also, for your main harmony/enhanced/classlib/trunk please be sure that you have checked out via 'https' and not 'http' or you can't check in. You can switch using svn switch. (See the manual) Finally, although you now have the ability to commit, please remember : 1) continue being as transparent and communicative as possible. You earned committer status in part because of your engagement with others. While it was a have to situation because you had to submit patches and defend them, but we believe it is a want to. Community is the key to any Apache project. 2)We don't want anyone going off and doing lots of work locally, and then committing. Committing is like voting in Chicago - do it early and often. Of course, you don't want to break the build, but keep the commit bombs to an absolute minimum, and warn the community if you are going to do it - we may suggest it goes into a branch at first. Use branches if you need to. 3) Always remember that you can **never** commit code that comes from someone else, even a co-worker. All code from someone else must be submitted by the copyright holder (either the author or author's employer, depending) as a JIRA, and then follow up with the required ACQs and BCC. Again, thanks for your hard work so far, and welcome. The Apache Harmony PPMC - 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: [general] Sun's permission to use exception messages and toString() formats
Good news! So we can output the same message if possible. Not sure whether we need to update all of us toStrings? Any comments? Geir Magnusson Jr wrote: Sun, via Graham Hamilton (my favorite Sun Fellow), has stated the following : Sun has no objections to Harmony (or other TCK-compliant Java SE implementations) using the same exception messages and toString formats as the Sun implementation of Java SE. Further, as a personal comment, he added : Keep in mind that since these messages and formats are not part of the Java SE specifications, Sun may occasionally change the messages and formats it uses. We tend to be cautious in doing that, so as not to impact applications, but it isn't ruled out. Also, it should be noted that in the APIs where Doug Lea or Josh Bloch had a major influence, there's a good change that the toString() format *is* defined in the spec. For example, see HashMap (via AbstractMap). The point is that while it hasn't been done consistently throughout the entire API, it's well understood by some that people depend on these things, and one should be careful about changing them. geir - 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: [general] Sun's permission to use exception messages and toString() formats
I do not think that we really need to rewrite all the toString messages. I suggest to update them as needed. For example if somebody will discover that some important application depends on it... SY, Alexey 2006/7/17, Richard Liang [EMAIL PROTECTED]: Good news! So we can output the same message if possible. Not sure whether we need to update all of us toStrings? Any comments? Geir Magnusson Jr wrote: Sun, via Graham Hamilton (my favorite Sun Fellow), has stated the following : Sun has no objections to Harmony (or other TCK-compliant Java SE implementations) using the same exception messages and toString formats as the Sun implementation of Java SE. Further, as a personal comment, he added : Keep in mind that since these messages and formats are not part of the Java SE specifications, Sun may occasionally change the messages and formats it uses. We tend to be cautious in doing that, so as not to impact applications, but it isn't ruled out. Also, it should be noted that in the APIs where Doug Lea or Josh Bloch had a major influence, there's a good change that the toString() format *is* defined in the spec. For example, see HashMap (via AbstractMap). The point is that while it hasn't been done consistently throughout the entire API, it's well understood by some that people depend on these things, and one should be careful about changing them. geir - 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] -- Alexey A. Petrenko 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: [announce] New Apache Harmony Committer : Paulex Yang
And Paulex, please accept my sincerest apologies for the copy-and-paste-o down there, leaving in Mark, twice. :) I'm very embarrassed, and this in no way has any bearing on you. geir Geir Magnusson Jr wrote: Please join the Apache Harmony PPMC in welcoming the project's newest committer, Paulex Yang. Mark has demonstrated the elements that help build a healthy community, namely his ability to work together with others, continued dedication to the project, an understanding of our overall goals of the project, and a really unnatural and probably unhealthy focus on nio :) We all continue to expect great things from him. Mark, as a first step to test your almighty powers of committership, please update the committers page on the website. That should be a good (and harmless) exercise to test if everything is working. Things to do : 1) test ssh-ing to the server people.apache.org. 2) Change your login password on the machine as per the account email 3) Add a public key to .ssh so you can stop using the password 4) Change your svn password as described in the account email At this point, you should be good to go. Checkout the website from svn and update it. See if you can figure out how. Also, for your main harmony/enhanced/classlib/trunk please be sure that you have checked out via 'https' and not 'http' or you can't check in. You can switch using svn switch. (See the manual) Finally, although you now have the ability to commit, please remember : 1) continue being as transparent and communicative as possible. You earned committer status in part because of your engagement with others. While it was a have to situation because you had to submit patches and defend them, but we believe it is a want to. Community is the key to any Apache project. 2)We don't want anyone going off and doing lots of work locally, and then committing. Committing is like voting in Chicago - do it early and often. Of course, you don't want to break the build, but keep the commit bombs to an absolute minimum, and warn the community if you are going to do it - we may suggest it goes into a branch at first. Use branches if you need to. 3) Always remember that you can **never** commit code that comes from someone else, even a co-worker. All code from someone else must be submitted by the copyright holder (either the author or author's employer, depending) as a JIRA, and then follow up with the required ACQs and BCC. Again, thanks for your hard work so far, and welcome. The Apache Harmony PPMC - 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] debug compilation as default
Ivan Volosyuk wrote:
I have already implemented it using ant variables, look at the latest
patch. You can use following notation with it:
ant -Dhy.cfg=release
Geir Magnusson Jr wrote:
Now we're getting somewhere.
I assume then I can put this into the build.properties that we'll be
adding Real Soon Now (as I can never remember command line args anyway...)
Please, please, do *not* introduce any more build.properties files.
The files that may need to be customized to get specific build configuration
should never be version-controlled. Besides, keeping configuration files
in the workspace means you cannot make your configuration permanent.
I see the properties files as anti-usable.
The main point of using environment variables instead of ant properties
is an ability to do a *workstation-specific* configuration in a permanent way,
so that I do not need to do any configuration steps before the build for
the fresh workspace, once I have configured my environment.
And by the way, the solution to run 'HY_CFG=xyz ant' with
corresponding
property environment=env/
condition property='hy.cfg' value='${env.HY_CFG}'
isset property=env.HY_CFG/
/condition
worked perfectly for the DRLVM builds on Windows. What's more,
it is *compatible* with 'ant -Dhy.cfg=...' syntax.
I have not heard any specific concerns why this can't be used.
-
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:
Continue this discussion?
Vladimir,
far below are results of my experiments with Log4cxx's ResourceBundle.
(I've managed to find it in Log4cxx documentation after carefully
rereading your original post).
The good news is that it does localization (severely limited).
The prototype has following good properties
* The unlocalized message is used as the message key
* No extra entities were introduced (like non-printable message keys)
* The localizable messages are marked by _() notation and can
be extracted from the source code automatically
The things that I have not implemented yet (to save time and make at least
something available):
* loading the system locale value
* reading the locale-specific localization file
* converting the localized messages to locale-specific encoding
* converting the unlocalized messages from source encoding (US-ASCII) to UTF-16
(wchar_t[])
The issues that I have encountered but haven't yet worked out a solution:
* PropertyResourceBundle.getString().c_str() returns the pointer to the stack
location. To make it work, I had to use wcsdup(), thus introducing
an unacceptable memory leak.
I think there must be some way to get the pointer to original bundle contents,
but haven't figured out how to achieve it.
* PropertyResourceBundle expects the good property format, so the unlocalized
messages needs to be mangled to property-compatible form
(in the patch below, the only transformation replaced spaces ' ' with
underscores '_',
but it needs to be generalized).
Given the number of issues PropertyResourceBundle introduces, and the number of
services it provides (parsing property-format and constructing in-memory
hashmap),
I think that it would be easier to reimplement the functionality without using
PropertyResourceBundle,
and change the storage on-disk file format to allow unmangled messages be the
keys.
===
From: Salikh Zakirov [EMAIL PROTECTED]
Date: Thu, 13 Jul 2006 12:06:05 +0400
Subject: [PATCH] Dummy l10n implemenation based on Log4cxx
---
vm/include/l10n.h | 31 +++
vm/port/include/loggerstring.h |9 +
vm/vmcore/src/init/l10n.cpp| 66
vm/vmcore/src/init/vm_main.cpp |2 +
4 files changed, 108 insertions(+), 0 deletions(-)
diff --git a/vm/include/l10n.h b/vm/include/l10n.h
new file mode 100755
index 000..bb3edfe
--- /dev/null
+++ b/vm/include/l10n.h
@@ -0,0 +1,31 @@
+#ifndef _L10N_H
+#define _L10N_H
+
+#include string
+#include log4cxx/helpers/propertyresourcebundle.h
+#include log4cxx/helpers/exception.h
+#include wchar.h
+#include cxxlog.h
+
+extern log4cxx::helpers::ResourceBundlePtr l10n_resource_bundle;
+
+inline const wchar_t* _(const wchar_t* message)
+{
+if (!l10n_resource_bundle) return message;
+try {
+wchar_t* mangled = wcsdup(message);
+wchar_t* c = mangled;
+while (*c) {
+if (*c == L' ') *c = L'_';
+c++;
+}
+std::wstring localized = l10n_resource_bundle-getString(mangled);
+free(mangled);
+return wcsdup(localized.c_str()); // FIXME: leak
+} catch (log4cxx::helpers::MissingResourceException ) {}
+return message;
+}
+
+void init_l10n();
+
+#endif // _L10N_H
diff --git a/vm/port/include/loggerstring.h b/vm/port/include/loggerstring.h
old mode 100644
new mode 100755
index 1efe5d2..1eae5c1
--- a/vm/port/include/loggerstring.h
+++ b/vm/port/include/loggerstring.h
@@ -41,6 +41,15 @@ public:
return (const char*)logger_string.c_str();
}
+LoggerString operator(const wchar_t* message) {
+const wchar_t* c = message;
+while (*c) {
+logger_string += (char)*c;
+c++;
+}
+return *this;
+}
+
LoggerString operator(const char* message) {
logger_string += message;
return *this;
diff --git a/vm/vmcore/src/init/l10n.cpp b/vm/vmcore/src/init/l10n.cpp
new file mode 100755
index 000..c8fd746
--- /dev/null
+++ b/vm/vmcore/src/init/l10n.cpp
@@ -0,0 +1,66 @@
+#include apr_env.h
+#include assert.h
+#include fstream
+#include string.h
+
+#include cxxlog.h
+#include l10n.h
+#include platform_lowlevel.h
+
+#include log4cxx/helpers/locale.h
+
+using namespace log4cxx;
+using namespace log4cxx::helpers;
+
+ResourceBundlePtr l10n_resource_bundle;
+
+void init_l10n()
+{
+INFO2(info, starting l10n initialization);
+
+/*
+apr_pool_t *pool;
+apr_pool_create(pool, 0); assert(pool);
+char *lang = NULL;
+
+apr_env_get(lang, LANG, pool);
+if (!lang) lang = C;
+
+char *encoding = strchr(lang,'.');
+if (encoding != NULL) {
+*encoding = '\0';
+encoding += 1;
+}
+char *region = strchr(lang,'_');
+if (region != NULL) {
+*region = '\0';
+region += 1;
+}
+INFO2(info, lang = lang , region = region
+ , encoding = encoding);
Re: [drlvm] proposals for VM internationalization
Geir Magnusson Jr wrote: 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 1. The launcher already packages some translations in property-format, it makes me believe that launcher localization was once completed at IBM. Though I wasn't able to find anything about localization in launcher sources. Tim, Mark, could you provide more information about localization already implemented in classlib natives? 2. As far as I can see, the only common thing that natives l10n can have with java l10n is translation files. Generally, this is a good goal, as it would make the translators job more straightforward, keeping the number of formats and message systems at minimum. 3. I personally consider the property-based design of l10n in Java inferior, because it requires the keys to be property-name-compatible (e.g. no spaces), and it often results in developers choosing to introduce short localization key names bearing no meaning. For example, see the harmony_*.properties in classlib: EXEL051=... Should the localization system fail, the only thing that user will get is EXEL051. The developers reading the code which prints localizable message, has no clue too. To find out the value of message, one needs to consult default localization file. Furthermore, when introducing new localizable message, one needs to edit 3(!) different places: add the message code, add the key, and add the printable message to default localization file. This particular design choice is ineffective in using developers' time, is less robust and less maintainable. And if the key names are used in construction of unlocalized messages, then it introduces runtime cost of mangling the unlocalized message to some property-name-compatible form. - 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:
Vladimir wrote:
(I believe Alexey used it to test. *Or J9 nevertheless*? IMHO it
needs to
specify when same discussions start).
I have tried both. And both differ from RI.
Richard wrote:
For getDeclaredMethods(), J9 has the same behavior as RI.
Well, there are some nuances nevertheless. I have wrote a small test
(that was close to my orginal test) and ran it on four different VMs.
The test simply does TestBean.class.getDeclaredMethods() and prints
the resulting array.
Alexei,
Good catch! I have not tested polymorphism. :-[
Richard
TestBean.java:
class TestBean {
String methodCalled = null;
public void method(Integer i) {
methodCalled = method1;
}
public void method(int i) {
methodCalled = method2;
}
public void method(boolean b) {
methodCalled = method3;
}
public void method(Boolean b) {
methodCalled = method4;
}
}
The results:
RI (Sun 1.5.0_05)
method int
method boolean
method java.lang.Boolean
method java.lang.Integer
j9 v3
method java.lang.Integer
method int
method boolean
method java.lang.Boolean
DLRVM
method java.lang.Integer
method int
method boolean
method java.lang.Boolean
jrockit-R26.3.0-jdk1.5.0_06
method java.lang.Boolean
method boolean
method int
method java.lang.Integer
With Best Regards,
2006/7/14, Richard Liang [EMAIL PROTECTED]:
Geir Magnusson Jr wrote:
Alexey Varlamov 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).
What does j9 do?
For getDeclaredMethods(), J9 has the same behavior as RI. For
getMethods, J9 and RI behave differently. ;-) But it's not so hard
to summarize RI's rule of method order. Am I wrong?
Best regards,
Richard
I believe we need a bit stronger motivation for scratching this
issue,
than a blunt testcase - some real-world application.
I agree that this isn't a critical issue, but a nice to have. Maybe
we see what J9 does, and follow the majority (if we spend the
time...)?
geir
--
Richard Liang
China Software Development Lab, IBM
--
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: [classlib] compatibility nuances
Vladimir Gorr wrote:
In this case I'd like to understand what behaviour is correct
and what should be made to satisfy the users. I have no any preference.
Hello Vladimir,
I think all of us agree that it's possible to following RI's behavior,
Right? The question is we shall decide to follow or not. Any suggestion?
Thanks a lot.
Best regards,
Richard.
Thanks,
Vladimir.
On 7/14/06, Alexei Zakharov [EMAIL PROTECTED] wrote:
Vladimir wrote:
(I believe Alexey used it to test. *Or J9 nevertheless*? IMHO it needs
to
specify when same discussions start).
I have tried both. And both differ from RI.
Richard wrote:
For getDeclaredMethods(), J9 has the same behavior as RI.
Well, there are some nuances nevertheless. I have wrote a small test
(that was close to my orginal test) and ran it on four different VMs.
The test simply does TestBean.class.getDeclaredMethods() and prints
the resulting array.
TestBean.java:
class TestBean {
String methodCalled = null;
public void method(Integer i) {
methodCalled = method1;
}
public void method(int i) {
methodCalled = method2;
}
public void method(boolean b) {
methodCalled = method3;
}
public void method(Boolean b) {
methodCalled = method4;
}
}
The results:
RI (Sun 1.5.0_05)
method int
method boolean
method java.lang.Boolean
method java.lang.Integer
j9 v3
method java.lang.Integer
method int
method boolean
method java.lang.Boolean
DLRVM
method java.lang.Integer
method int
method boolean
method java.lang.Boolean
jrockit-R26.3.0-jdk1.5.0_06
method java.lang.Boolean
method boolean
method int
method java.lang.Integer
With Best Regards,
2006/7/14, Richard Liang [EMAIL PROTECTED]:
Geir Magnusson Jr wrote:
Alexey Varlamov 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).
What does j9 do?
For getDeclaredMethods(), J9 has the same behavior as RI. For
getMethods, J9 and RI behave differently. ;-) But it's not so hard
to summarize RI's rule of method order. Am I wrong?
Best regards,
Richard
I believe we need a bit stronger motivation for scratching this
issue,
than a blunt testcase - some real-world application.
I agree that this isn't a critical issue, but a nice to have.
Maybe
we see what J9 does, and follow the majority (if we spend the
time...)?
geir
--
Richard Liang
China Software Development Lab, IBM
--
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]
--
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.)
LvJimmy,Jing wrote:
Hi Andrew:
Sorry for late, but as this solution does not resolve I18N (working
aound for 815 only?) , I guess we may have another way.
If I understand correctly, this solution try to analysis error code in
native code, throws ErrorCodeException; and java code catch this
exception,
get error code, and throw another exception.
If so, why not just return the error code directly instead? :)
Hello Jimmy,
IIRC, It's SocketException that is thrown in native code, not
ErrorCodeException. And we will set the ErrorCodeException as cause of
the SocketException. I18N is anther issue, we shall have full discussion
in community to mature our thoughts. :-)
Do I miss something?
Best regards,
Richard.
2006/7/14, Mikhail Loenko [EMAIL PROTECTED]:
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
Re: [classlib] debug compilation as default
Salikh Zakirov wrote:
Ivan Volosyuk wrote:
I have already implemented it using ant variables, look at the latest
patch. You can use following notation with it:
ant -Dhy.cfg=release
Geir Magnusson Jr wrote:
Now we're getting somewhere.
I assume then I can put this into the build.properties that we'll be
adding Real Soon Now (as I can never remember command line args anyway...)
Please, please, do *not* introduce any more build.properties files.
We need *one*. right now, things are in environment variables, embedded
in build.xml files, or randomly passed on the command line. It's ad-hoc
and not easily reproducible or portable.
The files that may need to be customized to get specific build configuration
should never be version-controlled. Besides, keeping configuration files
in the workspace means you cannot make your configuration permanent.
I see the properties files as anti-usable.
The default set is version controlled. It's not called
build.properties. The properties in build.properties override the defaults.
The main point of using environment variables instead of ant properties
is an ability to do a *workstation-specific* configuration in a permanent way,
so that I do not need to do any configuration steps before the build for
the fresh workspace, once I have configured my environment.
I disagree. you can use the properties to do things in a workstation
specific way, and in a very clean, localized way. One file, rather than
in semi-visible and distributed bits.
You can also come up with configuration sets, that can be checked in and
re-used in a predictable manner.
test_local_debug.properties
test_remote_debug.properties
test_local_release.properties
test_remote_release.propertes
etc
You can also cleanly, portably automate things too.
And by the way, the solution to run 'HY_CFG=xyz ant' with
corresponding
property environment=env/
condition property='hy.cfg' value='${env.HY_CFG}'
isset property=env.HY_CFG/
/condition
worked perfectly for the DRLVM builds on Windows. What's more,
it is *compatible* with 'ant -Dhy.cfg=...' syntax.
I have not heard any specific concerns why this can't be used.
It can be used. I'm just proposing something portable and reusable.
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: Geir Magnusson Jr wrote: 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 1. The launcher already packages some translations in property-format, it makes me believe that launcher localization was once completed at IBM. Though I wasn't able to find anything about localization in launcher sources. Who cares what was once completed at IBM? They had their reasons, their uses... This is Apache Harmony :) We can do what we feel is best (including keeping what was donated...) Tim, Mark, could you provide more information about localization already implemented in classlib natives? 2. As far as I can see, the only common thing that natives l10n can have with java l10n is translation files. Generally, this is a good goal, as it would make the translators job more straightforward, keeping the number of formats and message systems at minimum. +1 3. I personally consider the property-based design of l10n in Java inferior, because it requires the keys to be property-name-compatible (e.g. no spaces), and it often results in developers choosing to introduce short localization key names bearing no meaning. For example, see the harmony_*.properties in classlib: EXEL051=... Should the localization system fail, the only thing that user will get is EXEL051. Don't we have far bigger problems if the localization system in the JVM fails? The developers reading the code which prints localizable message, has no clue too. To find out the value of message, one needs to consult default localization file. Furthermore, when introducing new localizable message, one needs to edit 3(!) different places: add the message code, add the key, and add the printable message to default localization file. This particular design choice is ineffective in using developers' time, is less robust and less maintainable. And if the key names are used in construction of unlocalized messages, then it introduces runtime cost of mangling the unlocalized message to some property-name-compatible form. I understand what you are saying, and certainly agree that if we can find some way to use meaningful keys, so much the better. I guess the question is what does that cost us, versus the likelyhood that the localization system will fail... geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[drlvm] Status of drlvm
Hi, Can anyone share their experience on running DRLVM built from SVN? On my workstations, it requires several fixes in order to run properly: HARMONY-898 'workaround to get correct hythr.dll' (both for Linux and Windows) HARMONY-853 'DRLVM+classlib segfaults in hyzlib' (on Linux) Without HARMONY-898, DRLVM segfaults after reading NULL from TLS. Without HARMONY-853, DRLVM segfaults in libhyzlib.so on Linux. I would suggest that the patches from HARMONY-898 and HARMONY-853 be applied, because DRLVM doesn't work at all for me without these fixes. Any other experiences? Is anyone besides me running DRLVM from SVN? - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [general] Sun's permission to use exception messages and toString() formats
Richard Liang wrote: Good news! So we can output the same message if possible. Not sure whether we need to update all of us toStrings? Any comments? I think it's something we should do, although not drop everything to do it. I'd like to see if simply start listing (say in the wiki) the classes that have correct toString() implementations as per the RI/spec, and then people can lazily fix over time... geir Geir Magnusson Jr wrote: Sun, via Graham Hamilton (my favorite Sun Fellow), has stated the following : Sun has no objections to Harmony (or other TCK-compliant Java SE implementations) using the same exception messages and toString formats as the Sun implementation of Java SE. Further, as a personal comment, he added : Keep in mind that since these messages and formats are not part of the Java SE specifications, Sun may occasionally change the messages and formats it uses. We tend to be cautious in doing that, so as not to impact applications, but it isn't ruled out. Also, it should be noted that in the APIs where Doug Lea or Josh Bloch had a major influence, there's a good change that the toString() format *is* defined in the spec. For example, see HashMap (via AbstractMap). The point is that while it hasn't been done consistently throughout the entire API, it's well understood by some that people depend on these things, and one should be careful about changing them. 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]
Re: [general] Sun's permission to use exception messages and toString() formats
Alexey Petrenko wrote: I do not think that we really need to rewrite all the toString messages. I suggest to update them as needed. For example if somebody will discover that some important application depends on it... The problem with that approach is that you are letting your users find problems that you actually know are there. As I said in another note, I don't think we should drop everything to do this, but we *should* agree to do it lazily, track what has been fixed, and offer it as something that new people who want to get engaged in the project can do as well. geir SY, Alexey 2006/7/17, Richard Liang [EMAIL PROTECTED]: Good news! So we can output the same message if possible. Not sure whether we need to update all of us toStrings? Any comments? Geir Magnusson Jr wrote: Sun, via Graham Hamilton (my favorite Sun Fellow), has stated the following : Sun has no objections to Harmony (or other TCK-compliant Java SE implementations) using the same exception messages and toString formats as the Sun implementation of Java SE. Further, as a personal comment, he added : Keep in mind that since these messages and formats are not part of the Java SE specifications, Sun may occasionally change the messages and formats it uses. We tend to be cautious in doing that, so as not to impact applications, but it isn't ruled out. Also, it should be noted that in the APIs where Doug Lea or Josh Bloch had a major influence, there's a good change that the toString() format *is* defined in the spec. For example, see HashMap (via AbstractMap). The point is that while it hasn't been done consistently throughout the entire API, it's well understood by some that people depend on these things, and one should be careful about changing them. geir - 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] - 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.)
David Tanzer wrote:
On 17.07.2006, at 14:09, Richard Liang wrote:
LvJimmy,Jing wrote:
Hi Andrew:
Sorry for late, but as this solution does not resolve I18N (working
aound for 815 only?) , I guess we may have another way.
If I understand correctly, this solution try to analysis error code in
native code, throws ErrorCodeException; and java code catch this
exception,
get error code, and throw another exception.
If so, why not just return the error code directly instead? :)
Hello Jimmy,
IIRC, It's SocketException that is thrown in native code, not
ErrorCodeException. And we will set the ErrorCodeException as cause
of the SocketException.
Yes, this is how I remember it too. The idea was to do the equivalent
of the
following code in the native code (correct me if I'm wrong):
ErrorCodeException ece = new ErrorCodeException(SOME_ERROR_CODE);
throw new SocketException(Some Message, ece);
I don't think it is semantically correct to set the ErrorCodeException
as the cause
of the SocketException - the error code provides additional info, it
is not the cause
of the problem. For example, this code:
try {
ErrorCodeException ece = new ErrorCodeException(13);
throw new TestException(Something went wrong, ece);
} catch(TestException e) {
e.printStackTrace();
}
Yields the following stack trace:
net.guglhupf.test.TestException: Something went wrong
at net.guglhupf.test.ExceptionTest.main(ExceptionTest.java:7)
Caused by: Error Code 13
at net.guglhupf.test.ExceptionTest.main(ExceptionTest.java:6)
which might be confusing for some application developer so personally
I like the subclass - approach described by Andrew Zhang [1] better.
Hello David,
I also think the subclass-approach is more reasonable ;-) . I'm not sure
if it's regarded as breaking specification. (Spec requires us to throw
SocketExpception). Any comments? Thanks a lot.
Best regards,
Richard.
Regards,
David
[1]
http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200607.mbox/[EMAIL PROTECTED]
I18N is anther issue, we shall have full discussion in community to
mature our thoughts. :-)
Do I miss something?
Best regards,
Richard.
2006/7/14, Mikhail Loenko [EMAIL PROTECTED]:
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
Re: [drlvm] Status of drlvm
On 7/17/06, Salikh Zakirov [EMAIL PROTECTED] wrote: Hi, Can anyone share their experience on running DRLVM built from SVN? Removing classlib from drlvm build is a big improvement. At this point, I develop only on windows. No recent experience with the Linux build. ant seems to have intermittant problems with windows file paths that have blanks in them. The error messages are very vague. For example, set JAVA_HOME=c:\Program Files\jdk... causes strange problems. On my workstations, it requires several fixes in order to run properly: HARMONY-898 'workaround to get correct hythr.dll' (both for Linux and Windows) HARMONY-853 'DRLVM+classlib segfaults in hyzlib' (on Linux) Without HARMONY-898, DRLVM segfaults after reading NULL from TLS. Without HARMONY-853, DRLVM segfaults in libhyzlib.so on Linux. I would suggest that the patches from HARMONY-898 and HARMONY-853 be applied, because DRLVM doesn't work at all for me without these fixes. I don't see the segfaults. It might be because the initial port of MMTk does not involve threads. Any other experiences? Is anyone besides me running DRLVM from SVN? Getting the debugger to single step through unoptimized jitrino.jet code shows the build system needs some work. I don't want to plunge into fixing make files until I have more experience with the build system but it definitely needs fixing! - 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: svn commit: r422661 - /incubator/harmony/enhanced/classlib/trunk/modules/luni/src/main/java/java/util/AbstractCollection.java
Given that this is an API class, can we add a pointer to the real API
javadoc as well?
geir
[EMAIL PROTECTED] wrote:
Author: gharley
Date: Mon Jul 17 03:08:03 2006
New Revision: 422661
URL: http://svn.apache.org/viewvc?rev=422661view=rev
Log:
HARMONY 861 : [luni] Javadoc of java.util.AbstractCollection.add() is missing
Modified:
incubator/harmony/enhanced/classlib/trunk/modules/luni/src/main/java/java/util/AbstractCollection.java
Modified:
incubator/harmony/enhanced/classlib/trunk/modules/luni/src/main/java/java/util/AbstractCollection.java
URL:
http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/modules/luni/src/main/java/java/util/AbstractCollection.java?rev=422661r1=422660r2=422661view=diff
==
---
incubator/harmony/enhanced/classlib/trunk/modules/luni/src/main/java/java/util/AbstractCollection.java
(original)
+++
incubator/harmony/enhanced/classlib/trunk/modules/luni/src/main/java/java/util/AbstractCollection.java
Mon Jul 17 03:08:03 2006
@@ -1,4 +1,4 @@
-/* Copyright 1998, 2005 The Apache Software Foundation or its licensors, as
applicable
+/* Copyright 1998, 2006 The Apache Software Foundation or its licensors, as
applicable
*
* Licensed under the Apache License, Version 2.0 (the License);
* you may not use this file except in compliance with the License.
@@ -33,6 +33,35 @@
super();
}
+/**
+ * If the specified element is not contained within this collection, and
+ * addition of this element succeeds, then true will be returned. If the
+ * specified element is already contained within this collection, or
+ * duplication is not permitted, false will be returned. Different
+ * implementations may add specific limitations on this method to filter
+ * permitted elements. For example, in some implementation, null element
may
+ * be denied, and NullPointerException will be thrown out. These
limitations
+ * should be explicitly documented by specific collection implmentation.
+ *
+ * Add operation is not supported in this implementation, and
+ * UnsupportedOperationException will always be thrown out.
+ *
+ * @param object
+ *the element to be added.
+ * @return true if the collection is changed successfully after invoking
+ * this method. Otherwise, false.
+ * @exception UnsupportedOperationException
+ *if add operation is not supported by this class.
+ * @exception NullPointerException
+ *if null is used to invoke this method, and null is not
+ *permitted by this collection.
+ * @exception ClassCastException
+ *if the class type of the specified element is not
+ *compatible with the permitted class type.
+ * @exception IllegalArgumentException
+ *if limitations of this collection prevent the specified
+ *element from being added
+ */
public boolean add(E object) {
throw new UnsupportedOperationException();
}
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[classlib] Re: svn commit: r422501 [1/2] - in /incubator/harmony/enhanced/classlib/trunk/modules/text: ./ src/main/java/java/text/ src/test/java/org/apache/harmony/text/tests/java/text/
[EMAIL PROTECTED] wrote: --- incubator/harmony/enhanced/classlib/trunk/modules/text/src/main/java/java/text/AttributedString.java (original) +++ incubator/harmony/enhanced/classlib/trunk/modules/text/src/main/java/java/text/AttributedString.java Sun Jul 16 12:10:14 2006 @@ -1,26 +1,29 @@ -/* Copyright 1998, 2006 The Apache Software Foundation or its licensors, as applicable +/* + * Copyright 1998, 2006 The Apache Software Foundation or its licensors, as + * applicable * - * Licensed under the Apache License, Version 2.0 (the License); - * you may not use this file except in compliance with the License. - * You may obtain a copy of the License at + * Licensed under the Apache License, Version 2.0 (the License); you may not + * use this file except in compliance with the License. You may obtain a copy of + * the License at * - * http://www.apache.org/licenses/LICENSE-2.0 + * http://www.apache.org/licenses/LICENSE-2.0 * * Unless required by applicable law or agreed to in writing, software - * distributed under the License is distributed on an AS IS BASIS, - * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. - * See the License for the specific language governing permissions and - * limitations under the License. + * distributed under the License is distributed on an AS IS BASIS, WITHOUT + * WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the + * License for the specific language governing permissions and limitations under + * the License. Can we avoid doing this? It makes no material difference, but conforming to the format and line breaks suggested by the appendix to the license itself http://www.apache.org/licenses/LICENSE-2.0 means that it always looks the same, and therefore people don't feel the need to read it, which I did when I saw that you were changing it... geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[continuum] BUILD FAILURE: Classlib/win.ia32 Build/Test
The test below is failing as follows, I have not investigated: Wrong full date pattern expected:...full... but was:...long... junit.framework.ComparisonFailure: Wrong full date pattern expected:...full... but was:...long... at org.apache.harmony.text.tests.java.text.MessageFormatTest.test_applyPatternLjava_lang_String(MessageFormatTest.java:244) at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:205) Apache Harmony Build wrote: Online report : http://ibmonly.hursley.ibm.com/continuum/win.ia32/servlet/continuum/target/ProjectBuild.vm/view/ProjectBuild/id/6/buildId/1796 Build statistics: State: Failed Previous State: Failed Started at: Mon, 17 Jul 2006 14:09:15 +0100 Finished at: Mon, 17 Jul 2006 14:25:09 +0100 Total time: 15m 54s Build Trigger: Schedule Exit code: 1 Building machine hostname: hy1 Operating system : Windows XP(Service Pack 2) Java version : 1.5.0_06(Sun Microsystems Inc.) snip [exec] compile.tests: [exec] [echo] Compiling TEXT tests [exec] [javac] Compiling 26 source files to C:\continuum-1.0.2\apps\continuum\working-directory\6\classlib\modules\text\bin\test [exec] run.tests: [exec] [junit] Running org.apache.harmony.text.tests.java.text.StringCharacterIteratorTest [exec] [junit] java version 1.5 (subset) [exec] [junit] (c) Copyright 1991, 2006 The Apache Software Foundation or its licensors, as applicable. [exec] [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 0.172 sec [exec] [junit] Tests run: 10, Failures: 0, Errors: 0, Time elapsed: 0.031 sec [exec] [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0.031 sec [exec] [junit] Tests run: 23, Failures: 0, Errors: 0, Time elapsed: 0.047 sec [exec] [junit] Tests run: 30, Failures: 0, Errors: 0, Time elapsed: 0.25 sec [exec] [junit] Tests run: 18, Failures: 0, Errors: 0, Time elapsed: 0.125 sec [exec] [junit] Tests run: 10, Failures: 0, Errors: 0, Time elapsed: 0.093 sec [exec] [junit] Tests run: 5, Failures: 0, Errors: 0, Time elapsed: 0.015 sec [exec] [junit] Tests run: 8, Failures: 0, Errors: 0, Time elapsed: 0.327 sec [exec] [junit] Tests run: 6, Failures: 0, Errors: 0, Time elapsed: 0.016 sec [exec] [junit] Tests run: 21, Failures: 0, Errors: 0, Time elapsed: 0.016 sec [exec] [junit] Tests run: 16, Failures: 0, Errors: 0, Time elapsed: 1.295 sec [exec] [junit] Tests run: 30, Failures: 0, Errors: 0, Time elapsed: 0.015 sec [exec] [junit] Tests run: 37, Failures: 0, Errors: 0, Time elapsed: 0.343 sec [exec] [junit] Tests run: 12, Failures: 0, Errors: 0, Time elapsed: 0 sec [exec] [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0 sec [exec] [junit] Tests run: 16, Failures: 1, Errors: 0, Time elapsed: 0.187 sec [exec] [junit] TEST org.apache.harmony.text.tests.java.text.MessageFormatTest FAILED [exec] [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0 sec [exec] [junit] Tests run: 6, Failures: 0, Errors: 0, Time elapsed: 0.016 sec [exec] [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0 sec [exec] [junit] Tests run: 8, Failures: 0, Errors: 0, Time elapsed: 0.016 sec [exec] [junit] Tests run: 16, Failures: 0, Errors: 0, Time elapsed: 0.764 sec [exec] [junit] Tests run: 19, Failures: 0, Errors: 0, Time elapsed: 0.312 sec [exec] [junit] Tests run: 22, Failures: 0, Errors: 0, Time elapsed: 0 sec [exec] [junit] Tests FAILED snip -- 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]
[bild] linux failure
The linux build is failing as follows, I have not investigated: java.io.FileNotFoundException at org.apache.harmony.luni.platform.OSFileSystem.open(OSFileSystem.java:223) at java.io.FileOutputStream.init(FileOutputStream.java:92) at java.io.FileOutputStream.init(FileOutputStream.java:155) at java.util.logging.FileHandler.initOutputFiles(FileHandler.java:207) at java.util.logging.FileHandler.init(FileHandler.java:190) at java.util.logging.FileHandler.init(FileHandler.java:386) at org.apache.harmony.logging.tests.java.util.logging.FileHandlerTest.testInvalidParams(FileHandlerTest.java:453) at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:205) -- 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: [bild] linux failure
I can't. Vladimir Gorr wrote: I was able to successfully build on Linux for the recent sources. Thanks, Vladimir. On 7/17/06, Tim Ellison [EMAIL PROTECTED] wrote: The linux build is failing as follows, I have not investigated: java.io.FileNotFoundException at org.apache.harmony.luni.platform.OSFileSystem.open(OSFileSystem.java:223) at java.io.FileOutputStream.init(FileOutputStream.java:92) at java.io.FileOutputStream.init(FileOutputStream.java:155) at java.util.logging.FileHandler.initOutputFiles(FileHandler.java:207) at java.util.logging.FileHandler.init(FileHandler.java:190) at java.util.logging.FileHandler.init(FileHandler.java:386) at org.apache.harmony.logging.tests.java.util.logging.FileHandlerTest.testInvalidParams (FileHandlerTest.java:453) at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:205) -- 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] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [bild] linux failure
Oh, I can build, but tests don't pass. geir Vladimir Gorr wrote: I was able to successfully build on Linux for the recent sources. Thanks, Vladimir. On 7/17/06, Tim Ellison [EMAIL PROTECTED] wrote: The linux build is failing as follows, I have not investigated: java.io.FileNotFoundException at org.apache.harmony.luni.platform.OSFileSystem.open(OSFileSystem.java:223) at java.io.FileOutputStream.init(FileOutputStream.java:92) at java.io.FileOutputStream.init(FileOutputStream.java:155) at java.util.logging.FileHandler.initOutputFiles(FileHandler.java:207) at java.util.logging.FileHandler.init(FileHandler.java:190) at java.util.logging.FileHandler.init(FileHandler.java:386) at org.apache.harmony.logging.tests.java.util.logging.FileHandlerTest.testInvalidParams (FileHandlerTest.java:453) at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:205) -- 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] - 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] debug compilation as default
Mark Hindess wrote:
On 17 July 2006 at 15:34, Salikh Zakirov [EMAIL PROTECTED] wrote:
Ivan Volosyuk wrote:
I have already implemented it using ant variables, look at the latest
patch. You can use following notation with it:
ant -Dhy.cfg=release
Geir Magnusson Jr wrote:
Now we're getting somewhere.
I assume then I can put this into the build.properties that we'll be
adding Real Soon Now (as I can never remember command line args anyway...)
Please, please, do *not* introduce any more build.properties files.
The files that may need to be customized to get specific build
configuration should never be version-controlled. Besides, keeping
configuration files in the workspace means you cannot make your
configuration permanent. I see the properties files as anti-usable.
I'll let Geir speak for himself, but I think he was alluding to the use
of a user properties file:
property file=${user.home}/.harmony.properties /
that would *not* be checked in and would be read (if it existed or
ignored otherwise).
yes, but more than that - having configuration sets that could be
re-used is also a goal.
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: Solution on Harmony-815 (was Re: [jira] Commented: (HARMONY-815) [classlib][nio] Refine implConfigureBlocking(boolean) method of DatagramChannel and SocketChannel.)
On 7/17/06, David Tanzer [EMAIL PROTECTED] wrote:
On 17.07.2006, at 14:09, Richard Liang wrote:
LvJimmy,Jing wrote:
Hi Andrew:
Sorry for late, but as this solution does not resolve I18N (working
aound for 815 only?) , I guess we may have another way.
If I understand correctly, this solution try to analysis error
code in
native code, throws ErrorCodeException; and java code catch this
exception,
get error code, and throw another exception.
If so, why not just return the error code directly instead? :)
Hello Jimmy,
IIRC, It's SocketException that is thrown in native code, not
ErrorCodeException. And we will set the ErrorCodeException as cause
of the SocketException.
Yes, this is how I remember it too. The idea was to do the equivalent
of the
following code in the native code (correct me if I'm wrong):
ErrorCodeException ece = new ErrorCodeException(SOME_ERROR_CODE);
throw new SocketException(Some Message, ece);
I don't think it is semantically correct to set the
ErrorCodeException as the cause
of the SocketException - the error code provides additional info, it
is not the cause
of the problem. For example, this code:
try {
ErrorCodeException ece = new ErrorCodeException(13);
throw new TestException(Something went wrong, ece);
} catch(TestException e) {
e.printStackTrace();
}
Yields the following stack trace:
net.guglhupf.test.TestException: Something went wrong
at net.guglhupf.test.ExceptionTest.main(ExceptionTest.java:7)
Caused by: Error Code 13
at net.guglhupf.test.ExceptionTest.main(ExceptionTest.java:6)
which might be confusing for some application developer so personally
I like the subclass - approach described by Andrew Zhang [1] better.
David, thank you :)
I don't know whether exception compatibility guideline allows to throw
subclass of SocketException. IIRC, if we can throw exact exception as spec
and RI, then we have no reason to throw its subclass.
Regards,
David
[1] http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/
200607.mbox/%
[EMAIL PROTECTED]
I18N is anther issue, we shall have full discussion in community to
mature our thoughts. :-)
Do I miss something?
Best regards,
Richard.
2006/7/14, Mikhail Loenko [EMAIL PROTECTED]:
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
Re: [drlvm] Status of drlvm
Geir Magnusson Jr wrote: Without HARMONY-898, DRLVM segfaults after reading NULL from TLS. Without HARMONY-853, DRLVM segfaults in libhyzlib.so on Linux. Odd - I don't think I have those problems, since the tests that do run pass on my box. Adding a test to show this would be good. The hythr issue is not predictable, and may or may not work properly. I think that you've got correct hythr in deploy directory, and haven't done any rebuilds since then. Or maybe the build system chooses which hythr to take in some magic manner, that I cannot grasp. The easiest way to reproduce hythr issue on Windows (that's how I've come across it) is to check out and build fresh classlib, and rebuild DRLVM incrementally. In any case, having two hythr.dlls copied to a single locations is definitely a case of race condition with unpredictable result. I'd like to see us figure out the hythr problem, since 898 is a hack to just work around what seems to be an important issue. can we grind this one out? A couple of words in defense of HARMONY-898. The classlib doesn't depend on a particular hythr implementation. In fact, it depends on hythr *interface*, which must be implemented somewhere in the system. At the same time, classlib provides its own hythr implementation. DRLVM itself reimplements the subset of hythr interface, thus making possible interoperation with classlib, but doesn't uses classlib's hythr implementation. So, this is not the case of classlib wants hythr1, and drlvm wants hythr2, and hythr1 and hythr2 conflicts. In fact, this is classlib wants some hythr, and provides hythr1. DLRVM provides hythr2, and conflicts with hythr1. Thus, IMHO, the issue is not as important as it may seem, because there is no issue on who provides hythr, but there is an issue of competing hythr implementations, one of which comes with with DRLVM and works with it, and the other probably works with J9 (I have never checked it myself). The zlib seems reasonable, I guess. 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] Status of drlvm
Salikh Zakirov wrote: Geir Magnusson Jr wrote: I'd like to see us figure out the hythr problem, since 898 is a hack to just work around what seems to be an important issue. can we grind this one out? A couple of words in defense of HARMONY-898. The classlib doesn't depend on a particular hythr implementation. In fact, it depends on hythr *interface*, which must be implemented somewhere in the system. At the same time, classlib provides its own hythr implementation. DRLVM itself reimplements the subset of hythr interface, thus making possible interoperation with classlib, but doesn't uses classlib's hythr implementation. So, this is not the case of classlib wants hythr1, and drlvm wants hythr2, and hythr1 and hythr2 conflicts. In fact, this is classlib wants some hythr, and provides hythr1. DLRVM provides hythr2, and conflicts with hythr1. Thus, IMHO, the issue is not as important as it may seem, because there is no issue on who provides hythr, but there is an issue of competing hythr implementations, one of which comes with with DRLVM and works with it, and the other probably works with J9 (I have never checked it myself). This is darn important. We have two implementations of the same thing, and based on build order, we get differing results. Clearly, one implementation is *wrong*. Either : 0) Classlib implements hythread in entirety, and VM uses that. 1) Classlib implements hythread and maybe asks the VM to provide implementations for some stubs (like we do w/ kernel classes for the classlib) 2) Classlib depends entirely on the VM to provide. If there's a difference of opinion on how it should be implemented, or what functionality should be in there, lets have this out and sooner than later... 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] debug compilation as default
Mark Hindess wrote:
I'll let Geir speak for himself, but I think he was alluding to the use
of a user properties file:
property file=${user.home}/.harmony.properties /
that would *not* be checked in and would be read (if it existed or
ignored otherwise).
Which is exactly what you can achieve in a platform-independent way with
a property file as described above.
This solution is okay with me.
And by the way, the solution to run 'HY_CFG=xyz ant' with
corresponding
property environment=env/
condition property='hy.cfg' value='${env.HY_CFG}'
isset property=env.HY_CFG/
/condition
worked perfectly for the DRLVM builds on Windows. What's more,
it is *compatible* with 'ant -Dhy.cfg=...' syntax.
I have not heard any specific concerns why this can't be used.
Read the list archive. Environment variables are platform-specific and
differ - if they exist - from platform to platform. Windows for example
treats environment variable names as case-insensitive but when ant reads
them from env.VaR you must get the case exactly right. Ant properties
are platform-independent and so will work the same everywhere.
I have read the discussion, and still consider this as non-issue,
because anyone can be careful enough to define the name in correct case.
(So one must define the variable in proper case as HY_CFG even on Windows)
In my practice, environment variables worked fine on Windows.
And I have not heard a single report on how environment variables failed in
real life.
I have only seen discussion how this *may* fail if the user is not careful
enough
to do precisely what is written in instruction.
Still unconvinced why we can't allow careful users to use environment
variables for configuration.
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Fwd: MMTk re-org prelim release]
All, It looks like vmmagic Address.add() has been renamed Address.plus(). The MMTk port is very much blocked until jitrino.jet supports all the unboxed vmmagic functions. Alex --- can you fix this soon and post a JIRA patch? Below are the pointers to the latest MMTk code. On 7/13/06, Steve Blackburn [EMAIL PROTECTED] wrote: Hi Weldon, Please let me know if you have any queries. You should find everyhting you need inside the jar (as well as being able to run against it). You should be able to slurp it into Eclipse and edit it there without any problems. I suggest you start by looking at src/org/mmtk/vm/* Then to see a concrete example, look at ext/vm/JikesRVM/com/ibm/JikesRVM/mm/mmtk/ THis directory has concrete instances of the abstract classes in the previous directory. Cheers, --Steve -- Forwarded message -- From: Steve Blackburn [EMAIL PROTECTED] To: [EMAIL PROTECTED] Date: Fri, 14 Jul 2006 00:48:53 +1000 Subject: MMTk re-org prelim release Hi, For those interested in the pending reorganization of MMTk, I have finished the re-org and created a jar and a patch against Jikes RVM. The plan is to commit this to the cvs head as soon as the 2.4.5 release has been made (as long as everyone is happy with it ;-). http://cs.anu.edu.au/~Steve.Blackburn/private/mmtk-20060714.jar http://cs.anu.edu.au/~Steve.Blackburn/private/mmtk-reorg.patch.gz The most significant change is in the way MMTk interfaces to the VM. In essence it is now a lot cleaner and the interface is properly checked. If you don't care about MM-VM interfaces, then that's all you need to know, probably. Previously we used stubs comprising classes with static methods. The JVM provided classes which aliased (replaced) these, and there was no consistency checking between the two. We used static methods for performance reasons. We now define our requirements of the VM through a set of abstract classes in org.mmtk.vm. The VM implementor is then obliged to create final subclasses of these with the appropriate functionality. We lean on the opt compiler and static initialization to make sure we don't loose performance. The subclasses are accessed by MMTk by reflectively creating singleton instances of each class at build time (using the value of the system property: mmtk.hostjvm), and then invoking methods on these. So for example, I have now put the Jikes RVM bindings in a new package called com.ibm.JikesRVM.mm.mmtk (previously they aliased org.mmtk.vm). Jikes RVM's opt compiler is smart enough to realize these are run-time constant and inline etc. I have done some fairly careful performance analysis and it seems to make no difference to performance. I'll do some more between now and when we commit it. The magic to make this happen is mostly in org.mmtk.vm.VM. If anyone is interested or has feedback, I'm happy to discuss it further. Cheers, --Steve -- 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] Status of drlvm
On 7/17/06, Salikh Zakirov [EMAIL PROTECTED] wrote: Hi, Can anyone share their experience on running DRLVM built from SVN? On my workstations, it requires several fixes in order to run properly: HARMONY-898 'workaround to get correct hythr.dll' (both for Linux and Windows) HARMONY-853 'DRLVM+classlib segfaults in hyzlib' (on Linux) Without HARMONY-898, DRLVM segfaults after reading NULL from TLS. Without HARMONY-853, DRLVM segfaults in libhyzlib.so on Linux. I would suggest that the patches from HARMONY-898 and HARMONY-853 be applied, because DRLVM doesn't work at all for me without these fixes. Any other experiences? Is anyone besides me running DRLVM from SVN? I've built the DRLVM on Linux for the following cases: 1. w/o patches listed above; 2. w/ H-898 patch; 3. w/ H-898 H-853 patches. 'Segmentation fault' occurs for all cases, unfortunately. Thanks, Vladimir. - 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] debug compilation as default
Salikh Zakirov wrote:
Mark Hindess wrote:
I'll let Geir speak for himself, but I think he was alluding to the use
of a user properties file:
property file=${user.home}/.harmony.properties /
that would *not* be checked in and would be read (if it existed or
ignored otherwise).
Which is exactly what you can achieve in a platform-independent way with
a property file as described above.
This solution is okay with me.
That's not a solution. It's what people do to personalize. I'm
targeted at normalizing how we handle configuration properties.
And by the way, the solution to run 'HY_CFG=xyz ant' with
corresponding
property environment=env/
condition property='hy.cfg' value='${env.HY_CFG}'
isset property=env.HY_CFG/
/condition
worked perfectly for the DRLVM builds on Windows. What's more,
it is *compatible* with 'ant -Dhy.cfg=...' syntax.
I have not heard any specific concerns why this can't be used.
Read the list archive. Environment variables are platform-specific and
differ - if they exist - from platform to platform. Windows for example
treats environment variable names as case-insensitive but when ant reads
them from env.VaR you must get the case exactly right. Ant properties
are platform-independent and so will work the same everywhere.
I have read the discussion, and still consider this as non-issue,
because anyone can be careful enough to define the name in correct case.
(So one must define the variable in proper case as HY_CFG even on Windows)
The point is that we want to reduce the number of places that things can
get broken...
In my practice, environment variables worked fine on Windows.
And I have not heard a single report on how environment variables failed in
real life.
I have only seen discussion how this *may* fail if the user is not careful
enough
to do precisely what is written in instruction.
Still unconvinced why we can't allow careful users to use environment
variables for configuration.
because as a matter of engineering practice, you want to reduce the
number of places that errors can happen, and increase the amount of
easily reusable configuration.
Notice how you keep saying can be careful enough or allow careful
users
We can make it easier to work with Harmony, I believe, by removing the
'extra care' requirement when possible.
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: [announce] New Apache Harmony Committer : Paulex Yang
This is fantastic news. Congratulations Paulex. Best regards, George Geir Magnusson Jr wrote: Please join the Apache Harmony PPMC in welcoming the project's newest committer, Paulex Yang. Mark has demonstrated the elements that help build a healthy community, namely his ability to work together with others, continued dedication to the project, an understanding of our overall goals of the project, and a really unnatural and probably unhealthy focus on nio :) We all continue to expect great things from him. Mark, as a first step to test your almighty powers of committership, please update the committers page on the website. That should be a good (and harmless) exercise to test if everything is working. Things to do : 1) test ssh-ing to the server people.apache.org. 2) Change your login password on the machine as per the account email 3) Add a public key to .ssh so you can stop using the password 4) Change your svn password as described in the account email At this point, you should be good to go. Checkout the website from svn and update it. See if you can figure out how. Also, for your main harmony/enhanced/classlib/trunk please be sure that you have checked out via 'https' and not 'http' or you can't check in. You can switch using svn switch. (See the manual) Finally, although you now have the ability to commit, please remember : 1) continue being as transparent and communicative as possible. You earned committer status in part because of your engagement with others. While it was a have to situation because you had to submit patches and defend them, but we believe it is a want to. Community is the key to any Apache project. 2)We don't want anyone going off and doing lots of work locally, and then committing. Committing is like voting in Chicago - do it early and often. Of course, you don't want to break the build, but keep the commit bombs to an absolute minimum, and warn the community if you are going to do it - we may suggest it goes into a branch at first. Use branches if you need to. 3) Always remember that you can **never** commit code that comes from someone else, even a co-worker. All code from someone else must be submitted by the copyright holder (either the author or author's employer, depending) as a JIRA, and then follow up with the required ACQs and BCC. Again, thanks for your hard work so far, and welcome. The Apache Harmony PPMC - 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] debug compilation as default
+1 for property files.
The one of the main benefits for me is the possibility to define all
the needed properties just once. But not execute a huge number of set
SMTH and set ANOTHERTHING each time I open a new window or reboot
my machine.
That's why it is better to get proxy info from property file instead
of setting ANT_OPTS variable :)
http://issues.apache.org/jira/browse/HARMONY-523
SY, Alexey
2006/7/17, Geir Magnusson Jr [EMAIL PROTECTED]:
Salikh Zakirov wrote:
Mark Hindess wrote:
I'll let Geir speak for himself, but I think he was alluding to the use
of a user properties file:
property file=${user.home}/.harmony.properties /
that would *not* be checked in and would be read (if it existed or
ignored otherwise).
Which is exactly what you can achieve in a platform-independent way with
a property file as described above.
This solution is okay with me.
That's not a solution. It's what people do to personalize. I'm
targeted at normalizing how we handle configuration properties.
And by the way, the solution to run 'HY_CFG=xyz ant' with
corresponding
property environment=env/
condition property='hy.cfg' value='${env.HY_CFG}'
isset property=env.HY_CFG/
/condition
worked perfectly for the DRLVM builds on Windows. What's more,
it is *compatible* with 'ant -Dhy.cfg=...' syntax.
I have not heard any specific concerns why this can't be used.
Read the list archive. Environment variables are platform-specific and
differ - if they exist - from platform to platform. Windows for example
treats environment variable names as case-insensitive but when ant reads
them from env.VaR you must get the case exactly right. Ant properties
are platform-independent and so will work the same everywhere.
I have read the discussion, and still consider this as non-issue,
because anyone can be careful enough to define the name in correct case.
(So one must define the variable in proper case as HY_CFG even on Windows)
The point is that we want to reduce the number of places that things can
get broken...
In my practice, environment variables worked fine on Windows.
And I have not heard a single report on how environment variables failed in
real life.
I have only seen discussion how this *may* fail if the user is not careful
enough
to do precisely what is written in instruction.
Still unconvinced why we can't allow careful users to use environment
variables for configuration.
because as a matter of engineering practice, you want to reduce the
number of places that errors can happen, and increase the amount of
easily reusable configuration.
Notice how you keep saying can be careful enough or allow careful
users
We can make it easier to work with Harmony, I believe, by removing the
'extra care' requirement when possible.
geir
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Alexey A. Petrenko
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: [classlib] debug compilation as default
On 7/17/06, Salikh Zakirov [EMAIL PROTECTED] wrote: Still unconvinced why we can't allow careful users to use environment variables for configuration. +1 We used that environment variables through out all the drlvm development - no single problem. Btw, FYI: Salikh is the author of previous build system which was used by drlvm before massive movement to the ant based unified build system of drlvm which is used now. -- Ivan - 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 conventions - a proposal
Andrew Zhang wrote:
On 7/14/06, George Harley [EMAIL PROTECTED] wrote:
Hi,
If annotations were to be used to help us categorise tests in order to
simplify the definition of test configurations - what's included and
excluded etc - then a core set of annotations would need to be agreed by
the project. Consider the possibilities that the TestNG @Test
annotation offers us in this respect.
First, if a test method was identified as being broken and needed to be
excluded from all test runs while awaiting investigation then it would
be a simple matter of setting its enabled field like this:
@Test(enabled=false)
public void myTest() {
...
}
Temporarily disabling a test method in this way means that it can be
left in its original class and we do not have to refer to it in any
suite configuration (e.g. in the suite xml file).
If a test method was identified as being broken on a specific platform
then we could make use of the groups field of the @Test type by making
the method a member of a group that identifies its predicament.
Something like this:
@Test(groups={state.broken.win.IA32})
public void myOtherTest() {
...
}
The configuration for running tests on Windows would then specifically
exclude any test method (or class) that was a member of that group.
Making a test method or type a member of a well-known group (well-known
in the sense that the name and meaning has been agreed within the
project) is essentially adding some descriptive attributes to the test.
Like adjectives (the groups) and nouns (the tests) in the English
language.
It's the same in the Chinese language. :)
To take another example, if there was a test class that
contained methods only intended to be run on Windows and that were all
specific to Harmony (i.e. not API tests) then one could envisage the
following kind of annotation:
@Test(groups={type.impl, os.win.IA32})
public class MyTestClass {
public void testOne() {
...
}
public void testTwo() {
...
}
@Test(enabled=false)
public void brokenTest() {
...
}
}
Here the annotation on MyTestClass applies to all of its test methods.
So what are the well-known TestNG groups that we could define for use
inside Harmony ? Here are some of my initial thoughts:
* type.impl -- tests that are specific to Harmony
* state.broken.platform id -- tests bust on a specific platform
* state.broken -- tests broken on every platform but we want to decide
whether or not to run from our suite configuration
* os.platform id -- tests that are to be run only on the specified
platform (a test could be member of more than one of these)
Hi George, I have a small question.
Is os.platform id duplicate of state.broken.platform id?
Does os.platform.id equals state.broken.other platform ids? ( os.
platform.ids = all platforms - state.broken.platform ids)
Hi Andrew,
The way I see it, membership of the group os.platform id (e.g.
os.win.IA32) means that the annotated type - class or method - is
being flagged as specific to the identified platform. So, for instance
the following annotation on a test class means it should only be run on
the Win 32 platform:
@Test(groups={os.win.IA32})
public class Foo {
...various test methods...
}
The annotation state.broken.platform id (e.g. state.broken.win.IA32)
flags a test or entire test class as being broken *only* on the
identified platform. The test is intended to be run everywhere but has
been identified as failing on certain platforms. So, for instance, if
there was a test in the NIO module that that should be run everywhere
but failed on Linux then that test method could be annotated as:
@Test(groups={state.broken.linux.IA32})
public void testBaa() {
...
}
It is then simple to ensure that when the NIO tests are run on Windows
that the above test *is* included but when run on Linux it is
specifically *excluded* because it is broken on that platform.
To my mind, there is a big distinction between having platform-specific
tests (membership of a group os.*) and having tests that are intended to
be run everywhere but are in fact broken on one or more platforms
(membership of a group state.broken.*).
Best regards,
George
What does everyone else think ? Does such a scheme sound reasonable ?
+0.02$. I can't wait to see these annotations in Harmony. :)
I also have found some platform-dependent tests in NIO module. Looking
forward to deal with them when TestNG is integrated. :)
Thanks for reading this far.
Best regards,
George
George Harley wrote:
Hi,
Just seen Tim's note on test support classes and it really caught my
attention as I have been mulling over this issue for a little while
now. I think that it is a good time for us to return to the topic of
class library test layouts.
The current proposal [1] sets out to segment our different types of
test by placing them in different file locations. After looking at the
recent changes
Re: [classlib] debug compilation as default
Alexey Petrenko wrote: +1 for property files. The one of the main benefits for me is the possibility to define all the needed properties just once. But not execute a huge number of set SMTH and set ANOTHERTHING each time I open a new window or reboot my machine. That's why it is better to get proxy info from property file instead of setting ANT_OPTS variable :) http://issues.apache.org/jira/browse/HARMONY-523 It looks like the issue boils down to difference in habits. The java types prefer property files, because it saves them from working with incomprehensible environment variables and so on. But then, I am unix type, and having correctly defined environment is essential to me. I just keep my .profile file up-to-date, and don't care about setting it in a new window. It gets configured automatically. And I hate property files, because they cannot be configured in one central place, and I have to keep copying them over and over, and quickly get lost in a multitude of unsynchronized copies. Just another case of computing cultural differences. Anyway, I will lowly follow what the majority will decide as appropriate. - 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] debug compilation as default
Ivan Volosyuk wrote: On 7/17/06, Salikh Zakirov [EMAIL PROTECTED] wrote: Still unconvinced why we can't allow careful users to use environment variables for configuration. +1 We used that environment variables through out all the drlvm development - no single problem. Btw, FYI: Salikh is the author of previous build system which was used by drlvm before massive movement to the ant based unified build system of drlvm which is used now. is that old one still around? Does it use make? :) 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] debug compilation as default
Salikh Zakirov wrote: Alexey Petrenko wrote: +1 for property files. The one of the main benefits for me is the possibility to define all the needed properties just once. But not execute a huge number of set SMTH and set ANOTHERTHING each time I open a new window or reboot my machine. That's why it is better to get proxy info from property file instead of setting ANT_OPTS variable :) http://issues.apache.org/jira/browse/HARMONY-523 It looks like the issue boils down to difference in habits. The java types prefer property files, because it saves them from working with incomprehensible environment variables and so on. Please. They are not incomprehensible. They are not portable, nor generally repeatable or visible as a reusable artifact. I've been a C type for about twice as long as I've been a Java type, and I'll point out that we C type people also prefer things in files, ex makefiles and scripts. But then, I am unix type, and having correctly defined environment is essential to me. I just keep my .profile file up-to-date, and don't care about setting it in a new window. It gets configured automatically. How do you do A/B test for different configurations? Different logins? Maybe reboot to another OS partition? And I hate property files, because they cannot be configured in one central place, and I have to keep copying them over and over, and quickly get lost in a multitude of unsynchronized copies. I'm sorry - I don't get it. Property files can *certainly* be configured in one central place, and there is no reason to copy over and over. As for unsynchronized copies, I think that comes down to work habit... Just another case of computing cultural differences. I don't think so. I've been a unix user and C programmer since the mid 1980's, and this has nothing to do w/ unix. 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: [announce] New Apache Harmony Committer : Paulex Yang
Congratulations Paulex. Geir Magnusson Jr wrote: Please join the Apache Harmony PPMC in welcoming the project's newest committer, Paulex Yang. Mark has demonstrated the elements that help build a healthy community, namely his ability to work together with others, continued dedication to the project, an understanding of our overall goals of the project, and a really unnatural and probably unhealthy focus on nio :) We all continue to expect great things from him. Mark, as a first step to test your almighty powers of committership, please update the committers page on the website. That should be a good (and harmless) exercise to test if everything is working. Things to do : 1) test ssh-ing to the server people.apache.org. 2) Change your login password on the machine as per the account email 3) Add a public key to .ssh so you can stop using the password 4) Change your svn password as described in the account email At this point, you should be good to go. Checkout the website from svn and update it. See if you can figure out how. Also, for your main harmony/enhanced/classlib/trunk please be sure that you have checked out via 'https' and not 'http' or you can't check in. You can switch using svn switch. (See the manual) Finally, although you now have the ability to commit, please remember : 1) continue being as transparent and communicative as possible. You earned committer status in part because of your engagement with others. While it was a have to situation because you had to submit patches and defend them, but we believe it is a want to. Community is the key to any Apache project. 2)We don't want anyone going off and doing lots of work locally, and then committing. Committing is like voting in Chicago - do it early and often. Of course, you don't want to break the build, but keep the commit bombs to an absolute minimum, and warn the community if you are going to do it - we may suggest it goes into a branch at first. Use branches if you need to. 3) Always remember that you can **never** commit code that comes from someone else, even a co-worker. All code from someone else must be submitted by the copyright holder (either the author or author's employer, depending) as a JIRA, and then follow up with the required ACQs and BCC. Again, thanks for your hard work so far, and welcome. The Apache Harmony PPMC - 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: [bild] linux failure
Ok, I understand why. I'll either fix, or post an item for discussion re the fix. I think Nathan owes us a beer. geir Tim Ellison wrote: Sorry, yes I meant the test run. Regards, Tim Geir Magnusson Jr wrote: Oh, I can build, but tests don't pass. geir Vladimir Gorr wrote: I was able to successfully build on Linux for the recent sources. Thanks, Vladimir. On 7/17/06, Tim Ellison [EMAIL PROTECTED] wrote: The linux build is failing as follows, I have not investigated: java.io.FileNotFoundException at org.apache.harmony.luni.platform.OSFileSystem.open(OSFileSystem.java:223) at java.io.FileOutputStream.init(FileOutputStream.java:92) at java.io.FileOutputStream.init(FileOutputStream.java:155) at java.util.logging.FileHandler.initOutputFiles(FileHandler.java:207) at java.util.logging.FileHandler.init(FileHandler.java:190) at java.util.logging.FileHandler.init(FileHandler.java:386) at org.apache.harmony.logging.tests.java.util.logging.FileHandlerTest.testInvalidParams (FileHandlerTest.java:453) at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:205) -- 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] - 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:
On 7/13/06, Tim Ellison [EMAIL PROTECTED] wrote:
Andrey Chernyshev wrote:
snip
(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.
How the string _org.apache.harmony.vmi.portlib which is passed to VM
as an argument maps to a function table created by launcher? On VM
side, I guess I'm getting only that string from the launcher about the
portlib, nothing else...
The _org.apache.harmony.vmi.portlib option is passed to the VM
as a JavaVMOption struct (defined in jni.h) that looks like:
typedef struct JavaVMOption
{
char *optionString;
void *extraInfo;
} JavaVMOption;
When the launcher passes the _org.apache.harmony.vmi.portlib option
to the VM it sets optionString to be _org.apache.harmony.vmi.portlib
and extraInfo to be the pointer to the port library. We can see this in
modules/luni/src/main/native/launcher/shared/main.c:
options[j].optionString = portLibOptionStr;
options[j].extraInfo = portLibrary;
So, on the VM side, once you find the JavaVMOption that has
optionString==_org.apache.harmony.vmi.portlib, then its extraInfo
field will contain the relevant port library pointer.
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.
So it sounds like the launcher creates portlib, passes it to VM and
then expects it to be returned back from VM. What's the purpose of
doing that?
Kind of... Remember that the launcher isn't technically part of the
class library native code (it really should be completely separate
from classlib - what happened to the plan to move it out of classlib?).
So what actually happens is that the launcher creates a port library
and passes it to the VM. The VM stores this portlib pointer away
somewhere for future use.
One of the VMI functions provided by the VM is GetPortLibrary()
(the VMInterfaceFunctions struct is declared in
modules/luni/src/main/native/include/shared/vmi.h). So when the
Harmony classlib natives call this function they expect to receive
a pointer to an HyPortLibrary from the VM- since the VM has
already been given one by the launcher, it can just return that one.
Shall we consider the portlib as a part of classlib or VM? If the
classlib is responsible for instantiation of the portlib, then why
the classlib should be expecting to get it once again from VM? I'm
sure there must be some tricks there which I'm not getting yet...
I hope that what Ive described above might clarify things slightly -
that the portlib is created by the launcher, which isn't really part
of the classlib, then passed to the VM to be given to the classlib
upon request in the future.
Regards,
Oliver
Thanks,
Andrey.
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 a more graceful way to do this.
Good work Andrey, keep sending the questions and patches!
Regards,
Tim
Thanks,
Andrey.
On 7/11/06, Andrey Chernyshev [EMAIL PROTECTED] wrote:
OK, so I'm going to add CreateJavaVM into vm\vmcore\src\jni\jni.cpp
and also add implementation into DestroyVM (stub is already seem
to be
present there) based on destroy_vm(). Then we'll see how it works
with
the launcher.
Thanks,
Andrey.
On 7/11/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote:
This has been my thinking - even if not perfect, lets get it
working
using the launcher and then fix as required. It's arguable if that
brokenness matters at this point, and I think that there's
plenty to
be gained from having it work via the launcher.
geir
Rana Dasgupta wrote:
create_vm() looks quite close/complete to being a complete
prototype for
CreateJavaVM,
but I think more work is needed in DestroyVM which prototypes
DestroyJavaVM
for functional completeness. It is non waiting on user
threads, it
does not
send the corresponding JVMTI shutdown events, I also don't
know if it
handles shutdown hooks cleanly ( but these may not be critical
right now
for hooking up to the launcher ). What do you think?
When I ran a non trivial test.. upto 32 threads instantiating a
very large
number of objects with-XcleanupOnExit
Re: [classlib] debug compilation as default
On 7/17/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: Ivan Volosyuk wrote: On 7/17/06, Salikh Zakirov [EMAIL PROTECTED] wrote: Still unconvinced why we can't allow careful users to use environment variables for configuration. +1 We used that environment variables through out all the drlvm development - no single problem. Btw, FYI: Salikh is the author of previous build system which was used by drlvm before massive movement to the ant based unified build system of drlvm which is used now. is that old one still around? Does it use make? :) Yes, it does use make both on windows (cygwin is required) and linux. It was removed completly from work tree, but can be possibly restored from archives. It can be out dated for now and also require some paperwork to be done. -- Ivan - 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
IMHO since even BEA VM behave differently in this case we may qualify
this as a low-priority task, rise non-bug JIRA and postpone it until
we meet the real-world app that relies on this. Do nothing is better
than do something that we aren't really sure we should do. :)
Regards,
2006/7/17, Richard Liang [EMAIL PROTECTED]:
Vladimir Gorr wrote:
In this case I'd like to understand what behaviour is correct
and what should be made to satisfy the users. I have no any preference.
Hello Vladimir,
I think all of us agree that it's possible to following RI's behavior,
Right? The question is we shall decide to follow or not. Any suggestion?
Thanks a lot.
Best regards,
Richard.
Thanks,
Vladimir.
On 7/14/06, Alexei Zakharov [EMAIL PROTECTED] wrote:
Vladimir wrote:
(I believe Alexey used it to test. *Or J9 nevertheless*? IMHO it needs
to
specify when same discussions start).
I have tried both. And both differ from RI.
Richard wrote:
For getDeclaredMethods(), J9 has the same behavior as RI.
Well, there are some nuances nevertheless. I have wrote a small test
(that was close to my orginal test) and ran it on four different VMs.
The test simply does TestBean.class.getDeclaredMethods() and prints
the resulting array.
TestBean.java:
class TestBean {
String methodCalled = null;
public void method(Integer i) {
methodCalled = method1;
}
public void method(int i) {
methodCalled = method2;
}
public void method(boolean b) {
methodCalled = method3;
}
public void method(Boolean b) {
methodCalled = method4;
}
}
The results:
RI (Sun 1.5.0_05)
method int
method boolean
method java.lang.Boolean
method java.lang.Integer
j9 v3
method java.lang.Integer
method int
method boolean
method java.lang.Boolean
DLRVM
method java.lang.Integer
method int
method boolean
method java.lang.Boolean
jrockit-R26.3.0-jdk1.5.0_06
method java.lang.Boolean
method boolean
method int
method java.lang.Integer
With Best Regards,
2006/7/14, Richard Liang [EMAIL PROTECTED]:
Geir Magnusson Jr wrote:
Alexey Varlamov 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).
What does j9 do?
For getDeclaredMethods(), J9 has the same behavior as RI. For
getMethods, J9 and RI behave differently. ;-) But it's not so hard
to summarize RI's rule of method order. Am I wrong?
Best regards,
Richard
I believe we need a bit stronger motivation for scratching this
issue,
than a blunt testcase - some real-world application.
I agree that this isn't a critical issue, but a nice to have.
Maybe
we see what J9 does, and follow the majority (if we spend the
time...)?
geir
--
Richard Liang
China Software Development Lab, IBM
--
Alexei Zakharov,
Intel Middleware Product Division
--
Richard Liang
China Software Development Lab, IBM
--
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 mean this should have about the same priority with the toString()
conversion task discussed in adjacent thread IMHO.
2006/7/17, Alexei Zakharov [EMAIL PROTECTED]:
IMHO since even BEA VM behave differently in this case we may qualify
this as a low-priority task, rise non-bug JIRA and postpone it until
we meet the real-world app that relies on this. Do nothing is better
than do something that we aren't really sure we should do. :)
Regards,
2006/7/17, Richard Liang [EMAIL PROTECTED]:
Vladimir Gorr wrote:
In this case I'd like to understand what behaviour is correct
and what should be made to satisfy the users. I have no any preference.
Hello Vladimir,
I think all of us agree that it's possible to following RI's behavior,
Right? The question is we shall decide to follow or not. Any suggestion?
Thanks a lot.
Best regards,
Richard.
Thanks,
Vladimir.
On 7/14/06, Alexei Zakharov [EMAIL PROTECTED] wrote:
Vladimir wrote:
(I believe Alexey used it to test. *Or J9 nevertheless*? IMHO it needs
to
specify when same discussions start).
I have tried both. And both differ from RI.
Richard wrote:
For getDeclaredMethods(), J9 has the same behavior as RI.
Well, there are some nuances nevertheless. I have wrote a small test
(that was close to my orginal test) and ran it on four different VMs.
The test simply does TestBean.class.getDeclaredMethods() and prints
the resulting array.
TestBean.java:
class TestBean {
String methodCalled = null;
public void method(Integer i) {
methodCalled = method1;
}
public void method(int i) {
methodCalled = method2;
}
public void method(boolean b) {
methodCalled = method3;
}
public void method(Boolean b) {
methodCalled = method4;
}
}
The results:
RI (Sun 1.5.0_05)
method int
method boolean
method java.lang.Boolean
method java.lang.Integer
j9 v3
method java.lang.Integer
method int
method boolean
method java.lang.Boolean
DLRVM
method java.lang.Integer
method int
method boolean
method java.lang.Boolean
jrockit-R26.3.0-jdk1.5.0_06
method java.lang.Boolean
method boolean
method int
method java.lang.Integer
With Best Regards,
2006/7/14, Richard Liang [EMAIL PROTECTED]:
Geir Magnusson Jr wrote:
Alexey Varlamov 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).
What does j9 do?
For getDeclaredMethods(), J9 has the same behavior as RI. For
getMethods, J9 and RI behave differently. ;-) But it's not so hard
to summarize RI's rule of method order. Am I wrong?
Best regards,
Richard
I believe we need a bit stronger motivation for scratching this
issue,
than a blunt testcase - some real-world application.
I agree that this isn't a critical issue, but a nice to have.
Maybe
we see what J9 does, and follow the majority (if we spend the
time...)?
geir
--
Richard Liang
China Software Development Lab, IBM
--
Alexei Zakharov,
Intel Middleware Product Division
--
Richard Liang
China Software Development Lab, IBM
--
Alexei Zakharov,
Intel Middleware Product Division
[classlib][logging] Test Failures - FileHandlerTest (was Re: [bild] linux failure)
Ok, the problem is that we're including FileHandlerTest, there are a few bugs (maybe) and our implementation differs from the RI, and the failure is platform dependent to boot. First bug, in FileHandlerTest.testInvalidParams() we have things like : // %t and %p parsing can add file separate automatically FileHandler hl = new FileHandler(%taaa); First problem is that our implemention *doesn't* add the separator, so the result is that logging is trying to create (on linux) /tmpaaa and given that my root dir is locked down (and I don't run as root!), creating that file failed. On my windows box, this passed because java.io.tmpdir ends w/ a separator, so it creates the thing as expected. Now, the RI on linux puts in the separator, so the result is /tmp/aaa Reading the spec, this is not what I expected, as there is a separator / defined, and all examples use it, and nothing is said about it. So, we can either fix the test, or given that the RI does behave beyond the spec (and adds the separator), I suppose that we should just simply add a separator in the implementation for %t and %h? geir Geir Magnusson Jr wrote: Ok, I understand why. I'll either fix, or post an item for discussion re the fix. I think Nathan owes us a beer. geir Tim Ellison wrote: Sorry, yes I meant the test run. Regards, Tim Geir Magnusson Jr wrote: Oh, I can build, but tests don't pass. geir Vladimir Gorr wrote: I was able to successfully build on Linux for the recent sources. Thanks, Vladimir. On 7/17/06, Tim Ellison [EMAIL PROTECTED] wrote: The linux build is failing as follows, I have not investigated: java.io.FileNotFoundException at org.apache.harmony.luni.platform.OSFileSystem.open(OSFileSystem.java:223) at java.io.FileOutputStream.init(FileOutputStream.java:92) at java.io.FileOutputStream.init(FileOutputStream.java:155) at java.util.logging.FileHandler.initOutputFiles(FileHandler.java:207) at java.util.logging.FileHandler.init(FileHandler.java:190) at java.util.logging.FileHandler.init(FileHandler.java:386) at org.apache.harmony.logging.tests.java.util.logging.FileHandlerTest.testInvalidParams (FileHandlerTest.java:453) at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:205) -- 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] - 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]
[DRLVM] MMTk porting status + where should we put DRLVM/MMTk porting files?
All, The latest version of MMTk source code was downloaded from http://cs.anu.edu.au/~Steve.Blackburn/private/mmtk-20060714.jar This version is virtually identical to what will be in the new JikesRVM release shortly. (See email on Fwd: MMTk re-org… for details). The directory called src/org/mmtk/vm contains 19 java source files. These files are stubs which are intended to be modified to fit a specific JVM. The first pass at modifying these files is complete. The entire MMTk including modified stubs compiles to *.class files and an MMTk.jar file has been built. To make initial bringup simple, MMTk configuration called, NoGC has been hardcoded into the stubs. Basically NoGC has a normal allocator but the collector is a no op. This allows us to avoid write barrier, enumeration, etc issues for initial bringup. Also, initial bringup will be single threaded. Thus we avoid dealing with sync/deadlock/race issues initially. A simple java main() program was modified to create an instance of the MMTk. In other words, VM mmtk_init = new VM(); During clinit, Address.plus() is executed. Since jitrino.jet does not yet have an intrinsic for this vmmagic function, DRLVM throws an exception and exits. (See previous email called, Fwd: MMTk re-org…) Where should we put the DRLVM/MMTk porting layer? Following the precedent set by JikesRVM, the porting layer source code is in the MMTk tree under: MMTk/ext/vm/HarmonyDRLVM/org/apache/HarmonyDRLVM/mm/mmtk/*.java The porting layer is in the Java package: package org.apache.HarmonyDRLVM.mm.mmtk; Given the above, how about we put the porting layer java files at: …/incubator/harmony/enhanced/drlvm/trunk/org/apache/HarmonyDRLVM/mm/mmtk/*.java? Thoughts? -- 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: [classlib] Re: svn commit: r422501 [1/2] - in /incubator/harmony/enhanced/classlib/trunk/modules/text: ./ src/main/java/java/text/ src/test/java/org/apache/harmony/text/tests/java/text/
Sure. The change wasn't intentional. I have Eclipse set at 80 characters and any time I use the formatter for the whole file it attacks the license header. -Original Message- From: Geir Magnusson Jr [mailto:[EMAIL PROTECTED] Sent: Monday, July 17, 2006 8:35 AM To: harmony-dev@incubator.apache.org Subject: [classlib] Re: svn commit: r422501 [1/2] - in /incubator/harmony/enhanced/classlib/trunk/modules/text: ./ src/main/java/java/text/ src/test/java/org/apache/harmony/text/tests/java/text/ [EMAIL PROTECTED] wrote: --- incubator/harmony/enhanced/classlib/trunk/modules/text/src/main/java/java/te xt/AttributedString.java (original) +++ incubator/harmony/enhanced/classlib/trunk/modules/text/src/main/java/java/te xt/AttributedString.java Sun Jul 16 12:10:14 2006 @@ -1,26 +1,29 @@ -/* Copyright 1998, 2006 The Apache Software Foundation or its licensors, as applicable +/* + * Copyright 1998, 2006 The Apache Software Foundation or its licensors, as + * applicable * - * Licensed under the Apache License, Version 2.0 (the License); - * you may not use this file except in compliance with the License. - * You may obtain a copy of the License at + * Licensed under the Apache License, Version 2.0 (the License); you may not + * use this file except in compliance with the License. You may obtain a copy of + * the License at * - * http://www.apache.org/licenses/LICENSE-2.0 + * http://www.apache.org/licenses/LICENSE-2.0 * * Unless required by applicable law or agreed to in writing, software - * distributed under the License is distributed on an AS IS BASIS, - * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. - * See the License for the specific language governing permissions and - * limitations under the License. + * distributed under the License is distributed on an AS IS BASIS, WITHOUT + * WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the + * License for the specific language governing permissions and limitations under + * the License. Can we avoid doing this? It makes no material difference, but conforming to the format and line breaks suggested by the appendix to the license itself http://www.apache.org/licenses/LICENSE-2.0 means that it always looks the same, and therefore people don't feel the need to read it, which I did when I saw that you were changing it... 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]
RE: [announce] New Apache Harmony Committer : Paulex Yang
Congratulations Paulex. -Original Message- From: Geir Magnusson Jr [mailto:[EMAIL PROTECTED] Sent: Sunday, July 16, 2006 6:36 PM To: harmony-dev@incubator.apache.org Subject: [announce] New Apache Harmony Committer : Paulex Yang Please join the Apache Harmony PPMC in welcoming the project's newest committer, Paulex Yang. Mark has demonstrated the elements that help build a healthy community, namely his ability to work together with others, continued dedication to the project, an understanding of our overall goals of the project, and a really unnatural and probably unhealthy focus on nio :) We all continue to expect great things from him. Mark, as a first step to test your almighty powers of committership, please update the committers page on the website. That should be a good (and harmless) exercise to test if everything is working. Things to do : 1) test ssh-ing to the server people.apache.org. 2) Change your login password on the machine as per the account email 3) Add a public key to .ssh so you can stop using the password 4) Change your svn password as described in the account email At this point, you should be good to go. Checkout the website from svn and update it. See if you can figure out how. Also, for your main harmony/enhanced/classlib/trunk please be sure that you have checked out via 'https' and not 'http' or you can't check in. You can switch using svn switch. (See the manual) Finally, although you now have the ability to commit, please remember : 1) continue being as transparent and communicative as possible. You earned committer status in part because of your engagement with others. While it was a have to situation because you had to submit patches and defend them, but we believe it is a want to. Community is the key to any Apache project. 2)We don't want anyone going off and doing lots of work locally, and then committing. Committing is like voting in Chicago - do it early and often. Of course, you don't want to break the build, but keep the commit bombs to an absolute minimum, and warn the community if you are going to do it - we may suggest it goes into a branch at first. Use branches if you need to. 3) Always remember that you can **never** commit code that comes from someone else, even a co-worker. All code from someone else must be submitted by the copyright holder (either the author or author's employer, depending) as a JIRA, and then follow up with the required ACQs and BCC. Again, thanks for your hard work so far, and welcome. The Apache Harmony PPMC - 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] Re: svn commit: r422501 [1/2] - in /incubator/harmony/enhanced/classlib/trunk/modules/text: ./ src/main/java/java/text/ src/test/java/org/apache/harmony/text/tests/java/text/
You probably know this... but you can disable comment formatting in Eclipse. -Matt --- Nathan Beyer [EMAIL PROTECTED] wrote: Sure. The change wasn't intentional. I have Eclipse set at 80 characters and any time I use the formatter for the whole file it attacks the license header. -Original Message- From: Geir Magnusson Jr [mailto:[EMAIL PROTECTED] Sent: Monday, July 17, 2006 8:35 AM To: harmony-dev@incubator.apache.org Subject: [classlib] Re: svn commit: r422501 [1/2] - in /incubator/harmony/enhanced/classlib/trunk/modules/text: ./ src/main/java/java/text/ src/test/java/org/apache/harmony/text/tests/java/text/ [EMAIL PROTECTED] wrote: --- incubator/harmony/enhanced/classlib/trunk/modules/text/src/main/java/java/te xt/AttributedString.java (original) +++ incubator/harmony/enhanced/classlib/trunk/modules/text/src/main/java/java/te xt/AttributedString.java Sun Jul 16 12:10:14 2006 @@ -1,26 +1,29 @@ -/* Copyright 1998, 2006 The Apache Software Foundation or its licensors, as applicable +/* + * Copyright 1998, 2006 The Apache Software Foundation or its licensors, as + * applicable * - * Licensed under the Apache License, Version 2.0 (the License); - * you may not use this file except in compliance with the License. - * You may obtain a copy of the License at + * Licensed under the Apache License, Version 2.0 (the License); you may not + * use this file except in compliance with the License. You may obtain a copy of + * the License at * - * http://www.apache.org/licenses/LICENSE-2.0 + * http://www.apache.org/licenses/LICENSE-2.0 * * Unless required by applicable law or agreed to in writing, software - * distributed under the License is distributed on an AS IS BASIS, - * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. - * See the License for the specific language governing permissions and - * limitations under the License. + * distributed under the License is distributed on an AS IS BASIS, WITHOUT + * WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the + * License for the specific language governing permissions and limitations under + * the License. Can we avoid doing this? It makes no material difference, but conforming to the format and line breaks suggested by the appendix to the license itself http://www.apache.org/licenses/LICENSE-2.0 means that it always looks the same, and therefore people don't feel the need to read it, which I did when I saw that you were changing it... 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] __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[classlib] javax.sound contribution
Do we need to treat this JIRA as a bulk contribution: http://issues.apache.org/jira/browse/HARMONY-883? -Nathan
RE: [continuum] BUILD FAILURE: Classlib/win.ia32 Build/Test
Has anyone been able to recreate this failure? My WinXP build is successful. -Original Message- From: Apache Harmony Build [mailto:[EMAIL PROTECTED] Sent: Monday, July 17, 2006 7:18 PM To: [EMAIL PROTECTED] Subject: [continuum] BUILD FAILURE: Classlib/win.ia32 Build/Test Online report : http://ibmonly.hursley.ibm.com/continuum/win.ia32/servlet/continuum/target /ProjectBuild.vm/view/ProjectBuild/id/6/buildId/1807 Build statistics: State: Failed Previous State: Failed Started at: Tue, 18 Jul 2006 01:05:37 +0100 Finished at: Tue, 18 Jul 2006 01:17:04 +0100 Total time: 11m 26s Build Trigger: Schedule Exit code: 1 Building machine hostname: hy1 Operating system : Windows XP(Service Pack 2) Java version : 1.5.0_06(Sun Microsystems Inc.) Changes classlib\modules\luni\src\test\java\tests\api\java\io\FileTest.java classlib\modules\luni\src\test\java\tests\api\java\util\LocaleTest.java classlib\modules\luni\src\main\java\java\util\Locale.java ** ** Output: ** ** Buildfile: build.xml SNIP/ [exec] test: [exec] compile.java: [exec] [echo] Compiling TEXT classes [exec] build.jar: [exec] build: [exec] copy.test.resources: [exec] [copy] Copying 2 files to C:\continuum- 1.0.2\apps\continuum\working-directory\6\classlib\modules\text\bin\test [exec] compile.tests: [exec] [echo] Compiling TEXT tests [exec] [javac] Compiling 26 source files to C:\continuum- 1.0.2\apps\continuum\working-directory\6\classlib\modules\text\bin\test [exec] run.tests: [exec] [junit] Running org.apache.harmony.text.tests.java.text.StringCharacterIteratorTest [exec] [junit] (c) Copyright 1991, 2006 The Apache Software Foundation or its licensors, as applicable. [exec] [junit] java version 1.5 (subset) [exec] [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 0.156 sec [exec] [junit] Tests run: 10, Failures: 0, Errors: 0, Time elapsed: 0.031 sec [exec] [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0.031 sec [exec] [junit] Tests run: 23, Failures: 0, Errors: 0, Time elapsed: 0.11 sec [exec] [junit] Tests run: 30, Failures: 0, Errors: 0, Time elapsed: 0.156 sec [exec] [junit] Tests run: 18, Failures: 0, Errors: 0, Time elapsed: 0.11 sec [exec] [junit] Tests run: 10, Failures: 0, Errors: 0, Time elapsed: 0.079 sec [exec] [junit] Tests run: 5, Failures: 0, Errors: 0, Time elapsed: 0.016 sec [exec] [junit] Tests run: 8, Failures: 0, Errors: 0, Time elapsed: 0.234 sec [exec] [junit] Tests run: 6, Failures: 0, Errors: 0, Time elapsed: 0.015 sec [exec] [junit] Tests run: 21, Failures: 0, Errors: 0, Time elapsed: 0 sec [exec] [junit] Tests run: 16, Failures: 0, Errors: 0, Time elapsed: 0.843 sec [exec] [junit] Tests run: 30, Failures: 0, Errors: 0, Time elapsed: 0.031 sec [exec] [junit] Tests run: 37, Failures: 0, Errors: 0, Time elapsed: 0.469 sec [exec] [junit] Tests run: 12, Failures: 0, Errors: 0, Time elapsed: 0 sec [exec] [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0.016 sec [exec] [junit] Tests run: 16, Failures: 1, Errors: 0, Time elapsed: 0.187 sec [exec] [junit] TEST org.apache.harmony.text.tests.java.text.MessageFormatTest FAILED [exec] [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0 sec [exec] [junit] Tests run: 6, Failures: 0, Errors: 0, Time elapsed: 0.016 sec [exec] [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0 sec [exec] [junit] Tests run: 8, Failures: 0, Errors: 0, Time elapsed: 0 sec [exec] [junit] Tests run: 16, Failures: 0, Errors: 0, Time elapsed: 0.453 sec [exec] [junit] Tests run: 19, Failures: 0, Errors: 0, Time elapsed: 0.109 sec [exec] [junit] Tests run: 22, Failures: 0, Errors: 0, Time elapsed: 0 sec [exec] [junit] Tests FAILED [exec] touch-failures-file: [exec] touch-errors-file: SNIP/ - 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 mean this should have about the same priority with the toString()
conversion task discussed in adjacent thread IMHO.
Yes. We could do it *lazily* if there's no objection. ;-)
2006/7/17, Alexei Zakharov [EMAIL PROTECTED]:
IMHO since even BEA VM behave differently in this case we may qualify
this as a low-priority task, rise non-bug JIRA and postpone it until
we meet the real-world app that relies on this. Do nothing is better
than do something that we aren't really sure we should do. :)
Regards,
2006/7/17, Richard Liang [EMAIL PROTECTED]:
Vladimir Gorr wrote:
In this case I'd like to understand what behaviour is correct
and what should be made to satisfy the users. I have no any
preference.
Hello Vladimir,
I think all of us agree that it's possible to following RI's behavior,
Right? The question is we shall decide to follow or not. Any
suggestion?
Thanks a lot.
Best regards,
Richard.
Thanks,
Vladimir.
On 7/14/06, Alexei Zakharov [EMAIL PROTECTED] wrote:
Vladimir wrote:
(I believe Alexey used it to test. *Or J9 nevertheless*? IMHO
it needs
to
specify when same discussions start).
I have tried both. And both differ from RI.
Richard wrote:
For getDeclaredMethods(), J9 has the same behavior as RI.
Well, there are some nuances nevertheless. I have wrote a small
test
(that was close to my orginal test) and ran it on four different
VMs.
The test simply does TestBean.class.getDeclaredMethods() and prints
the resulting array.
TestBean.java:
class TestBean {
String methodCalled = null;
public void method(Integer i) {
methodCalled = method1;
}
public void method(int i) {
methodCalled = method2;
}
public void method(boolean b) {
methodCalled = method3;
}
public void method(Boolean b) {
methodCalled = method4;
}
}
The results:
RI (Sun 1.5.0_05)
method int
method boolean
method java.lang.Boolean
method java.lang.Integer
j9 v3
method java.lang.Integer
method int
method boolean
method java.lang.Boolean
DLRVM
method java.lang.Integer
method int
method boolean
method java.lang.Boolean
jrockit-R26.3.0-jdk1.5.0_06
method java.lang.Boolean
method boolean
method int
method java.lang.Integer
With Best Regards,
2006/7/14, Richard Liang [EMAIL PROTECTED]:
Geir Magnusson Jr wrote:
Alexey Varlamov 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).
What does j9 do?
For getDeclaredMethods(), J9 has the same behavior as RI. For
getMethods, J9 and RI behave differently. ;-) But it's not
so hard
to summarize RI's rule of method order. Am I wrong?
Best regards,
Richard
I believe we need a bit stronger motivation for scratching
this
issue,
than a blunt testcase - some real-world application.
I agree that this isn't a critical issue, but a nice to have.
Maybe
we see what J9 does, and follow the majority (if we spend the
time...)?
geir
--
Richard Liang
China Software Development Lab, IBM
--
Alexei Zakharov,
Intel Middleware Product Division
--
Re: [announce] New Apache Harmony Committer : Paulex Yang
Geir Magnusson Jr wrote: And Paulex, please accept my sincerest apologies for the copy-and-paste-o down there, leaving in Mark, twice. :) No problem:). And thank everybody, glad to work with you all. I'm very embarrassed, and this in no way has any bearing on you. geir Geir Magnusson Jr wrote: Please join the Apache Harmony PPMC in welcoming the project's newest committer, Paulex Yang. Mark has demonstrated the elements that help build a healthy community, namely his ability to work together with others, continued dedication to the project, an understanding of our overall goals of the project, and a really unnatural and probably unhealthy focus on nio :) We all continue to expect great things from him. Mark, as a first step to test your almighty powers of committership, please update the committers page on the website. That should be a good (and harmless) exercise to test if everything is working. Things to do : 1) test ssh-ing to the server people.apache.org. 2) Change your login password on the machine as per the account email 3) Add a public key to .ssh so you can stop using the password 4) Change your svn password as described in the account email At this point, you should be good to go. Checkout the website from svn and update it. See if you can figure out how. Also, for your main harmony/enhanced/classlib/trunk please be sure that you have checked out via 'https' and not 'http' or you can't check in. You can switch using svn switch. (See the manual) Finally, although you now have the ability to commit, please remember : 1) continue being as transparent and communicative as possible. You earned committer status in part because of your engagement with others. While it was a have to situation because you had to submit patches and defend them, but we believe it is a want to. Community is the key to any Apache project. 2)We don't want anyone going off and doing lots of work locally, and then committing. Committing is like voting in Chicago - do it early and often. Of course, you don't want to break the build, but keep the commit bombs to an absolute minimum, and warn the community if you are going to do it - we may suggest it goes into a branch at first. Use branches if you need to. 3) Always remember that you can **never** commit code that comes from someone else, even a co-worker. All code from someone else must be submitted by the copyright holder (either the author or author's employer, depending) as a JIRA, and then follow up with the required ACQs and BCC. Again, thanks for your hard work so far, and welcome. The Apache Harmony PPMC - 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] -- 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] logging tests failing?
Which tests failed on your machine? Anymore error messages? Geir Magnusson Jr wrote: I'm having my logging tests fail on Ubuntu 6 (will test win in a sec...) I'll start digging, but if someone knows why, speak up... geir - 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: Solution on Harmony-815 (was Re: [jira] Commented: (HARMONY-815) [classlib][nio] Refine implConfigureBlocking(boolean) method of DatagramChannel and SocketChannel.)
David Tanzer wrote:
On 17.07.2006, at 14:09, Richard Liang wrote:
LvJimmy,Jing wrote:
Hi Andrew:
Sorry for late, but as this solution does not resolve I18N (working
aound for 815 only?) , I guess we may have another way.
If I understand correctly, this solution try to analysis error code in
native code, throws ErrorCodeException; and java code catch this
exception,
get error code, and throw another exception.
If so, why not just return the error code directly instead? :)
Hello Jimmy,
IIRC, It's SocketException that is thrown in native code, not
ErrorCodeException. And we will set the ErrorCodeException as cause of
the SocketException.
Yes, this is how I remember it too. The idea was to do the equivalent of
the
following code in the native code (correct me if I'm wrong):
ErrorCodeException ece = new ErrorCodeException(SOME_ERROR_CODE);
throw new SocketException(Some Message, ece);
Yes, sorry for my mistake :)
I don't think it is semantically correct to set the ErrorCodeException
as the cause
of the SocketException - the error code provides additional info, it is
not the cause
of the problem. For example, this code:
try {
ErrorCodeException ece = new ErrorCodeException(13);
throw new TestException(Something went wrong, ece);
} catch(TestException e) {
e.printStackTrace();
}
Yields the following stack trace:
net.guglhupf.test.TestException: Something went wrong
at net.guglhupf.test.ExceptionTest.main(ExceptionTest.java:7)
Caused by: Error Code 13
at net.guglhupf.test.ExceptionTest.main(ExceptionTest.java:6)
which might be confusing for some application developer so personally
I like the subclass - approach described by Andrew Zhang [1] better.
In this case, I guess if we set the cause to null when catching the
SocketException will properly solve the problem. However it seems
difficult as Throwable.initCause() can be called only once.
If throwing a subclass may also break compatibility guideline, I still
suggest return value, though it may break the current
infrastructure(currently, all errors throw exception), it is still easy
to deal with, only some of operation, read/write, require a little
change, and we no longer need try...catch in Java code
BTW, I find the code shall also deal with InterruptIOException.
Regards,
David
[1]
http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200607.mbox/[EMAIL PROTECTED]
I18N is anther issue, we shall have full discussion in community to
mature our thoughts. :-)
Do I miss something?
Best regards,
Richard.
2006/7/14, Mikhail Loenko [EMAIL PROTECTED]:
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
Re: [classlib] logging tests failing?
Sorry, please ignore it. Just catch up with the other thread on this below. Paulex Yang wrote: Which tests failed on your machine? Anymore error messages? -- 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] logging tests failing?
Just for record: all logging tests passed on my linux box (SLES9 2.6.5-7.191-bigsmp distributive). thanks, Vladimir On 7/18/06, Paulex Yang [EMAIL PROTECTED] wrote: Sorry, please ignore it. Just catch up with the other thread on this below. Paulex Yang wrote: Which tests failed on your machine? Anymore error messages? -- 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] logging tests failing?
Sorry, I miss that test was updated. In any case, now it passed on SLES9. thanks, vladimir On 7/18/06, Vladimir Ivanov [EMAIL PROTECTED] wrote: Just for record: all logging tests passed on my linux box (SLES9 2.6.5-7.191-bigsmp distributive). thanks, Vladimir On 7/18/06, Paulex Yang [EMAIL PROTECTED] wrote: Sorry, please ignore it. Just catch up with the other thread on this below. Paulex Yang wrote: Which tests failed on your machine? Anymore error messages? -- 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: Solution on Harmony-815 (was Re: [jira] Commented: (HARMONY-815) [classlib][nio] Refine implConfigureBlocking(boolean) method of DatagramChannel and SocketChannel.)
IMHO, throwing a subclass certainly fits to specification and can hardly break compatibility with RI. I consider this is the proper workaround for now. Just my $0.02 :) -- Alexey Varlamov In this case, I guess if we set the cause to null when catching the SocketException will properly solve the problem. However it seems difficult as Throwable.initCause() can be called only once. If throwing a subclass may also break compatibility guideline, I still suggest return value, though it may break the current infrastructure(currently, all errors throw exception), it is still easy to deal with, only some of operation, read/write, require a little change, and we no longer need try...catch in Java code BTW, I find the code shall also deal with InterruptIOException. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
