Re: [classlib] build / test system
2006/2/15, Geir Magnusson Jr [EMAIL PROTECTED]: Stepan Mishura wrote: I need sync. with repository once a day, for example, in the morning to get yours and Tim's last updates :-) . And during a working day I may do dozen workspace builds. So each build will verify whether used jar files (I think we will have a number of them) are up to date or not. Right? Is this necessary? Well, generally no, because dependencies won't change that fast. When working with systems like this in the past, I would always run in offline mode until something broke - an then I would let it sync. Overall, this was far more time efficient. So we can do jar update target to run it when necessary. And default target will check for jar availability (not version) and run jar-update if there is no jar files... Thoughts? -- Alexey A. Petrenko Intel Middleware Products Division
[jira] Reopened: (HARMONY-67) java.nio.charset.Charset.decode(ByteBuffer) throws unexpected BufferOverflowException for UTF-16BE, UTF-16LE, UTF-16 charsets.
[ http://issues.apache.org/jira/browse/HARMONY-67?page=all ]
Tim Ellison reopened HARMONY-67:
java.nio.charset.Charset.decode(ByteBuffer) throws unexpected
BufferOverflowException for UTF-16BE, UTF-16LE, UTF-16 charsets.
---
Key: HARMONY-67
URL: http://issues.apache.org/jira/browse/HARMONY-67
Project: Harmony
Type: Bug
Components: Classlib
Reporter: Svetlana Samoilenko
Assignee: Tim Ellison
According to j2se 1.4.2 specification for Charset.decode(ByteBuffer b) the
method must not throw any exceptions.
The test listed below shows that there is unexpected BufferOverflowException
thrown if charset name is one in the following: UTF-16BE, UTF-16LE, UTF-16.
BEA does not throw any exceptions.
Code to reproduce:
import java.nio.charset.Charset;
import java.nio.ByteBuffer;
import java.nio.CharBuffer;
public class test2 {
public static void main(String[] args) throws Exception {
byte[] b = new byte[] {(byte)1};
ByteBuffer buf= ByteBuffer.wrap(b);
CharBuffer charbuf=Charset.forName(UTF-16).decode(buf);
System.out.println(CharBuffer.length()=+ charbuf.length());
}
}
Steps to Reproduce:
1. Build Harmony (check-out on 2006-01-30) j2se subset as described in
README.txt.
2. Compile test2.java using BEA 1.4 javac
javac -d . test2.java
3. Run java using compatible VM (J9)
java -showversion test2
Output:
C:\tmpC:\jrockit-j2sdk1.4.2_04\bin\java.exe -showversion test2
java version 1.4.2_04
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_04-b05)
BEA WebLogic JRockit(TM) 1.4.2_04 JVM (build
ari-31788-20040616-1132-win-ia32, Native Threads, GC strategy: parallel)
CharBuffer.length()=0
C:\tmpC:\harmony\trunk\deploy\jre\bin\java -showversion test2
(c) Copyright 1991, 2005 The Apache Software Foundation or its licensors, as
applicable.
java.nio.BufferOverflowException
at java.nio.CharBuffer.put(CharBuffer.java:662)
at java.nio.CharBuffer.put(CharBuffer.java:629)
at java.nio.charset.CharsetDecoder.decode(CharsetDecoder.java:406)
at java.nio.charset.CharsetDecoder.decode(CharsetDecoder.java:243)
at java.nio.charset.Charset.decode(Charset.java:630)
at test2.main(test2.java:8)
Suggested junit test case:
CharsetTest.java
-
import java.nio.charset.Charset;
import java.nio.ByteBuffer;
import java.nio.CharBuffer;
import junit.framework.*;
public class CharsetTest extends TestCase {
public static void main(String[] args) {
junit.textui.TestRunner.run(CharsetTest.class);
}
public void test_decode() {
byte[] b = new byte[] {(byte)1};
ByteBuffer buf= ByteBuffer.wrap(b);
CharBuffer charbuf=Charset.forName(UTF-16).decode(buf);
assertEquals(Assert 0: charset UTF-16,0,charbuf.length());
charbuf=Charset.forName(UTF-16BE).decode(buf);
assertEquals(Assert 1: charset UTF-16BE,0, charbuf.length());
charbuf=Charset.forName(UTF-16LE).decode(buf);
assertEquals(Assert 2: charset UTF16LE,0, charbuf.length());
}
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Closed: (HARMONY-85) java.util.jar.Attributes.Name(String name) does not throw IllegalArgumentException if name.length 70
[ http://issues.apache.org/jira/browse/HARMONY-85?page=all ]
Tim Ellison closed HARMONY-85:
--
Verified by Svetlana.
java.util.jar.Attributes.Name(String name) does not throw
IllegalArgumentException if name.length 70
--
Key: HARMONY-85
URL: http://issues.apache.org/jira/browse/HARMONY-85
Project: Harmony
Type: Bug
Components: Classlib
Reporter: Svetlana Samoilenko
Assignee: Tim Ellison
According to j2se 1.4.2 and 1.5 specification for Attributes.Name(String
name) a string length cannot exceed 70 characters.
Harmony does not throw IllegalArgumentException if name.length 70.
Code to reproduce: import java.util.jar.*;
public class test2 {
public static void main(String args[]) throws Exception {
try {
//no more than 70 chars in attribute name allowed
new Attributes.Name(
01234567890123456789012345678901234567890123456789012345678901234567890);
System.out.println(Failed. Should be IllegalArgumentException
);
} catch(IllegalArgumentException e) {
System.out.println(Expected IllegalArgumentException);
}
}
}
Steps to Reproduce:
1. Build Harmony (check-out on 2006-01-30) j2se subset as described in
README.txt.
2. Compile test2.java using BEA 1.4 javac
javac -d . test2.java
3. Run java using compatible VM (J9)
java -showversion test2
Output:
C:\tmpC:\jrockit-j2sdk1.4.2_04\bin\java.exe -showversion test2
java version 1.4.2_04
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_04-b05)
BEA WebLogic JRockit(TM) 1.4.2_04 JVM (build
ari-31788-20040616-1132-win-ia32, Native Threads, GC strategy: parallel)
Expected IllegalArgumentException
C:\tmpC:\harmony\trunk\deploy\jre\bin\java -showversion test2
(c) Copyright 1991, 2005 The Apache Software Foundation or its licensors, as
applicable.
Failed. Should be IllegalArgumentException
Siggested fix:
@@ -84,7 +84,7 @@
public Name(String s) {
int i = s.length();
- if (i == 0)
+ if (i == 0 || i 70)
throw new IllegalArgumentException();
for (; --i = 0;) {
char ch = s.charAt(i);
Suggested junit test case:
AttributesTest.java
-
import java.util.jar.*;
import junit.framework.*;
public class AttributesTest extends TestCase {
public static void main(String[] args) {
junit.textui.TestRunner.run(AttributesTest.class);
}
public void test_constructor () {
try {
new Attributes.Name(
01234567890123456789012345678901234567890123456789012345678901234567890);
fail(Should be IllegalArgumentException);
} catch(IllegalArgumentException e) {
//expected
}
}
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Closed: (HARMONY-86) java.util.zip.Inflater.needsDictionary() throws unspecified IllegalStateException
[ http://issues.apache.org/jira/browse/HARMONY-86?page=all ]
Tim Ellison closed HARMONY-86:
--
Verified by Svetlana
java.util.zip.Inflater.needsDictionary() throws unspecified
IllegalStateException
-
Key: HARMONY-86
URL: http://issues.apache.org/jira/browse/HARMONY-86
Project: Harmony
Type: Bug
Components: Classlib
Reporter: Svetlana Samoilenko
Assignee: Tim Ellison
According to the j2se 1.4 and 1.5 specification
java.util.zip.needsDictionary() method must not throw any exception.
Harmony throws unspecified IllegalStateException that contradicts
specification.
Code to reproduce:
import java.util.zip.*;
public class test2 {
public static void main(String args[]) {
Inflater inf = new Inflater();
System.out.println(Inflater.needsDictionary() =
+inf.needsDictionary());
}
}
Steps to Reproduce:
1. Build Harmony (check-out on 2006-01-30) j2se subset as described in
README.txt.
2. Compile test2.java using BEA 1.4 javac
javac -d . test2.java
3. Run java using compatible VM (J9)
java -showversion test2
Output:
C:\tmpC:\jrockit-j2sdk1.4.2_04\bin\java.exe -showversion test2
java version 1.4.2_04
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_04-b05)
BEA WebLogic JRockit(TM) 1.4.2_04 JVM (build
ari-31788-20040616-1132-win-ia32, Native Threads, GC strategy: parallel)
Inflater.needsDictionary() = true
C:\tmpC:\harmony\trunk\deploy\jre\bin\java -showversion test2
(c) Copyright 1991, 2005 The Apache Software Foundation or its licensors, as
applicable.
java.lang.IllegalStateException
at java.util.zip.Inflater.needsDictionary(Inflater.java:212)
at test2.main(test2.java:8)
Siggested fix: to remove the lines in needsDictionary() method in
archive/src/main/java/java/util/zip/Inflater.java :
211 if (inputBuffer == null)
212throw new IllegalStateException();
Suggested junit test case:
InflaterTest.java
-
import java.util.zip.*;
import junit.framework.*;
public class InflaterTest extends TestCase {
public static void main(String[] args) {
junit.textui.TestRunner.run(InflaterTest .class);
}
public void test_needsDictionary () {
Inflater inf = new Inflater();
assertFalse(inf.needsDictionary());
}
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
Re: [classlib] proposal to revisit componentization for security (was: Re: problems with security2)
Sounds reasonable.
Sure, I can make 'getInstance' functionality visible as an internal API.
So we put classes that has many internal dependencies into the same component,
but not only that. For example java.lang.Error and java.lang.Ecxeption do not
have internal dependencies but we put them into the same component.
Having internal dependency is not the only reasong to go into the same
component. Other reasons could be belonging to the same package or having
some semantical connection.
For example I'd put java.security.cert and javax.security.cert into the same
component.
What do you think?
Thanks,
Mikhail
On 2/15/06, Tim Ellison [EMAIL PROTECTED] wrote:
Mikhail Loenko wrote:
There is coupling.
BTW... Could you give an example of close and weak coupling?
Sure. The goal is to define modules that represent functional units
whose implementation can be contained within the module as much as
possible. The measure of coupling is the number of internal-API
dependencies shared between two modules. (Internal-APIs are those that
Anton described, and that we are proposing to put into
org.apache.harmony.module_name.whatever packages and explicitly
export from the module.)
For example, we have code like LUNI and NIO that require some
non-Java-API dependencies upon one another, but these are 'weakly'
coupled because they are coupled by a small number of 'internal APIs'.
Where the code has a large number of implementation dependencies that
you would not want to export then that is an indication of close
coupling. So, for example, if we tried to separate java.io into its own
module we would have lots of impl dependencies between that module and
LUNI that would indicate poor modularity. Similarly trying to move the
NIO buffers impls out to a separate module to NIO would result in those
two modules being closely coupled.
The following two groups of classes use the same internal stuff:
GROUP1 (use/provide inernal implementation of 'getInstance' ):
Can you make this visible as an internal API (e.g. exported factory type)?
java.security.AlgorithmParameterGenerator
java.security.AlgorithmParameters
java.security.KeyFactory
java.security.KeyPairGenerator
java.security.KeyStore
java.security.KeyStoreSpi
java.security.MessageDigest
java.security.Provider
java.security.SecureRandom
java.security.Security
java.security.Signature
java.security.cert.CertPathBuilder
java.security.cert.CertPathValidator
java.security.cert.CertStore
java.security.cert.CertificateFactory
javax.crypto.Cipher
javax.crypto.ExemptionMechanism
javax.crypto.KeyAgreement
javax.crypto.KeyGenerator
javax.crypto.Mac
javax.crypto.SecretKeyFactory
javax.net.ssl.KeyManagerFactory
javax.net.ssl.SSLContext
javax.net.ssl.SSLServerSocketFactory
javax.net.ssl.SSLSocketFactory
javax.net.ssl.TrustManagerFactory
GROUP2 (all use internal implementation of ASN.1):
The ASN.1 code is a good example of an internal-API that we would want
to expose to other module developers.
To be clear, we are not extending the Java API here, just making it
visible as a contract that replacements to whatever module implements
it must conform.
java.security.cert.PolicyQualifierInfo
java.security.cert.TrustAnchor
java.security.cert.X509CRLSelector
java.security.cert.X509CertSelector
javax.crypto.EncryptedPrivateKeyInfo
javax.security.auth.kerberos.KerberosKey
javax.security.auth.kerberos.KerberosTicket
All other dependencies seem to be public ones.
Sounds good.
Regards,
Tim
On 2/14/06, Tim Ellison [EMAIL PROTECTED] wrote:
Mikhail Loenko wrote:
Tim
On 2/13/06, Tim Ellison [EMAIL PROTECTED] wrote:
Mikhail Loenko wrote:
It looks good but it is not clear where would you put certification
stuff.
According to SUN's guide it is splitted between JSSE and general
security.
(According to SUN general security includes also crypto architecture)
I wouldn't get too hung up about where Sun put it. There is likely a
different partitioning about where the architectural/semantic boundaries
are best placed, and how we componentize the implementation.
Looking into this a bit more, the certificate management
(java.security.cert.*) code should likely go in 'general security'.
It is mostly instinct behind the decision, but that was formed by the
following reasoning:
Historical - JCE, JSSE and JAAS used to be optional packages for the JDK
at a time when the certificate management code was included in the JDK
By process of exclusion - the other modules ('crypto', 'x-net' and
'jaas') are self-contained and can be removed without breaking any other
APIs.
That was in the past. In 1.5 for example
java.security.KeyStore.SecretKeyEntry.getSecretKey()
returns
javax.crypto.SecretKey
Method
java.security.AuthProvider.login()
takes arguments
javax.security.auth.Subject and
[jira] Commented: (HARMONY-67) java.nio.charset.Charset.decode(ByteBuffer) throws unexpected BufferOverflowException for UTF-16BE, UTF-16LE, UTF-16 charsets.
[
http://issues.apache.org/jira/browse/HARMONY-67?page=comments#action_12366469 ]
Vladimir Strigun commented on HARMONY-67:
-
I don't think that this bug should be reopened. Possibly it's another
compatibility bug, and I'll try to explain why.
Specification of decode method says that A newly-allocated character buffer
containing the result of the decoding operation. will be returned. Harmony
implementation of decode buffer returns CharBuffer with length equal to 1.
Inside resulting buffer we can see one element: FFFD, i.e default replacement
for unmappable character. In compliance with spec Charset.decode(buffer)
method invoke following line:
cs.newDecoder().onMalformedInput(CodingErrorAction.REPLACE).onUnmappableCharacter(CodingErrorAction.REPLACE).decode(bb);
So, IMO Harmony implementation is fully correspond to the spec.
java.nio.charset.Charset.decode(ByteBuffer) throws unexpected
BufferOverflowException for UTF-16BE, UTF-16LE, UTF-16 charsets.
---
Key: HARMONY-67
URL: http://issues.apache.org/jira/browse/HARMONY-67
Project: Harmony
Type: Bug
Components: Classlib
Reporter: Svetlana Samoilenko
Assignee: Tim Ellison
According to j2se 1.4.2 specification for Charset.decode(ByteBuffer b) the
method must not throw any exceptions.
The test listed below shows that there is unexpected BufferOverflowException
thrown if charset name is one in the following: UTF-16BE, UTF-16LE, UTF-16.
BEA does not throw any exceptions.
Code to reproduce:
import java.nio.charset.Charset;
import java.nio.ByteBuffer;
import java.nio.CharBuffer;
public class test2 {
public static void main(String[] args) throws Exception {
byte[] b = new byte[] {(byte)1};
ByteBuffer buf= ByteBuffer.wrap(b);
CharBuffer charbuf=Charset.forName(UTF-16).decode(buf);
System.out.println(CharBuffer.length()=+ charbuf.length());
}
}
Steps to Reproduce:
1. Build Harmony (check-out on 2006-01-30) j2se subset as described in
README.txt.
2. Compile test2.java using BEA 1.4 javac
javac -d . test2.java
3. Run java using compatible VM (J9)
java -showversion test2
Output:
C:\tmpC:\jrockit-j2sdk1.4.2_04\bin\java.exe -showversion test2
java version 1.4.2_04
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_04-b05)
BEA WebLogic JRockit(TM) 1.4.2_04 JVM (build
ari-31788-20040616-1132-win-ia32, Native Threads, GC strategy: parallel)
CharBuffer.length()=0
C:\tmpC:\harmony\trunk\deploy\jre\bin\java -showversion test2
(c) Copyright 1991, 2005 The Apache Software Foundation or its licensors, as
applicable.
java.nio.BufferOverflowException
at java.nio.CharBuffer.put(CharBuffer.java:662)
at java.nio.CharBuffer.put(CharBuffer.java:629)
at java.nio.charset.CharsetDecoder.decode(CharsetDecoder.java:406)
at java.nio.charset.CharsetDecoder.decode(CharsetDecoder.java:243)
at java.nio.charset.Charset.decode(Charset.java:630)
at test2.main(test2.java:8)
Suggested junit test case:
CharsetTest.java
-
import java.nio.charset.Charset;
import java.nio.ByteBuffer;
import java.nio.CharBuffer;
import junit.framework.*;
public class CharsetTest extends TestCase {
public static void main(String[] args) {
junit.textui.TestRunner.run(CharsetTest.class);
}
public void test_decode() {
byte[] b = new byte[] {(byte)1};
ByteBuffer buf= ByteBuffer.wrap(b);
CharBuffer charbuf=Charset.forName(UTF-16).decode(buf);
assertEquals(Assert 0: charset UTF-16,0,charbuf.length());
charbuf=Charset.forName(UTF-16BE).decode(buf);
assertEquals(Assert 1: charset UTF-16BE,0, charbuf.length());
charbuf=Charset.forName(UTF-16LE).decode(buf);
assertEquals(Assert 2: charset UTF16LE,0, charbuf.length());
}
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
Re: [jchevm] porting harmony classlib to JCHEVM
Geir Magnusson Jr wrote: Archie Cobbs wrote: snip Compare Classlib's Thread.java: trunk/modules/kernel/src/main/java/java/lang/Thread.java with these files from Classpath: http://cvs.savannah.gnu.org/viewcvs/classpath/java/lang/Thread.java?rev=1.17root=classpathview=markup http://cvs.savannah.gnu.org/viewcvs/classpath/vm/reference/java/lang/VMThread.java?rev=1.9root=classpathview=markup Note every method in Classlib's Thread.java is: return null. On the other hand, Classpath's API is much more complete and fully developed, race conditions have been analyzed and handled, SecurityManager implications have been taken into account, etc. To get Classlib to the same level, you'd have to duplicate a whole bunch of (at times very tricky and subtle) work -- not only implementing the API, but figuring out what the right API is -- that's already been figured out over several years in Classpath. Ok, I'm not sure what you are referring to. I know that our VM API is production tested on a certified, complete stack. I'm not sure where Classpath has been used in anger yet. In short there is lots of unimplemented stuff remaining in Classlib's existing API. From a simple argument of expediency, not to mention the benefits for debugging previously mentioned, adopting the already baked Classpath API makes lots of sense. We might be missing information from IBM on this. Tim? Not sure what information you are expecting. Caveat: I've deliberately not studied the Classpath VM interface code, so my understanding is limited. As Archie points out, the Harmony classlib code has a 'higher-level' VM interface than Classpath. Taking his Thread example, in classlib the VM implementor shows up with a full Thread implementation, and AIUI in Classpath they are required to implement a VMThread type and can reuse common code in Classpath's Thread. That's fine, and if Weldon or anyone else wants to create a version of Thread that is implemented in terms of the same VMThread interface then I say 'go for it'. (If Classpath were to dual license their code that would be even better!) A while ago there was a discussion about the pro's and con's of splitting Thread into common and VM-specific sections at all, even before trying to agree on what goes where. We can go through that again if people like. IMHO, saying 'show up with a working Thread' kinda sidesteps that discussion, and people can implement it as they see fit. I have no problem with growing the classlib KERNEL stubs to have code that VMs may choose to reuse. For example, you can imagine providing a Java-based impl of TLS that some VMs would just want to use (or the String.intern() as another example); but without imposing it on all VMs that may choose to implement TLS|whatever as they see fit. So to close the loop -- I'm happy to share info, just not sure what you want. If you want to know how IBM's VME implemented Thread then I can take you down to a certain level at which point it becomes so VM-specific that I'm not convinced it would help anyone. Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.
build problems (was: Re: [jchevm] porting harmony classlib to JCHEVM)
what build problems do you have? Regards, Tim Weldon Washburn wrote: Tim, Good points below. I have a first cut at a kernel_path/Thread.java that glues Harmony Class Library to GNU Classpath compatible VM (jchevm). I will post it as soon as I get it to compile. Then we will have some code for a debate on what parts (if any) can be sucked into the baseline kernel/Thread.java. I am currently having problems getting the Class Library build system working. - Weldon On 2/15/06, Tim Ellison [EMAIL PROTECTED] wrote: Geir Magnusson Jr wrote: Archie Cobbs wrote: snip Compare Classlib's Thread.java: trunk/modules/kernel/src/main/java/java/lang/Thread.java with these files from Classpath: http://cvs.savannah.gnu.org/viewcvs/classpath/java/lang/Thread.java?rev=1.17root=classpathview=markup http://cvs.savannah.gnu.org/viewcvs/classpath/vm/reference/java/lang/VMThread.java?rev=1.9root=classpathview=markup Note every method in Classlib's Thread.java is: return null. On the other hand, Classpath's API is much more complete and fully developed, race conditions have been analyzed and handled, SecurityManager implications have been taken into account, etc. To get Classlib to the same level, you'd have to duplicate a whole bunch of (at times very tricky and subtle) work -- not only implementing the API, but figuring out what the right API is -- that's already been figured out over several years in Classpath. Ok, I'm not sure what you are referring to. I know that our VM API is production tested on a certified, complete stack. I'm not sure where Classpath has been used in anger yet. In short there is lots of unimplemented stuff remaining in Classlib's existing API. From a simple argument of expediency, not to mention the benefits for debugging previously mentioned, adopting the already baked Classpath API makes lots of sense. We might be missing information from IBM on this. Tim? Not sure what information you are expecting. Caveat: I've deliberately not studied the Classpath VM interface code, so my understanding is limited. As Archie points out, the Harmony classlib code has a 'higher-level' VM interface than Classpath. Taking his Thread example, in classlib the VM implementor shows up with a full Thread implementation, and AIUI in Classpath they are required to implement a VMThread type and can reuse common code in Classpath's Thread. That's fine, and if Weldon or anyone else wants to create a version of Thread that is implemented in terms of the same VMThread interface then I say 'go for it'. (If Classpath were to dual license their code that would be even better!) A while ago there was a discussion about the pro's and con's of splitting Thread into common and VM-specific sections at all, even before trying to agree on what goes where. We can go through that again if people like. IMHO, saying 'show up with a working Thread' kinda sidesteps that discussion, and people can implement it as they see fit. I have no problem with growing the classlib KERNEL stubs to have code that VMs may choose to reuse. For example, you can imagine providing a Java-based impl of TLS that some VMs would just want to use (or the String.intern() as another example); but without imposing it on all VMs that may choose to implement TLS|whatever as they see fit. So to close the loop -- I'm happy to share info, just not sure what you want. If you want to know how IBM's VME implemented Thread then I can take you down to a certain level at which point it becomes so VM-specific that I'm not convinced it would help anyone. Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. -- Weldon Washburn Intel Middleware Products Division -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.
newbie to project-where to start from
I need to know how I can start on harmony. I would like to start by writing some tests. Here are my questions : 1. Are there any predefined assertions to test or do we simply write test after looking at the api docs for each method 2. Are there any naming conventions for test cases 3. When one files a JIRA for a failed test, does one also attach the test to the JIRA -- Karan Singh
Platform dependent code placement (was: Re: repo layout again)
Hi All,
Sorry for my late attempt to resurrect this thread, but I'm not sure
if we've already came to a well-defined picture here:
On 1/4/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Some more platform tree names:
solaris32.sparc solaris64.sparc
linux32.sparc linux64.sparc
darwin32.ppc (Is this correct for the new MAC boxes?)
Wouldn't the wordsize be better associated with the processor family?
So solaris.sparc32, windows.x86, linux.ppc32, and so on.
Better yet, keep the three variables independent because the
_same_ chip can operate in both a 32-bit and a 64-bit modes.
It is the operating system that works in one mode or the other.
Furthermore, a 64-bit OS also allows 32-bit applications to run
on it in a compatibility mode. A good example of this is the
Sun JDK that runs on Solaris. There is a 32-bit version, which
is the default, and there is an additional 64-bit module that
may be added on for running in 64-bit mode. The same SPARC
processor is used for both.
I think another example showing the benefit of having independent OS /
CPU attributes could be scenario when we have, for instance, a JIT
compiler which is producing nearly equal code for different OSes on
IA32 (or whataver CPU), and, for example, file I/O module which
doesn't care a much about the specific CPU, but rather cares about
the specific OS. In other words, there will be likely the code which
can be easily shared between the different CPU's, and the code which
can be shared between the different OSes.
On the other hand, having a separate source trees like linux32.sparc,
solaris64.sparc, win.IA32 for each specific platform combination may
lead to a huge code duplication. We may need to be able to share the
code through the certain, but not through all platform combinations.
To address that issue, I can suggest a pretty straightforward scheme
for platform-dependent code placement which looks as follows:
1. There is a fixed set of attributes which denotes a specific target
configuration. As a starter set, we may have OS (for operating system)
and, say ARCH (for architecture) attributes. This set can be extended
later, but, as it was suggested, let's don't cross that bridge if we
come to it.
2. Files in the source tree are selected for compilation based on the
OS or ARCH attribute values which may (or may not appear) in a file or
directory name.
Some examples are:
src\main\native\solaris\foo.cpp
- means file is applicable for whatever system running Solaris;
src\main\native\win\foo_ia32.cpp
- file is applicable only for Windows / IA32;
src\main\native\foo_ia32_em64t.cpp
- file can be compiled for whatever OS on either IA32 or EM64T
architecture, but nothing else.
The formal file selection rule may look like:
(1) File is applicable for the given OS value if its pathname contains regexp
[\W_]${OS}[\W_], or pathname doesn't contain any OS value;
(2) File is applicable for the given ARCH value if its pathname contains regexp
[\W_]${ARCH}[\W_], or pathname doesn't contain any ARCH value;
(3) File is selected for a compilation if it satisfies both (1) and
(2) criteria.
One can see that this naming convention gives developers enough
freedom to layout their code in a most convenient way (actually,
experience shows that the meaning of convenient may differ
significantly depending on a component type :). On the other hand, it
gives well defined (and hopefully intuitive enough) rule showing
whether the particular file is picked up by the compiler or not,
depending on a configuration.
In addition to the above, the code could also be selected for
compilation by means of #defines directives in C/C++ files (it is
convenient when the most of a file is platform-independent, with the
exception of just a few lines of code). The building system could set
up the OS and ARCH attributes as appropriate defines for the C/C++
code.
For example, for Windows/IA32 config, the following defines could be set:
#define OS WIN
#define WIN
#define ARCH IA32
#define IA32
Then the platform-dependent code sections may look like:
#ifdef WIN
….
#endif
which is essentially same as:
#if OS == WIN
….
#endif
It is important that OS/ARCH (or whatever additional) attribute names
and values are used consistently in the file names and define
directives.
Finally, I'd suggest that the platform dependent code can be organized
in 3 different ways:
(1) Explicitly, via defining the appropriate file list. For example,
Ant xml file may choose either one or another fileset, depending on
the current OS and ARCH property values. This approach is most
convenient, for example, whenever a third-party code is compiled or
the file names could not be changed for some reason.
(2) Via the file path naming convention. This is the preferred
approach and works well whenever distinctive files for different
platforms can be identified.
(3) By means of the preprocessor directives. This could be convenient
Re: newbie to project-where to start from
karan malhi wrote: I need to know how I can start on harmony. I would like to start by writing some tests. That would be great -- thanks Karan! If you have detailed knowledge of another implementation of Java then we need to talk further, otherwise dive right in. Examples of 'detailed knowledge' can be found in the Harmony Questionnaire [0] [0] http://incubator.apache.org/harmony/auth_cont_quest.html Here are my questions : 1. Are there any predefined assertions to test or do we simply write test after looking at the api docs for each method Looking at the spec and writing tests is a pretty good start. There are some tests in the repository already, and some more incoming, but we'll worry about merging new code into the full test suite. 2. Are there any naming conventions for test cases Yes. Pick a module [1] that interests you and from there the test code is in module_name/src/test/java/org.apache.harmony.tests.pkg.typeTest.java where pkg and type are the package and type under test; see here [2] for an example. We are using JUnit, so your test class extends junit.framework.TestCase. Each test method is public void test_methodID() where methodID is the method under test including param types; e.g. [3]. Don't worry too much about the names, we'll fix them on the way in if necessary. [1] http://svn.apache.org/viewcvs.cgi/incubator/harmony/enhanced/classlib/trunk/modules/ [2] http://svn.apache.org/viewcvs.cgi/incubator/harmony/enhanced/classlib/trunk/modules/luni/src/test/java/org/apache/harmony/tests/java/net/ [3] http://svn.apache.org/viewcvs.cgi/incubator/harmony/enhanced/classlib/trunk/modules/luni/src/test/java/org/apache/harmony/tests/java/net/InetAddressTest.java?view=markup 3. When one files a JIRA for a failed test, does one also attach the test to the JIRA Yes please, a succinct description with a unit test is great, and if you have a proposed patch that would be even better ;-) We have had lots of good examples of bug reports, here's one I picked at random to show the type of thing we like to see: https://issues.apache.org/jira/browse/HARMONY-53 Thanks again for your offer of help. Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.
Re: newbie to project-where to start from
Just piggybacking on this. I've been on the mailing list for some months now and have downloaded the code and been brwosing through it. I'm a reasonably adept programmer but this is a very major project and it's a little daunting to know just where to begin. I'd appreciate any suggestions of where I might be best able to contribute my time. I'd prefer to work on the actual implementation rather than just testing if possible but I'm keen to help out anywhere that might be useful. Cheers James. -- James Pluck PalmOS Ergo Sum
Increasing Java Startup Performance
I went to a this talk this morning http://www.csail.mit.edu/events/eventcalendar/calendar.php?show=eventid=978 that presented the paper found at http://www.research.ibm.com/people/m/marnold/arnold-welc-rajan.final.pdf which implements a very interesting trick to speed up java startup performance: save the hotspot information in a repository (at JVM shut down) so that the JIT doesn't have to wait when it starts until it knows what is a hotspot to start compiling it. the performance improvements are not likely to change the perception that java is awefully slow to start up on the desktop, but it's a clever idea. In the meanwhile, Sun's attempt to solve the same problem in JSE6 is this: http://java.sun.com/developer/JDCTechTips/2005/tt1115.html#1 No comment. -- Stefano.
RE: newbie to project-where to start from
JCSC is a Java Coding Standard Checker - ie, just conformance, not coverage. There's a good list of code coverage tools at http://java-source.net/open-source/code-coverage. Matt -Original Message- From: Mikhail Loenko [mailto:[EMAIL PROTECTED] Sent: Thursday, 16 February 2006 4:00 PM To: harmony-dev@incubator.apache.org Subject: Re: newbie to project-where to start from Hi Karan if there is some area that you are interesting in the most, you might want to say it and people who developed classes in that area could advise for which of them are untested. All, I think it makes sense to include into the build a target that calculates coverage - that would advise people where to contribute the tests. BTW, what do you think about JCSC coverage tool? http://jcsc.sourceforge.net/ Thanks, Mikhail On 2/16/06, karan malhi [EMAIL PROTECTED] wrote: Tim, Thanks for such a detailed reply. I have a couple of more questions: 1. Do I have to sign and fax back the questionnaire before I start working on harmony ? 2. I know this is dumb but I saw in some previous posts that the tests were being compiled with jrockit. I guess I can use any compiler (sun) without causing any licensing issues - right? Sorry, but I am very poor with this licensing stuff. Just want to make sure I am playing within the rules of the game. Tim Ellison wrote: karan malhi wrote: I need to know how I can start on harmony. I would like to start by writing some tests. That would be great -- thanks Karan! If you have detailed knowledge of another implementation of Java then we need to talk further, otherwise dive right in. Examples of 'detailed knowledge' can be found in the Harmony Questionnaire [0] [0] http://incubator.apache.org/harmony/auth_cont_quest.html Here are my questions : 1. Are there any predefined assertions to test or do we simply write test after looking at the api docs for each method Looking at the spec and writing tests is a pretty good start. There are some tests in the repository already, and some more incoming, but we'll worry about merging new code into the full test suite. 2. Are there any naming conventions for test cases Yes. Pick a module [1] that interests you and from there the test code is in module_name/src/test/java/org.apache.harmony.tests.pkg.t ypeTest.java where pkg and type are the package and type under test; see here [2] for an example. We are using JUnit, so your test class extends junit.framework.TestCase. Each test method is public void test_methodID() where methodID is the method under test including param types; e.g. [3]. Don't worry too much about the names, we'll fix them on the way in if necessary. [1] http://svn.apache.org/viewcvs.cgi/incubator/harmony/enhanced/ classlib/trunk/modules/ [2] http://svn.apache.org/viewcvs.cgi/incubator/harmony/enhanced/ classlib/trunk/modules/luni/src/test/java/org/apache/harmony/tests/java/ net/ [3] http://svn.apache.org/viewcvs.cgi/incubator/harmony/enhanced/ classlib/trunk/modules/luni/src/test/java/org/apache/harmony/tests/java/ net/InetAddressT est.java?view=markup 3. When one files a JIRA for a failed test, does one also attach the test to the JIRA Yes please, a succinct description with a unit test is great, and if you have a proposed patch that would be even better ;-) We have had lots of good examples of bug reports, here's one I picked at random to show the type of thing we like to see: https://issues.apache.org/jira/browse/HARMONY-53 Thanks again for your offer of help. Regards, Tim -- Karan Singh
Re: newbie to project-where to start from
I mixed with Emma - both of them of 4 chars :) http://emma.sourceforge.net Mikhail On 2/16/06, Matthew Johnson [EMAIL PROTECTED] wrote: JCSC is a Java Coding Standard Checker - ie, just conformance, not coverage. There's a good list of code coverage tools at http://java-source.net/open-source/code-coverage. Matt -Original Message- From: Mikhail Loenko [mailto:[EMAIL PROTECTED] Sent: Thursday, 16 February 2006 4:00 PM To: harmony-dev@incubator.apache.org Subject: Re: newbie to project-where to start from Hi Karan if there is some area that you are interesting in the most, you might want to say it and people who developed classes in that area could advise for which of them are untested. All, I think it makes sense to include into the build a target that calculates coverage - that would advise people where to contribute the tests. BTW, what do you think about JCSC coverage tool? http://jcsc.sourceforge.net/ Thanks, Mikhail On 2/16/06, karan malhi [EMAIL PROTECTED] wrote: Tim, Thanks for such a detailed reply. I have a couple of more questions: 1. Do I have to sign and fax back the questionnaire before I start working on harmony ? 2. I know this is dumb but I saw in some previous posts that the tests were being compiled with jrockit. I guess I can use any compiler (sun) without causing any licensing issues - right? Sorry, but I am very poor with this licensing stuff. Just want to make sure I am playing within the rules of the game. Tim Ellison wrote: karan malhi wrote: I need to know how I can start on harmony. I would like to start by writing some tests. That would be great -- thanks Karan! If you have detailed knowledge of another implementation of Java then we need to talk further, otherwise dive right in. Examples of 'detailed knowledge' can be found in the Harmony Questionnaire [0] [0] http://incubator.apache.org/harmony/auth_cont_quest.html Here are my questions : 1. Are there any predefined assertions to test or do we simply write test after looking at the api docs for each method Looking at the spec and writing tests is a pretty good start. There are some tests in the repository already, and some more incoming, but we'll worry about merging new code into the full test suite. 2. Are there any naming conventions for test cases Yes. Pick a module [1] that interests you and from there the test code is in module_name/src/test/java/org.apache.harmony.tests.pkg.t ypeTest.java where pkg and type are the package and type under test; see here [2] for an example. We are using JUnit, so your test class extends junit.framework.TestCase. Each test method is public void test_methodID() where methodID is the method under test including param types; e.g. [3]. Don't worry too much about the names, we'll fix them on the way in if necessary. [1] http://svn.apache.org/viewcvs.cgi/incubator/harmony/enhanced/ classlib/trunk/modules/ [2] http://svn.apache.org/viewcvs.cgi/incubator/harmony/enhanced/ classlib/trunk/modules/luni/src/test/java/org/apache/harmony/tests/java/ net/ [3] http://svn.apache.org/viewcvs.cgi/incubator/harmony/enhanced/ classlib/trunk/modules/luni/src/test/java/org/apache/harmony/tests/java/ net/InetAddressT est.java?view=markup 3. When one files a JIRA for a failed test, does one also attach the test to the JIRA Yes please, a succinct description with a unit test is great, and if you have a proposed patch that would be even better ;-) We have had lots of good examples of bug reports, here's one I picked at random to show the type of thing we like to see: https://issues.apache.org/jira/browse/HARMONY-53 Thanks again for your offer of help. Regards, Tim -- Karan Singh
[jira] Created: (HARMONY-95) Extract auth component from 'security2' module
Extract auth component from 'security2' module -- Key: HARMONY-95 URL: http://issues.apache.org/jira/browse/HARMONY-95 Project: Harmony Type: Task Components: Classlib Reporter: Stepan Mishura 'security2' module includes API that provides authorization, authentication and secure communication. As was agreed on harmony-dev list this API will be formed as a separate module - auth. (for initial proposal see http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200601.mbox/[EMAIL PROTECTED]) The new module includes the following packages: javax.security.auth javax.security.auth.callback javax.security.auth.kerberos javax.security.auth.login javax.security.auth.spi javax.security.auth.x500 javax.security.sasl org.ietf.jgss -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[classlib] do we need a global exclude list?
Did anybody think of creating a 'global' (i.e. shared by all modules) exclude list or every module will have its own exclude list? Or Harmony tests will always pass and we don't need it at all :-) I see at least the following benefits of creating 'global' exclude list: all know issues are kept in one well known place (they don't spread between several private lists), also it is easier to create an exclude list for a target platform, for example, linux.exclude or win.exclude. Thoughts? Thanks, Stepan Mishura Intel Middleware Products Division
I welcome J2SE 6's faster-splash.... re: Java speed-up
On 2/16/06, Stefano Mazzocchi [EMAIL PROTECTED] wrote: which implements a very interesting trick to speed up java startup performance: save the hotspot information in a repository (at JVM shut down) so that the JIT doesn't have to wait when it starts until it knows what is a hotspot to start compiling it. the performance improvements are not likely to change the perception that java is awefully slow to start up on the desktop, but it's a clever idea. In the meanwhile, Sun's attempt to solve the same problem in JSE6 is this= : http://java.sun.com/developer/JDCTechTips/2005/tt1115.html#1 No comment. You try to sound clever by making that statement, but imho, despite any other speed-up work who might be implemented, Sun's solution is very important, and something that should have been implemented a long, long time ago. I welcome their implementation, even if late. Get this: Splash screens sever an important purpose: they're a visual cue to tell the user that the program is loading (even if it takes a long time). It's all about PERCEPTION. Java aps are PERCEIVED as slower because the computer appears to freeze until the program's UI is finally showed on the screen (after ALL classes -and even more if it uses Swing- needed to run are loaded- By then, the user is no longer interested in seeing a splash screen, he's already wondering why it took so long See, most Flash content on the web takes an AWFUL LOT of time to download, yet if you ask users, they'll tell you that Flash loads faster than java. The difference? Flash applets can show a message RIGHT AWAY and often display a progress dialog as the rest of the flash cr*p is downloading, telling the user what is going on. In contrast, java applets (and desktop applications as well) freeze the user experience until the applet (or desktop app) has loaded. I wonder why no one has tought about having java auto-load at startup and having a single instance of the Java VM running all the time, and then pass control of the first loaded java application to it (as Mozilla or Firefox pre-loads itself at boot time when the quick launch feature is enabled). FC
Re: NDA issues and acceptable use of sun source (was: Re: JavaSound Was: java.sql.*)
Leo Simons mail at leosimons.com writes: Since the JDK stuff is now all mostly out in the public, and most NDAs are effectively voided once the information they are meant to protect is available through other means not involving an NDA. Missing the cue by just a few days, Sun Microsystems proudly unveiled a new license to go with the 1.6 Mustang beta, and it contains the following, explicit talk about trade secrets, and confidentiality agreements that seems to fit the recently discussed NDA issues perfectly like a fist a glove: 7.0 CONFIDENTIAL INFORMATION 7.1 For purposes of this Agreement, Confidential Information means: (i) business and technical information and any source code or binary code, which Sun discloses to Licensee related to Licensed Software; (ii) Licensee's feedback based on Licensed Software; and (iii) the terms, conditions, and existence of this Agreement. 7.1.(iii) is the Mustang Fight Club rule: The first rule of the Mustang licensee club: you don't talk about the Mustang licensee club. Fortunately, I have not accepted the license, so I can make fun of it. [...] Licensee's obligations regarding Confidential Information will expire no less than five (5) years from the date of receipt of the Confidential Information, except for Sun source code which will be protected in perpetuity. A perpetual NDA on the included Sun source code with each purchase, yum. Licensee agrees that Licensed Software contains Sun trade secrets. Et voila, explicit acknowledgement of trade secrets. Taken from http://java.sun.com/javase/6/jdk-6-beta-license.txt As long as Sun Microsystems believes to have some trade secrets in there, that are worthy of such draconian measures, I don't think it's wise to assume that NDAs with Sun have become invalid without proof to the contrary. The 1.6 beta license has a lot of other nice, comical gems, and is a wonderful piece in the finest tradition of the earlier works from the same software license publishing house. Use with care, avoid excessive exposure, etc. cheers, dalibor topic
Re: I welcome J2SE 6's faster-splash.... re: Java speed-up
Fernando Cassia fcassia at gmail.com writes: I wonder why no one has tought about having java auto-load at startup and having a single instance of the Java VM running all the time, and then pass control of the first loaded java application to it (as Mozilla or Firefox pre-loads itself at boot time when the quick launch feature is enabled). People have thought about it, and done it to death, in so far as it can be done. It turns out to not work that great in practice for a lot of reasons: the class libraries are not designed for that, the VMs are not designed for that, the security model is not designed for that at all, etc. In order to do it somewhat sensibly, you need isolates, and isolates are having their winter sleep at this point, judging by the JSR mailing list activity (none in past two months). Yay JCP! :) cheers, dalibor topic
Re: newbie to project-where to start from
Tim Ellison wrote: Pick a module [1] that interests you and from there the test code is in module_name/src/test/java/org.apache.harmony.tests.pkg.typeTest.java where pkg and type are the package and type under test; see here [2] for an example. I'm not convinced that we should only use this package convention for tests. One should certainly be able to put a test in the same package as the class being tested... geir
Re: newbie to project-where to start from
James Pluck wrote: Just piggybacking on this. I've been on the mailing list for some months now and have downloaded the code and been brwosing through it. I'm a reasonably adept programmer but this is a very major project and it's a little daunting to know just where to begin. I'd appreciate any suggestions of where I might be best able to contribute my time. I'd prefer to work on the actual implementation rather than just testing if possible but I'm keen to help out anywhere that might be useful. What would you like to work on? We clearly need bunches of things, including the standard included utilities, so start thinking about an area that you would really enjoy to work on (I'd love to see someone get our compiler-launcher done, so we would have javac using the eclipse compiler.) geir
Re: newbie to project-where to start from
I think we should certainly be using Muave for testing. However, that doesn't remove the need for our own unit tests to be testing implementation internals. Would you like to help us get it working in our build/test framework? geir Stuart Ballard wrote: Tim Ellison t.p.ellison at gmail.com writes: We are using JUnit, so your test class extends junit.framework.TestCase. Each test method is public void test_methodID() where methodID is the method under test including param types; e.g. [3]. Apologies if I'm (re)opening a can of worms here, but is there some reason why Harmony isn't collaborating with the existing and extensive Mauve test suite? I understand the license issues that prevent closer ties between Harmony and Classpath, even if I find them frustrating. But I don't see that there can possibly be license issues on a test suite, because individual tests are independent of each other so there's no reason they all have to share the same license. I can't quickly find an explicit statement of Mauve's license on its homepage[1] sadly. Stuart. [1] http://sourceware.org/mauve/
