Re: ITC: Contribution of java.math and javax.crypto
Hello Miguel Thank you for your recent contribution to Harmony project! I've noticed that class javax.crypto.Util invokes a method from undocumented package sun.misc.* I assume that you did not have access to Sun sources, so it probably would be good if you provide a link to how did you learn about that Sun's internal functionality and its usage. Thanks, Mikhail 2006/3/14, Tim Ellison [EMAIL PROTECTED]: Excellent! -- thanks Miguel and team. Regards, Tim Miguel Montes wrote: As it was announced by Iris Gastañaga we are contributing the packages javax.crypto and java.math on behalf of ITC (Córdoba Technolgy Institute). We have been developing this code for several months and we believe it is a valid contribution. Our code not only implements the full 5.0 API but also uses 5.0 features and syntax. As 5.0 is a stated goal of Harmony we hope that a 5.0 VM will be available soon. We are also contributing a set of test cases for both packages. Below there is a short description of the contribution. We will soon contribute also an implementation of java.rmi. *Package name* **javax.crypto * Package Description* This is a clean room implementation of the package javax.crypto as specified in the JDK 5.0. It requires the existence of other java packages, in particular java.security and java.util. It can be used to replace jce.jar in the jdk. *Current Status* The package is almost fully implemented. It does not implement the ExemptionMechanism logic. *Testing * Unit and integration tests (and their documentation) are provided with the code.* * *Implementation Notes The code uses heavily J2SE 5.0 features, such as generics, so it requires 5.0 VM and libraries (for instance java.security). It has been tested against Sun SDK, removing the original jce.jar and replacing it by ours. * *Package name* **java.math *Package Description* This is a clean room implementation of the package java.math as specified in JDK 5.0. *Current Status* The package is fully implemented. Some methods are fairly optimized (for example multiplication combines paper-and-pencil and Karatsuba algorithms). *Testing * Unit and integration tests (and their documentation) are provided with the code.* * *Implementation Notes The internal representation for BigInteger is two-complement (this is different from the sign-magnitude implementation already donated to Harmony). BigDecimal uses only BigInteger's public interface and implements the full 5.0 specification (which has about twice as many methods as in 1.4). The code uses J2SE 5.0 features, so it requires 5.0 VM. It has been tested against Sun SDK. * ** -- Miguel Montes -- 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: New IBM VME
Daniel Gandara wrote: Oliver Deakin wrote: ok, I'll ask there about removing 1.5 dependencies from java.rmi and compile it to get 1.4 bytecode... I hope that you would not have to remove too much when compiling to 1.4 bytecodes - I guess this is something we still need to investigate. Have you tried building the rmi code with the -target jsr14 option? Id (amongst others, Im sure) be interested to hear what results you get, and whether any alterations are necessary. I'll try building the code with -target jsr14 and see how much has to be removed; I'll create a new thread with the results; ok? Sounds good - thanks My hope is that in the not too distant future we may see one or two of the Harmony VMs stepping up to 1.5 level, and we can begin to use them with our classlib :) hope so too. Thanks, Daniel Regards, Oliver [1] http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200604.mbox/[EMAIL PROTECTED] Daniel Gandara wrote: Oliver, pleased to hear good news from you!! I believe this is great for the project. I have one question regarding the version of the VME, is it 1.5? I'm asking this because we have received contributions of some packages (for example: java.math and java.rmi packages) which are 1.5 (compliant and dependant) but cannot be used with current VM. Thanks, Daniel - Original Message - From: Oliver Deakin [EMAIL PROTECTED] To: harmony-dev@incubator.apache.org Sent: Tuesday, April 04, 2006 1:26 PM Subject: New IBM VME Hi all, I'm pleased to announce that a new IBM VME will be made available soon at: http://www-128.ibm.com/developerworks/java/jdk/harmony/index.html The new VME downloads are named Harmony-vme-win.IA32-v2.zip and Harmony-vme-linux.IA32-v2.tar.gz. I would like to stress that if you download these packages now, they will *not* work with the class library code currently in Harmony Subversion. This VME has been created looking forward to changes that have been discussed on the list, but have not yet been carried out. They are: - completion of renaming of com.ibm packages, especially in LUNI module. The new VME expects only org.apache.harmony package names. - removal of String from the kernel, and addition of an intern(String) method to the org.apache.harmony.kernel.vm.VM class. The new VME does *not* contain String in its kernel jars. It does, however, provide an intern(String) method in the VM class, as was suggested in [1]. The String.intern() method in Harmony will just redirect the call to VM.intern(String). Once these changes are made in the Harmony repository, the new version of the VME will be required to run with Harmony classlib. I will send out a further mail when this is done confirming that the new VME is available and ready to use. A link to the VME v1 will still be available in the same place, and this should still be used until the above changes are made. Regards, Oliver [1] http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200602.mbox/[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] - 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] - 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] - 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]
Refactoring package names
Hi all, Tim and I plan to complete the refactoring of package names from com.ibm to org.apache.harmony over the next few hours. We are going to make a backup of the current classlib trunk in a branch before we make our changes, so we can revert should anything unexpected occur. Please be aware that while we are making these changes the build will probably be broken, so it may be worth not updating until we complete. Ill send a mail to confirm when we are finished. Regards, Oliver -- 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]
[classlib] New snapshot build available
New class library snapshot builds are available on the Harmony binary downloads page: http://cvs.apache.org/dist/incubator/harmony/snapshots/ This is the state of the classlib code at repository revision 391918 (linux) and 391919 (windows) [1], and is made available as a convenience for those who do not have the required tool chain to build the code themselves. The latest downloads for windows and linux are: harmony-classlib-r391918-Linux-x86-snapshot.tar.gz harmony-classlib-r391919-win-x86-snapshot.zip Details of how to rebuild these binaries from source and how to obtain a compatible VM [2] to run the code are given here: http://incubator.apache.org/harmony/subcomponents/classlibrary/build_classlib.html There are a number of bug fixes, enhancements, and new contributions in this new snapshot. Please download it and try it, and if there are any problems send a note to the dev list. Thanks to everyone who has contributed to this build! Regards, Tim [1] they are different repository revision numbers because we share our SVN with other projects, the code in each build is at an identical Harmony level. [2] This is the last snapshot that is designed to run on the IBM VME version 1, subsequent builds will require the VME version 2. Details of this change are being posted to the dev list separately. -- 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: Refactoring package names
FYI: Before we do the refactoring I'm making a copy of trunk onto the branch directory ... I'll remove it once things are settled. Regards, Tim Oliver Deakin wrote: Hi all, Tim and I plan to complete the refactoring of package names from com.ibm to org.apache.harmony over the next few hours. We are going to make a backup of the current classlib trunk in a branch before we make our changes, so we can revert should anything unexpected occur. Please be aware that while we are making these changes the build will probably be broken, so it may be worth not updating until we complete. Ill send a mail to confirm when we are finished. Regards, Oliver -- 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]
Problems with accessing JIRA
Hi, I cannot access JIRA with Service Temporarily Unavailable message. Could someone please investigate? Thank you in advance, -- Anton Avtamonov, 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: Problems with accessing JIRA
Same problem to me:(. Anton Avtamonov wrote: Hi, I cannot access JIRA with Service Temporarily Unavailable message. Could someone please investigate? Thank you in advance, -- Anton Avtamonov, 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] -- 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: Refactoring package names
Ok, the renames are done -- I'll leave this around for a few hours in case somebody screams. Otherwise it is a case of checking out the earlier revision. Regards, Tim Tim Ellison wrote: FYI: Before we do the refactoring I'm making a copy of trunk onto the branch directory ... I'll remove it once things are settled. Regards, Tim Oliver Deakin wrote: Hi all, Tim and I plan to complete the refactoring of package names from com.ibm to org.apache.harmony over the next few hours. We are going to make a backup of the current classlib trunk in a branch before we make our changes, so we can revert should anything unexpected occur. Please be aware that while we are making these changes the build will probably be broken, so it may be worth not updating until we complete. Ill send a mail to confirm when we are finished. Regards, Oliver -- 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]
select one (was: RE: svn commit: r391955 [5/5] - in /incubator/harmony/enhanced/...)
We have pairs of implementations for the following functionality (modules luni and security): ASN1 De/Encoding Base64 De/Encoding DefaultPolicy I'm going to compare and choose one them but I'd appreciate if someone else would compare them too. Thanks, Mikhail - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[classlib][announce] New VM required to run classlib code!
Just so people can't claim they missed it ;-) If you check out the Harmony classlib code *at or before* repository revision 391919 you will need to use the IBM VME version 1 to run the code. If you check out the classlib code now (revision 391957 onwards) you will need to use the IBM VME version 2 to run the code. You cannot mix and match between these versions. Both versions of the IBM VME are available from: http://www.ibm.com/developerworks/java/jdk/harmony Thanks to Oliver for making the new VME available. 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]
[sablevm] SIGSEGV signal received from Cygwin
Hi, I'm doing some testing on SableVM, and noticed that is receives the very same segmentation fault signal that JCHEVM does, from pthread_key_create() which is embedded in: /usr/bin/cygwin1.dll I read around that this problem could be fixed, but the error means that the Cygwin platform can only be used for developing, studying and testing and not for real world use. Let me recap the problems we face when trying to port JCHEVM and SableVM on Windows: problem 1: POSIX dependancy - The code contains a certain number of POSIX calls (dependancies). Much of them can be easily replaced, but some might be hard to replace. problem 2: GCC extensions - The code contains some GCC extensions which are not ANSI. problem 3: Which compiler? - GCC seems to be the best candidate but MSVC is more popular. 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? 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 wrote: I'm doing some testing on SableVM, and noticed that is receives the very same segmentation fault signal that JCHEVM does, from pthread_key_create() which is embedded in: /usr/bin/cygwin1.dll I read around that this problem could be fixed, but the error means that the Cygwin platform can only be used for developing, studying and testing and not for real world use. Can you expand a little on this. I am not sure what you mean. problem 1: POSIX dependancy - The code contains a certain number of POSIX calls (dependancies). Much of them can be easily replaced, but some might be hard to replace. I think that moving to Harmony's port library should solve this. I agree that it shouldn't be hard to fix. problem 2: GCC extensions - The code contains some GCC extensions which are not ANSI. When compiling a switch interpreter (--with-treading=switch), there shouldn't be GCC extensions. The only exception is atomic operations which cannot be expressed in C. Yet, I've found an elegant solution to this: use Hans Boehm's atomic_ops library to get this code out of SableVM. See: http://sablevm.org/bugs/179 problem 3: Which compiler? - GCC seems to be the best candidate but MSVC is more popular. Ideally, I'd like both to work. Getting the faster direct/inlined interpreters to work with MSVC might be tricky (require inline assembly or linking to an asm library), but the switch interpreter shouldn't be a problem. 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 Yep, using this layer and atomic_ops should hopefully be sufficient to remove all system-specific dependencies. If anything is missing, we should probably abstract it into the port layer. Now, the interesting thing would be for Harmony native code to compile and work on something other than ia32. SableVM already works on pretty much anything (using gcc, so far), as long as libffi and GNU classpath compiles on the target. The only other limitation is 2 operations that cannot be expressed in C: compare_and_swap and clear_cache. 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: Starting my next round on BootJVM
Hi Dan,
Enrico,
Are you able to compile this latest source level?
I'm busy at the moment and didn't download your latest snapshot. Sorry :-(
Whether you can or not, would you mind to send
me your MS project and MS workspace files
(I forget if this is the right name on VS. Maybe
this is just Eclipse nomenclature.) I would like
to look at using your settings as the starting
point for MSVS compilations.
Dan Lydick
Yes, I can send you the source and the workspace files.
E-mail is fine?
The tag used for commenting out the code are:
(four slashes)
enrico: (my name)
I just checked and notice that the number of modifications I did is
really little.
The major work was moving the declarations of a certain number of stack
variables up to the top of the body of the function, as shown in the
follwing example:
old_function:
int my_func (void)
{
printf(Ciao);
int i;
i=0;
return i;
}
new_function:
int my_func (void)
{
int i;
printf(Ciao);
i=0;
return i;
}
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 wrote: snip 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 -- 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: Refactoring package names
Oliver Deakin wrote: Tim and I have now completed the package renames at repository revision 391957. It is now safe to update and start building the Harmony classlib again. If you use the IBM VME in combination with Harmony classlib, you will need to download the new version (v2) to continue working with classlib after revision 391957. They can be found at: http://www-128.ibm.com/developerworks/java/jdk/harmony/index.html and are called Harmony-vme-win.IA32-v2.zip for Windows and Harmony-vme-linux.IA32-v2.tar.gz for Linux. The VME v1 is not compatible with Harmony classlib after revision 391957. Awesome! I'm downloading the new VME BTW, there is only IBM Development Package for Apache Harmony v1.0 https://www14.software.ibm.com/webapp/iwm/web/preLogin.do?lang=en_USsource=ahdkS_TACT=105AGX05S_CMP=JDK link in the index page. But after you login (if you already have a IBM ID), following the link you will see the new VME v2. Regards, Oliver Tim Ellison wrote: Ok, the renames are done -- I'll leave this around for a few hours in case somebody screams. Otherwise it is a case of checking out the earlier revision. Regards, Tim Tim Ellison wrote: FYI: Before we do the refactoring I'm making a copy of trunk onto the branch directory ... I'll remove it once things are settled. Regards, Tim Oliver Deakin wrote: Hi all, Tim and I plan to complete the refactoring of package names from com.ibm to org.apache.harmony over the next few hours. We are going to make a backup of the current classlib trunk in a branch before we make our changes, so we can revert should anything unexpected occur. Please be aware that while we are making these changes the build will probably be broken, so it may be worth not updating until we complete. Ill send a mail to confirm when we are finished. Regards, Oliver -- Richard Liang China Software Development Lab, IBM
Re: Refactoring package names
Thanks Richard - this is fixed now Richard Liang wrote: Oliver Deakin wrote: Tim and I have now completed the package renames at repository revision 391957. It is now safe to update and start building the Harmony classlib again. If you use the IBM VME in combination with Harmony classlib, you will need to download the new version (v2) to continue working with classlib after revision 391957. They can be found at: http://www-128.ibm.com/developerworks/java/jdk/harmony/index.html and are called Harmony-vme-win.IA32-v2.zip for Windows and Harmony-vme-linux.IA32-v2.tar.gz for Linux. The VME v1 is not compatible with Harmony classlib after revision 391957. Awesome! I'm downloading the new VME BTW, there is only IBM Development Package for Apache Harmony v1.0 https://www14.software.ibm.com/webapp/iwm/web/preLogin.do?lang=en_USsource=ahdkS_TACT=105AGX05S_CMP=JDK link in the index page. But after you login (if you already have a IBM ID), following the link you will see the new VME v2. Regards, Oliver Tim Ellison wrote: Ok, the renames are done -- I'll leave this around for a few hours in case somebody screams. Otherwise it is a case of checking out the earlier revision. Regards, Tim Tim Ellison wrote: FYI: Before we do the refactoring I'm making a copy of trunk onto the branch directory ... I'll remove it once things are settled. Regards, Tim Oliver Deakin wrote: Hi all, Tim and I plan to complete the refactoring of package names from com.ibm to org.apache.harmony over the next few hours. We are going to make a backup of the current classlib trunk in a branch before we make our changes, so we can revert should anything unexpected occur. Please be aware that while we are making these changes the build will probably be broken, so it may be worth not updating until we complete. Ill send a mail to confirm when we are finished. Regards, Oliver -- 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: [sablevm] SIGSEGV signal received from Cygwin
Hi Etienne,
Enrico Migliore wrote:
I'm doing some testing on SableVM, and noticed that is receives the very
same segmentation fault signal that JCHEVM does, from
pthread_key_create() which is embedded in:
/usr/bin/cygwin1.dll
I read around that this problem could be fixed, but the error means that
the Cygwin platform can only be used for developing, studying and
testing and not for real world use.
Can you expand a little on this. I am not sure what you mean.
I debugged the classical HelloWorld class with DDD and found the problem
in the following function:
_svmf_init(void)
{
pthread_once(...); SEGSEGV signal
}
problem 1: POSIX dependancy
-
The code contains a certain number of POSIX calls (dependancies). Much
of them can be easily replaced, but some might be hard to replace.
I think that moving to Harmony's port library should solve this. I
agree that it shouldn't be hard to fix.
Are you referring to the work-in-progress that is adapting SableVM to
the VMI?
problem 2: GCC extensions
-
The code contains some GCC extensions which are not ANSI.
When compiling a switch interpreter (--with-treading=switch), there
shouldn't be GCC extensions. The only exception is atomic operations
which cannot be expressed in C. Yet, I've found an elegant solution to
this: use Hans Boehm's atomic_ops library to get this code out of
SableVM. See:
http://sablevm.org/bugs/179
Ok
problem 3: Which compiler?
-
GCC seems to be the best candidate but MSVC is more popular.
Ideally, I'd like both to work. Getting the faster direct/inlined
interpreters to work with MSVC might be tricky (require inline assembly
or linking to an asm library), but the switch interpreter shouldn't be a
problem.
I see what you're saying
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
Yep, using this layer and atomic_ops should hopefully be sufficient to
remove all system-specific dependencies. If anything is missing, we
should probably abstract it into the port layer.
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.
Now, the interesting thing would be for Harmony native code to compile
and work on something other than ia32. SableVM already works on pretty
much anything (using gcc, so far), as long as libffi and GNU classpath
compiles on the target. The only other limitation is 2 operations that
cannot be expressed in C: compare_and_swap and clear_cache.
Etienne
That's another reasonable goal :-)
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 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.
problem 1: POSIX dependancy
-
...
I think that moving to Harmony's port library should solve this. I
agree that it shouldn't be hard to fix.
Are you referring to the work-in-progress that is adapting SableVM to
the VMI?
Yep.
problem 2: GCC extensions
-
...
this: use Hans Boehm's atomic_ops library to get this code out of
SableVM. See:
http://sablevm.org/bugs/179
Just FYI, fixing this is a short term objective. (i.e. work in progress).
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
--
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: [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
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
New Harmony Launcher Plug-in Available For Eclipse
Hi, The Apache Harmony launcher plug-in has been updated to work with the new IBM VME announced earlier today in which the kernel jars have been split. Please point your Eclipse update manager at the following site and install version 1.0.1 ... http://svn.apache.org/viewcvs.cgi/*checkout*/incubator/harmony/enhanced/tools/trunk/eclipse/org.apache.harmony.eclipse.site Best regards, George - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: New Harmony Launcher Plug-in Available For Eclipse
The link gives me: An Exception Has Occurred Python Traceback Traceback (most recent call last): File /usr/local/viewcvs-1.0-dev/lib/viewcvs.py, line 3351, in main request.run_viewcvs() ... George Harley wrote: split. Please point your Eclipse update manager at the following site and install version 1.0.1 ... http://svn.apache.org/viewcvs.cgi/*checkout*/incubator/harmony/enhanced/tools/trunk/eclipse/org.apache.harmony.eclipse.site -- 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: New Harmony Launcher Plug-in Available For Eclipse
Hi Etienne, That is as expected, I think, as the URL is intended for the Eclipse update manager not web browsers. Best regards, George Etienne Gagnon wrote: The link gives me: An Exception Has Occurred Python Traceback Traceback (most recent call last): File /usr/local/viewcvs-1.0-dev/lib/viewcvs.py, line 3351, in main request.run_viewcvs() ... George Harley wrote: split. Please point your Eclipse update manager at the following site and install version 1.0.1 ... http://svn.apache.org/viewcvs.cgi/*checkout*/incubator/harmony/enhanced/tools/trunk/eclipse/org.apache.harmony.eclipse.site - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: New Harmony Launcher Plug-in Available For Eclipse
Hi Etienne, That is as expected, I think, as the URL is intended for the Eclipse update manager not web browsers. So, I do not need it if I do not work with Eclipse, do I ? Best regards, George Etienne Gagnon wrote: The link gives me: An Exception Has Occurred Python Traceback Traceback (most recent call last): File /usr/local/viewcvs-1.0-dev/lib/viewcvs.py, line 3351, in main request.run_viewcvs() ... George Harley wrote: split. Please point your Eclipse update manager at the following site and install version 1.0.1 ... http://svn.apache.org/viewcvs.cgi/*checkout*/incubator/harmony/enhanced/tools/trunk/eclipse/org.apache.harmony.eclipse.site - 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: New Harmony Launcher Plug-in Available For Eclipse
[EMAIL PROTECTED] wrote: Hi Etienne, That is as expected, I think, as the URL is intended for the Eclipse update manager not web browsers. So, I do not need it if I do not work with Eclipse, do I ? Hi Hadrien, That's right ; the plug-in is an extension to Eclipse that enables developers to conveniently define a Harmony JRE to the IDE and run applications on it from within their IDE workspace. Best regards, George Best regards, George Etienne Gagnon wrote: The link gives me: An Exception Has Occurred Python Traceback Traceback (most recent call last): File /usr/local/viewcvs-1.0-dev/lib/viewcvs.py, line 3351, in main request.run_viewcvs() ... George Harley wrote: split. Please point your Eclipse update manager at the following site and install version 1.0.1 ... http://svn.apache.org/viewcvs.cgi/*checkout*/incubator/harmony/enhanced/tools/trunk/eclipse/org.apache.harmony.eclipse.site - 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]
Porting Harmony classlib to Sablevm
Hi, in the Harmony Class Library Porting Documentation, it said that VM vendor must implement the kernel classes (like java.lang.Object). In the kernel classes harmony code, most classes are skeletons (for exemple Object.hashCode returns zero). Does it mean IBM VM intercepts directly all calls to these skeleton methods to execute them in native code or load kernel classes from their own package (in a .zip or .jar) linked with VM via native declared methods ? Regards, Hadrien - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Porting Harmony classlib to Sablevm
On 4/6/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hi, Hi Hadrien, in the Harmony Class Library Porting Documentation, it said that VM vendor must implement the kernel classes (like java.lang.Object). In the kernel classes harmony code, most classes are skeletons (for exemple Object.hashCode returns zero). The versions you find in the classlib svn are just stubs for the classlib to build. Does it mean IBM VM intercepts directly all calls to these skeleton methods to execute them in native code or load kernel classes from their own package (in a .zip or .jar) linked with VM via native declared methods ? Yes. The VM vendor is expected to provide the implementations of these classes. As you suspected, the IBM VME contains it's implementations in: deploy/jre/bin/default/luni-kernel.jar and deploy/jre/bin/default/security-kernel.jar. which are the real versions used at runtime. Regards, Mark. -- Mark Hindess [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]
[classlib] update on running Harmony Classlib on GNU Classpath VMs
All, I was able to eliminate almost all mods necessary to run Harmony Classlib on a GNU Classpath VM. The VM used is still JCHEVM. 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. The one remaining mod to JCHEVM is because dlopen() fails to load hynio.dll. I will investigate the cause soon. What is known at this time is that dlopen() will successfully load a DLL that contains the following sections: .bss .data .edata .idata .rdata .reloc .text On the other hand, hynio.dll has the following sections: .data .rdata .reloc .rsrc .text The problem might be caused because hynio.dll is not built with tools that are compatible with cygwin's dlopen(). Does anyone have any suggestions? A zip file with all the mods to get Harmony Classlib to do hello world on JCHEVM have been uploaded to JIRA Harmony-318. -- 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] Created: (HARMONY-318) mods to Harmony Classlib that eliminate most of the changes to JCHEVM
Geir, [resend] Is it OK to commit this stuff to the repo?? Thanks, -Archie weldon washburn (JIRA) wrote: mods to Harmony Classlib that eliminate most of the changes to JCHEVM - Key: HARMONY-318 URL: http://issues.apache.org/jira/browse/HARMONY-318 Project: Harmony Type: Bug Components: Classlib Environment: cygwin Reporter: weldon washburn Most of the modifications to JCHEVM to support Harmony Classlib have been removed. The one remaining mod is because JCHEVM uses cygwin dlopen() to load a DLL. And dlopen(), for an unknown reason, refuses to load hynio.dll. __ 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]
Re: ITC: Contribution of java.math and javax.crypto
Hi Mikhail: I'm glad that you are looking at our code. I'm afraid that the problem was caused by Eclipse's black magic. Searching for a Base 64 decoder, the developer typed B ctrl+space, and the first option was BASE64Decoder. We have even src.zip removed from the workstations, so the absence of doc comments was not a hint. It was clearly a mistake, and we are working on fixing it. Thanks for pointing at it. Miguel On 4/6/06, Mikhail Loenko [EMAIL PROTECTED] wrote: Hello Miguel Thank you for your recent contribution to Harmony project! I've noticed that class javax.crypto.Util invokes a method from undocumented package sun.misc.* I assume that you did not have access to Sun sources, so it probably would be good if you provide a link to how did you learn about that Sun's internal functionality and its usage. Thanks, Mikhail 2006/3/14, Tim Ellison [EMAIL PROTECTED]: Excellent! -- thanks Miguel and team. Regards, Tim Miguel Montes wrote: As it was announced by Iris Gastañaga we are contributing the packages javax.crypto and java.math on behalf of ITC (Córdoba Technolgy Institute). We have been developing this code for several months and we believe it is a valid contribution. Our code not only implements the full 5.0 API but also uses 5.0 features and syntax. As 5.0 is a stated goal of Harmony we hope that a 5.0 VM will be available soon. We are also contributing a set of test cases for both packages. Below there is a short description of the contribution. We will soon contribute also an implementation of java.rmi. *Package name* **javax.crypto * Package Description* This is a clean room implementation of the package javax.crypto as specified in the JDK 5.0. It requires the existence of other java packages, in particular java.security and java.util. It can be used to replace jce.jar in the jdk. *Current Status* The package is almost fully implemented. It does not implement the ExemptionMechanism logic. *Testing * Unit and integration tests (and their documentation) are provided with the code.* * *Implementation Notes The code uses heavily J2SE 5.0 features, such as generics, so it requires 5.0 VM and libraries (for instance java.security). It has been tested against Sun SDK, removing the original jce.jar and replacing it by ours. * *Package name* **java.math *Package Description* This is a clean room implementation of the package java.math as specified in JDK 5.0. *Current Status* The package is fully implemented. Some methods are fairly optimized (for example multiplication combines paper-and-pencil and Karatsuba algorithms). *Testing * Unit and integration tests (and their documentation) are provided with the code.* * *Implementation Notes The internal representation for BigInteger is two-complement (this is different from the sign-magnitude implementation already donated to Harmony). BigDecimal uses only BigInteger's public interface and implements the full 5.0 specification (which has about twice as many methods as in 1.4). The code uses J2SE 5.0 features, so it requires 5.0 VM. It has been tested against Sun SDK. * ** -- Miguel Montes -- 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] -- Miguel Montes
Re: ITC: Contribution of java.math and javax.crypto
Miguel, You can set up Eclipse to avoid this problem by defining access rules that ensure you can only 'see' API packages. Take a look at: https://bugs.eclipse.org/bugs/show_bug.cgi?id=116656 (contains an example for JDK 1.4.2 rules) Regards, Tim Miguel Montes wrote: Hi Mikhail: I'm glad that you are looking at our code. I'm afraid that the problem was caused by Eclipse's black magic. Searching for a Base 64 decoder, the developer typed B ctrl+space, and the first option was BASE64Decoder. We have even src.zip removed from the workstations, so the absence of doc comments was not a hint. It was clearly a mistake, and we are working on fixing it. Thanks for pointing at it. Miguel On 4/6/06, Mikhail Loenko [EMAIL PROTECTED] wrote: Hello Miguel Thank you for your recent contribution to Harmony project! I've noticed that class javax.crypto.Util invokes a method from undocumented package sun.misc.* I assume that you did not have access to Sun sources, so it probably would be good if you provide a link to how did you learn about that Sun's internal functionality and its usage. Thanks, Mikhail 2006/3/14, Tim Ellison [EMAIL PROTECTED]: Excellent! -- thanks Miguel and team. Regards, Tim Miguel Montes wrote: As it was announced by Iris Gastañaga we are contributing the packages javax.crypto and java.math on behalf of ITC (Córdoba Technolgy Institute). We have been developing this code for several months and we believe it is a valid contribution. Our code not only implements the full 5.0 API but also uses 5.0 features and syntax. As 5.0 is a stated goal of Harmony we hope that a 5.0 VM will be available soon. We are also contributing a set of test cases for both packages. Below there is a short description of the contribution. We will soon contribute also an implementation of java.rmi. *Package name* **javax.crypto * Package Description* This is a clean room implementation of the package javax.crypto as specified in the JDK 5.0. It requires the existence of other java packages, in particular java.security and java.util. It can be used to replace jce.jar in the jdk. *Current Status* The package is almost fully implemented. It does not implement the ExemptionMechanism logic. *Testing * Unit and integration tests (and their documentation) are provided with the code.* * *Implementation Notes The code uses heavily J2SE 5.0 features, such as generics, so it requires 5.0 VM and libraries (for instance java.security). It has been tested against Sun SDK, removing the original jce.jar and replacing it by ours. * *Package name* **java.math *Package Description* This is a clean room implementation of the package java.math as specified in JDK 5.0. *Current Status* The package is fully implemented. Some methods are fairly optimized (for example multiplication combines paper-and-pencil and Karatsuba algorithms). *Testing * Unit and integration tests (and their documentation) are provided with the code.* * *Implementation Notes The internal representation for BigInteger is two-complement (this is different from the sign-magnitude implementation already donated to Harmony). BigDecimal uses only BigInteger's public interface and implements the full 5.0 specification (which has about twice as many methods as in 1.4). The code uses J2SE 5.0 features, so it requires 5.0 VM. It has been tested against Sun SDK. * ** -- Miguel Montes -- 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] -- Miguel Montes -- 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: ITC: Contribution of java.math and javax.crypto
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 Regards, Tim Chris Gray wrote: On Thursday 06 April 2006 23:02, Miguel Montes wrote: Hi Mikhail: I'm glad that you are looking at our code. I'm afraid that the problem was caused by Eclipse's black magic. Searching for a Base 64 decoder, the developer typed B ctrl+space, and the first option was BASE64Decoder. We have even src.zip removed from the workstations, so the absence of doc comments was not a hint. It was clearly a mistake, and we are working on fixing it. Thanks for pointing at it. Miguel Guess this is a good illustration of why being able to run eclipse on Classpath or Harmony, and not install even a jre from Sun on the dev machine, is / will be a Good Thing ... Chris -- 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 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. 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? 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. Who is trying to load it? The hynio.dll is scheduled for deletion once we figure out there is no longer a need for it (based on Paulex's ongoing work on IO refactoring). 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: ITC: Contribution of java.math and javax.crypto
Thanks for the tip, Tim. I think the set of access rules for 1.5 should be pretty much the same Miguel On 4/6/06, Tim Ellison [EMAIL PROTECTED] wrote: Miguel, You can set up Eclipse to avoid this problem by defining access rules that ensure you can only 'see' API packages. Take a look at: https://bugs.eclipse.org/bugs/show_bug.cgi?id=116656 (contains an example for JDK 1.4.2 rules) Regards, Tim Miguel Montes wrote: Hi Mikhail: I'm glad that you are looking at our code. I'm afraid that the problem was caused by Eclipse's black magic. Searching for a Base 64 decoder, the developer typed B ctrl+space, and the first option was BASE64Decoder. We have even src.zip removed from the workstations, so the absence of doc comments was not a hint. It was clearly a mistake, and we are working on fixing it. Thanks for pointing at it. Miguel On 4/6/06, Mikhail Loenko [EMAIL PROTECTED] wrote: Hello Miguel Thank you for your recent contribution to Harmony project! I've noticed that class javax.crypto.Util invokes a method from undocumented package sun.misc.* I assume that you did not have access to Sun sources, so it probably would be good if you provide a link to how did you learn about that Sun's internal functionality and its usage. Thanks, Mikhail 2006/3/14, Tim Ellison [EMAIL PROTECTED]: Excellent! -- thanks Miguel and team. Regards, Tim Miguel Montes wrote: As it was announced by Iris Gastañaga we are contributing the packages javax.crypto and java.math on behalf of ITC (Córdoba Technolgy Institute). We have been developing this code for several months and we believe it is a valid contribution. Our code not only implements the full 5.0 API but also uses 5.0 features and syntax. As 5.0 is a stated goal of Harmony we hope that a 5.0 VM will be available soon. We are also contributing a set of test cases for both packages. Below there is a short description of the contribution. We will soon contribute also an implementation of java.rmi. *Package name* **javax.crypto * Package Description* This is a clean room implementation of the package javax.crypto as specified in the JDK 5.0. It requires the existence of other java packages, in particular java.security and java.util. It can be used to replace jce.jar in the jdk. *Current Status* The package is almost fully implemented. It does not implement the ExemptionMechanism logic. *Testing * Unit and integration tests (and their documentation) are provided with the code.* * *Implementation Notes The code uses heavily J2SE 5.0 features, such as generics, so it requires 5.0 VM and libraries (for instance java.security). It has been tested against Sun SDK, removing the original jce.jar and replacing it by ours. * *Package name* **java.math *Package Description* This is a clean room implementation of the package java.math as specified in JDK 5.0. *Current Status* The package is fully implemented. Some methods are fairly optimized (for example multiplication combines paper-and-pencil and Karatsuba algorithms). *Testing * Unit and integration tests (and their documentation) are provided with the code.* * *Implementation Notes The internal representation for BigInteger is two-complement (this is different from the sign-magnitude implementation already donated to Harmony). BigDecimal uses only BigInteger's public interface and implements the full 5.0 specification (which has about twice as many methods as in 1.4). The code uses J2SE 5.0 features, so it requires 5.0 VM. It has been tested against Sun SDK. * ** -- Miguel Montes -- 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] -- Miguel Montes -- 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] -- Miguel Montes
Re: [classlib] update on running Harmony Classlib on GNU Classpath VMs
Hi Tim, 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. 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. 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. 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. 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. The hynio.dll is scheduled for deletion once we figure out there is no longer a need for it (based on Paulex's ongoing work on IO refactoring). Its good to see progress on IO refactoring! 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: [classlib] Switching to a 5.0 compiler
+1 from me, especially with the 1.4 target as an intermediate provision. This should facilitate work while contributions dependent on version 5 begin to happen. At some point, there will be enough version 5 tools around to move away from 1.4 provisions. We will just have to bide our time and it will happen pretty much of its own accord. Dan Lydick [Original Message] From: George Harley [EMAIL PROTECTED] To: harmony-dev@incubator.apache.org Date: 4/5/06 7:29:11 AM Subject: Re: [classlib] Switching to a 5.0 compiler Hi, Using the Sun 5.0 javac with the jsr14 target it is possible to do a complete compile of the Harmony Java source and successfully run the tests on the existing VME. That means we could add in more contributions that depended on 5.0 language features being understood instead of letting them queue up. So +1 from me for using the straightforward but undocumented jsr14 target as a purely temporary measure to keep things moving onwards. Best regards, George - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: New Harmony Launcher Plug-in Available For Eclipse
Hi George: Thanks very much for your work, I've struggled for eclipse Harmony-JRE-configuration for hours this morning until find a solution from your mail :) For alternative, a direct copy of this file org.apache.harmony.eclipse.jdt.launching_1.0.1.jar to eclipse plug-in directory works properly as well :) Best regards, Jimmy,Jing lv 2006/4/7, George Harley [EMAIL PROTECTED]: [EMAIL PROTECTED] wrote: Hi Etienne, That is as expected, I think, as the URL is intended for the Eclipse update manager not web browsers. So, I do not need it if I do not work with Eclipse, do I ? Hi Hadrien, That's right ; the plug-in is an extension to Eclipse that enables developers to conveniently define a Harmony JRE to the IDE and run applications on it from within their IDE workspace. Best regards, George Best regards, George Etienne Gagnon wrote: The link gives me: An Exception Has Occurred Python Traceback Traceback (most recent call last): File /usr/local/viewcvs-1.0-dev/lib/viewcvs.py, line 3351, in main request.run_viewcvs() ... George Harley wrote: split. Please point your Eclipse update manager at the following site and install version 1.0.1 ... http://svn.apache.org/viewcvs.cgi/*checkout*/incubator/harmony/enhanced/tools/trunk/eclipse/org.apache.harmony.eclipse.site - 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: Starting my next round on BootJVM
[Original Message] From: Enrico Migliore [EMAIL PROTECTED] To: harmony-dev@incubator.apache.org Cc: bootjvm [EMAIL PROTECTED] Date: 4/5/06 7:58:57 AM Subject: Re: Starting my next round on BootJVM ...snip... As far as I can say, the main problem of porting a JVM, designed for UNIX, to the Windows environment are the ANSI signals: Windows, in fact, doesn't honor not even a fourth of all ANSI signals, therefore, the JVM signals handler WILL NOT be called by Windows. I am not an MSVS expert, but my previous MS C/C++ work has had no problem using the signal library, which was in any case borrowed from Unix, so I don't think this will be a problem. The only signal I really need is SIGALRM for the time slicer. I don't know yet if and how Cygwin deals with this kind of problem... Those who have compiled it had misc. header files to adjust, but nobody has so far complained about signals. Thanks, Dan Lydick 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: Starting my next round on BootJVM
Hi As far as I can say, the main problem of porting a JVM, designed for UNIX, to the Windows environment are the ANSI signals: Windows, in fact, doesn't honor not even a fourth of all ANSI signals, therefore, the JVM signals handler WILL NOT be called by Windows. I am not an MSVS expert, but my previous MS C/C++ work has had no problem using the signal library, which was in any case borrowed from Unix, so I don't think this will be a problem. The only signal I really need is SIGALRM for the time slicer. If nothing changed since MSVC 6.0 (1999), the signals available in Windows are: SIGABRT,SIGFPE,SIGILL,SIGINT,SIGSEGV,SIGTERM Yet: The SIGILL, SIGSEGV, and SIGTERM signals are not generated under Windows NT. They are included for ANSI compatibility I don't know yet if and how Cygwin deals with this kind of problem... Those who have compiled it had misc. header files to adjust, but nobody has so far complained about signals. Thanks, Dan Lydick snip ... Enrico - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
