[jira] Closed: (HARMONY-72) java.net.URLConnection.setAllowUserInteraction (boolean b) throws unspecified SecurityException
[ http://issues.apache.org/jira/browse/HARMONY-72?page=all ]
Tim Ellison closed HARMONY-72:
--
Verified by Svetlana
java.net.URLConnection.setAllowUserInteraction (boolean b) throws unspecified
SecurityException
---
Key: HARMONY-72
URL: http://issues.apache.org/jira/browse/HARMONY-72
Project: Harmony
Type: Bug
Components: Classlib
Reporter: Svetlana Samoilenko
Assignee: Tim Ellison
According to j2se 1.4.2 spec
java.net.URLConnection.setAllowUserInteraction(boolean) throws
IllegalStateException - if already connected.
Harmony throws java.lang.SecurityException instead.
Code to reproduce:
import java.io.IOException;
import java.net.*;
public class test2 {
public static void main(String[] args) {
HttpURLConnection u=null;
try {
u=(HttpURLConnection)(new
URL(http://intel.com;).openConnection());
u.connect();
} catch (MalformedURLException e) {
System.out.println(unexpected MalformedURLException+e);
} catch (IOException f) {
System.out.println(unexpected IOException+f);
}
try {
u.setAllowUserInteraction(false);
} catch (IllegalStateException e) {
System.out.println(OK. Expected IllegalStateException);
e.printStackTrace();
};
}
}
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)
OK. Expected IllegalStateException
java.lang.IllegalStateException: Already connected
at
java.net.URLConnection.setAllowUserInteraction(Z)V(URLConnection.java:765)
at test2.main([Ljava.lang.String;)V(test2.java:16)
at test2.main([Ljava.lang.String;)V(test2.java:18)
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.SecurityException: Connection already established
at
java.net.URLConnection.setAllowUserInteraction(URLConnection.java:736)
at test2.main(test2.java:18)
Suggested junit test case:
URLConnectionTest.java
-
import java.io.IOException;
import java.net.*;
import junit.framework.*;
public class URLConnectionTest extends TestCase {
public static void main(String[] args) {
junit.textui.TestRunner.run(URLConnectionTest.class);
}
public void test_setUseCaches () {
HttpURLConnection u=null;
try {
u=(HttpURLConnection)(new
URL(http://intel.com;).openConnection());
u.connect();
} catch (MalformedURLException e) {
fail(unexpected MalformedURLException+e);
} catch (IOException f) {
fail(unexpected IOException+f);
}
try {
u.setAllowUserInteraction(false);
} catch (IllegalStateException 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-82) wrong signature for 2 constructors in java.net.DatagramPacket
[ http://issues.apache.org/jira/browse/HARMONY-82?page=all ] Tim Ellison closed HARMONY-82: -- Verified by Svetlana wrong signature for 2 constructors in java.net.DatagramPacket - Key: HARMONY-82 URL: http://issues.apache.org/jira/browse/HARMONY-82 Project: Harmony Type: Bug Reporter: Svetlana Samoilenko Assignee: Tim Ellison Priority: Minor According to j2se 1.4.2 and 1.5 specification java.net.DatagramPacket.(byte[], int, int, java.net.SocketAddress) and java.net.DatagramPacket.(byte[], int, java.net.SocketAddress) must throw SocketException. -- 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-71) java.net.URLConnection.setUseCaches throws unspecified IllegalAccessError
[ http://issues.apache.org/jira/browse/HARMONY-71?page=all ]
Tim Ellison closed HARMONY-71:
--
Verified by Svetlana
java.net.URLConnection.setUseCaches throws unspecified IllegalAccessError
--
Key: HARMONY-71
URL: http://issues.apache.org/jira/browse/HARMONY-71
Project: Harmony
Type: Bug
Components: Classlib
Reporter: Svetlana Samoilenko
Assignee: Tim Ellison
According to j2se 1.4.2 specification method
java.net.URLConnection.setUseCaches(boolean) throws IllegalStateException, if
already connected. Harmony throws java.lang.IllegalAccessError instead, that
contradicts the specification.
Code to reproduce:
import java.io.IOException;
import java.net.*;
public class test2 {
public static void main(String[] args) {
HttpURLConnection u=null;
try {
u=(HttpURLConnection)(new
URL(http://intel.com;).openConnection());
u.connect();
} catch (MalformedURLException e) {
System.out.println(unexpected MalformedURLException+e);
} catch (IOException f) {
System.out.println(unexpected IOException+f);
}
try {
u.setUseCaches(true);
} catch (IllegalStateException e) {
System.out.println(OK. Expected IllegalStateException);
e.printStackTrace();
};
}
}
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)
OK. Expected IllegalStateException
java.lang.IllegalStateException: Already connected
at java.net.URLConnection.setUseCaches(Z)V(URLConnection.java:828)
at test2.main([Ljava.lang.String;)V(test2.java:17)
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.IllegalAccessError: Connection already established
at java.net.URLConnection.setUseCaches(URLConnection.java:923)
at test2.main(test2.java:17)
Suggested junit test case:
URLConnectionTest.java
-
import java.io.IOException;
import java.net.*;
import junit.framework.*;
public class URLConnectionTest extends TestCase {
public static void main(String[] args) {
junit.textui.TestRunner.run(URLConnectionTest.class);
}
public void test_setUseCaches () {
HttpURLConnection u=null;
try {
u=(HttpURLConnection)(new
URL(http://intel.com;).openConnection());
u.connect();
} catch (MalformedURLException e) {
fail(unexpected MalformedURLException+e);
} catch (IOException f) {
fail(unexpected IOException+f);
}
try {
u.setUseCaches(true);
} catch (IllegalStateException 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-83) java.net.URL(String, String, int port, String) throws MalformedURLException when port is 65535
[ http://issues.apache.org/jira/browse/HARMONY-83?page=all ]
Tim Ellison closed HARMONY-83:
--
Verified by Svetlana
java.net.URL(String, String, int port, String) throws MalformedURLException
when port is 65535
Key: HARMONY-83
URL: http://issues.apache.org/jira/browse/HARMONY-83
Project: Harmony
Type: Bug
Components: Classlib
Reporter: Svetlana Samoilenko
Assignee: Tim Ellison
Priority: Minor
According to the j2se 1.4 and 1.5 specification constructor
java.net.URL(String, String, int port, String) throws
MalformedURLException - if an unknown protocol is specified.
Harmony throws the exception if protocol is correct but a port out of range
that contradicts specification.
Code to reproduce:
import java.net.*;
public class test2 {
public static void main(String[] args) {
try {
new URL(http, google.com, 1093812784, file );
System.out.println(Test passed);
} catch (MalformedURLException e) {
e.printStackTrace();
}
}
}
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)
Test passed
C:\tmpC:\harmony\trunk\deploy\jre\bin\java -showversion test2
(c) Copyright 1991, 2005 The Apache Software Foundation or its licensors, as
applicable.
java.net.MalformedURLException: Port out of range: 1093812784
at java.net.URL.init(URL.java:382)
at java.net.URL.init(URL.java:356)
at test2.main(test2.java:6)
Suggested fix in attachment.
Suggested junit test case:
URLTest.java
-
import java.net.*;
import junit.framework.*;
public class URLTest extends TestCase {
public static void main(String[] args) {
junit.textui.TestRunner.run(URLTest.class);
}
public void test_constructor () {
try {
new URL(http, google.com, 1093812784, file );
} catch (MalformedURLException e) {
fail(unexpected MalformedURLException);
}
}
}
--
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: [tools] Javadoc! Javadoc! Javadoc! (the tool, not the debate...)
... and it goes without saying that if gjdoc were dual licensed/contributed we'd welcome it with open arms. Regards, Tim Geir Magnusson Jr wrote: Because distributing software under the GPL is a non-starter for us. Anthony Green wrote: On Thu, 2006-02-09 at 13:41 -0500, Geir Magnusson Jr wrote: We were planning to just use the eclipse compiler. No reason to rewrite. Didn't you just write in this thread that you need all the tooling? What makes the compiler special? If you can non-Apache FOSS licensed tools, why not just use the excellent gjdoc for your javadoc tool? http://www.gnu.org/software/classpath/cp-tools/ AG -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.
Re: Location for API extensions
Alexey Petrenko wrote: As it said before it is not a good idea to positioning any Harmony classes as extension for the standard API. However we can think about creating some standalone utilities library. That's fair. In the first instance I expect that these will be well-defined internal API that are mostly of interest to class library developers themselves, but give our modular structure, such internal APIs need to be managed as carefully as any end-user API or else we will end up breaking component compatibility unnecessarily. But there are a lot of questions. For example what structure and content should such library have. What classes used in Harmony modules we should include and what classes we should not include. It's obvious that library which simply consists of classes used by different developers in different places will look like trash can but not like useful library. Agreed. I think the package naming convention goes a long way to structuring the code properly to make the usability interesting. As I wrote elsewhere, I propose that packages whose naming convention is: org.apache.harmony.modulename.something represent internal APIs. All visible (public/protected) types in those packages can be used by class library developers from any module, and such developers can expect the API to be evolved in a compatible way. Module developers should not rely on the stability of anything starting: org.apache.harmony.modulename.internal and are strongly discouraged from referencing visible types in such packages since these are type internal module implementation code (and when we turn on OSGi runtime checks the imports from other modules will fail). From other hand if we are talking about using these useful classes only inside Harmony then it's probably a good idea. But we need some procedure for moving a class to utilities package and we need to notify developers about class capabilities. Moving it to a 'utilities' package should be as simple as making it a non-internal package name; and the notification is javadoc of those non-internal types. If people agree I'll write something for the website along these lines, if not we can continue to debate it on the list. Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.
verifying signed jars (was: Re: FYI missing mail)
Stepan Mishura wrote: snip Returning back to the 'missing post'. I agreed with suggestion but currently we don't have Harmony provider so we should define how we locate 'trusted provides' to be secure. We just need a trusted SHA1PRNG, right? then we can open signed providers' jars and get any others. Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.
Re: Location for API extensions
As I wrote elsewhere, I propose that packages whose naming convention is: org.apache.harmony.modulename.something represent internal APIs. All visible (public/protected) types in those packages can be used by class library developers from any module, and such developers can expect the API to be evolved in a compatible way. Module developers should not rely on the stability of anything starting: org.apache.harmony.modulename.internal and are strongly discouraged from referencing visible types in such packages since these are type internal module implementation code (and when we turn on OSGi runtime checks the imports from other modules will fail). From other hand if we are talking about using these useful classes only inside Harmony then it's probably a good idea. But we need some procedure for moving a class to utilities package and we need to notify developers about class capabilities. Moving it to a 'utilities' package should be as simple as making it a non-internal package name; and the notification is javadoc of those non-internal types. If people agree I'll write something for the website along these lines, if not we can continue to debate it on the list. Regards, Tim Agree. Thank you. -- Anton Avtamonov, Intel Middleware Products Division
Re: FYI missing mail
Hi, Aha ! Mystery solved. I must have screwed up when replying to one of Stepan's earlier posts. Thanks Stepan. Here is a paste of last week's dialogue then that *I thought* was going to the list Best regards, George paste of note from George to Stepan sent on 1st Feb at 10:16am GMT Hi Stepan, Thanks for your response. My comments are inlined below. Best regards, George IBM UK Stepan Mishura wrote: Hi George, I just suggested a possible way to make a provider 'trusted'. As far as I know the spec. doesn't explicitly define which kind of jar files is trusted. And security implementation only provides API to verify a jar's signature. A decision whether to verify a particular jar or not is taken in jar implementation. We have to work out our approach for jar verification and trusted providers. We have the following variants: - define a special location for trusted jar file, for example, bootclasspath, lib/ext directory and put BC provider here OK, I appreciate that the above are examples but allow me to just add my shiny two pence sterling. Specifying that third party provider jars need to go on the bootclasspath means additional work for the user. They are either going to have to add in the necessary -Xbootclasspath option to every launch (tedious) or else drop the jar into jre/lib/boot and update the bootclasspath.properties file with information on the extra entry (tedious and potentially dangerous as this is one file we really don't want to be edited too often). I personally find neither appealing. I also find it somewhat misleading to be using the bootclasspath for loading third party libraries which are not essential for the bootstrapping of the JRE. These libraries are extending the JRE. That's why I think that using the extensions loader is the better option from your examples. It also has the practical benefit of alleviating user burden if they can just drop a third party provider jar into jre/lib/ext and forget about any extra command line options. - develop Harmony provider (and exclude necessity of having a 'trusted' location) Yes, absolutely ! We need a default Harmony provider at position #1 in the preferred provider search sequence that has sufficient functionality to handle the verification of signed jars. This would rid us of this cyclic problem we currently have with the BC jar. - use any unsigned jar form open source Providers like Bouncy Castle and Cryptix etc typically deliver their classes inside signed jars. Don't you think it would seem a bit strange asking Harmony users to unsign these jars before actually using in Harmony ? For one thing, it is again more work for the user (I know I keep harping on about the poor old users, but I kind of have a soft spot for them) and introduces a point of potential failure into the platform configuration as people may inadvertently screw up the unsigning. - let's user to decide whether a provider is trusted or not and where to place it It would be nice if Harmony could help inform them whether or not a signed provider jar is verifiably trustworthy. - others …. My suggestion in harmony-dev mailing list coincided with the current Harmony build behavior: when a signed provider jar (e.g. BC provider) is placed to bootclasspath to run security2 tests then signature is not verified. So I may call it a 'trusted' provider. And according to your experiments if I'll move it to lib/ext then it will need to pass jar verification. So I may call it 'untrusted' provider. However I don't know whether such behavior was especially designed or not. As mentioned above, I think that a default Harmony provider (something like security.provider.1=org.apache.harmony.provider.Harmony in the java.security file) that could verify third party jars without having to rely on functionality from third party jars is the way forward. Certainly better than using the bootclasspath as a salve for all our problems. Thanks, Stepan. On 1/31/06, *George Harley* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Hi Stepan, Not sure that I understand. Are you saying that taking a signed provider jar (e.g. bcprov-jdk14-131.jar) and adding it to the bootclasspath makes it a trusted provider ? Best regards, George IBM UK Stepan Mishura wrote: Certainly the Bouncy Castle jar contains an implementation of the SHA algorithm. Assuming that you have an uncorrupted BC provider jar in HARMONY_JRE/lib/ext, does this failure get fixed by unsigning the BC jar ? Well, there is a cyclic dependency here: to verify a signed jar we need already verified provider that has all required algorithms for jar verification. To avoid this we can define a 'trusted' provider, for example, currently a signed provider's jar is not verified if it was added to the bootclasspath. Or we can create an unsigned provider's jar intended for jar verification. BTW, all
Re: verifying signed jars
Hi Tim, In order to verify the signature of those signed provider jars I believe that you would also need trusted implementations of : * SHA-1 and MD5 digest algorithms * DSA and RSA signature algorithms Best regards, George IBM UK Tim Ellison wrote: Stepan Mishura wrote: snip Returning back to the 'missing post'. I agreed with suggestion but currently we don't have Harmony provider so we should define how we locate 'trusted provides' to be secure. We just need a trusted SHA1PRNG, right? then we can open signed providers' jars and get any others. Regards, Tim
Re: [classlib] security2 - security
I've reviewed exception classes: General: security has javadocs that reword SUN's spec, while sec2 does not have security seems to follow 1.4 spec, while sec2 - 1.5 AccessControlException - almost no difference. permission field is private in s2 and package-vis in sec PrivilegedActionException - almost the same. the difference is in toString() DigestException, GeneralSecurityException InvalidAlgorithmParameterException InvalidKeyException KeyException NoSuchAlgorithmException SignatureException cert/CertificateEncodingException cert/CertificateException cert/CertificateParsingException cert/CRLException - sec misses two constructors (new in 1.5) and serialVersionUID. sec2 has them. InvalidParameterException NoSuchProviderException cert/CertificateExpiredException cert/CertificateNotYetValidException - sec misses serialVersionUID. sec2 has it. KeyManagementException KeyStoreException ProviderException UnrecoverableEntryException UnrecoverableKeyException acl/* spec/* cert/CertStoreException cert/CertPathBuilderException cert/CertPathValidatorException - present in security2 only The question is: are we going to take javadocs? Thanks, Mikhail On 2/9/06, Mikhail Loenko [EMAIL PROTECTED] wrote: I'm going to walk method by method, compare and present results starting with the easiest cases. I've already taken some look at security so I think it would not be very difficult - it has 50+ classes, ~20 of them are exceptions, there are some interfaces... Thanks, Mikhail On 2/9/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: Tim Ellison wrote: +1 to consolidating on a single security module. I'm also interested to hear what merging Mikhail has in mind. I was led to believe that security2 was a proper superset of security, so we should be able to do a 'big bang' switch. The security_orig won't be too far away if we need to pull something in. (Perhaps move it out of trunk/modules/ to avoid confusion?) Right - it will live forever in SVN, and of course we always can copy forward in time if we need to - i.e. copy from some past rev into now, whenever that is. I just don't want to lose anything useful that may be in security... geir Regards, Tim Geir Magnusson Jr wrote: Before you do that... What are you thinking as your approach? geir Mikhail Loenko wrote: I suggest merging these two bundles. I can do this and provide a patch... Thanks, Mikhail On 2/9/06, Mikhail Loenko [EMAIL PROTECTED] wrote: security classes are a subset of security2 classes. security2 is 1.5-ready while security has javadocs. What do you mean by 'better'? Are there any original approaches or efficient algorithms used in security? Thanks, Mikhail On 2/9/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: Hm. I thought security was stubs, but it isn't. Is there anything in security/ that we don't have in security2/ or is better? geir Geir Magnusson Jr wrote: Unless I hear massive bellowing in opposition, I'm going to move security - security_orig and security2 - security sometime tomorrow. Please register protests now... geir
Re: verifying signed jars
More implementatoins we have in Harmony - less we depend on third parties. I think SHA-1 and DSA is something to start with. Makes sense? Thanks, Mikhail On 2/10/06, George Harley [EMAIL PROTECTED] wrote: Hi Stepan, In the short term, yes, SHA-1 and DSA should suffice for verifying the BouncyCastle provider jar. Long term though, Harmony will also need to support the MD5 and RSA algorithms for other providers that may have been signed with those algorithms. While the Jar file specification does not mandate a set of digest and signature algorithms that may be used for signing, it should be noted that the reference jarsigner tool supports both DSA+SHA-1 and RSA+MD5. Best regards, George IBM UK PS, Keeping my fingers crossed this ends up on the dev-list :-) Stepan Mishura wrote: We should have at least to verify BC provider: 1) Message digest algorithm: SHA-1 2) Signature algorithm: SHA1withDSA Other jars may require additional algorithms, for example, SHA1withRSA. We can verify BC provider first and use it for further jar verifications. Thanks, Stepan Mishura Intel Middleware Products Division On 2/10/06, *George Harley* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Hi Tim, In order to verify the signature of those signed provider jars I believe that you would also need trusted implementations of : * SHA-1 and MD5 digest algorithms * DSA and RSA signature algorithms Best regards, George IBM UK Tim Ellison wrote: Stepan Mishura wrote: snip Returning back to the 'missing post'. I agreed with suggestion but currently we don't have Harmony provider so we should define how we locate 'trusted provides' to be secure. We just need a trusted SHA1PRNG, right? then we can open signed providers' jars and get any others. Regards, Tim --
Re: [jira] Updated: (HARMONY-73) java.net.InetAddress.getLocalHost() returns wrong host name for loopback address
Ok.
aside
The behavior strikes me as dumb. Why return a textual representation?
What good does that do anyone? The caller has no clue there was a
problem...
/aside
geir
Paulex Yang wrote:
As I commented in the JIRA, further study shows some interesting facts,
first, my prior patch is redundant, the actual bug is
http://issues.apache.org/jira/browse/HARMONY-84.
second, there is another different behavior of getHostName() between RI
and Harmony, but I consider it as RI's bug:
The java spec of getHostName() says:
spec*
Returns: *the host name for this IP address, or if the operation is not
allowed by the security check, the textual representation of the IP
address.
/spec
But the following test shows RI will return host name instead of IP
address if the host name can be got without reverse name lookup.
code
public class HostNameTest{
public static void main(String[] args) throws Exception{
InetAddress addr = InetAddress.getByName(localhost);
InetAddress addr2 = InetAddress.getByAddress(new byte[]{127, 0,
0, 1});
SecurityManager sm = new Inet_SecurityManager();
System.setSecurityManager(sm);
System.out.println(addr.getHostName());
System.out.println(addr2.getHostName());
}
static class Inet_SecurityManager extends SecurityManager {
public void checkConnect(String host, int port) {
super.checkConnect(host,port);
throw new SecurityException();
}
}
}
/code
RI outputs:
localhost
127.0.0.1
Harmony outputs:
127.0.0.1
127.0.0.1
This time, Harmony win :-D .
Geir Magnusson Jr wrote:
isn't localhost actually something in the local hosts file? Don't
you want to look this up?
Paulex Yang (JIRA) wrote:
[ http://issues.apache.org/jira/browse/HARMONY-73?page=all ]
Paulex Yang updated HARMONY-73:
---
Attachment: InetAddress.patch
A suggested modification is to add these two lines before Ln. 296 of
java.net.InetAddress,
if(this == LOOPBACK){
return localhost;
}
So that the getHostName() will return localhost instead of
127.0.0.1.
The patch is attached.
java.net.InetAddress.getLocalHost() returns wrong host name for
loopback address
-
Key: HARMONY-73
URL: http://issues.apache.org/jira/browse/HARMONY-73
Project: Harmony
Type: Bug
Components: Classlib
Reporter: Svetlana Samoilenko
Priority: Minor
Attachments: InetAddress.patch
J2se 1.4.2 and 5.0 specifications for
java.net.InetAddress.getLocalHost() read, that if there is a
security manager, its checkConnect method is called with the local
host name and -1 as its arguments to see if the operation is
allowed. If the operation is not allowed, an InetAddress
representing the loopback address is returned as
hostname/hostaddress (as followed from toString() specification).
The test listed below shows that the returned loopback address has
wrong hostname, 127.0.0.1 instead of loopback.
Inet_SecurityManager class is called twice and therefore host name
is substituted with hostaddress address.
Code to reproduce: import java.net.*; public class test2 {
public static void main(String[] args) { try {
System.setSecurityManager(new Inet_SecurityManager());
System.out.println(Loopback address = +
InetAddress.getLocalHost());
} catch (Exception e){
System.out.println(Unexpected exception = + e); }; }
} class Inet_SecurityManager extends SecurityManager { public
void checkConnect(String host, int port) {
super.checkConnect(host,port); throw new SecurityException();
}
}
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) Inet_SecurityManager :host= nswssamoil1
Inet_SecurityManager :port= -1
Loopback address = localhost/127.0.0.1
C:\tmpC:\harmony\trunk\deploy\jre\bin\java -showversion test2 (c)
Copyright 1991, 2005 The Apache Software Foundation or its
licensors, as applicable. Inet_SecurityManager :host= nswssamoil1
Inet_SecurityManager :port= -1
Inet_SecurityManager :host= localhost
Inet_SecurityManager :port= -1
Loopback address = 127.0.0.1/127.0.0.1
Suggested junit test case:
InetAddressTest.java
- import java.net.*;
import junit.framework.*; public class InetAddressTest extends
TestCase { public static void main(String[] args) {
Re: Location for API extensions
Alexey Petrenko wrote: But there are a lot of questions. For example what structure and content should such library have. What classes used in Harmony modules we should include and what classes we should not include. It's obvious that library which simply consists of classes used by different developers in different places will look like trash can but not like useful library. Agreed. I think the package naming convention goes a long way to structuring the code properly to make the usability interesting. Yep. But I'm trying to say that creating tolls library is probably different project with different goals. I agree. We have enough work in the project as scoped already ;-) As I wrote elsewhere, I propose that packages whose naming convention is: org.apache.harmony.modulename.something represent internal APIs. All visible (public/protected) types in those packages can be used by class library developers from any module, and such developers can expect the API to be evolved in a compatible way. We also should remember that using classes from different modules create additional dependencies between modules and this will decrease modularity. And developers should document such dependencies anyway. So probably we need do create utilities or harmonyutilities module and put all useful for other modules classes into this package. No objection if it gets to that point, but let's not create it prematurely. Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.
Re: [classlib:security2] bootclasspath for security tests [HARMONY-58]
Stepan Mishura wrote:
On 2/9/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote:
Stepan Mishura wrote:
Hi Geir,
For the record, I put the jvmarg line back - I did some test class
renaming, and things broke! I put it back, and all is well. Dunno.
Leaving there so it doesn't break anyone else. Will continue to chase
down after dinner
crypto.jar and x_net.jar are not created by the 'main build file' (i.e.
make/build.xml) and they are absent in Harmony boot
(deploy/jre/lib/boot)
directory. So the build script from 'security2' builds them and places
explicitly to the bootclasspath.
Then this is wrong then, correct? We should put putting crypto.jar and
x_net.jar into the bootclasspath?
As I understood you removed only jvmarg line but didn't update ant script to
copy generated jar files. So tests failed. Right?
Yes, because we were inconsistent about what we are doing. Not all jars
made it to jre/lib/boot
So I've now cut x-net out into a separate module, and will stuff crypto
into security for now to keep the 1 artifact per module scheme.
I'm sure we'll cut them apart again at some point in the future.
The question was how to put required jars in jre/lib/boot directory. A fast
solution was to copy jars generated with local make file in security2/make.
And a right solution is to adjust 'security2' to common build structure (i.e.
make/build.xml) as you did for 'x-net' component. I reviewed your update for
x-net and I'm ok with it.
Great. I think that the build will evolve to having to drive the
general build from the top because of the circular dependencies, and
then testing being localized to the modules. I've started on this -
will have one build-test.xml at the top that calls the individual module
tests scripts. Just playing w/ it now - expect more later today.
I think the similar can be done for 'security-x'. As there are no objections
for creating the new component I can create a JIRA task for extracting
'security-x' from 'security2'. And provide a patch for it by analogy with
extracting 'x-net'.
What do you think?
I guess I'm interested in why. I can see crypto being shaken out, but
why x-security?
geir
Thanks,
Stepan Mishura
Intel Middleware Products Division
If you remove jvmarg line then you need to update additionally
make/build.xml or the build script from 'security2' to put these jars to
Harmony boot directory.
Yes - I think that is the sensical way to go as we do want them there,
right?
I think that we should work out some kind of 'transition procedure' for
substituting security with security2 to be sure that we don't miss
anything
and we are consistent. The first step may be extracting x-net component
because it is quite independent.
Don't mix the issues. Right now, no modules/security code is being built.
So - first - any problem with crypto and x_net into bootclasspath?
geir
Thanks,
Stepan Mishura
Intel Middleware Products Division
On 2/9/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote:
For the record, I put the jvmarg line back - I did some test class
renaming, and things broke! I put it back, and all is well. Dunno.
Leaving there so it doesn't break anyone else. Will continue to chase
down after dinner
Geir Magnusson Jr wrote:
I applied patch for HARMONY-58 (thanks Stepan and Tim) and closed the
issue.
However, there was a small thing that bugged me. We were setting the
bootclasspath as follows :
jvmarg
value=-Xbootclasspath/p:${build.jars.path}/crypto.jar${path.separator
}${build.jars.path}/x_net.jar/
which has 2 of the 3 artifacts generated by security2 coming from the
local modules/security2 tree, and the third, security.jar, coming from
deploy/jre/lib/boot. This isn't healthy.
So I just removed the above line, and now we depend on all three jars
coming from the same place, namely the deploy boot classpath.
I only feel strongly that we are consistent. We can change from
deploy/
to modules/security2 if we need to.
I suspect this will be fine, but it does mean that working in
modules/security2 means that you need to go to top level to re-run the
build to get the jars in the right place.
I think I'll change the local make in modules/security2 to also copy
the
generated jars to ../../deploy/jre/lib/boot/
That way, you can work locally and still do the proper testing w/o
having to out of the module you are working in. I suspect that this
will be a pattern we repeat in all modules.
geir
--
Thanks,
Stepan Mishura
Intel Middleware Products Division
Re: [tools] Javadoc! Javadoc! Javadoc! (the tool, not the debate...)
indeed. We're lazy. geir Tim Ellison wrote: ... and it goes without saying that if gjdoc were dual licensed/contributed we'd welcome it with open arms. Regards, Tim Geir Magnusson Jr wrote: Because distributing software under the GPL is a non-starter for us. Anthony Green wrote: On Thu, 2006-02-09 at 13:41 -0500, Geir Magnusson Jr wrote: We were planning to just use the eclipse compiler. No reason to rewrite. Didn't you just write in this thread that you need all the tooling? What makes the compiler special? If you can non-Apache FOSS licensed tools, why not just use the excellent gjdoc for your javadoc tool? http://www.gnu.org/software/classpath/cp-tools/ AG
Re: FYI missing mail
Process note : (George : I don't believe that there's any problem here, but using it as an example.) If you ever are in the situation where you will forward a private exchange to a public list, be sure to ask all participants in the exchange for permission. People can react in different and surprising ways to this, so it's always good to take the extra step and get explicit permission. gei George Harley wrote: Hi, Aha ! Mystery solved. I must have screwed up when replying to one of Stepan's earlier posts. Thanks Stepan. Here is a paste of last week's dialogue then that *I thought* was going to the list Best regards, George paste of note from George to Stepan sent on 1st Feb at 10:16am GMT Hi Stepan, Thanks for your response. My comments are inlined below. Best regards, George IBM UK Stepan Mishura wrote: Hi George, I just suggested a possible way to make a provider 'trusted'. As far as I know the spec. doesn't explicitly define which kind of jar files is trusted. And security implementation only provides API to verify a jar's signature. A decision whether to verify a particular jar or not is taken in jar implementation. We have to work out our approach for jar verification and trusted providers. We have the following variants: - define a special location for trusted jar file, for example, bootclasspath, lib/ext directory and put BC provider here OK, I appreciate that the above are examples but allow me to just add my shiny two pence sterling. Specifying that third party provider jars need to go on the bootclasspath means additional work for the user. They are either going to have to add in the necessary -Xbootclasspath option to every launch (tedious) or else drop the jar into jre/lib/boot and update the bootclasspath.properties file with information on the extra entry (tedious and potentially dangerous as this is one file we really don't want to be edited too often). I personally find neither appealing. I also find it somewhat misleading to be using the bootclasspath for loading third party libraries which are not essential for the bootstrapping of the JRE. These libraries are extending the JRE. That's why I think that using the extensions loader is the better option from your examples. It also has the practical benefit of alleviating user burden if they can just drop a third party provider jar into jre/lib/ext and forget about any extra command line options. - develop Harmony provider (and exclude necessity of having a 'trusted' location) Yes, absolutely ! We need a default Harmony provider at position #1 in the preferred provider search sequence that has sufficient functionality to handle the verification of signed jars. This would rid us of this cyclic problem we currently have with the BC jar. - use any unsigned jar form open source Providers like Bouncy Castle and Cryptix etc typically deliver their classes inside signed jars. Don't you think it would seem a bit strange asking Harmony users to unsign these jars before actually using in Harmony ? For one thing, it is again more work for the user (I know I keep harping on about the poor old users, but I kind of have a soft spot for them) and introduces a point of potential failure into the platform configuration as people may inadvertently screw up the unsigning. - let's user to decide whether a provider is trusted or not and where to place it It would be nice if Harmony could help inform them whether or not a signed provider jar is verifiably trustworthy. - others …. My suggestion in harmony-dev mailing list coincided with the current Harmony build behavior: when a signed provider jar (e.g. BC provider) is placed to bootclasspath to run security2 tests then signature is not verified. So I may call it a 'trusted' provider. And according to your experiments if I'll move it to lib/ext then it will need to pass jar verification. So I may call it 'untrusted' provider. However I don't know whether such behavior was especially designed or not. As mentioned above, I think that a default Harmony provider (something like security.provider.1=org.apache.harmony.provider.Harmony in the java.security file) that could verify third party jars without having to rely on functionality from third party jars is the way forward. Certainly better than using the bootclasspath as a salve for all our problems. Thanks, Stepan. On 1/31/06, *George Harley* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Hi Stepan, Not sure that I understand. Are you saying that taking a signed provider jar (e.g. bcprov-jdk14-131.jar) and adding it to the bootclasspath makes it a trusted provider ? Best regards, George IBM UK Stepan Mishura wrote: Certainly the Bouncy Castle jar contains an implementation of the SHA algorithm. Assuming that you have an uncorrupted BC provider jar in HARMONY_JRE/lib/ext, does this failure get
Re: [classlib] security2 - security
So it's javadoc. I vote that we : - take security up and outside of modules/ to a archive/ directory for now - move security2-security - over time, start migrating javadoc Mikhail Loenko wrote: I've reviewed exception classes: General: security has javadocs that reword SUN's spec, while sec2 does not have security seems to follow 1.4 spec, while sec2 - 1.5 AccessControlException - almost no difference. permission field is private in s2 and package-vis in sec PrivilegedActionException - almost the same. the difference is in toString() DigestException, GeneralSecurityException InvalidAlgorithmParameterException InvalidKeyException KeyException NoSuchAlgorithmException SignatureException cert/CertificateEncodingException cert/CertificateException cert/CertificateParsingException cert/CRLException - sec misses two constructors (new in 1.5) and serialVersionUID. sec2 has them. InvalidParameterException NoSuchProviderException cert/CertificateExpiredException cert/CertificateNotYetValidException - sec misses serialVersionUID. sec2 has it. KeyManagementException KeyStoreException ProviderException UnrecoverableEntryException UnrecoverableKeyException acl/* spec/* cert/CertStoreException cert/CertPathBuilderException cert/CertPathValidatorException - present in security2 only The question is: are we going to take javadocs? Thanks, Mikhail On 2/9/06, Mikhail Loenko [EMAIL PROTECTED] wrote: I'm going to walk method by method, compare and present results starting with the easiest cases. I've already taken some look at security so I think it would not be very difficult - it has 50+ classes, ~20 of them are exceptions, there are some interfaces... Thanks, Mikhail On 2/9/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: Tim Ellison wrote: +1 to consolidating on a single security module. I'm also interested to hear what merging Mikhail has in mind. I was led to believe that security2 was a proper superset of security, so we should be able to do a 'big bang' switch. The security_orig won't be too far away if we need to pull something in. (Perhaps move it out of trunk/modules/ to avoid confusion?) Right - it will live forever in SVN, and of course we always can copy forward in time if we need to - i.e. copy from some past rev into now, whenever that is. I just don't want to lose anything useful that may be in security... geir Regards, Tim Geir Magnusson Jr wrote: Before you do that... What are you thinking as your approach? geir Mikhail Loenko wrote: I suggest merging these two bundles. I can do this and provide a patch... Thanks, Mikhail On 2/9/06, Mikhail Loenko [EMAIL PROTECTED] wrote: security classes are a subset of security2 classes. security2 is 1.5-ready while security has javadocs. What do you mean by 'better'? Are there any original approaches or efficient algorithms used in security? Thanks, Mikhail On 2/9/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: Hm. I thought security was stubs, but it isn't. Is there anything in security/ that we don't have in security2/ or is better? geir Geir Magnusson Jr wrote: Unless I hear massive bellowing in opposition, I'm going to move security - security_orig and security2 - security sometime tomorrow. Please register protests now... geir
Re: Which applications run using Harmony classes?
OK - well - here is a plan. I have these scripts in a hacked together state and they currently rely on reading the output from -verbose:class generated by an IBM JRE. Ideally I'd like them to be able to read a couple of different formats. If anyone is interested in knowing if their app would (in theory) run using Harmony classes open a JIRA called Would $my_favourite_app run on Harmony? and attach the output from java -verbose:class $my_favourite_app. If this works I can pick up the output and use it to test the tool. Please would you also attach the output from java -version? I will append (or ask someone to append) a list of missing files to the JIRA. When I'm happy that my scripts work and I've tidied up the code I'll attach the source as a JIRA and write some instructions on how to use it. FWIW in looking at Derby, it looks as though we still need SQL (could have predicted that I suppose) and JNDI, but those seem to be all that are missing. I can send the list of missing classes to anyone that wants to verify this - it's just slightly too long to paste into mail Geir Magnusson Jr wrote: zoe slattery wrote: I've tried to post this a couple of times from another mail account - but it seems to go into a black hole - apologies if another two copies turn up later :-( I had some thoughts about running applications using Harmony classes. Rather than just getting various applications and trying them with Harmony I've been trying to see what classes they need. For example, I downloaded and installed Derby then ran this: java –verbose:class org.apache.derby.drda.NetworkServerControl start dbc.txt This generates a file (dbc.txt) showing all of the classes that get loaded when Derby starts up. The format of the output is something like this: ... class load: java/io/BufferedOutputStream class load: java/io/BufferedReader class load: java/io/BufferedWriter class load: java/io/ByteArrayInputStream class load: java/io/ByteArrayOutputStream class load: java/io/CharConversionException class load: java/io/DataInput class load: java/io/DataInputStream ... using an IBM JRE - the format would likely be different using another JRE. I ran a few more similar things to look at what classes get loaded when you create tables, add rows etc. and then cat'd the class load output into a single file. A more extensive test could be run by using Derby unit tests. I wrote a small perl script that extracts the names of all of the java classes and then compares these against the API spec to generate a final list of API classes that are used by an application. I'd be happy to supply the perl, although it needs a bit of tidying up. This is cool. The next step would be to check how many of these exist in SVN already - and maybe highlight the areas that we are missing? Yes! So far, the only way I have found to get a list of files that exist in SVN is using something like svn list $repos_path -R, if anyone knows of a better (faster) way I'd be happy to hear it. Try to find a way to do it on a local checkout. We don't want to be banging the SVN repo like this. (We've been having problems lately w/ people walking through the SVN repo, file after file, version after version, via the viewCVS interface. Not a good use of resources. Agreed - I did try the svn list command once and realised that it wasn't going to be practical. It's easy to do on a local checkout. This would be cool - I'd love to post these on the website, to let people know what they could do to help get their favorite app up and going. I wonder too if this could be combined with Gump somehow, so we can automatically test a large swatch of the popular java app world. I don't know but would be happy to look (later) Thoughts? -- Zoe Slattery IBM
Re: Which applications run using Harmony classes?
zoe slattery wrote: OK - well - here is a plan. I have these scripts in a hacked together state and they currently rely on reading the output from -verbose:class generated by an IBM JRE. Ideally I'd like them to be able to read a couple of different formats. If anyone is interested in knowing if their app would (in theory) run using Harmony classes open a JIRA called Would $my_favourite_app run on Harmony? and attach the output from java -verbose:class $my_favourite_app. If this works I can pick up the output and use it to test the tool. Please would you also attach the output from java -version? I will append (or ask someone to append) a list of missing files to the JIRA. When I'm happy that my scripts work and I've tidied up the code I'll attach the source as a JIRA and write some instructions on how to use it. FWIW in looking at Derby, it looks as though we still need SQL (could have predicted that I suppose) and JNDI, but those seem to be all that are missing. I can send the list of missing classes to anyone that wants to verify this - it's just slightly too long to paste into mail Paste it on the wiki (wiki.apache.org/harmony/). I'd be curious to see it. Upayavira
Re: [classlib] security2 - security
+1 Geir Magnusson Jr wrote: So it's javadoc. I vote that we : - take security up and outside of modules/ to a archive/ directory for now - move security2-security - over time, start migrating javadoc Mikhail Loenko wrote: I've reviewed exception classes: General: security has javadocs that reword SUN's spec, while sec2 does not have security seems to follow 1.4 spec, while sec2 - 1.5 AccessControlException - almost no difference. permission field is private in s2 and package-vis in sec PrivilegedActionException - almost the same. the difference is in toString() DigestException, GeneralSecurityException InvalidAlgorithmParameterException InvalidKeyException KeyException NoSuchAlgorithmException SignatureException cert/CertificateEncodingException cert/CertificateException cert/CertificateParsingException cert/CRLException - sec misses two constructors (new in 1.5) and serialVersionUID. sec2 has them. InvalidParameterException NoSuchProviderException cert/CertificateExpiredException cert/CertificateNotYetValidException - sec misses serialVersionUID. sec2 has it. KeyManagementException KeyStoreException ProviderException UnrecoverableEntryException UnrecoverableKeyException acl/* spec/* cert/CertStoreException cert/CertPathBuilderException cert/CertPathValidatorException - present in security2 only The question is: are we going to take javadocs? Thanks, Mikhail On 2/9/06, Mikhail Loenko [EMAIL PROTECTED] wrote: I'm going to walk method by method, compare and present results starting with the easiest cases. I've already taken some look at security so I think it would not be very difficult - it has 50+ classes, ~20 of them are exceptions, there are some interfaces... Thanks, Mikhail On 2/9/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: Tim Ellison wrote: +1 to consolidating on a single security module. I'm also interested to hear what merging Mikhail has in mind. I was led to believe that security2 was a proper superset of security, so we should be able to do a 'big bang' switch. The security_orig won't be too far away if we need to pull something in. (Perhaps move it out of trunk/modules/ to avoid confusion?) Right - it will live forever in SVN, and of course we always can copy forward in time if we need to - i.e. copy from some past rev into now, whenever that is. I just don't want to lose anything useful that may be in security... geir Regards, Tim Geir Magnusson Jr wrote: Before you do that... What are you thinking as your approach? geir Mikhail Loenko wrote: I suggest merging these two bundles. I can do this and provide a patch... Thanks, Mikhail On 2/9/06, Mikhail Loenko [EMAIL PROTECTED] wrote: security classes are a subset of security2 classes. security2 is 1.5-ready while security has javadocs. What do you mean by 'better'? Are there any original approaches or efficient algorithms used in security? Thanks, Mikhail On 2/9/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: Hm. I thought security was stubs, but it isn't. Is there anything in security/ that we don't have in security2/ or is better? geir Geir Magnusson Jr wrote: Unless I hear massive bellowing in opposition, I'm going to move security - security_orig and security2 - security sometime tomorrow. Please register protests now... geir -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.
Re: running eclipse on Harmony classlib
On 2/10/06, Stefano Mazzocchi [EMAIL PROTECTED] wrote: Vladimir Strigun wrote: I'm able to run eclipse on Harmony classlib + J9 VM. To run Eclipse you need to make following steps: - download xalan.jar, xercesImpl.jar, xml-apis.jar and serializer.jar from xml.apache.org and put it to deploy/jre/lib/boot/ - add next line to jre/lib/boot/bootclasspath.properties : bootclasspath.38=serializer.jar - download and build Intel contribution of beans, math and regex packages ( http://issues.apache.org/jira/browse/HARMONY-39 ) - copy beans.jar, math.jar, regex.jar to deploy/jre/lib/boot/ folder - launch deploy/jre/bin/java -cp $ECLIPSE_HOME/startup.jar org.eclipse.core.launcher.Main I've tried to create simple Java project and Hello class inside. Everything works fine without any exception or problems. Tim, in your movie I have seen new type for installed JRE in Eclipse: Apache Harmony VM. Do you have Eclipse plugin for Harmony already? Holy cow, this is awesome! Have you tried with our own VM? Unfortunately haven't tried yet. Thanks, Vladimir Strigun, Intel Middleware Products Division
Re: Location for API extensions
From other hand if we are talking about using these useful classes only inside Harmony then it's probably a good idea. But we need some procedure for moving a class to utilities package and we need to notify developers about class capabilities. I think the key to get this started is to identify some set of functionality to focus on... Agreed. -- Alexey A. Petrenko Intel Middleware Products Division
Re: Which applications run using Harmony classes?
I did a simple test and put the results here: http://wiki.apache.org/harmony/Apache_Derby but it sounds like Zoe's approach is smarter. Regards, Tim Upayavira wrote: zoe slattery wrote: OK - well - here is a plan. I have these scripts in a hacked together state and they currently rely on reading the output from -verbose:class generated by an IBM JRE. Ideally I'd like them to be able to read a couple of different formats. If anyone is interested in knowing if their app would (in theory) run using Harmony classes open a JIRA called Would $my_favourite_app run on Harmony? and attach the output from java -verbose:class $my_favourite_app. If this works I can pick up the output and use it to test the tool. Please would you also attach the output from java -version? I will append (or ask someone to append) a list of missing files to the JIRA. When I'm happy that my scripts work and I've tidied up the code I'll attach the source as a JIRA and write some instructions on how to use it. FWIW in looking at Derby, it looks as though we still need SQL (could have predicted that I suppose) and JNDI, but those seem to be all that are missing. I can send the list of missing classes to anyone that wants to verify this - it's just slightly too long to paste into mail Paste it on the wiki (wiki.apache.org/harmony/). I'd be curious to see it. Upayavira -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.
Re: [classlib] proposal to revisit componentization for security (was: Re: problems with security2)
Why would you put JCE and general security together? Regards, Tim Mikhail Loenko wrote: Geir Sounds like no one objects to the proposal itself, the discussion is about the naming. Could you please approve/decline new componentization? Thanks, Mikhail On 1/27/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: Stepan Mishura wrote: Sounds dirty. How about security-x? Ok. I named it by analogy with x-net. Your variant works for me. x-net has the same issue for me. I figure that net-x is better too because it will sit next to net in a directory/IDE package tree, etc... (just like security-x near security) geir Thanks, Stepan On 1/27/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: Sounds dirty. How about security-x? Stepan Mishura wrote: I agree with the proposal and I'm ready to start working on a patch for splitting 'security2' into suggested components and integrating them with the current build. Also I'd like to suggest a name for a new component: 'x-security'. Thanks, Stepan Mishura Intel Middleware Products Division On 1/19/06, Mikhail Loenko [EMAIL PROTECTED] wrote: Hello Let's start a different thread for that. I suggest revisiting current componentization for security related parts. Now we have for example crypto architecture in security module but crypto extension in the crypto module. See natural components in the UserGuide http://java.sun.com/j2se/1.5.0/docs/guide/security/ The proposal is to have 3 components: 1. general security crypto 2. ssl 3. jaas The logical content of those components would be: 1. - General Security - Certification Path - JCE 2. - JSSE 3. - JAAS - JGSS - SASL Physical content of those components: 1. java.security javax.crypto javax.security.cert 2. javax.net 3. javax.security w/o javax.security.cert org.ietf Opinions? Thanks, Mikhail Loenko Intel Middleware Products Division -- -- Thanks, Stepan Mishura Intel Middleware Products Division -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.
[jira] Commented: (HARMONY-29) java.util.zip.ZipException while onening jar file on local machine
[
http://issues.apache.org/jira/browse/HARMONY-29?page=comments#action_12365891 ]
Vladimir Strigun commented on HARMONY-29:
-
another fix (using internal utils):
37a38
import com.ibm.oti.util.Util;
235c236
jar = new JarFile(new File(fileString), true, flags);
---
jar = new JarFile(new File(Util.decode(fileString,
true)), true, flags);
java.util.zip.ZipException while onening jar file on local machine
--
Key: HARMONY-29
URL: http://issues.apache.org/jira/browse/HARMONY-29
Project: Harmony
Type: Bug
Components: Classlib
Reporter: Vladimir Strigun
Assignee: Geir Magnusson Jr
When I try to get entries from jar file I get java.util.zip.ZipException.
Here is testcase for reproducing the issue:
import java.net.JarURLConnection;
import java.net.URL;
import java.util.Enumeration;
public class TestZipFile {
public static void main(String argv[]) throws Throwable {
final String urlStr = jar:file:/C:/Documents%20and%20Settings/ +
user/test.jar!/Test.class;
JarURLConnection conn = (JarURLConnection)
new URL(urlStr).openConnection();
Enumeration enum = conn.getJarFile().entries();
System.out.println(PASS);
}
}
On RI test passed, but with Harmony classlibs I get following exception:
java.util.zip.ZipException: Unable to open:
C:\Documents%20and%20Settings\user\test.jar
at java.util.zip.ZipFile.openZip()
at java.util.zip.ZipFile.init()
at java.util.jar.JarFile.init()
at com.ibm.oti.net.www.protocol.jar.JarURLConnection.openJarFile()
at com.ibm.oti.net.www.protocol.jar.JarURLConnection.findJarFile()
at com.ibm.oti.net.www.protocol.jar.JarURLConnection.connect()
at com.ibm.oti.net.www.protocol.jar.JarURLConnection.getJarFile()
at TestZipFile.main(TestZipFile.java:9)
--
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)
Tim, The goal is to unite JCA and JCE (crypto and crypto extension). JCA is a part of general security... Another goal is to separate Authentication and Authorization stuff from general security. Thanks, Mikhail
classlib/trunk repository structure
Isn't it a good time to normalize classlib/trunk repository structure and update Apache Harmony Contribution Policy document (http://incubator.apache.org/harmony/contribution_policy.html) while we got small number of modules? Here is what I mean... 1. There is classlib/trunk/native-src directory. README says: native-src contains native source files only. So it looks like correct place for ALL the native sources. If so why we got native sources in classlib/trunk/modules/security2/src/linux/other/? And why we got additional java subdirectory in every main directory? I think that we should store native sources under modules directory with all other module sources. modules/modulename/src/main/native looks like a good place for this. It will make looking for module sources much easier. 2. It's not clear where the system specific java sources should be stored. I think modules/modulename/src/linux and modules/modulename/src/windows will be a good place. 3. It's not clear what should be placed in modules/modulename/src/main directory. Main sources? What is main sources? May be it's system independent sources? If so may be common it better name for this directory? So I suggest the following structure for sources: classlib/trunk/modules/modulename/src/ - all the sources for modulename are here. classlib/trunk/modules/modulename/src/common - all the system independent sources are here classlib/trunk/modules/modulename/src/common/java - common java sources classlib/trunk/modules/modulename/src/common/native - common native sources classlib/trunk/modules/modulename/src/linux/java - linux specific java sources classlib/trunk/modules/modulename/src/linux/native - linux specific native sources classlib/trunk/modules/modulename/src/windows/java - windows specific java sources classlib/trunk/modules/modulename/src/windows/native - windows specific native sources The last question is platform specific sources (IA32, IA64 and so on)... We can easily put them under windows/IA32 or so... Any thoughts? When some decision will be agreed or current structure become clear I will prepare patch for Contribution Policy... If nobody mind. -- Alexey A. Petrenko Intel Middleware Products Division
Re: [classlib] proposal to revisit componentization for security (was: Re: problems with security2)
I don't understand. I did the breakout of x-net... Mikhail Loenko wrote: Geir Sounds like no one objects to the proposal itself, the discussion is about the naming. Could you please approve/decline new componentization? Thanks, Mikhail On 1/27/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: Stepan Mishura wrote: Sounds dirty. How about security-x? Ok. I named it by analogy with x-net. Your variant works for me. x-net has the same issue for me. I figure that net-x is better too because it will sit next to net in a directory/IDE package tree, etc... (just like security-x near security) geir Thanks, Stepan On 1/27/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: Sounds dirty. How about security-x? Stepan Mishura wrote: I agree with the proposal and I'm ready to start working on a patch for splitting 'security2' into suggested components and integrating them with the current build. Also I'd like to suggest a name for a new component: 'x-security'. Thanks, Stepan Mishura Intel Middleware Products Division On 1/19/06, Mikhail Loenko [EMAIL PROTECTED] wrote: Hello Let's start a different thread for that. I suggest revisiting current componentization for security related parts. Now we have for example crypto architecture in security module but crypto extension in the crypto module. See natural components in the UserGuide http://java.sun.com/j2se/1.5.0/docs/guide/security/ The proposal is to have 3 components: 1. general security crypto 2. ssl 3. jaas The logical content of those components would be: 1. - General Security - Certification Path - JCE 2. - JSSE 3. - JAAS - JGSS - SASL Physical content of those components: 1. java.security javax.crypto javax.security.cert 2. javax.net 3. javax.security w/o javax.security.cert org.ietf Opinions? Thanks, Mikhail Loenko Intel Middleware Products Division -- -- Thanks, Stepan Mishura Intel Middleware Products Division
Re: verifying signed jars
Heh. Everything we will do is legal :) The point is - would taking some source from BC be the smart thing to do - would it be complete, and what kind of maintenance burden would this be going forward? Would some kind of re-packaged artifact from the BC project itself be better? Do we need source? Could we have a step where we re-package BC code in a form more suited for our purposes? geir Mikhail Loenko wrote: We can if it is legal Thanks, Mikhail On 2/10/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: So I'll ask the obvious - can we borrow some of this from BC? Stepan Mishura wrote: We should have at least to verify BC provider: 1) Message digest algorithm: SHA-1 2) Signature algorithm: SHA1withDSA Other jars may require additional algorithms, for example, SHA1withRSA. We can verify BC provider first and use it for further jar verifications. Thanks, Stepan Mishura Intel Middleware Products Division On 2/10/06, George Harley [EMAIL PROTECTED] wrote: Hi Tim, In order to verify the signature of those signed provider jars I believe that you would also need trusted implementations of : * SHA-1 and MD5 digest algorithms * DSA and RSA signature algorithms Best regards, George IBM UK Tim Ellison wrote: Stepan Mishura wrote: snip Returning back to the 'missing post'. I agreed with suggestion but currently we don't have Harmony provider so we should define how we locate 'trusted provides' to be secure. We just need a trusted SHA1PRNG, right? then we can open signed providers' jars and get any others. Regards, Tim --
Re: verifying signed jars
Folks, FYI, we are going take some code from BC in juice project. Check [1] for more info. thanks, dims [1] http://mail-archives.apache.org/mod_mbox/xml-juice-dev/200601.mbox/[EMAIL PROTECTED] On 2/10/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: Heh. Everything we will do is legal :) The point is - would taking some source from BC be the smart thing to do - would it be complete, and what kind of maintenance burden would this be going forward? Would some kind of re-packaged artifact from the BC project itself be better? Do we need source? Could we have a step where we re-package BC code in a form more suited for our purposes? geir Mikhail Loenko wrote: We can if it is legal Thanks, Mikhail On 2/10/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: So I'll ask the obvious - can we borrow some of this from BC? Stepan Mishura wrote: We should have at least to verify BC provider: 1) Message digest algorithm: SHA-1 2) Signature algorithm: SHA1withDSA Other jars may require additional algorithms, for example, SHA1withRSA. We can verify BC provider first and use it for further jar verifications. Thanks, Stepan Mishura Intel Middleware Products Division On 2/10/06, George Harley [EMAIL PROTECTED] wrote: Hi Tim, In order to verify the signature of those signed provider jars I believe that you would also need trusted implementations of : * SHA-1 and MD5 digest algorithms * DSA and RSA signature algorithms Best regards, George IBM UK Tim Ellison wrote: Stepan Mishura wrote: snip Returning back to the 'missing post'. I agreed with suggestion but currently we don't have Harmony provider so we should define how we locate 'trusted provides' to be secure. We just need a trusted SHA1PRNG, right? then we can open signed providers' jars and get any others. Regards, Tim -- -- Davanum Srinivas : http://wso2.com/blogs/
Re: Using APR for Harmony's native link to the OS?
Stefano Mazzocchi wrote: [EMAIL PROTECTED] wrote: Author: tellison Date: Fri Feb 10 05:57:38 2006 New Revision: 376690 URL: http://svn.apache.org/viewcvs?rev=376690view=rev Log: Applying patches received as HARMONY-42 (com.ibm.io.nio.FileChannel is not fully implemented) - refactoring of some java platform code - additional behavior on NIO file channels - refactoring of some IO code - work in progress on memory mapping Tim's commits made me think about something that I thought about a loong time ago (probably 1999) in the would be awesome kind of department but I put off for a future where we would have a project to work on a JVM. turns out we do have one now and turns out that APR[1] is a library that is now very solid and reached API stability over years of work by a lot of people. so, here it is, does it make sense to have harmony depend on APR and therefore abstract away all those OS-specificities? (I'm talking about both the VM and the native part of the class library). I've thought about this a while, and while I'm personally committed to using APR wherever and whenever we can, I don't think it's wise to let the APR tail wag the VM internal architecture dog, so to speak. For example, the VM should have resource requirements that APR doesn't have, and that make no sense for general APR usage. (For example, coordinating memory use between APR and the VM...) I think that we need a clear 'interface' between the VM and the OS Abstraction Component, which I expect will then be implemented using APR for every platform APR supports. However, where there is no APR support for a platform, or someone wants to do something differently, they can just (re) implement the OS Abstraction Compoment as they see fit. It also has a major social side effects: it would create the ultimate social bridge between the HTTPD/APR side of the foundation and the java side of the foundation, maybe allowing people from one side to contribute to the other, or, at least to help out in the interface between them which naturally is the JVM. What do you think? I think that doing our implementations using APR is a solid way to go. A good place to start looking is JCHEVM and BootVM... geir
Re: classlib/trunk repository structure
Alexey Petrenko wrote: Isn't it a good time to normalize classlib/trunk repository structure and update Apache Harmony Contribution Policy document (http://incubator.apache.org/harmony/contribution_policy.html) while we got small number of modules? I think that given the fact that everyone is short on cycles as well as certainty, I'd like to see us test some alternative approaches before we decide on the One Tru Way and start moving things. As for the policy doc, why? To match component names to policy documentation? Here is what I mean... 1. There is classlib/trunk/native-src directory. README says: native-src contains native source files only. So it looks like correct place for ALL the native sources. If so why we got native sources in classlib/trunk/modules/security2/src/linux/other/? I'm not at all convinced that the natives should be separate from the modules. And why we got additional java subdirectory in every main directory? It's the language the stuff below is written in. I think that we should store native sources under modules directory with all other module sources. modules/modulename/src/main/native looks like a good place for this. It will make looking for module sources much easier. yes - and I'm sure it's on the list 2. It's not clear where the system specific java sources should be stored. I think modules/modulename/src/linux and modules/modulename/src/windows will be a good place. M. We talked about this before I think the thought was to group the natives for a module together under something to prevent src/ having too many children... I'll go look back in archives. 3. It's not clear what should be placed in modules/modulename/src/main directory. Main sources? What is main sources? May be it's system independent sources? If so may be common it better name for this directory? It's to distinguish from test So I suggest the following structure for sources: classlib/trunk/modules/modulename/src/ - all the sources for modulename are here. classlib/trunk/modules/modulename/src/common - all the system independent sources are here classlib/trunk/modules/modulename/src/common/java - common java sources classlib/trunk/modules/modulename/src/common/native - common native sources classlib/trunk/modules/modulename/src/linux/java - linux specific java sources classlib/trunk/modules/modulename/src/linux/native - linux specific native sources classlib/trunk/modules/modulename/src/windows/java - windows specific java sources classlib/trunk/modules/modulename/src/windows/native - windows specific native sources I think this is like what we came up with on the list earlier. I had a few concerns : 1) That when working in common IDEs, that it was convenient to work with. 2) That build scripts were parametized and simple - so that you could specify a platform, and it would build for that platform. w/o lots of special cases or duplication in the build scripts. The last question is platform specific sources (IA32, IA64 and so on)... We can easily put them under windows/IA32 or so... That's where I fear irregularity, and where this gets harder. Because there are going to be some platforms where there is divisions (like windows - ia32, ia64) and some not (say, OSX, although now they have PPC and Intel) So what happens with platform common code? windows/common /ia32 /ia64 ? As long as the build system and test system is easily parameterized for maintainabliity, I'm happy w/ something like this. Any thoughts? When some decision will be agreed or current structure become clear I will prepare patch for Contribution Policy... If nobody mind. Hang on. before you do that, care to explain a bit why? -- Alexey A. Petrenko Intel Middleware Products Division
Re: [classlib] proposal to revisit componentization for security (was: Re: problems with security2)
x-net is a separate module according to both original and proposed componentization. What I'd like to propose is: 1. separate Authentication and Authorization stuff (javax.security package) from general security 2. unite crypto (java.security) and crypto extension (javax.crypto) It would make componentization more natural, see also my first posting in this thread: On 1/19/06, Mikhail Loenko [EMAIL PROTECTED] wrote: Hello Let's start a different thread for that. I suggest revisiting current componentization for security related parts. Now we have for example crypto architecture in security module but crypto extension in the crypto module. See natural components in the UserGuide http://java.sun.com/j2se/1.5.0/docs/guide/security/ The proposal is to have 3 components: 1. general security crypto 2. ssl 3. jaas The logical content of those components would be: 1. - General Security - Certification Path - JCE 2. - JSSE 3. - JAAS - JGSS - SASL Physical content of those components: 1. java.security javax.crypto javax.security.cert 2. javax.net 3. javax.security w/o javax.security.cert org.ietf Opinions? Thanks, Mikhail.
Re: Using APR for Harmony's native link to the OS?
Geir Magnusson Jr wrote: I think that doing our implementations using APR is a solid way to go. A good place to start looking is JCHEVM and BootVM... I haven't looked at APR in detail, but the O/S requirements of the VM proper are not that involved and I'm sure APR could handle them. There's probably more corner case requirements from the class library's native code, as that stuff implements most of Java's I/O, networking, etc. -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com
Re: Using APR for Harmony's native link to the OS?
Archie Cobbs wrote: Geir Magnusson Jr wrote: I think that doing our implementations using APR is a solid way to go. A good place to start looking is JCHEVM and BootVM... I haven't looked at APR in detail, but the O/S requirements of the VM proper are not that involved and I'm sure APR could handle them. There's probably more corner case requirements from the class library's native code, as that stuff implements most of Java's I/O, networking, etc. Which wouldn't have an APR dependency -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com
Re: Using APR for Harmony's native link to the OS?
Geir Magnusson Jr wrote: I've thought about this a while, and while I'm personally committed to using APR wherever and whenever we can, I don't think it's wise to let the APR tail wag the VM internal architecture dog, so to speak. Already there :) http://cvs.apache.org/viewcvs.cgi/tomcat/connectors/trunk/jni/ All that is needed for example for socket or file api is a wrapper over org.apache.tomcat.jni.* What is most important, it works :) Regards, Mladen.
Re: classlib/trunk repository structure
Isn't it a good time to normalize classlib/trunk repository structure and update Apache Harmony Contribution Policy document (http://incubator.apache.org/harmony/contribution_policy.html) while we got small number of modules? I think that given the fact that everyone is short on cycles as well as certainty, I'd like to see us test some alternative approaches before we decide on the One Tru Way and start moving things. OK, I understand your point. As for the policy doc, why? To match component names to policy documentation? Because it is not show the real repository structure... For example... Contribution policy: Division of Repository === skipped === enhanced/classlib /applet /awt /beans /... === skipped === Real repository: enhanced/classlib/ enhanced/classlib/branches/ - unspecified but with obvious meaning enhanced/classlib/tag/ - unspecified but with obvious meaning enhanced/classlib/trunk/ - unspecified but with obvious meaning All the directories inside trunk are not specified but almost obvious. And only inside enhanced/classlib/trunk/modules/ we can find module names which were mentioned in the policy. I think that we should store native sources under modules directory with all other module sources. modules/modulename/src/main/native looks like a good place for this. It will make looking for module sources much easier. yes - and I'm sure it's on the list OK. 2. It's not clear where the system specific java sources should be stored. I think modules/modulename/src/linux and modules/modulename/src/windows will be a good place. M. We talked about this before I think the thought was to group the natives for a module together under something to prevent src/ having too many children... But I believe that we need clear decision anyway... To put the native sources inside the modules or not to put. I think it will be very useful for developers (who plans to contribute something to Harmony) to have up to date policy on repository structure and building process. It will also help for users and fix developers to understand where to find needed sources. And my other point that now we got not much sources and it will be rather easy to adjust them to the policy. When we will have more modules with much more sources it will be much more hard. -- Alexey A. Petrenko Intel Middleware Products Division
Re: Using APR for Harmony's native link to the OS?
On Feb 10, 2006, at 9:54 AM, Stefano Mazzocchi wrote: It also has a major social side effects: it would create the ultimate social bridge between the HTTPD/APR side of the foundation and the java side of the foundation, maybe allowing people from one side to contribute to the other, or, at least to help out in the interface between them which naturally is the JVM. What do you think? Tomcat is APR aware via JNI (for connectors), and when it uses APR has some *very* appreciable enhancements :)
Re: classlib/trunk repository structure
2. It's not clear where the system specific java sources should be stored. I think modules/modulename/src/linux and modules/modulename/src/windows will be a good place. M. We talked about this before I think the thought was to group the natives for a module together under something to prevent src/ having too many children... I'll go look back in archives. I've googled list archieves and found only one theme: http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200512.mbox/[EMAIL PROTECTED] I've read it before but it is not answer the questions about layout inside the classlib/trunk directory -- Alexey A. Petrenko Intel Middleware Products Division
Re: [classlib] proposal to revisit componentization for security (was: Re: problems with security2)
Mikhail Loenko wrote: What I'd like to propose is: 1. separate Authentication and Authorization stuff (javax.security package) from general security Ok, so I can see this. 2. unite crypto (java.security) and crypto extension (javax.crypto) but this makes no sense to me. Why would you want to unite JCE with general security? There is no close coupling afaict. How about - general security - crypto - x-net - jaas there may be good reason to want to replace crypto independently of general security. Am I missing something? Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.
Re: Using APR for Harmony's native link to the OS?
On Fri, Feb 10, 2006 at 04:40:03PM +0100, Mladen Turk wrote: Geir Magnusson Jr wrote: I've thought about this a while, and while I'm personally committed to using APR wherever and whenever we can, I don't think it's wise to let the APR tail wag the VM internal architecture dog, so to speak. Already there :) http://cvs.apache.org/viewcvs.cgi/tomcat/connectors/trunk/jni/ All that is needed for example for socket or file api is a wrapper over org.apache.tomcat.jni.* What is most important, it works :) That is just *too* cool. At a glance it looks like rather decent JNI wrappers around a lot of APR stuff. Having worked a little with APR recently, I'd expect core networking performance is several times that of anything native-java-based? Is there any more developer-like information on this implementation? This is just so cool. This code is begging for some more attention, exposure, use outside tomcat, etc. Did I mention yet how cool this is? LSD
site documentation
When I was writing the page to host the eclipse movie I wanted to drop some 'random' html into the xdocs xml, but the page build whined -- so I cheated and wrote the whole page as a .html. So what should I have done to produce a page like this? (site/xdocs/subcomponents/classlibrary/dev_eclipse_movie.html) Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.
Re: classlib/trunk repository structure
Hi, Google missed this one ... http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200601.mbox/[EMAIL PROTECTED] Best regards, George IBM UK Alexey Petrenko wrote: 2. It's not clear where the system specific java sources should be stored. I think modules/modulename/src/linux and modules/modulename/src/windows will be a good place. M. We talked about this before I think the thought was to group the natives for a module together under something to prevent src/ having too many children... I'll go look back in archives. I've googled list archieves and found only one theme: http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200512.mbox/[EMAIL PROTECTED] I've read it before but it is not answer the questions about layout inside the classlib/trunk directory -- Alexey A. Petrenko Intel Middleware Products Division
Re: classlib/trunk repository structure
Alexey Petrenko wrote: As for the policy doc, why? To match component names to policy documentation? Because it is not show the real repository structure... For example... Contribution policy: Division of Repository === skipped === enhanced/classlib /applet /awt /beans /... === skipped === Real repository: enhanced/classlib/ enhanced/classlib/branches/ - unspecified but with obvious meaning enhanced/classlib/tag/ - unspecified but with obvious meaning enhanced/classlib/trunk/ - unspecified but with obvious meaning All the directories inside trunk are not specified but almost obvious. And only inside enhanced/classlib/trunk/modules/ we can find module names which were mentioned in the policy. Sure -- if you want to change the website doc to better reflect reality that would be welcomed. I think that we should store native sources under modules directory with all other module sources. modules/modulename/src/main/native looks like a good place for this. It will make looking for module sources much easier. yes - and I'm sure it's on the list OK. Yes, on the list (and getting higher) 2. It's not clear where the system specific java sources should be stored. I think modules/modulename/src/linux and modules/modulename/src/windows will be a good place. M. We talked about this before I think the thought was to group the natives for a module together under something to prevent src/ having too many children... But I believe that we need clear decision anyway... To put the native sources inside the modules or not to put. I think it will be very useful for developers (who plans to contribute something to Harmony) to have up to date policy on repository structure and building process. It will also help for users and fix developers to understand where to find needed sources. And my other point that now we got not much sources and it will be rather easy to adjust them to the policy. When we will have more modules with much more sources it will be much more hard. We are actually in the enviable position of receiving some great contributions into the project, which means (1) we are kinda busy integrating this stuff which is more productive than rearranging the stuff we currently have, and (2) it makes it easier for contributors to hit a stationary target than one that changes from week to week. So I don't disagree, and if the world were a perfect place... We'll get there. Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.
Re: [classlib] proposal to revisit componentization for security (was: Re: problems with security2)
javax.crypto is an exportable package: it's defined as an extension (JCE) that has key and parameters' export restrictions defined in JAVA_HOME/lib/security/local_policy.jar and JAVA_HOME/lib/security/US_export_policy.jar If you don't define such restrictions its make sense to merge JCE with JCA. Regards, Diego On 2/10/06, Tim Ellison [EMAIL PROTECTED] wrote: Mikhail Loenko wrote: What I'd like to propose is: 1. separate Authentication and Authorization stuff (javax.security package) from general security Ok, so I can see this. 2. unite crypto (java.security) and crypto extension (javax.crypto) but this makes no sense to me. Why would you want to unite JCE with general security? There is no close coupling afaict. How about - general security - crypto - x-net - jaas there may be good reason to want to replace crypto independently of general security. Am I missing something? Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. -- Diego
Re: [classlib] proposal to revisit componentization for security (was: Re: problems with security2)
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'd rather put it into crypto (or maybe into x-net) - all of them use service-provider architecture. What do you think? Thanks, Mikhail On 2/10/06, Tim Ellison [EMAIL PROTECTED] wrote: Mikhail Loenko wrote: What I'd like to propose is: 1. separate Authentication and Authorization stuff (javax.security package) from general security Ok, so I can see this. 2. unite crypto (java.security) and crypto extension (javax.crypto) but this makes no sense to me. Why would you want to unite JCE with general security? There is no close coupling afaict. How about - general security - crypto - x-net - jaas there may be good reason to want to replace crypto independently of general security. Am I missing something? Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.
Re: classlib/trunk repository structure
Thanks for pointing out. This message shows the structure I'm talking about :) And there is also description of current structure from Tim: http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200512.mbox/[EMAIL PROTECTED] -- Alexey A. Petrenko Intel Middleware Products Division
Re: Using APR for Harmony's native link to the OS?
Jim Jagielski wrote: On Feb 10, 2006, at 9:54 AM, Stefano Mazzocchi wrote: It also has a major social side effects: it would create the ultimate social bridge between the HTTPD/APR side of the foundation and the java side of the foundation, maybe allowing people from one side to contribute to the other, or, at least to help out in the interface between them which naturally is the JVM. What do you think? Tomcat is APR aware via JNI (for connectors), and when it uses APR has some *very* appreciable enhancements :) Heh. The reason is because they are taking a different approach to IO, right? IOW, my guess is that if the Sun JVM used APR, nothing would change, because the problem is the standard Java APIs, not the integration of the VM w/ the OS services. My understanding is that the Tomcat peeps just found a more optimal path to the OS services they needed for their specific problem. geir
Re: site documentation
Tim Ellison wrote: When I was writing the page to host the eclipse movie I wanted to drop some 'random' html into the xdocs xml, but the page build whined -- so I cheated and wrote the whole page as a .html. Bad Tim! Bad Tim! :) So what should I have done to produce a page like this? (site/xdocs/subcomponents/classlibrary/dev_eclipse_movie.html) I dunno - that's a good question. What I'd suggest another addition to the xdoc to be a callout to HTML so we get full rendering of top and nav. Something like document section name=foo htmlinclude file=dev_eclipse_movie.html / /section /document where htmlinclude is implemented in the velocity stylesheet via a #include(), and the .html file contains the body snippet you want. Fairly straightforward, and you then don't have to try and get HTML into the .xml file... Regards, Tim
Re: verifying signed jars
The sources would be good - we would be able to fix bugs quickly and replace parts of implementation for example where our code is faster. Thanks, Mikhail On 2/10/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: Heh. Everything we will do is legal :) The point is - would taking some source from BC be the smart thing to do - would it be complete, and what kind of maintenance burden would this be going forward? Would some kind of re-packaged artifact from the BC project itself be better? Do we need source? Could we have a step where we re-package BC code in a form more suited for our purposes? geir Mikhail Loenko wrote: We can if it is legal Thanks, Mikhail On 2/10/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: So I'll ask the obvious - can we borrow some of this from BC? Stepan Mishura wrote: We should have at least to verify BC provider: 1) Message digest algorithm: SHA-1 2) Signature algorithm: SHA1withDSA Other jars may require additional algorithms, for example, SHA1withRSA. We can verify BC provider first and use it for further jar verifications. Thanks, Stepan Mishura Intel Middleware Products Division On 2/10/06, George Harley [EMAIL PROTECTED] wrote: Hi Tim, In order to verify the signature of those signed provider jars I believe that you would also need trusted implementations of : * SHA-1 and MD5 digest algorithms * DSA and RSA signature algorithms Best regards, George IBM UK Tim Ellison wrote: Stepan Mishura wrote: snip Returning back to the 'missing post'. I agreed with suggestion but currently we don't have Harmony provider so we should define how we locate 'trusted provides' to be secure. We just need a trusted SHA1PRNG, right? then we can open signed providers' jars and get any others. Regards, Tim --
Re: Using APR for Harmony's native link to the OS?
Geir Magnusson Jr wrote: IOW, my guess is that if the Sun JVM used APR, nothing would change, because the problem is the standard Java APIs, not the integration of the VM w/ the OS services. My understanding is that the Tomcat peeps just found a more optimal path to the OS services they needed for their specific problem. Not to mention that the IO layer is not covered with SCSL license, and that there is no need to have platform-specific JNI code ;) Of course, the current code covers more then standard Java API does, like sendfile, shared memory, unix domain sockets, NT pipes, etc, but that doesn't mean it's 'mandatory'. If you remember, I spoke about developing classpath with APR as OS abstraction layer, from Harmony start-up :) Regards, Mladen.
Re: Which applications run using Harmony classes?
Upayavira wrote: zoe slattery wrote: OK - well - here is a plan. I have these scripts in a hacked together state and they currently rely on reading the output from -verbose:class generated by an IBM JRE. Ideally I'd like them to be able to read a couple of different formats. If anyone is interested in knowing if their app would (in theory) run using Harmony classes open a JIRA called Would $my_favourite_app run on Harmony? and attach the output from java -verbose:class $my_favourite_app. If this works I can pick up the output and use it to test the tool. Please would you also attach the output from java -version? I will append (or ask someone to append) a list of missing files to the JIRA. When I'm happy that my scripts work and I've tidied up the code I'll attach the source as a JIRA and write some instructions on how to use it. FWIW in looking at Derby, it looks as though we still need SQL (could have predicted that I suppose) and JNDI, but those seem to be all that are missing. I can send the list of missing classes to anyone that wants to verify this - it's just slightly too long to paste into mail Paste it on the wiki (wiki.apache.org/harmony/). I'd be curious to see it. Done - at the end of Tim's Apache Derby page: http://wiki.apache.org/harmony/Apache_Derby Upayavira
Re: classlib/trunk repository structure
Alexey Petrenko wrote: Geir : As for the policy doc, why? To match component names to policy documentation? Because it is not show the real repository structure... It's not meant to. The componentization is conceptual, not representing the literal layout in SVN. For example... Contribution policy: Division of Repository === skipped === enhanced/classlib /applet /awt /beans /... === skipped === Real repository: enhanced/classlib/ enhanced/classlib/branches/ - unspecified but with obvious meaning enhanced/classlib/tag/ - unspecified but with obvious meaning enhanced/classlib/trunk/ - unspecified but with obvious meaning All the directories inside trunk are not specified but almost obvious. And only inside enhanced/classlib/trunk/modules/ we can find module names which were mentioned in the policy. There are all sorts of interesting things in here that we have to deal with as time goes on. For example, what happens when we branch to do a release? :) I think that we should store native sources under modules directory with all other module sources. modules/modulename/src/main/native looks like a good place for this. It will make looking for module sources much easier. yes - and I'm sure it's on the list OK. 2. It's not clear where the system specific java sources should be stored. I think modules/modulename/src/linux and modules/modulename/src/windows will be a good place. M. We talked about this before I think the thought was to group the natives for a module together under something to prevent src/ having too many children... But I believe that we need clear decision anyway... To put the native sources inside the modules or not to put. I think that they go inside. I think it will be very useful for developers (who plans to contribute something to Harmony) to have up to date policy on repository structure and building process. It will also help for users and fix developers to understand where to find needed sources. That's all well and good, but I want to arrive at good solution through experience that doesn't unncessarily disrupt us. I think that we're starting to things crystalize At some point we'll say hey, that works well! and adjust things to fit. Now, I don't mean that things are random I don't expect that each module will be different I think that we accept new code, we will be able to learn something new (maybe) and do some minor adjustments were possible to existing, or just make the new code conform to what we think of as best practice. I know I'm not explaining this well, but I'm not convinved we have enough of a reason at this point to stop work and move things around, which will be disruptive... And my other point that now we got not much sources and it will be rather easy to adjust them to the policy. When we will have more modules with much more sources it will be much more hard. Yes, that's true. I think we just keep this in mind and move organically. I don't have the answers :) geir -- Alexey A. Petrenko Intel Middleware Products Division
Re: classlib/trunk repository structure
Sure -- if you want to change the website doc to better reflect reality that would be welcomed. OK. We are actually in the enviable position of receiving some great contributions into the project, which means (1) we are kinda busy integrating this stuff which is more productive than rearranging the stuff we currently have, and (2) it makes it easier for contributors to hit a stationary target than one that changes from week to week. Yes. It is so. But I believe that we will help contributors if we will strictly define repostitory layout. Even without the changes to current one. The following questions are unclear (after reading policy and loking into repository): 1. Where to put native sources? Inside the module or inside the native-src. 2. Where to put system dependent java sources? 3. Where to put system independent native sources? Or these questions are does not matter now and commiters can put their sources anywhere they want? -- Alexey A. Petrenko Intel Middleware Products Division
Re: Using APR for Harmony's native link to the OS?
Stefano Mazzocchi wrote: [EMAIL PROTECTED] wrote: Author: tellison Date: Fri Feb 10 05:57:38 2006 New Revision: 376690 URL: http://svn.apache.org/viewcvs?rev=376690view=rev Log: Applying patches received as HARMONY-42 (com.ibm.io.nio.FileChannel is not fully implemented) - refactoring of some java platform code - additional behavior on NIO file channels - refactoring of some IO code - work in progress on memory mapping Tim's commits made me think about something that I thought about a loong time ago (probably 1999) in the would be awesome kind of department but I put off for a future where we would have a project to work on a JVM. turns out we do have one now and turns out that APR[1] is a library that is now very solid and reached API stability over years of work by a lot of people. so, here it is, does it make sense to have harmony depend on APR and therefore abstract away all those OS-specificities? (I'm talking about both the VM and the native part of the class library). It also has a major social side effects: it would create the ultimate social bridge between the HTTPD/APR side of the foundation and the java side of the foundation, maybe allowing people from one side to contribute to the other, or, at least to help out in the interface between them which naturally is the JVM. What do you think? [1] http://apr.apache.org/ I haven't gone through the APR library therefore I don't know how many layers (i.e. function calls) it puts between Apache and the underlying OS. As far as the the native code of the Classlib and the VM is concerned, I think that we should keep it as thinner as possible in order to: 1. have Java programs run fast 2. ease portability to different OS's and platforms (embedded systems included) The GNU/Classpath guys, for example, have defined a standard interface to underlying OS and that's it. Therefore I don't think we really need the APR layer. Enrico
Re: classlib/trunk repository structure
Ok, I got your point. Will raise this questions later :) -- Alexey A. Petrenko Intel Middleware Products Division
Re: Using APR for Harmony's native link to the OS?
Enrico Migliore wrote: Stefano Mazzocchi wrote: The GNU/Classpath guys, for example, have defined a standard interface to underlying OS and that's it. Therefore I don't think we really need the APR layer. Well, perhaps some day, someone will just 'brake' and instead of loosing hair decide simply to build a better thing then GNU/Classpath is. The only reason why it's still there is because no one wrote something different, but the same thing applies to the JVM thought. Regards, Mladen.
Re: Using APR for Harmony's native link to the OS?
Mladen Turk wrote: Enrico Migliore wrote: Stefano Mazzocchi wrote: The GNU/Classpath guys, for example, have defined a standard interface to underlying OS and that's it. Therefore I don't think we really need the APR layer. Well, perhaps some day, someone will just 'brake' and instead of loosing hair decide simply to build a better thing then GNU/Classpath is. The only reason why it's still there is because no one wrote something different, but the same thing applies to the JVM thought. Regards, Mladen. I wouldn't mind at all using a rock solid library like APR between the JVM and the OS. The only problem I see here is: performance, in terms of execution speed. Enrico
java.sql.* (was: Re: Which applications run using Harmony classes?)
Would I be correct in assuming that the majority of java.sql would be trivial to implement by reading the javadocs (everything except DriverManager)? I can take a whack at the low hanging fruit this weekend. Jeremy On 10-Feb-06, at 12:05 PM, zoe slattery wrote: Upayavira wrote: zoe slattery wrote: OK - well - here is a plan. I have these scripts in a hacked together state and they currently rely on reading the output from -verbose:class generated by an IBM JRE. Ideally I'd like them to be able to read a couple of different formats. If anyone is interested in knowing if their app would (in theory) run using Harmony classes open a JIRA called Would $my_favourite_app run on Harmony? and attach the output from java -verbose:class $my_favourite_app. If this works I can pick up the output and use it to test the tool. Please would you also attach the output from java -version? I will append (or ask someone to append) a list of missing files to the JIRA. When I'm happy that my scripts work and I've tidied up the code I'll attach the source as a JIRA and write some instructions on how to use it. FWIW in looking at Derby, it looks as though we still need SQL (could have predicted that I suppose) and JNDI, but those seem to be all that are missing. I can send the list of missing classes to anyone that wants to verify this - it's just slightly too long to paste into mail Paste it on the wiki (wiki.apache.org/harmony/). I'd be curious to see it. Done - at the end of Tim's Apache Derby page: http:// wiki.apache.org/harmony/Apache_Derby Upayavira
Re: Using APR for Harmony's native link to the OS?
On 2/10/06, Enrico Migliore [EMAIL PROTECTED] wrote: Stefano Mazzocchi wrote: [EMAIL PROTECTED] wrote: Author: tellison Date: Fri Feb 10 05:57:38 2006 New Revision: 376690 URL: http://svn.apache.org/viewcvs?rev=376690view=rev Log: Applying patches received as HARMONY-42 (com.ibm.io.nio.FileChannel is not fully implemented) - refactoring of some java platform code - additional behavior on NIO file channels - refactoring of some IO code - work in progress on memory mapping Tim's commits made me think about something that I thought about a loong time ago (probably 1999) in the would be awesome kind of department but I put off for a future where we would have a project to work on a JVM. turns out we do have one now and turns out that APR[1] is a library that is now very solid and reached API stability over years of work by a lot of people. so, here it is, does it make sense to have harmony depend on APR and therefore abstract away all those OS-specificities? (I'm talking about both the VM and the native part of the class library). It also has a major social side effects: it would create the ultimate social bridge between the HTTPD/APR side of the foundation and the java side of the foundation, maybe allowing people from one side to contribute to the other, or, at least to help out in the interface between them which naturally is the JVM. What do you think? [1] http://apr.apache.org/ I haven't gone through the APR library therefore I don't know how many layers (i.e. function calls) it puts between Apache and the underlying OS. I was looking into APR's part which is responsible for threading (threadproc and locks). From what I've seen, I've got an impression that the APR does almost exactly what I would do in order to find a smallest common denominator between, for example, Win32 threading API and pthreads. So in my opinion it is pretty much close to the concept of thin portability layer we may need between VM/Classlib and OS. As far as the the native code of the Classlib and the VM is concerned, I think that we should keep it as thinner as possible in order to: 1. have Java programs run fast I suspect the performance could be a requirement for HTTPD as well. 2. ease portability to different OS's and platforms (embedded systems included) Yes, this means some layer between VM/Classlib and OS is needed anyways, and it might be good to reuse some of the existing standard solutions, rather than try to create one more. It seems that HTTPD mist be in the same position regarding the performance and portability requirements. Therefore, I would agree with the point that having a shared layer for two different projects, like HTTPD and Harmony, could be beneficial for both of them. Thank you, Andrey Chernyshev Intel Middleware Products Division The GNU/Classpath guys, for example, have defined a standard interface to underlying OS and that's it. Therefore I don't think we really need the APR layer. Enrico
Re: Using APR for Harmony's native link to the OS?
Enrico Migliore wrote: Mladen Turk wrote: I wouldn't mind at all using a rock solid library like APR between the JVM and the OS. The only problem I see here is: performance, in terms of execution speed. OTOH, I thought it's more about quality :) You can have as fast library as you wish, but if can not open a simple unicode file, what's the purpose? Also, what's the purpose of any JVM project if it needs a cygwin to open a file? Do you still think it's faster? Regards, Mladen.
Re: java.sql.*
Jeremy Huiskamp schrieb: Would I be correct in assuming that the majority of java.sql would be trivial to implement by reading the javadocs (everything except DriverManager)? I can take a whack at the low hanging fruit this weekend. The java.sql package mostly contains interfaces, so it shouldn't be too much work, but what's so difficult about the DriverManager. It only has to manage a list of registered Driver implementations and the getConnection methods should only iterate through the available drivers, check if the URL is supported and if yes, delegate the call to Driver#connect. Tor
[jira] Closed: (HARMONY-48) Extract x-net component from 'security2' module
[ http://issues.apache.org/jira/browse/HARMONY-48?page=all ] Geir Magnusson Jr closed HARMONY-48: Resolution: Fixed I think that this is in resonable shape. Thanks. Extract x-net component from 'security2' module --- Key: HARMONY-48 URL: http://issues.apache.org/jira/browse/HARMONY-48 Project: Harmony Type: Task Components: Classlib Reporter: Stepan Mishura Assignee: Geir Magnusson Jr Attachments: extractXnetPatch.txt 'security2' module contains a number of components. According to the current class library componentization a set of javax.net.* packages is a separate module (x-net). And proposed components reorganization (see http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200601.mbox/[EMAIL PROTECTED]) also suggests keeping these packages in a separate module Since there are no objections x-net component may be extracted from 'security2' and formed as a separate module. -- 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: java.sql.*
On 10-Feb-06, at 1:14 PM, Tor-Einar Jarnbjo wrote: Jeremy Huiskamp schrieb: Would I be correct in assuming that the majority of java.sql would be trivial to implement by reading the javadocs (everything except DriverManager)? I can take a whack at the low hanging fruit this weekend. The java.sql package mostly contains interfaces, so it shouldn't be too much work, but what's so difficult about the DriverManager. It only has to manage a list of registered Driver implementations and the getConnection methods should only iterate through the available drivers, check if the URL is supported and if yes, delegate the call to Driver#connect. Didn't say it was difficult, just that it's not trivial ;-) As in, the javadocs don't tell me everything I could possibly need to know to implement it. I'd love to take a crack at it, but I figured I'd start with the really easy stuff. If you beat me to it then so much the better :) Jeremy Tor
Re: Using APR for Harmony's native link to the OS?
Jim Jagielski wrote: On Feb 10, 2006, at 9:54 AM, Stefano Mazzocchi wrote: It also has a major social side effects: it would create the ultimate social bridge between the HTTPD/APR side of the foundation and the java side of the foundation, maybe allowing people from one side to contribute to the other, or, at least to help out in the interface between them which naturally is the JVM. What do you think? Tomcat is APR aware via JNI (for connectors), and when it uses APR has some *very* appreciable enhancements :) like what? (curious) -- Stefano.
[jchevm] porting harmony classlib to JCHEVM
Archie Cobbs,
Do you know if anyone is working on a port of Harmony Classlib to
JCHEVM? If false, I would like to start this port. I can't guarantee
I have time to finish the port but intend to at least sketch out what
needs to be done so that others can join the effort.
I have started looking at JCHEVM to figure out how to glue the Harmony
Classlibrary kernel classes (see
…modules/kernel/src/main/java/java/lang/*.java) to the native entry
points listed in jchevm/libjc/native_lib.c. The goal is to make only
absolutely essential mods to JCHEVM code. Ideally, there would be
zero changes to JCHEVM. All the glue would reside in JCHEVM's
private copy of Classlib's kernel classes.
Looking at Classlib's Class.java, about 17 of 40 APIs look to be a
simple conversion of a virtual method to a static method that takes a
this ptr as its first parameter. For example, the method isArray()
in Class.java would be modified to look like the code below. This
modified Class.java file would reside somewhere in the JCHEVM tree.
The original Class.java file in the Harmony Classlib tree would remain
untouched.
//Harmony/modules/kernel/src/main/java/java/lang/Class.java
Public boolean isArray () {
Boolean bb = VMClass.wrapperIsArray(this);
Return bb;
}
Because the wrapper is adding a layer of identically named methods and
thus potentially really confusing the name space, I renamed
java_lang_VMClass_isArray() to java_lang_VMClass_wrapperIsArray().
All the enties in _jc_ilib_table[ ] would also be decorated with
wrapper.
Thoughts?
Thanks
Weldon
--
Weldon Washburn
Intel Middleware Products Division
Re: Using APR for Harmony's native link to the OS?
Geir Magnusson Jr wrote: Jim Jagielski wrote: On Feb 10, 2006, at 9:54 AM, Stefano Mazzocchi wrote: It also has a major social side effects: it would create the ultimate social bridge between the HTTPD/APR side of the foundation and the java side of the foundation, maybe allowing people from one side to contribute to the other, or, at least to help out in the interface between them which naturally is the JVM. What do you think? Tomcat is APR aware via JNI (for connectors), and when it uses APR has some *very* appreciable enhancements :) Heh. The reason is because they are taking a different approach to IO, right? IOW, my guess is that if the Sun JVM used APR, nothing would change, because the problem is the standard Java APIs, not the integration of the VM w/ the OS services. My understanding is that the Tomcat peeps just found a more optimal path to the OS services they needed for their specific problem. Geir, I'm not proposed we expose a java APR API instead of the standard java API, that's not the point. My point is that a JVM has a lot of native hooks, by design. And that those native hooks will have to be ported across operating systems and that APR was designed to separate those OS dependencies from the Apache 2 codebase so that the web server could be built with some sort of 'OS abstraction' in mind. therefore, my suggestion is: instead of hooking our native stuff to the OS directly (or to the standard C libraries) we should hook them up to something that is a little more abstract and therefore reduces the effort of porting across OSes. As you note, if we do this right, the java users wouldn't be able to tell a difference (if not, maybe, performance), but the difference would be in lowing the costs of porting the native code across different OSes. But then again, since I'm not the one doing the coding, I'll be happy to let do-ocracy take place.. I just thought I mentioned it since others might not know of APR's existance and Apache HTTPD and Tomcat connectors's dependency on it (which means it's there to stay and it's heavily maintained and licensing compatible) -- Stefano.
Re: java.sql.*
Actually, we've been looking at contributing some stuff that we have already got in this area - I'll let you know by Tuesday (latest). If we can it would at least give you a head start on this and it would be really great if you could help us improve what we have. Jeremy Huiskamp wrote: On 10-Feb-06, at 1:14 PM, Tor-Einar Jarnbjo wrote: Jeremy Huiskamp schrieb: Would I be correct in assuming that the majority of java.sql would be trivial to implement by reading the javadocs (everything except DriverManager)? I can take a whack at the low hanging fruit this weekend. The java.sql package mostly contains interfaces, so it shouldn't be too much work, but what's so difficult about the DriverManager. It only has to manage a list of registered Driver implementations and the getConnection methods should only iterate through the available drivers, check if the URL is supported and if yes, delegate the call to Driver#connect. Didn't say it was difficult, just that it's not trivial ;-) As in, the javadocs don't tell me everything I could possibly need to know to implement it. I'd love to take a crack at it, but I figured I'd start with the really easy stuff. If you beat me to it then so much the better :) Jeremy Tor
Re: Using APR for Harmony's native link to the OS?
Enrico Migliore wrote: Stefano Mazzocchi wrote: [EMAIL PROTECTED] wrote: Author: tellison Date: Fri Feb 10 05:57:38 2006 New Revision: 376690 URL: http://svn.apache.org/viewcvs?rev=376690view=rev Log: Applying patches received as HARMONY-42 (com.ibm.io.nio.FileChannel is not fully implemented) - refactoring of some java platform code - additional behavior on NIO file channels - refactoring of some IO code - work in progress on memory mapping Tim's commits made me think about something that I thought about a loong time ago (probably 1999) in the would be awesome kind of department but I put off for a future where we would have a project to work on a JVM. turns out we do have one now and turns out that APR[1] is a library that is now very solid and reached API stability over years of work by a lot of people. so, here it is, does it make sense to have harmony depend on APR and therefore abstract away all those OS-specificities? (I'm talking about both the VM and the native part of the class library). It also has a major social side effects: it would create the ultimate social bridge between the HTTPD/APR side of the foundation and the java side of the foundation, maybe allowing people from one side to contribute to the other, or, at least to help out in the interface between them which naturally is the JVM. What do you think? [1] http://apr.apache.org/ I haven't gone through the APR library therefore I don't know how many layers (i.e. function calls) it puts between Apache and the underlying OS. As far as the the native code of the Classlib and the VM is concerned, I think that we should keep it as thinner as possible in order to: 1. have Java programs run fast I agree this is the goal, but since performance is *also* one of the needs for the Apache HTTPD 2.x project, I doubt they went very light on that front (especially after 5 years of development!) 2. ease portability to different OS's and platforms (embedded systems included) APR was designed to ease OS portability. The GNU/Classpath guys, for example, have defined a standard interface to underlying OS and that's it. Therefore I don't think we really need the APR layer. I disagree. I think we would gain a lot of value by using APR instead of reinventing something that 5 years from now will look just like it. -- Stefano.
Re: Using APR for Harmony's native link to the OS?
Enrico Migliore wrote: Mladen Turk wrote: Enrico Migliore wrote: Stefano Mazzocchi wrote: The GNU/Classpath guys, for example, have defined a standard interface to underlying OS and that's it. Therefore I don't think we really need the APR layer. Well, perhaps some day, someone will just 'brake' and instead of loosing hair decide simply to build a better thing then GNU/Classpath is. The only reason why it's still there is because no one wrote something different, but the same thing applies to the JVM thought. Regards, Mladen. I wouldn't mind at all using a rock solid library like APR between the JVM and the OS. The only problem I see here is: performance, in terms of execution speed. early optimization is the root to all evil, and I think it clearly applies here. -- Stefano.
Re: Using APR for Harmony's native link to the OS?
Enrico Migliore wrote: As far as the the native code of the Classlib and the VM is concerned, I think that we should keep it as thinner as possible in order to: 1. have Java programs run fast 2. ease portability to different OS's and platforms (embedded systems included) The GNU/Classpath guys, for example, have defined a standard interface to underlying OS and that's it. Therefore I don't think we really need the APR layer. I think where APR will help is in *implementing* that standard interface for various platforms geir
Re: java.sql.*
Jeremy Huiskamp wrote: Didn't say it was difficult, just that it's not trivial ;-) As in, the javadocs don't tell me everything I could possibly need to know to implement it. I'd love to take a crack at it, but I figured I'd start with the really easy stuff. If you beat me to it then so much the better :) I already thought about contributing some other stuff, but I am unsure if I fulfil the requirements for contributing (especially regarding exposure to Sun's source code). I sent a mail to Geir Magnusson about JavaSound implementation a few weeks ago, but didn't get any reaction. Perhaps it's better to discuss this here on the mailing list. Tor
Re: java.sql.*
Tor-Einar Jarnbjo wrote: Jeremy Huiskamp wrote: Didn't say it was difficult, just that it's not trivial ;-) As in, the javadocs don't tell me everything I could possibly need to know to implement it. I'd love to take a crack at it, but I figured I'd start with the really easy stuff. If you beat me to it then so much the better :) I already thought about contributing some other stuff, but I am unsure if I fulfil the requirements for contributing (especially regarding exposure to Sun's source code). I sent a mail to Geir Magnusson about JavaSound implementation a few weeks ago, but didn't get any reaction. Perhaps it's better to discuss this here on the mailing list. Yes, this would be the place. Sorry about that - I am in the middle of a machine change, and email switch, so I've been an email blackhole at times... geir Tor
Re: verifying signed jars
Why not contribute directly to BouncyCastle? Regards, Tim Mikhail Loenko wrote: The sources would be good - we would be able to fix bugs quickly and replace parts of implementation for example where our code is faster. Thanks, Mikhail On 2/10/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: Heh. Everything we will do is legal :) The point is - would taking some source from BC be the smart thing to do - would it be complete, and what kind of maintenance burden would this be going forward? Would some kind of re-packaged artifact from the BC project itself be better? Do we need source? Could we have a step where we re-package BC code in a form more suited for our purposes? geir Mikhail Loenko wrote: We can if it is legal Thanks, Mikhail On 2/10/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: So I'll ask the obvious - can we borrow some of this from BC? Stepan Mishura wrote: We should have at least to verify BC provider: 1) Message digest algorithm: SHA-1 2) Signature algorithm: SHA1withDSA Other jars may require additional algorithms, for example, SHA1withRSA. We can verify BC provider first and use it for further jar verifications. Thanks, Stepan Mishura Intel Middleware Products Division On 2/10/06, George Harley [EMAIL PROTECTED] wrote: Hi Tim, In order to verify the signature of those signed provider jars I believe that you would also need trusted implementations of : * SHA-1 and MD5 digest algorithms * DSA and RSA signature algorithms Best regards, George IBM UK Tim Ellison wrote: Stepan Mishura wrote: snip Returning back to the 'missing post'. I agreed with suggestion but currently we don't have Harmony provider so we should define how we locate 'trusted provides' to be secure. We just need a trusted SHA1PRNG, right? then we can open signed providers' jars and get any others. Regards, Tim -- -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.
Re: classlib/trunk repository structure
Geir Magnusson Jr wrote: Alexey Petrenko wrote: Sure -- if you want to change the website doc to better reflect reality that would be welcomed. OK. Hang on - the Authorized Contributor Questionnaire is conceptual in how we want to manage any exposure issues. The fact that it doesn't absolutely reflect the layout in SVN is irrelevant. I think one of us is missing the point... I'm looking at the text in the Division of Repository subsection in the page http://incubator.apache.org/harmony/contribution_policy.html it has a schematic representation of the repository that is not precise. I'm *not* suggesting that we change the contribution policy / ACQ. I'd prefer making any changes to that document until our overall layout settles down to avoid having to do continual changes. We are actually in the enviable position of receiving some great contributions into the project, which means (1) we are kinda busy integrating this stuff which is more productive than rearranging the stuff we currently have, and (2) it makes it easier for contributors to hit a stationary target than one that changes from week to week. Yes. It is so. But I believe that we will help contributors if we will strictly define repostitory layout. Even without the changes to current one. What problem are you really trying to solve? IOW, has this stopped anyone from contributing? If so, please let us know, because there is no need to match the structure when a contribution is made. Good code is good code, and as the receiver of the gift, we're happy to do the work to put into our project layout, with gratitude. +2 (send good code) The following questions are unclear (after reading policy and loking into repository): 1. Where to put native sources? Inside the module or inside the native-src. We haven't resolved with 100% certainty, but I think we're in agreement that in module is preferred. But so far, there has been no compelling reason to stop what we're doing and move it. 2. Where to put system dependent java sources? 3. Where to put system independent native sources? We'll figure it out. Right now we have a few good exmaples, and we should take a hard look and decide. Or these questions are does not matter now and commiters can put their sources anywhere they want? No - we all work together. Committers aren't individual contractors - we're collaborating to build something we all agree with... Contributors, on the other hand, are free to provide to us in any way they want. We'd be happier if it was more like our structure(s) than different, but we beggars can't be choosers... :) Agree with all above too. Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.
Re: Using APR for Harmony's native link to the OS?
Stefano Mazzocchi wrote:
snip
therefore, my suggestion is: instead of hooking our native stuff to the
OS directly (or to the standard C libraries) we should hook them up to
something that is a little more abstract and therefore reduces the
effort of porting across OSes.
Have you seen the classlib port layer code that is already in Harmony?
http://svn.apache.org/viewcvs.cgi/*checkout*/incubator/harmony/enhanced/classlib/trunk/doc/vm_doc/html/group__Port.html
The existing natives(*) use this layer for all OS interaction. There is
a portlib implementation for Windows and Linux on IA32 in Harmony.
I'm no expert on APR, but I would expect that implementing the portlib
on APR would be no more difficult than implementing it on any other
platform.
(*) modulo the security2 native code
For classlib developers who need to twiddle bits, there is a set of
pluggable Java interfaces (called I{File|Memory|Network}System.java) here:
http://svn.apache.org/viewcvs.cgi/incubator/harmony/enhanced/classlib/trunk/modules/nio/src/main/java/com/ibm/platform/
Regards,
Tim
--
Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.
Re: classlib/trunk repository structure
Tim Ellison wrote: Geir Magnusson Jr wrote: Alexey Petrenko wrote: Sure -- if you want to change the website doc to better reflect reality that would be welcomed. OK. Hang on - the Authorized Contributor Questionnaire is conceptual in how we want to manage any exposure issues. The fact that it doesn't absolutely reflect the layout in SVN is irrelevant. I think one of us is missing the point... I'm looking at the text in the Division of Repository subsection in the page http://incubator.apache.org/harmony/contribution_policy.html it has a schematic representation of the repository that is not precise. I'm *not* suggesting that we change the contribution policy / ACQ. Got it. Ok. I'm wrong. Sorry. Yes - that diagram was just handwaving to get the idea across. It could actually go away for all I care. We can fix it too, but the conceptual dimensions of the idea are more important than representing the physical layout of the code. geir
Re: java.sql.*
Geir Magnusson Jr wrote: Yes, this would be the place. Sorry about that - I am in the middle of a machine change, and email switch, so I've been an email blackhole at times... So, I sent you a partial implementation of JavaSound and a Vorbis SPI, any interest? One problem is of course, that I more than once have taken a look at Sun's source code for different reasons and even signed an NDA some ten years ago to get access to the source code for JDK 1.1. Your requirements in the contributor license agreement and questionnaire are IMHO rather vague. Tor
Re: java.sql.*
Tor-Einar Jarnbjo wrote: Geir Magnusson Jr wrote: Yes, this would be the place. Sorry about that - I am in the middle of a machine change, and email switch, so I've been an email blackhole at times... So, I sent you a partial implementation of JavaSound and a Vorbis SPI, any interest? Lets discuss that here. :) I didn't mean to ignore you - but two mail machines were hard to follow. I'm ready to join them into one, and hopefully I'll stop dropping the ball :) One problem is of course, that I more than once have taken a look at Sun's source code for different reasons and even signed an NDA some ten years ago to get access to the source code for JDK 1.1. Your requirements in the contributor license agreement and questionnaire are IMHO rather vague. Which code, and what were the terms of the NDA? The CLA is fairly lightwieght. What questions do you have for both? geir
Re: [jchevm] porting harmony classlib to JCHEVM
Weldon Washburn wrote: Do you know if anyone is working on a port of Harmony Classlib to JCHEVM? If false, I would like to start this port. I can't guarantee I have time to finish the port but intend to at least sketch out what needs to be done so that others can join the effort. I don't know of anyone working on it yet. That would be great to do some exploration. Since JCHEVM already works with the VM interface defined by Classpath, as much re-use of that API as possible makes a lot of sense. If we can't import Classpath files directly (which itself is stupid and highly ironic imho, but that's another discussion) then we can write new files that provide the same API (doing that should not have any copyright problems). From my initial glances the Classpath API is often lower level than the Classlib API, so all that would be needed in theory is to fill the resulting gap with some Java code glue. I have started looking at JCHEVM to figure out how to glue the Harmony Classlibrary kernel classes (see …modules/kernel/src/main/java/java/lang/*.java) to the native entry points listed in jchevm/libjc/native_lib.c. The goal is to make only absolutely essential mods to JCHEVM code. Ideally, there would be zero changes to JCHEVM. All the glue would reside in JCHEVM's private copy of Classlib's kernel classes. The overlay approach, which works well. Because the wrapper is adding a layer of identically named methods and thus potentially really confusing the name space, I renamed java_lang_VMClass_isArray() to java_lang_VMClass_wrapperIsArray(). All the enties in _jc_ilib_table[ ] would also be decorated with wrapper. Is that really necessary? It seems to me that the existing JCHEVM native API can remain intact. There are great advantages in being able to run JCHEVM with both Classlib and Classpath at the same time for debugging purposes (not to mention Classlib on J9). The more combinations you can try, the easier it is to hone in on a bug's source. So I'd strongly prefer that the Java/VM API remain the same as much as possible. Certainly this can be done with the right overlay classes. Cheers, -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com
JavaSound Was: java.sql.*
Geir Magnusson Jr wrote: Lets discuss that here. :) I didn't mean to ignore you - but two mail machines were hard to follow. I'm ready to join them into one, and hopefully I'll stop dropping the ball :) Ok, here are a snippet from the mail I sent you: (Win32 partial implementation of JavaSound): http://jarnbjo.de/HJavaSound.zip Installation is quite simple, just copy the following files to jre\lib\ext: dist/sound.jar, dist/vorbis-spi.jar and the following files to some directory in the dll path (e.g. jre\bin\default): dist/sound.dll The ant build file will build the HJavaSound Java source code and the C source using Borland's CBuilderX. I know it's not pretty, using hard coded paths etc., but it was just a quick hack to simplify the build process. The source code for the SPI and player are included in the vorbis-spi and spiplayer directories, for which no build files are included. Hope you don't mind that I already chose to put implementation specific classes in the org.apache.harmony.sound.sampled package. Ogg/Vorbis files should now play with java -jar dist/spiplayer.jar filename. The Vorbis SPI for JavaSound and the SpiPlayer itself are actually parts of my project J-Ogg (ww.j-ogg.de), which is already released under an Apache-style license (http://www.j-ogg.de/core/main?/download-libraries.html). Another issue with this is of course that the current VMs working with Harmony are not able to use Java 5 class files and implementing JavaSound for 1.4 and later extending it for Java 5 would be at least some unnecessary work. Are there any current plans for extending the VMs for Java 5 code? Which code, and what were the terms of the NDA? The CLA is fairly lightwieght. Good questions, I honestly don't know. Working as a Java developer, I now and then need to trace into the original source code or take a look or two at the API implementation to realize why something is not working as I expect. As far as I can remember, I have not done this with Sun's JavaSound implementation. I don't have the NDA anymore, or am at least not able to find it, having moved around several times the last ten years. For working on a JavaSound implementation, it is probably irrelevant anyway, as JavaSound was not introduced until Java 1.3 and ought not to be covered by any agreement in Sun's NDA. Tor
CLA issues Was: java.sql.*
Geir Magnusson Jr wrote: Which code, and what were the terms of the NDA? The CLA is fairly lightwieght. What questions do you have for both? I thought I better split this, to prevent the discussion from getting too confusing. One thing I already pointed out with the Apache CLA is that it is very biased towards US copyright law. I am not a lawyer and I really have no clue if US copyright law, German Urheberrecht or both applies if I, living in Germany, am signing a contract with a US entity. The most serious legal crash is probably section 2: Grant of Copyright License. First problem is, that I can't grant you anything I currently don't have, a copyright on my work. The German counterpart, my Urheberrecht is not transferable and any license I give to use, redistribute, modify etc. the work may under some conditions be revoked. Any contract diverging from these principles is in Germany legally void. Another specific issue related to my proposed Vorbis SPI for JavaSound donation, is if you regard third party source code to be classified as format documentation . To be more exact, the Vorbis format specification from the Xiph Foundation proved to contain several errors and their attitude when me pointing it out was, that the reference decoder is the only thing to be considered as a formal specification. This means of course, that at least when it comes to some estimated 20-40 lines of code, my Vorbis decoder implementation is at least based on the reference decoder from Xiph, which is AFAIK released under a BSD license. Patent issues are also unclear to me. At this point the CLA is really vague (§5), only demaning me to represent that my contribution is free of any patents that I am personally aware of. I have absolutely no ability to judge on that, which of course fulfils, that I am not personally aware of any claims, but depending on the contributors knowledge on patent and license law, this paragraph lies somewhere between meaningsless and very dependent on which country's patents and licenses are to be considered. Tor
[jira] Updated: (HARMONY-63) java.text.MessageFormat.parse(String): incorrect size of Object array parsed from the string
[ http://issues.apache.org/jira/browse/HARMONY-63?page=all ]
Nathan Beyer updated HARMONY-63:
Attachment: MessageFormat_patch.txt
Try this patch out. It should resolve the issue and update the test case with a
regression test, as proposed by the reporter. It seems like the MessageFormat
and other related format classes need some serious testing done, so we may need
to just write a full test case to make sure this little fix and others aren't
introducing new issues.
java.text.MessageFormat.parse(String): incorrect size of Object array parsed
from the string
Key: HARMONY-63
URL: http://issues.apache.org/jira/browse/HARMONY-63
Project: Harmony
Type: Bug
Components: Classlib
Reporter: tatyana doubtsova
Attachments: MessageFormat_patch.txt
Problem details:
Method java.text.MessageFormat.parse(String) returns the array of 10 elements
when parsing string 1,00,00' using pattern {0,number,#,}. It should
return array of 1 element.
Code for reproducing Test.java:
import java.text.MessageFormat;
import java.util.Locale;
public class Test {
public static void main(String[] args) {
try {
MessageFormat mf = new MessageFormat({0,number,#,},
Locale.US);
Object[] res = mf.parse(1,00,00);
System.out.println(result's length: + res.length);
for (int i = 0; i res.length; i++) {
System.out.println(result is: + res[0]);
}
} catch (Exception e) {
e.printStackTrace();
}
}
}
Steps to Reproduce:
1. Build Harmony (check-out on 2006-01-30) j2se subset as described in
README.txt.
2. Compile Test.java using BEA 1.4 javac
javac -d . Test.java
3. Run java using compatible VM (J9)
java -showversion Test
Output:
java version 1.4.2 (subset)
(c) Copyright 1991, 2005 The Apache Software Foundation or its licensors, as
applicable.
result's length: 10
result is: 1
result is: 1
result is: 1
result is: 1
result is: 1
result is: 1
result is: 1
result is: 1
result is: 1
result is: 1
Output on BEA 1.4.2 to compare with:
result's length: 1
result is: 1
Suggested junit test case:
package org.apache.harmony.tests.java.text;
import java.text.MessageFormat;
import java.util.Locale;
import junit.framework.TestCase;
public class MessageFormatTest extends TestCase {
public static void main(String[] args) {
junit.textui.TestRunner.run(MessageFormatTest.class);
}
public void test_parse() {
try {
MessageFormat mf = new MessageFormat({0,number,#,},
Locale.US);
Object[] res = mf.parse(1,00,00);
assertEquals(Assert 0: incorrect size of parsed data , 1,
res.length);
} catch (Exception e) {
fail(Assert 0: Unexpected exception + e);
}
}
}
--
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
