Re: [sablevm] SIGSEGV signal received from Cygwin

[Etienne Gagnon]

Enrico Migliore wrote:
> Yet, I remember, that in JCHEVM I had to remove the POPT_AUTOHELP string
> in a struct in order not to receive that signal,
> therefore, I'm pretty much sure that somewhere in the Pthread library
> there's an access to an area used to initialize constants:
> something that maybe GCC likes but Windows doesn't.
> That's just a guess.

I have to look more carfully to the port library, and see what thread
supports it provides.  I've had lots of professorish things to do over
the last days, so I didn't get enough time to look deeply.  I'll get
back to you about it.

> The documentation included in SableVM trunk is more than good.
> Therefore, I would like to try do this job. I'm not sure I'll succeed
> but I want to
> 
> As far as the port is concerned, there are 3 things to talk about:
> 
> build system in MSVC
> ---
> to my knowledge, MSVC doesn't have a build system like UNIX (autotool +
> configure) therefore, I think that the "config.h" file will have to be
> built manually.

This shouldn't be too much of a problem.  SableVM has no intrinsict
dependence on auto* tools.  It does, however, require m4.  This could be
eliminated if we decided to allow for a Java dependency for building
(i.e. ant & sablecc-based code generator).

Yet, on shorter term, some simpler make file is feasible.  All you
actually need to build is libsablevm.dll.  There's no need for the
sablevm launcher; we already know that the harmony one works, and it is
much more complete...

> how to modify the source files?
> --
> Let's say that removing a POSIX dependancy in a SableVM file means:
> replacing some lines of codes and replacing some include files. How am I
> suppost to deal with this kind of thing? Should I modify the trunk or my
> sandbox?

Ideally, initial work should happen in your sandbox.  This way you can
use it to do backups of your code, even when it doesn't compile, without
disturbing anybody.

I am playing with the idea of making a copy of current trunk in
sablevm/branches/last-stable, and simply allowing for a broken trunk
during the Harmony transition (not as broken as a typical sandbox;
should at least compile).

We have a strict policy on using the "svn merge" operation.  We can
discuss it the day you need it.

> how to track source modifications
> --
> Let's say that one source file gets modified by one of SableVM
> developers, and another is added to the trunk. Should I rely on SVN to
> know where the modifications were done?

Not sure I understand the question...  Developers may only checkin code
they wrote themselves.  This way, svn keeps a clear history of who wrote
what.

I think this discussion should probably continue on sablevm-devel@, as
not to add too much noise into [EMAIL PROTECTED]  We could, there, discuss
of work distribution among you, hadrien and me, as well as any other
interested contributor, to get a working sablevm+harmony duo as soon and
as cleanly as possible.

We should come back to this list for any topic related to the class-lib
and port library side of things.

Etienne

-- 
Etienne M. Gagnon, Ph.D.http://www.info2.uqam.ca/~egagnon/
SableVM:   http://www.sablevm.org/
SableCC:   http://www.sablecc.org/


signature.asc
Description: OpenPGP digital signature

Re: [classlib] update on running Harmony Classlib on GNU Classpath VMs

[Etienne Gagnon]

Like Tim, I object to have GNU Classpath specific code in the Harmony
kernel code.

Etienne

Tim Ellison wrote:
> Weldon Washburn wrote:
>>I added a bunch of VMx.java files to
>>kernel/src/main/java/java/lang/   These files are only needed for GNU
>>Classpath compatible JVMs.  Should we keep these files in this
>>directory or should we create a separate directory?  It might make
>>sense to create
>>kernel/src/gnuclasspathadapter/java/java/lang/VMx.java
> 
> I would object to making the Harmony kernel GNU Classpath specific, so
> why not make the adapter a separate 'project', i.e. just
>   gnuclasspathadapter/src/java/java/lang/VMx.java

-- 
Etienne M. Gagnon, Ph.D.http://www.info2.uqam.ca/~egagnon/
SableVM:   http://www.sablevm.org/
SableCC:   http://www.sablecc.org/


signature.asc
Description: OpenPGP digital signature

Re: [port library] windows manager

[Gregory Shimansky]

2006/4/7, Enrico Migliore <[EMAIL PROTECTED]>:
>
> >>Does instead, the port library for UNIX support any windows manager?
> >
> >AFAIK you generally choose a windowing manager and code to it -- I'm
> >unaware of any cross-manager port libraries (but I'm not a UI person so
> >there may well be such a thing).


There is a wxWindows cross platform C++ library but it has a very big
abstraction layer overhead on top of platform APIs. Also there is GTK+ which
has a win32 port and some linux native applications like gimp and xchat have
win32 native ports to windows. QT is also free for non profit usage, but
only for non-profit.

I see what you are saying: all windowing native issues are managed by
> SWT or AWT, therefore the port library dosen't include and windowing
> native functions. Right?


I am not a UI person as well but as far as I know you are right. Porting
layers for UI are huge and not trivial, and there is nothing about UI in the
port library.

--
Gregory Shimansky, Intel Middleware Products Division

Re: [classlib] update on running Harmony Classlib on GNU Classpath VMs

[Archie Cobbs]

Tim Ellison wrote:

I would object to making the Harmony kernel GNU Classpath specific, so
why not make the adapter a separate 'project', i.e. just
gnuclasspathadapter/src/java/java/lang/VMx.java


GNU Classpath needs unique "pointer" classes.  We could put them at
kernel/src/gnuclasspathadapter/java/gnu/classpath/Pointerx.java


or
gnuclasspathadapter/src/java/gnu/classpath/Pointerx.java


Thoughts on the above?


it's more important to get the code working than figure out where in the
Harmony repository it would end up isn't it?

Wherever it goes I expect it will simply be built into one or more JARs
that are put on the bootclasspath to run Classpath-oriented VMs (just
like any other VM provides its own own kernel implementation).


We can commit the kernel_path stuff into JCHEVM somewhere under java.

I started working on this but never heard from Geir whether it was OK
to check it in. If someone will confirm it's OK to commit the kernelpath
stuff I'll do it.

-Archie

__
Archie Cobbs  *CTO, Awarix*  http://www.awarix.com

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[rmi] getting 1.4 bytecode

[Daniel Gandara]

Hi, 
   As discussed with Oliver, I built the rmi code with the 
-target jsr14 option and I got a 1.4 bytecode for the package.
I run our test suit against the package and it seems to work ok.   


This is a sum up of the experience:
1) -target jsr14 option only worked with Sun's compiler, I 
   could not make it work on Eclipse...
2) I had to make changes to the code, basically I had to 
   change enums and change/remove java.util.concurrent 
   classes we use (ConcurrentHashMap and 
   ThreadPoolExecutor)


note: there is obviously a performance penalty due to 2).

The question I have now is if I should send this modified code 
to be used in Harmony during this transitional phase or not.  
What do you think?


I'll be waitting for comments, 

Daniel 




-
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] update on running Harmony Classlib on GNU Classpath VMs

[Tim Ellison]

Weldon Washburn wrote:
> On 4/7/06, Tim Ellison <[EMAIL PROTECTED]> wrote:
>>> I tried to give a complete explaination in the readme in JIRA
>>> Harmony-318.  It would be great if you could tell me what this
>>> document is missing or where it is unclear.
>> Ok, I'll take a look.  I think this adapter work is very important, it
>> would be good to discuss problems/progress on the dev list too.
> 
> Aha!  Let's now discuss the problems on the dev list:

Well I'm about to disappear for a week ;-) -- but this is likely the
best way of getting a broad discussion and comments.

> I added a bunch of VMx.java files to
> kernel/src/main/java/java/lang/   These files are only needed for GNU
> Classpath compatible JVMs.  Should we keep these files in this
> directory or should we create a separate directory?  It might make
> sense to create
> kernel/src/gnuclasspathadapter/java/java/lang/VMx.java

I would object to making the Harmony kernel GNU Classpath specific, so
why not make the adapter a separate 'project', i.e. just
gnuclasspathadapter/src/java/java/lang/VMx.java

> GNU Classpath needs unique "pointer" classes.  We could put them at
> kernel/src/gnuclasspathadapter/java/gnu/classpath/Pointerx.java

or
gnuclasspathadapter/src/java/gnu/classpath/Pointerx.java

> Thoughts on the above?

it's more important to get the code working than figure out where in the
Harmony repository it would end up isn't it?

Wherever it goes I expect it will simply be built into one or more JARs
that are put on the bootclasspath to run Classpath-oriented VMs (just
like any other VM provides its own own kernel implementation).

>>> Actually I could not get JCHEVM/cygwin to read the JAR files.
>> Is that an issue with JCHEVM or the JAR files do you think?
> 
> I think JCHEVM/cygwin inability to read JAR files is one of the
> problems that will go away if you ignore it.  In other words, someone
> has probably already fixed this problem in the latest download of
> JCHEVM.  Its not a biggie.  I can wait.



>>> I am working with a 2 month old copy of Harmony Classlib.  I would
>>> like to hold off the move to current Harmony Classlib until after I
>>> get the cygwin dlopen() problems solved.
>
>> Ah, ok -- I'll try and do the timeshift thing, but if there are fixes
>> that are required in Harmony classlib to make things work/easier for you
>> they will be applied to the current HEAD, and we can discuss what is
>> required for them to work in your local sandbox.
> 
> So far, the biggest thing has been where to put the new kernel files.

I guess I don't understand why the location of your adapter source code
is a big deal?

> The next item is likely to be the tool chain that the make files are
> using.  I worry that there is incompatiblity between *.dll's built for
> GNU Classpath environment and *.dll's built for Harmony Classlib.  It
> would be good if JNI compilant Windows *.dll's can plug-and-play on
> both Harmony and GNU Classpath environments.  I suspect Cygwin
> environment is involved.  Do you know if anyone has looked at this
> issue yet?

I haven't seen such interop problems -- hopefully somebody will chime in.

>>> I modified System.java to do a "VMRuntime.nativeLoad("hynio.dll");"
>>> This is a call into GNU Classpath JVM that will cause a DLL to be
>>> loaded.
>
>> (Two months ago:) IIRC there is an explicit call to
>> System.loadLibary("hynio") in the class libary code, so why do you need
>> to make that into a Classpath-specific call?
> 
> I checked just now.  I can't find evidence of hynio.dll being called
> in the version of Harmony Classlib kernel files I have.

It was there in the OSMemory class up to six days ago[1], but whatever.

[1]
http://svn.apache.org/viewcvs.cgi/incubator/harmony/enhanced/classlib/trunk/modules/luni/src/main/java/org/apache/harmony/luni/platform/OSMemory.java?rev=390453&r1=390038&r2=390453&diff_format=h

> In any case,
> when kernel_path is moved to the latest version of Classlib, the code
> that currently tries to loead hynio.dll should be replaced with the
> correct stuff.

It currently isn't loaded/used, those functions were moved into
lyluni.dll | libhyluni.so.

Regards,
Tim

-- 

Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [classlib] update on running Harmony Classlib on GNU Classpath VMs

[Weldon Washburn]

On 4/7/06, Tim Ellison <[EMAIL PROTECTED]> wrote:
> > I tried to give a complete explaination in the readme in JIRA
> > Harmony-318.  It would be great if you could tell me what this
> > document is missing or where it is unclear.
>
> Ok, I'll take a look.  I think this adapter work is very important, it
> would be good to discuss problems/progress on the dev list too.

Aha!  Let's now discuss the problems on the dev list:

I added a bunch of VMx.java files to
kernel/src/main/java/java/lang/   These files are only needed for GNU
Classpath compatible JVMs.  Should we keep these files in this
directory or should we create a separate directory?  It might make
sense to create
kernel/src/gnuclasspathadapter/java/java/lang/VMx.java

GNU Classpath needs unique "pointer" classes.  We could put them at
kernel/src/gnuclasspathadapter/java/gnu/classpath/Pointerx.java

Thoughts on the above?

> > Actually I could not get JCHEVM/cygwin to read the JAR files.
>
> Is that an issue with JCHEVM or the JAR files do you think?

I think JCHEVM/cygwin inability to read JAR files is one of the
problems that will go away if you ignore it.  In other words, someone
has probably already fixed this problem in the latest download of
JCHEVM.  Its not a biggie.  I can wait.

> > I am working with a 2 month old copy of Harmony Classlib.  I would
> > like to hold off the move to current Harmony Classlib until after I
> > get the cygwin dlopen() problems solved.
>
> Ah, ok -- I'll try and do the timeshift thing, but if there are fixes
> that are required in Harmony classlib to make things work/easier for you
> they will be applied to the current HEAD, and we can discuss what is
> required for them to work in your local sandbox.

So far, the biggest thing has been where to put the new kernel files. 
The next item is likely to be the tool chain that the make files are
using.  I worry that there is incompatiblity between *.dll's built for
GNU Classpath environment and *.dll's built for Harmony Classlib.  It
would be good if JNI compilant Windows *.dll's can plug-and-play on
both Harmony and GNU Classpath environments.  I suspect Cygwin
environment is involved.  Do you know if anyone has looked at this
issue yet?

> > I modified System.java to do a "VMRuntime.nativeLoad("hynio.dll");"
> > This is a call into GNU Classpath JVM that will cause a DLL to be
> > loaded.
>
> (Two months ago:) IIRC there is an explicit call to
> System.loadLibary("hynio") in the class libary code, so why do you need
> to make that into a Classpath-specific call?

I checked just now.  I can't find evidence of hynio.dll being called
in the version of Harmony Classlib kernel files I have.  In any case,
when kernel_path is moved to the latest version of Classlib, the code
that currently tries to loead hynio.dll should be replaced with the
correct stuff.
>
> Regards,
> Tim
>
> --
>
> Tim Ellison ([EMAIL PROTECTED])
> IBM Java technology centre, UK.
>
> -
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


--
Weldon Washburn
Intel Middleware Products Division

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [jira] Updated: (HARMONY-308) java.nio.charset.Charset.encode(CharBuffer) returns bytes in a different order in Harmony and RI for the UTF-16 charset

[Tim Ellison]

Just to clarify...

Dmitry M. Kononov wrote:

> Harmony and IBM jdk1.4.2 use the ICU to provide
> java.nio.charsetfunctionality. So, they have the same behavior in our
> case. This behavior
> does not follow the java documentation (or I something don't understand :)
> ).

No, IBM's JDK 1.4.2 does not use the same ICU code as Harmony.

(The precise relationship is complex, but the summary is that a long
time ago some ICU code was adopted into the Sun code base.  Harmony is
using a significantly different release.  I believe both use data from
the CLDR.)

Regards,
Tim

> Thus, we probably need to ask about fixing the ICU, don't we?
> 
> What do you think, does it make sense to file a bug against ICU?
> Thanks.
> --
> Dmitry M. Kononov
> Intel Managed Runtime Division
> 

-- 

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: [jira] Updated: (HARMONY-308) java.nio.charset.Charset.encode(CharBuffer) returns bytes in a different order in Harmony and RI for the UTF-16 charset

[Dmitry M. Kononov]

Hi Andrew,

On 4/7/06, Andrew Zhang <[EMAIL PROTECTED]> wrote:
>
> Hello, Dmirty,
>
> I agree with you that Harmony's behavior is not consistent with java spec.


:)


As you may know, java.nio.charset.Charset wraps ICU to implement
> encode/decode operations.
>
> The following description is cited from ICU: (
> http://icu.sourceforge.net/userguide/unicodeBasics.html)
>
> *The names "UTF-16" and "UTF-32" are ambiguous. Depending on context, they
> refer either to character encoding forms where 16/32-bit words are
> processed
> and are naturally stored in the platform endianness, or they refer to the
> IANA-registered charset names, i.e., to character encoding schemes or byte
> serializations. In addition to simple byte serialization, the charsets
> with
> these names also use optional Byte Order Marks (see **Serialized
> Formats*<
> http://icu.sourceforge.net/userguide/unicodeBasics.html#serialized_formats
> >
> * below).*
>
> Thanks, it's a good point. However, I found the following text in this
document that let us think that there is a bug in ICU. Please note the
latest sentence, that describes our case exactly, I believe:

"In UTF-16 and UTF-32, where the signature also distinguishes between
big-endian and little-endian byte orders, it is also called a byte order
mark (BOM). The signature works for UTF-16 since the code point that has the
byte-swapped encoding, FFFE16, will never be a valid Unicode character. (It
is a "non-character" code point.) In Internet protocols, if an encoding
specification of "UTF-16" or "UTF-32" is used, it is expected that there is
a signature byte sequence (BOM) that identifies the byte ordering, which is
not the case for the encoding scheme/charset names with "BE" or "LE".
If text is specified to be encoded in the UTF-16 or UTF-32 charset and does
not begin with a BOM, then it must be interpreted as UTF-16BE or UTF-32BE,
respectively."

Harmony and IBM jdk1.4.2 use the ICU to provide
java.nio.charsetfunctionality. So, they have the same behavior in our
case. This behavior
does not follow the java documentation (or I something don't understand :)
). Thus, we probably need to ask about fixing the ICU, don't we?

What do you think, does it make sense to file a bug against ICU?
Thanks.
--
Dmitry M. Kononov
Intel Managed Runtime Division

Re: [port library] windows manager

[Enrico Migliore]

Hi Tim,


Of course, the plan is for Harmony to have AWT and Swing code.

 


Ok


Does instead, the port library for UNIX support any windows manager?
   



AFAIK you generally choose a windowing manager and code to it -- I'm
unaware of any cross-manager port libraries (but I'm not a UI person so
there may well be such a thing).

Regards,
Tim

 

I see what you are saying: all windowing native issues are managed by 
SWT or AWT, therefore the port library dosen't include and windowing 
native functions. Right?



Enrico


-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [sablevm] SIGSEGV signal received from Cygwin

[Enrico Migliore]

Hi Etienne,


Enrico Migliore wrote:
 


I debugged the classical HelloWorld class with DDD and found the problem
in the following function:

_svmf_init(void)
{
pthread_once(...);< SEGSEGV  signal
   



That's definitely a cygwin bug.  I see.

 

The SEGSEGV signal is issued by Windows when the program does an 
"Illegal storage access".

The following simple example does receive the signal:

void my_function (char *pippo)
{
   pippo[0] = '\0';
}

int main (int argc, char** argv)
{
   my_function("Hello World");
   return 0;
}

Yet, I remember, that in JCHEVM I had to remove the POPT_AUTOHELP string 
in a struct in order not to receive that signal,
therefore, I'm pretty much sure that somewhere in the Pthread library 
there's an access to an area used to initialize constants:

something that maybe GCC likes but Windows doesn't.
That's just a guess.


In any case, before starting the port, I think that I and the people who
would like to help, will have analyze the code file by file.
   



Actually, you should really start looking at:

src/libsablevm/include/jni_system_specific.h
src/libsablevm/system.c
src/libsablevm/system.h

These are the files which contain system-specific code.  Outside of
these files, the only real dependencies are POSIX calls.  [I think
there's some exception in System.getCurrentMillis() implementation that
shouldn't even be in the VM to start with, as there's no VM-specific
functionality in it...  I had to live with Classpath's decisions on
their VM interface.]

If you really want to read every single source file (!), then you should
definitely:
0.1) [prerequisite] read the JVMS fully, a few times over
0.2) [prerequisite] read the JNI spec fully, a few times over
1) read my Ph.D. thesis
2) read the documents in doc/
3) ask questions on sablevm-devel@ for clarifications

Going that deep shouldn't be necessary, though.  Identifying POSIX
dependencies and replacing them with VMI-port calls should be sufficient
to start with.

Etienne
 

The documentation included in SableVM trunk is more than good. 
Therefore, I would like to try do this job. I'm not sure I'll succeed 
but I want to


As far as the port is concerned, there are 3 things to talk about:

build system in MSVC
---
to my knowledge, MSVC doesn't have a build system like UNIX (autotool + 
configure) therefore, I think that the "config.h" file will have to be 
built manually.


how to modify the source files?
--
Let's say that removing a POSIX dependancy in a SableVM file means: 
replacing some lines of codes and replacing some include files. How am I 
suppost to deal with this kind of thing? Should I modify the trunk or my 
sandbox?



how to track source modifications
--
Let's say that one source file gets modified by one of SableVM 
developers, and another is added to the trunk. Should I rely on SVN to 
know where the modifications were done?



ciao,
Enrico





-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [jira] Updated: (HARMONY-308) java.nio.charset.Charset.encode(CharBuffer) returns bytes in a different order in Harmony and RI for the UTF-16 charset

[Richard Liang]

Dmitry M. Kononov wrote:

Hi Richard,

On 4/6/06, Richard Liang <[EMAIL PROTECTED]> wrote:

  

Dmitry M. Kononov wrote:


As you exactly noticed the cause of this issue that Harmony uses the
little-endian byte order, if an encoded UTF-16 sequence has no
  

byte-order


mark. However, the spec reads such a case explicitly as follows:

"When decoding, the UTF-16 charset interprets a byte-order mark to
  

indicate


the byte order of the stream but defaults to big-endian if there is no
byte-order mark; when encoding, it uses big-endian byte order and writes
  

a


big-endian byte-order mark."


  

Hello Dmitry,

Yes, although Harmony and RI use different byte order, as both Harmony
and RI use byte-order mark (U+FEFF), I think both Harmony and RI are
compliant with the specification. So could we regard Harmony-308 as "not
a bug"?




I think Harmony's behavior in this case is inconsistent with the java spec,
since the spec defines the expected behavior explicitly:
"when encoding, it uses big-endian byte order and writes a big-endian
byte-order mark." But Harmony's encode() returns bytes in the little-endian
order.

It seems I do not understand why do you think Harmony follows the spec
correctly in this case? :)
I am really sorry for my misunderstanding.

  
You're Dmitry. :-) Now I agree with you that Harmony is not compliant 
with the specification. We will discuss with our Charset Provider - ICU 
to determine how to fix this issue. Thanks a lot.



>From a test case attached to the HARMONY-308:

1) We have a char array that has no byte-order mark:
private static final char chars[] = {

0x041b,0x0435,0x0442,0x043e,0x0020,0x0432,0x0020,0x0420,0x043e,0x0441,
0x0441,0x0438,0x0438};

2) We have a byte array that encode() should return as we expect.
private static final byte bytes[] = {
(byte)254,(byte)255,(byte)  4,(byte) 27,(byte)  4,(byte) 53,(byte)
4,
(byte) 66,(byte)  4,(byte) 62,(byte)  0,(byte) 32,(byte)  4,(byte)
50,
(byte)  0,(byte) 32,(byte)  4,(byte) 32,(byte)  4,(byte) 62,(byte)
4,
(byte) 65,(byte)  4,(byte) 65,(byte)  4,(byte) 56,(byte)  4,(byte)
56};

Please note, according to the spec we expect bytes returned by encode() in
big-endian byte order. So, we expect the FEFF byte-order mark.
Do you agree this expectation is correct and consistent with the spec?

Thanks.
--
Dmitry M. Kononov
Intel Managed Runtime Division

  



--
Richard Liang
China Software Development Lab, IBM 

Re: [jira] Updated: (HARMONY-308) java.nio.charset.Charset.encode(CharBuffer) returns bytes in a different order in Harmony and RI for the UTF-16 charset

[Andrew Zhang]

Hello, Dmirty,

I agree with you that Harmony's behavior is not consistent with java spec.

As you may know, java.nio.charset.Charset wraps ICU to implement
encode/decode operations.

The following description is cited from ICU: (
http://icu.sourceforge.net/userguide/unicodeBasics.html)

*The names "UTF-16" and "UTF-32" are ambiguous. Depending on context, they
refer either to character encoding forms where 16/32-bit words are processed
and are naturally stored in the platform endianness, or they refer to the
IANA-registered charset names, i.e., to character encoding schemes or byte
serializations. In addition to simple byte serialization, the charsets with
these names also use optional Byte Order Marks (see **Serialized
Formats*
* below).*

The result of running your test case on IBM jdk 1.4.2  is exactly the same
as on Harmony. I guess IBM jdk 1.4.2 has passed TCK.

Therefore, IMO, both behaviours are acceptable.

What's your opinion?

On 4/7/06, Dmitry M. Kononov <[EMAIL PROTECTED]> wrote:
>
> Hi Richard,
>
> On 4/6/06, Richard Liang <[EMAIL PROTECTED]> wrote:
>
> > Dmitry M. Kononov wrote:
> > > As you exactly noticed the cause of this issue that Harmony uses the
> > > little-endian byte order, if an encoded UTF-16 sequence has no
> > byte-order
> > > mark. However, the spec reads such a case explicitly as follows:
> > >
> > > "When decoding, the UTF-16 charset interprets a byte-order mark to
> > indicate
> > > the byte order of the stream but defaults to big-endian if there is no
> > > byte-order mark; when encoding, it uses big-endian byte order and
> writes
> > a
> > > big-endian byte-order mark."
> > >
> > >
> > Hello Dmitry,
> >
> > Yes, although Harmony and RI use different byte order, as both Harmony
> > and RI use byte-order mark (U+FEFF), I think both Harmony and RI are
> > compliant with the specification. So could we regard Harmony-308 as "not
> > a bug"?
>
>
> I think Harmony's behavior in this case is inconsistent with the java
> spec,
> since the spec defines the expected behavior explicitly:
> "when encoding, it uses big-endian byte order and writes a big-endian
> byte-order mark." But Harmony's encode() returns bytes in the
> little-endian
> order.
>
> It seems I do not understand why do you think Harmony follows the spec
> correctly in this case? :)
> I am really sorry for my misunderstanding.
>
> From a test case attached to the HARMONY-308:
>
> 1) We have a char array that has no byte-order mark:
>private static final char chars[] = {
>
> 0x041b,0x0435,0x0442,0x043e,0x0020,0x0432,0x0020,0x0420,0x043e,0x0441,
>0x0441,0x0438,0x0438};
>
> 2) We have a byte array that encode() should return as we expect.
>private static final byte bytes[] = {
>(byte)254,(byte)255,(byte)  4,(byte) 27,(byte)  4,(byte) 53,(byte)
> 4,
>(byte) 66,(byte)  4,(byte) 62,(byte)  0,(byte) 32,(byte)  4,(byte)
> 50,
>(byte)  0,(byte) 32,(byte)  4,(byte) 32,(byte)  4,(byte) 62,(byte)
> 4,
>(byte) 65,(byte)  4,(byte) 65,(byte)  4,(byte) 56,(byte)  4,(byte)
> 56};
>
> Please note, according to the spec we expect bytes returned by encode() in
> big-endian byte order. So, we expect the FEFF byte-order mark.
> Do you agree this expectation is correct and consistent with the spec?
>
> Thanks.
> --
> Dmitry M. Kononov
> Intel Managed Runtime Division
>
>
--
Andrew Zhang
China Software Development Lab, IBM

Re: keyword scanning (was: Re: ITC: Contribution of java.math and javax.crypto)

[Alex Orlov]

:) Thanks for letting know this!

Thanks,
Alex Orlov.
Intel Middleware Products Division

On 4/7/06, Tim Ellison <[EMAIL PROTECTED]> wrote:
> Thanks Alex,
>
> We already have a keyword scanner[1] so we should ensure your dictionary
> words are in there.
>
> I'd rather add the scan to the automated build rather than rely upon the
> committers to remember to run it (at least one of the committers is lazy
> like that ;-) )
>
> [1]
> http://svn.apache.org/viewcvs.cgi/incubator/harmony/standard/tools/keywordscan
>
> Regards,
> Tim
>
> Alex Orlov wrote:
> > On 4/7/06, Chris Gray <[EMAIL PROTECTED]> wrote:
> >> On Thursday 06 April 2006 23:59, Tim Ellison wrote:
> >>> You can run the Eclipse IDE on Classpath or Harmony(*) class libraries,
> >>> both are sufficiently well advanced to run it.
> >>>
> >>> (*) you need to use the regex code from regex-beans-math which hasn't
> >>> been merged into the build process yet
> >> I knew eclipse ran on Classpath (e.g. gcj), wasn't sure about Harmony. 
> >> That's
> >> good to hear.
> >>
> >> IMO Harmony developers should be encouraged to use a Sun-free workstation
> >> whenever possible, to avoid this kind of slip-up. There should also be
> >> automatic detectors for references to sun.* or com.sun.* classes.
> >
> > Hi folks,
> >
> > BTW we use simple script to check if the sources contain the words we
> > would like to avoid. You can find it attached. The usage is pretty
> > straightforward:
> >
> >   perl check_bad_words.pl  
> >
> > Also attached is dictionary file that contains "Sun" and "GPL" as two
> > sample words. You can turn on your imagination and enhance the
> > dictionary significantly. :)
> >
> > May we propose the committers to run it before committing anyuthing to SVN?
> >
> > Thanks,
> > Alex Orlov.
> > Intel Middleware Products Division
> >
> >
> >> Regards,
> >>
> >> Chris
> >>
> >> --
> >> Chris Gray/k/ Embedded Java Solutions  BE0503765045
> >> Embedded & Mobile Java, OSGihttp://www.k-embedded-java.com/
> >> [EMAIL PROTECTED] +32 3 216 0369
> >>
> >>
> >> -
> >> Terms of use : http://incubator.apache.org/harmony/mailing.html
> >> To unsubscribe, e-mail: [EMAIL PROTECTED]
> >> For additional commands, e-mail: [EMAIL PROTECTED]
> >>
> >>
> >>
> >> 
> >>
> >> #!/usr/bin/perl
> >>
> >> use File::Spec;
> >> use strict;
> >>
> >> my $ext_src = "java|c|h|cpp|hpp|j|jfl|ccode";
> >> my $ext_sup = "xml|txt|pl|sh|bat|cmd";
> >> my $ext = "(" . $ext_src . "|" . $ext_sup . ")";
> >> my $filename = "copyright|license|notice|readme";
> >> my %bad_words = ();
> >>
> >> sub readDictionary {
> >>  my ($dic) = @_;
> >>  if (-f $dic) {
> >>  open (FD_DIC, "< $dic") or die "Can't open dictionary file: 
> >> $dic\n";
> >>  while () {
> >>  unless (/^#/ || /^\s+$/) {
> >>  my ($word, $area) = split(" ; ");
> >>  chomp $area;
> >>  my @areas = split(":", $area);
> >>  push @{$bad_words{$word}}, @areas;
> >>  }
> >>  }
> >>  close(FD_DIC);
> >>  } else {
> >>  die "Invalid dictionary file: $dic\n";
> >>  }
> >> }
> >>
> >> sub readDir {
> >>  my ($file) = @_;
> >>  if (-d $file) {
> >>  if (opendir(FD_DIR, $file)) {
> >>  chdir ($file);
> >>  foreach my $item (readdir(FD_DIR)) {
> >>  if ($item ne '.' && $item ne '..') {
> >>  readDir($item);
> >>  }
> >>  }
> >>  chdir ("..");
> >>  closedir (FD_DIR);
> >>  } else {
> >>  print "Can't open dir $file\n";
> >>  }
> >>  } elsif (-f $file) {
> >>  if ($file =~ /\.$ext$/ || $file =~ /^$filename/i) {
> >>  &searchBadWords(&readFile($file), $file);
> >>  }
> >>  } else {
> >>  print "File or directory doesn't exist: $file\n";
> >>  }
> >> }
> >>
> >> sub searchBadWords($$) {
> >>  my ($content, $file) = @_;
> >> my ($prev, $after, $match, $area);
> >>  my $abs_fname = File::Spec->rel2abs($file);
> >>  foreach my $word (sort keys %bad_words) {
> >>  my $checkable = 0; # false
> >>  foreach $area (@{$bad_words{$word}}) {
> >>  if (($area eq "all") or (index($abs_fname, $area) ne 
> >> -1)) {
> >>  $checkable = 1; # true
> >>  }
> >>  }
> >>  if ($checkable) {
> >>  if ($content =~ m/$word/i) {
> >>  $match = $&;
> >> 

keyword scanning (was: Re: ITC: Contribution of java.math and javax.crypto)

[Tim Ellison]

Thanks Alex,

We already have a keyword scanner[1] so we should ensure your dictionary
words are in there.

I'd rather add the scan to the automated build rather than rely upon the
committers to remember to run it (at least one of the committers is lazy
like that ;-) )

[1]
http://svn.apache.org/viewcvs.cgi/incubator/harmony/standard/tools/keywordscan

Regards,
Tim

Alex Orlov wrote:
> On 4/7/06, Chris Gray <[EMAIL PROTECTED]> wrote:
>> On Thursday 06 April 2006 23:59, Tim Ellison wrote:
>>> You can run the Eclipse IDE on Classpath or Harmony(*) class libraries,
>>> both are sufficiently well advanced to run it.
>>>
>>> (*) you need to use the regex code from regex-beans-math which hasn't
>>> been merged into the build process yet
>> I knew eclipse ran on Classpath (e.g. gcj), wasn't sure about Harmony. That's
>> good to hear.
>>
>> IMO Harmony developers should be encouraged to use a Sun-free workstation
>> whenever possible, to avoid this kind of slip-up. There should also be
>> automatic detectors for references to sun.* or com.sun.* classes.
> 
> Hi folks,
> 
> BTW we use simple script to check if the sources contain the words we
> would like to avoid. You can find it attached. The usage is pretty
> straightforward:
> 
>   perl check_bad_words.pl  
> 
> Also attached is dictionary file that contains "Sun" and "GPL" as two
> sample words. You can turn on your imagination and enhance the
> dictionary significantly. :)
> 
> May we propose the committers to run it before committing anyuthing to SVN?
> 
> Thanks,
> Alex Orlov.
> Intel Middleware Products Division
> 
> 
>> Regards,
>>
>> Chris
>>
>> --
>> Chris Gray/k/ Embedded Java Solutions  BE0503765045
>> Embedded & Mobile Java, OSGihttp://www.k-embedded-java.com/
>> [EMAIL PROTECTED] +32 3 216 0369
>>
>>
>> -
>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>>
>> 
>>
>> #!/usr/bin/perl
>>
>> use File::Spec;
>> use strict;
>>
>> my $ext_src = "java|c|h|cpp|hpp|j|jfl|ccode";
>> my $ext_sup = "xml|txt|pl|sh|bat|cmd";
>> my $ext = "(" . $ext_src . "|" . $ext_sup . ")";
>> my $filename = "copyright|license|notice|readme";
>> my %bad_words = ();
>>
>> sub readDictionary {
>>  my ($dic) = @_;
>>  if (-f $dic) {
>>  open (FD_DIC, "< $dic") or die "Can't open dictionary file: 
>> $dic\n";
>>  while () {
>>  unless (/^#/ || /^\s+$/) {
>>  my ($word, $area) = split(" ; ");
>>  chomp $area;
>>  my @areas = split(":", $area);
>>  push @{$bad_words{$word}}, @areas;
>>  }
>>  }
>>  close(FD_DIC);
>>  } else {
>>  die "Invalid dictionary file: $dic\n";
>>  }
>> }
>>
>> sub readDir {
>>  my ($file) = @_;
>>  if (-d $file) {
>>  if (opendir(FD_DIR, $file)) {
>>  chdir ($file);
>>  foreach my $item (readdir(FD_DIR)) {
>>  if ($item ne '.' && $item ne '..') {
>>  readDir($item);
>>  }
>>  }
>>  chdir ("..");
>>  closedir (FD_DIR);
>>  } else {
>>  print "Can't open dir $file\n";
>>  }
>>  } elsif (-f $file) {
>>  if ($file =~ /\.$ext$/ || $file =~ /^$filename/i) {
>>  &searchBadWords(&readFile($file), $file);
>>  }
>>  } else {
>>  print "File or directory doesn't exist: $file\n";
>>  }
>> }
>>
>> sub searchBadWords($$) {
>>  my ($content, $file) = @_;
>> my ($prev, $after, $match, $area);
>>  my $abs_fname = File::Spec->rel2abs($file);
>>  foreach my $word (sort keys %bad_words) {
>>  my $checkable = 0; # false
>>  foreach $area (@{$bad_words{$word}}) {
>>  if (($area eq "all") or (index($abs_fname, $area) ne 
>> -1)) {
>>  $checkable = 1; # true
>>  }
>>  }
>>  if ($checkable) {
>>  if ($content =~ m/$word/i) {
>>  $match = $&;
>>  chomp($match);
>>  $prev = $`;
>>  $after = $';
>>  print "File: $abs_fname\n";
>>  print "Bad word: $match\n";
>>  print "Line #" . &getLineNumber($prev) . "\n";
>>  print "String: " . &getString($prev, $after, 
>> $match) . "\

Re: ITC: Contribution of java.math and javax.crypto

[Alex Orlov]

On 4/7/06, Chris Gray <[EMAIL PROTECTED]> wrote:
> On Thursday 06 April 2006 23:59, Tim Ellison wrote:
> > You can run the Eclipse IDE on Classpath or Harmony(*) class libraries,
> > both are sufficiently well advanced to run it.
> >
> > (*) you need to use the regex code from regex-beans-math which hasn't
> > been merged into the build process yet
>
> I knew eclipse ran on Classpath (e.g. gcj), wasn't sure about Harmony. That's
> good to hear.
>
> IMO Harmony developers should be encouraged to use a Sun-free workstation
> whenever possible, to avoid this kind of slip-up. There should also be
> automatic detectors for references to sun.* or com.sun.* classes.

Hi folks,

BTW we use simple script to check if the sources contain the words we
would like to avoid. You can find it attached. The usage is pretty
straightforward:

  perl check_bad_words.pl  

Also attached is dictionary file that contains "Sun" and "GPL" as two
sample words. You can turn on your imagination and enhance the
dictionary significantly. :)

May we propose the committers to run it before committing anyuthing to SVN?

Thanks,
Alex Orlov.
Intel Middleware Products Division


>
> Regards,
>
> Chris
>
> --
> Chris Gray/k/ Embedded Java Solutions  BE0503765045
> Embedded & Mobile Java, OSGihttp://www.k-embedded-java.com/
> [EMAIL PROTECTED] +32 3 216 0369
>
>
> -
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
#!/usr/bin/perl

use File::Spec;
use strict;

my $ext_src = "java|c|h|cpp|hpp|j|jfl|ccode";
my $ext_sup = "xml|txt|pl|sh|bat|cmd";
my $ext = "(" . $ext_src . "|" . $ext_sup . ")";
my $filename = "copyright|license|notice|readme";
my %bad_words = ();

sub readDictionary {
my ($dic) = @_;
if (-f $dic) {
open (FD_DIC, "< $dic") or die "Can't open dictionary file: 
$dic\n";
while () {
unless (/^#/ || /^\s+$/) {
my ($word, $area) = split(" ; ");
chomp $area;
my @areas = split(":", $area);
push @{$bad_words{$word}}, @areas;
}
}
close(FD_DIC);
} else {
die "Invalid dictionary file: $dic\n";
}
}

sub readDir {
my ($file) = @_;
if (-d $file) {
if (opendir(FD_DIR, $file)) {
chdir ($file);
foreach my $item (readdir(FD_DIR)) {
if ($item ne '.' && $item ne '..') {
readDir($item);
}
}
chdir ("..");
closedir (FD_DIR);
} else {
print "Can't open dir $file\n";
}
} elsif (-f $file) {
if ($file =~ /\.$ext$/ || $file =~ /^$filename/i) {
&searchBadWords(&readFile($file), $file);
}
} else {
print "File or directory doesn't exist: $file\n";
}
}

sub searchBadWords($$) {
my ($content, $file) = @_;
my ($prev, $after, $match, $area);
my $abs_fname = File::Spec->rel2abs($file);
foreach my $word (sort keys %bad_words) {
my $checkable = 0; # false
foreach $area (@{$bad_words{$word}}) {
if (($area eq "all") or (index($abs_fname, $area) ne 
-1)) {
$checkable = 1; # true
}
}
if ($checkable) {
if ($content =~ m/$word/i) {
$match = $&;
chomp($match);
$prev = $`;
$after = $';
print "File: $abs_fname\n";
print "Bad word: $match\n";
print "Line #" . &getLineNumber($prev) . "\n";
print "String: " . &getString($prev, $after, 
$match) . "\n";
print "\n";
}   
}
}
if ($file =~ /^*\.($ext_src)/) {
if ($content =~ /[\s_]bug[\s_]*(#*)(\d+)/) {
$match = $&;
chomp($match);
$prev = $`;
$after = $';
print "File: $abs_fname\n";
print "Bug mentioning: $match\n";
print "Line #" . &getLineNumber($prev) . "\n";
print "String: " . &getString($prev, $after, $match) . "\n

Re: [port library] windows manager

[Tim Ellison]

Enrico Migliore wrote:
>> Enrico Migliore wrote:
>>> does the MSVC port library support the windowing system of Windows?
>>
>> No (but I can recommend SWT as a cross-platform windowing model ;-) )
>>
> the consequence of that is that, at the moment, the Harmony Class
> Library can only support console based applications, right?

Well we can't run apps that require AWT or Swing at the moment, but we
can run GUI apps (like Eclipse and RSSOwl) that are SWT-based.

Of course, the plan is for Harmony to have AWT and Swing code.

> I don't get exactly how and in which terms we can use the SWT
> (cross-platform GUI develiped by IBM)

SWT is available under the EPL.  I was only teasing though, it is not a
solution for our need to write the JSE windowing libraries.

> Does instead, the port library for UNIX support any windows manager?

AFAIK you generally choose a windowing manager and code to it -- I'm
unaware of any cross-manager port libraries (but I'm not a UI person so
there may well be such a thing).

Regards,
Tim

-- 

Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [port library] windows manager

[Enrico Migliore]

Hi Tim,


Enrico Migliore wrote:
 


does the MSVC port library support the windowing system of Windows?
   



No (but I can recommend SWT as a cross-platform windowing model ;-) )

 

the consequence of that is that, at the moment, the Harmony Class 
Library can only support console based applications, right?


I don't get exactly how and in which terms we can use the SWT 
(cross-platform GUI develiped by IBM)


Does instead, the port library for UNIX support any windows manager?


And yet, what happened to the proposal of using the Apache Portable
Runtime as an interface to the native layer?
   



I believe it remains a proposal.  Artem Aliev did some work on using APR
as a portability layer (by coding the Harmony portlib to APR) in late
February, and reported his findings to the list[1].  AFAIK nobody has
continued this work.

[1]
http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200602.mbox/[EMAIL
 PROTECTED]

Regards,
Tim
 


I see

ciao,
Enrico

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [port library] windows manager

[Tim Ellison]

Enrico Migliore wrote:
> does the MSVC port library support the windowing system of Windows?

No (but I can recommend SWT as a cross-platform windowing model ;-) )

> And yet, what happened to the proposal of using the Apache Portable
> Runtime as an interface to the native layer?

I believe it remains a proposal.  Artem Aliev did some work on using APR
as a portability layer (by coding the Harmony portlib to APR) in late
February, and reported his findings to the list[1].  AFAIK nobody has
continued this work.

[1]
http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200602.mbox/[EMAIL
 PROTECTED]

Regards,
Tim

-- 

Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [classlib] update on running Harmony Classlib on GNU Classpath VMs

[Tim Ellison]

Weldon Washburn wrote:
> On 4/6/06, Tim Ellison <[EMAIL PROTECTED]> wrote:
>> Weldon Washburn wrote:
>>> I was able to eliminate almost all mods necessary to run Harmony
>>> Classlib on a GNU Classpath VM.  The VM used is still JCHEVM.
>> Cool -- I'd be very interested to hear about what you are doing.
> 
> I tried to give a complete explaination in the readme in JIRA
> Harmony-318.  It would be great if you could tell me what this
> document is missing or where it is unclear.

Ok, I'll take a look.  I think this adapter work is very important, it
would be good to discuss problems/progress on the dev list too.

>>> The VM
>>> expects a specific hardcoded java lib directory structure.  Therefore,
>>> directories such as kernel/src/main/java/gnu/classpath have been added
>>> to Harmony Classlib.
>> Do you mean directory paths to the class library JARs or specific class
>> package names?
> 
> Actually I could not get JCHEVM/cygwin to read the JAR files.

Is that an issue with JCHEVM or the JAR files do you think?

> I simply use unzipped Harmony class files.  The directory paths in
> question were added because generic GNU Classpath VMs are hardcoded to
> expect to find specific class files in specific packages.  Which, in
> turn, means creating the corresponding *.java files in new
> directories.  The alternative would be to get GNU Classpath to modify
> their directory structure plus get all the JVMs using GNU Classpath to
> change their hardcoding.

I agree that producing an adapter to redirect from Classpath's
hard-coded assumptions is the right answer.

>>> The one remaining mod to JCHEVM is because dlopen() fails to load
>>> hynio.dll.
>> That DLL shouldn't be loaded?  We moved the natives out into hyluni.dll
>> and (I just checked) there are no references to it from the Java code.
> 
> I am working with a 2 month old copy of Harmony Classlib.  I would
> like to hold off the move to current Harmony Classlib until after I
> get the cygwin dlopen() problems solved.

Ah, ok -- I'll try and do the timeshift thing, but if there are fixes
that are required in Harmony classlib to make things work/easier for you
they will be applied to the current HEAD, and we can discuss what is
required for them to work in your local sandbox.

>> Who is trying to load it?
> 
> I modified System.java to do a "VMRuntime.nativeLoad("hynio.dll");" 
> This is a call into GNU Classpath JVM that will cause a DLL to be
> loaded.

(Two months ago:) IIRC there is an explicit call to
System.loadLibary("hynio") in the class libary code, so why do you need
to make that into a Classpath-specific call?

Regards,
Tim

-- 

Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[port library] windows manager

[Enrico Migliore]

Tim Ellison wrote:


Enrico Migliore wrote:

 


problem 4:  Native code dependancies
---
The Harmony class library depends on the port layer:

http://svn.apache.org/viewcvs.cgi/*checkout*/incubator/harmony/enhanced/classlib/trunk/doc/vm_doc/html/index.html


Is this layer available for MSVC?
   



Yes it is written using MSVC (and in fact would require some
modification to make it work with gcc on Windows).

Regards,
Tim

 


Hi Tim,

does the MSVC port library support the windowing system of Windows?

And yet, what happened to the proposal of using the Apache Portable 
Runtime as an interface to the native layer?


Enrico

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]