Hi Vladimir,
Where exceptions should be thrown is a big question in this thread. Native
code or Java code or mixed?
Shall we avoid throwing all exceptions in Harmony native code?
If all exceptions are thrown in java code, there is no need to involve any
other I18N utilities (i.e. log4cXXX).
Mikhail Loenko wrote:
I suggest that we:
1) avoid throwing exceptions from native code
I have no strong feelings yet which is better, to throw Exception in
native codes directly or always to return error codes to Java. There are
different styles in Java and C programming on error handling, C
On 7/13/06, Andrew Zhang [EMAIL PROTECTED] wrote:
Hi Vladimir,
Where exceptions should be thrown is a big question in this thread. Native
code or Java code or mixed?
Yes, I'm aware about this. However I'd prefer to have other subject for this
thread :-).
Thanks,
Vladimir.
Shall we avoid
Hi Harmony community.
I'd like to discuss with you a design for the VM native code
internationalization (attached below).
We'd like to consider this approach for the DRLVM first of all. However it
can be suitable for other parts of Harmony project I suppose.
Please let me know your
Andrew Zhang wrote:
Hello everybody,
I plan to implement
java.nio.channels.spi.SelectorProvider.inheritedChannel()
method. Currently Harmony simply returns null.
Spec doesn not specify how to detect inheritedChannel clearly,
Returns the
channel inherited from the entity that created this
On 7/13/06, Paulex Yang [EMAIL PROTECTED] wrote:
Andrew Zhang wrote:
Hello everybody,
I plan to implement
java.nio.channels.spi.SelectorProvider.inheritedChannel()
method. Currently Harmony simply returns null.
Spec doesn not specify how to detect inheritedChannel clearly,
Returns the
Hi, Vladimir
Log4c and log4cpp are both good tools, but if our requirements are just
message internationalization, maybe log4cxx is overkill? After all, as a
complete log framework, it provides supports to i18n, category, layout
And if we talk about ResourceBundle only, I'd suggest
Minor note:
I havn't insisted that we *always* return error code rather than throw
Exception,
instead I suggest that we avoid throwing exceptions from native
whenever possible.
I thought that native calls that don't throw exceptions might be optimized
by JIT. But it's only a guess, I leave it
Andrew Zhang wrote:
On 7/13/06, Paulex Yang [EMAIL PROTECTED] wrote:
Andrew Zhang wrote:
Hello everybody,
I plan to implement
java.nio.channels.spi.SelectorProvider.inheritedChannel()
method. Currently Harmony simply returns null.
Spec doesn not specify how to detect inheritedChannel
Vladimir Gorr wrote:
Internationalization design *1. Introduction*
...
The key idea is to use ResourceBundle class from apache log4cxx which allow
to store and effective use bundles with localized messages.
Why not use GNU gettext -- de facto standard i18n system on GNU/Linux systems?
I think
On 7/13/06, Mikhail Loenko [EMAIL PROTECTED] wrote:
Minor note:
I havn't insisted that we *always* return error code rather than throw
Exception,
AFAIK, luni and nio modules always throw exception rather than return error
code.
instead I suggest that we avoid throwing exceptions from
On 7/13/06, Paulex Yang [EMAIL PROTECTED] wrote:
Hi, Vladimir
Log4c and log4cpp are both good tools, but if our requirements are just
message internationalization, maybe log4cxx is overkill? After all, as a
complete log framework, it provides supports to i18n, category,
layout
And if we
Vladimir Gorr wrote:
On 7/13/06, Paulex Yang [EMAIL PROTECTED] wrote:
Hi, Vladimir
Log4c and log4cpp are both good tools, but if our requirements are just
message internationalization, maybe log4cxx is overkill? After all, as a
complete log framework, it provides supports to i18n, category,
In my opinion using the gettext() for the i18n goals will involve too big
re-factoring of source code.
I also disagree with the 'no-meaning' for message key. All we need is to
create the sensible ID for these messages.
*4) Add to this that most of the developers will not know where the
localized
Vladimir Gorr wrote:
In my opinion using the gettext() for the i18n goals will involve too big
re-factoring of source code.
I also disagree with the 'no-meaning' for message key. All we need is to
create the sensible ID for these messages.
I think this is the case of good intentions, which
Vladimir Gorr wrote:
I'd like to discuss with you a design for the VM native code
internationalization (attached below).
...
Please let me know your opinions/objections.
To make my point clearer, I would repeat my suggestion.
0) Agree on a design decision that the message key
is the
Geir Magnusson Jr wrote:
Fair enough. If it's really only a few days, I have no objection, and
if no one else has an objection, you might as well go for it. I hate
seeing the build broken ever, but...
Maybe the thing to do is send a separate mail w/ build broken for
windows AWT natives
On 12 July 2006 at 20:00, Geir Magnusson Jr [EMAIL PROTECTED] wrote:
+1 from geir, tim, george, mikhail, mark, stepan,
No 0 or -1.
Contribution open for integration :)
I'll do the integration (after the natives) if no one else wants to do
it.
-Mark.
geir
Geir Magnusson Jr wrote:
Andrey Chernyshev wrote:
With some changes I was able to run the DRLVM with classlib's
launcher. Here is what I did (you can see the experimental patch at
http://issues.apache.org/jira/browse/HARMONY-857):
- I have added JNI_CreateJavaVM declaration to jni.h (guess it will be
the most
Andrey Chernyshev wrote:
With some changes I was able to run the DRLVM with classlib's
launcher. Here is what I did (you can see the experimental patch at
http://issues.apache.org/jira/browse/HARMONY-857):
- I have added JNI_CreateJavaVM declaration to jni.h (guess it will be
the most
Mikhail Loenko wrote:
Hi George
I did not know that. When I run ant test -Dtest.jre.home=... for some
odd reason this test does not run at all. I'll try to figure out why.
I completely agree that the test should pass on RI. I'll fix the test.
The old version of the test copied files on the
On 7/13/06, Salikh Zakirov [EMAIL PROTECTED] wrote:
Vladimir Gorr wrote:
I'd like to discuss with you a design for the VM native code
internationalization (attached below).
...
Please let me know your opinions/objections.
To make my point clearer, I would repeat my suggestion.
0) Agree on
Tim Ellison wrote:
Magnusson, Geir wrote:
Clearly this is a great example to use to discuss this aspect of our
project.
First, this is a not an unreasonable objection to prevent code from
moving into classlib, but I still don't see why it can't sit in
sandbox to help with discussion of
Salikh Zakirov wrote:
Vladimir Gorr wrote:
Internationalization design *1. Introduction*
...
The key idea is to use ResourceBundle class from apache log4cxx which allow
to store and effective use bundles with localized messages.
Why not use GNU gettext -- de facto standard i18n system on
I'll state the obvious... there is another thread going on about how do
to similar things with Classlib. Maybe you can find common ground for
message bundles and such...
geir
Vladimir Gorr wrote:
Hi Harmony community.
I'd like to discuss with you a design for the VM native code
Tim Ellison wrote:
Geir Magnusson Jr wrote:
Fair enough. If it's really only a few days, I have no objection, and
if no one else has an objection, you might as well go for it. I hate
seeing the build broken ever, but...
Maybe the thing to do is send a separate mail w/ build broken for
Hi,
I have discovered we have small incompatibility in our java.lang.Class
implementation. The order of elements returned by
Class.getDeclaredMethods() differs from RI. The spec says here: The
elements in the array returned are not sorted and are not in any
particular order. But I already know
I assume you mean [drlvm], since java.lang.Class in [classlib] is just a
stub, right?
Anyway, what would you say exactly? That our not in any particular
order is different than the not in any particular order that the RI
does? I'm not trying to make light of it, but it sounds like all is
On 7/13/06, Vladimir Gorr [EMAIL PROTECTED] wrote:
On 7/13/06, Salikh Zakirov [EMAIL PROTECTED] wrote:
Vladimir Gorr wrote:
I'd like to discuss with you a design for the VM native code
internationalization (attached below).
...
Please let me know your opinions/objections.
To make my
On 7/13/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote:
I assume you mean [drlvm], since java.lang.Class in [classlib] is just a
stub, right?
Anyway, what would you say exactly? That our not in any particular
order is different than the not in any particular order that the RI
does? I'm not
-Original Message-
From: Andrew Zhang [mailto:[EMAIL PROTECTED]
Sent: Thursday, July 13, 2006 10:04 AM
To: harmony-dev@incubator.apache.org; [EMAIL PROTECTED]
Subject: Re: [classlib] compatibility nuances
On 7/13/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote:
I assume you mean
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
Weldon,
Warning: unknown flag - jet::wb4j
This warning means that the code for 'wb4j' switch processing is
not on its place.
Either the patch failed to apply, or jitrino.dll was not rebuild
properly.
Will rebuild help ? E.g. to remove
build\win_ia32_msvc_debug\semis\vm\jitrino
and then run
-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
On 7/13/06, Magnusson, Geir [EMAIL PROTECTED] wrote:
-Original Message-
From: Alexei Zakharov [mailto:[EMAIL PROTECTED]
Sent: Thursday, July 13, 2006 10:19 AM
To: harmony-dev@incubator.apache.org; [EMAIL PROTECTED]
Subject: Re: [classlib] compatibility nuances
That our not in
Geir Magnusson Jr wrote:
Salikh Zakirov wrote:
Why not use GNU gettext -- de facto standard i18n system on GNU/Linux
systems?
Isn't it under the GPL?
The runtime part (libintl) is LGPL, so it allows linking to non-GPL programs.
The tools are indeed GPL, but Harmony project is not going
-Original Message-
From: Salikh Zakirov [mailto:[EMAIL PROTECTED]
Sent: Thursday, July 13, 2006 10:32 AM
To: harmony-dev@incubator.apache.org
Subject: Re: [drlvm] proposals for VM internationalization
Geir Magnusson Jr wrote:
Salikh Zakirov wrote:
Why not use GNU gettext --
Can you figure out what their order is? If so, I'd use that since we
are free to do what we want, and if someone does depende on this, it's
one less change, and it's spec compliant.
I would say it is in the definition order but some methods are placed
in the begining of the list by no
Vladimir Gorr wrote:
Have you looked at the patch I've sent? It doesn't use gettext.
It just proposes the way to move forward towards propertly localized DRLVM.
I think we will be able to use ICU4C java-like localization in the following
way:
* extract localizable strings from .cpp files using
Hello,
Some time ago I installed FreeBSD 6.1-RELEASE on my home computer and
tried to build original Harmony VM donation [1] + corresponding
classlib on it. In the end of the efforts I've managed to build it and
print something with '-?' argument, but unfortunately an attempt to
run 'Hello,
Andrew Zhang wrote:
Vladimir Gorr wrote:
namely, ICU4C or
LOG4CXX or combination of them.
log4cxx is already used in DRLVM. It does not provide localization services.
If only for i18n, icu4c is prefered.
So, would the following solution be acceptable to all?
1 mark the localizable strings
Magnusson, Geir wrote:
Do you mean there won't be any runtime dependencies? We can't
distribute LGPL-ed binaries.
In this case, libintl is definitely out of question.
However, I like the simplicity of _() interface.
I think we can use it with ICU4C too.
I don't know if this is being considered, but
1) Classlib has lots of java internationalization needs, and some native
internationalization needs
2) DRLVM has lots of native internationalization needs, and some java
needs (kernel classes).
So it seems clear to me we need to at least try for a
Geir Magnusson Jr wrote:
Alexey Petrenko wrote:
Geir,
I've reread your email in the morning :)
Internationalization classes auto-generation is really good idea. We
can apply it for method described here and for new Eclipse method.
I'll settle for it being an idea. Not sure if it's a
Hi,
I would like to announce a contribution of assorted bug fixes
and improvements to DRLVM on behalf of my colleagues and Intel corporation.
The zip file with patches is attached to HARMONY-856.
The bug fixes were developed simultaneously with the tedious
process of preparing the original DRLVM
Alexei Zakharov wrote:
I know one already.
Go on, stop teasing, what is it? ;-)
As others have said elsewhere, if you can determine the order, and we
don't have to perform unnatural acts to make it the same, then no reason
to be different just because we can.
Regards,
Tim
--
Tim Ellison
Salikh,
Thanks for this set of fixes. Though I understand that the changes are
described in the zip, would it be possible for you to list/summarize some of
the key changes in the submission on this thread?
Thanks,
Rana
On 7/13/06, Salikh Zakirov [EMAIL PROTECTED] wrote:
Hi,
I would like to
Geir Magnusson Jr wrote:
I don't know if this is being considered, but
1) Classlib has lots of java internationalization needs, and some native
internationalization needs
2) DRLVM has lots of native internationalization needs, and some java
needs (kernel classes).
FWIW, I as far as I can
Tim Ellison wrote:
Geir Magnusson Jr wrote:
Alexey Petrenko wrote:
Geir,
I've reread your email in the morning :)
Internationalization classes auto-generation is really good idea. We
can apply it for method described here and for new Eclipse method.
I'll settle for it being an idea.
we stand corrected. Both need localization, and we should be able to
find commonality in the approaches.
geir
Salikh Zakirov wrote:
Geir Magnusson Jr wrote:
I don't know if this is being considered, but
1) Classlib has lots of java internationalization needs, and some native
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
I like this
Tim Ellison wrote:
Andrew Zhang wrote:
How about design a subclass which extends from SocketException, looks like:
If you want to preserve the throwable type you could create a
o.a.h.luni.ErrorCodeException that has a errorCode field set by the
native, and then make that the
I think you may have inadvertently checked the code into the wrong
location in SVN. Could you move it please?
Thanks
Tim
Nathan Beyer wrote:
-Original Message-
From: Geir Magnusson Jr [mailto:[EMAIL PROTECTED]
snip/
First problem is that you included CopyOnWriteArrayList.java, which
Rana Dasgupta wrote:
would it be possible for you to list/summarize
some of the key changes in the submission on this thread?
sure.
The contributed patches fix
* a couple of memory leaks in DRLVM
* incorrect code for SWAP operation in Jitrino.JET
* a number of bugs in kernel classes
* bug in
Thanks Salikh -- just to make it clear I have classified the JIRA as a
'contribution' rather than a 'new feature'.
Regards,
Tim
Salikh Zakirov wrote:
Hi,
I would like to announce a contribution of assorted bug fixes
and improvements to DRLVM on behalf of my colleagues and Intel corporation.
Tim Ellison wrote:
Geir Magnusson Jr wrote:
Tim Ellison wrote:
Geir Magnusson Jr wrote:
Tim Ellison wrote:
Nathan Beyer wrote:
I've checked in my proposal for the java.util.concurrent module at
https://svn.apache.org/repos/asf/incubator/harmony/enhanced/classlib/trunk/s
Go on, stop teasing, what is it? ;-)
Not a big deal, I have already mentioned it in my first mail. This is
our java.beans tests. :-) The idea was if one person hit upon the idea
of such tests then another person can similarly build a complete
application based on the same precondition.
Tim Ellison wrote:
Thanks Salikh -- just to make it clear I have classified the JIRA as a
'contribution' rather than a 'new feature'.
Thanks, Tim.
It was very awkward of me to file it as new feature.
I have even managed to upload the file twice and could not delete it :)
Salikh Zakirov
All,
The following build mods will create a drlvm binary that can be used
to debug the Jitrino.JET write barriers. Rather than make everyone
suffer through long email chains, Alex and I collaborated offline.
The mods to drlvm/trunk/build/build.bat:
--- build.bat (revision 421403)
+++
Weldon,
Thanks. If jitrino building in debug mode was switched off to not make it
crawl, is it an option to not apply these mods, but just leave this thread
as a reference for people who need this?
I am somehow being able to debug just fine with devenv ( but I don't use
jitrino symbols )
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
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
Andrew Zhang wrote:
On 7/14/06, Tim Ellison [EMAIL PROTECTED] wrote:
Andrew Zhang wrote:
How about design a subclass which extends from SocketException, looks
like:
If you want to preserve the throwable type you could create a
o.a.h.luni.ErrorCodeException that has a errorCode field set by
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
On 7/13/06, Rana Dasgupta [EMAIL PROTECTED] wrote:
Weldon,
Thanks. If jitrino building in debug mode was switched off to not make it
crawl, is it an option to not apply these mods, but just leave this thread
as a reference for people who need this?
Yes, of course. These mods are most
On 7/14/06, Richard Liang [EMAIL PROTECTED] wrote:
Andrew Zhang wrote:
On 7/14/06, Tim Ellison [EMAIL PROTECTED] wrote:
Andrew Zhang wrote:
How about design a subclass which extends from SocketException, looks
like:
If you want to preserve the throwable type you could create a
Resulting actions:
* Move code to the 'standard' folder? (I'll do this in the next few days if
there aren't any complaints)
* Continue with proposal code, create a prototype and try to work with the
concurrency group.
Any other major items?
-Nathan
-Original Message-
From: Geir
On the 0x1A6 day of Apache Harmony Weldon Washburn wrote:
All,
The following build mods will create a drlvm binary that can be used
to debug the Jitrino.JET write barriers. Rather than make everyone
suffer through long email chains, Alex and I collaborated offline.
Great! Good feature for
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?
Vladimir Ivanov wrote:
On 7/7/06, Tim Ellison [EMAIL PROTECTED] wrote:
...
Currently I'm looking on the excluded TestCases and it requires more time
than I expected.
I'll prepare a report/summary about excluded TestCases at the end of this
process.
Hello Vladimir,
How about the progress
On 14 Jul 2006 09:47:14 +0700, Egor Pasko [EMAIL PROTECTED] wrote:
On the 0x1A6 day of Apache Harmony Weldon Washburn wrote:
All,
The following build mods will create a drlvm binary that can be used
to debug the Jitrino.JET write barriers. Rather than make everyone
suffer through long
New page http://wiki.apache.org/harmony/Excluded_tests was added to WIKI
(refered from http://wiki.apache.org/harmony/ClassLibrary).
It would be good if before test investigation one would specify 'in
progress, Name' near module name, showing it is under investigation being
done by Name.
Thanks,
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
On 7/14/06, Alexey Varlamov [EMAIL PROTECTED] wrote:
2006/7/14, Richard Liang [EMAIL PROTECTED]:
Magnusson, Geir wrote:
-Original Message-
From: Alexei Zakharov [mailto:[EMAIL PROTECTED]
Sent: Thursday, July 13, 2006 10:19 AM
To: harmony-dev@incubator.apache.org; [EMAIL
On 7/13/06, Anton Luht [EMAIL PROTECTED] wrote:
Hello,
Some time ago I installed FreeBSD 6.1-RELEASE on my home computer and
tried to build original Harmony VM donation [1] + corresponding
classlib on it. In the end of the efforts I've managed to build it and
print something with '-?'
75 matches
Mail list logo
