code or we should
introduce other JAVA_PROPERTIES with functionality of properties
described above and rewrite existing kernel classes.
Thanks
Dmitry
2006/10/20, Dmitry Yershov [EMAIL PROTECTED]:
Hi All,
I finished implementation of new properties module for DRL VM.
Also, HARMONY-1925
] wrote:
On Tuesday 10 October 2006 11:36 Geir Magnusson Jr. wrote:
Inline
Dmitry Yershov wrote:
[snip]
VM properties proposal
==
The general purpose of VM
[snip]
Requirements
1) The key and value are represented as string (i.e. char*).
and I propose that on each operation, a copy is made, so that the caller
frees the string that they got or gave.
Agree.
..
[snip]
Requirements
1) The key and value are represented as string (i.e. char*).
and I propose that on each operation, a copy is made, so that the caller
frees the string that they got or gave.
2006/10/10, Mikhail Fursov [EMAIL PROTECTED]:
On 10/10/06, Alexey Varlamov [EMAIL PROTECTED] wrote:
I think there is correlation between these 2 questions :). If we use
const char*, we simply copy key and value when setting a property.
And this is impossible with void*.
Ok, this way it
There are my thoughts about VM properties. I observe some problem with
current VM properties implementation:
1) The current VM properties initialization is rather chaotic:
* Some properties stored into two places: Properties class and array of
VmStandardProperty structure. A certain
At first, all assembler files should be propagated to the 64bit platforms. e.g.:
classlib/modules/luni/src/main/native/thread/linux/thrspinlock.s
classlib/modules/luni/src/main/native/thread/linux/thrhelp.s
or
classlib/modules/luni/src/main/native/thread/windows/thrspinlock.asm
Hello all.
Salikh Zakirov wrote:
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
