Re: [jira] Updated: (HARMONY-35) Harmony ignores java.security.policy property
Good -- so what I'll do is to release George's patch to the com.ibm
version to get him working, on the understanding that the whole type
will become obsolete soon when the security2 code is integrated. Ok?
Regards,
Tim
Stepan Mishura wrote:
Hi George,
The reason for this buggy behaviour is the incomplete implementation of
com.ibm.oti.util.DefaultPolicy in the luni component. The readPolicy()
method needs work to actually fulfill its contract as laid out in the
Javadoc comments.
com.ibm.oti.util.DefaultPolicy extends java.security.Policy class that is
from the security component.
BTW, we do have another implementation of java.security.Policy that is
org.apache.harmony.security.fortress.DefaultPolicy and
I've verified that in this particular case implementation from 'security2'
works correctly.
Thanks,
Stepan Mishura
Intel Middleware Products Division
On 1/20/06, George Harley (JIRA) [EMAIL PROTECTED] wrote:
[ http://issues.apache.org/jira/browse/HARMONY-35?page=all ]
George Harley updated HARMONY-35:
-
Attachment: HARMONY-35-patch.txt
The attached patch seems to fix it for me on Win XP. Not tested on Linux.
Best regards,
George
Harmony ignores java.security.policy property
-
Key: HARMONY-35
URL: http://issues.apache.org/jira/browse/HARMONY-35
Project: Harmony
Type: Bug
Components: Classlib
Environment: Win32 and Linux
Reporter: George Harley
Attachments: HARMONY-35-patch.txt
Here is the complete contents of a Java security policy file called
mysecurity.policy that can be used to specify additional permissions to a
JRE...
-snip--
grant {
// so we can remove the security manager
permission java.lang.RuntimePermission setSecurityManager;
};
-snip--
If its location is passed in the Java launch arguments with the
java.security.policy property as below then the permissions are added to
the default set of permissions that the JRE runs with ...
-Djava.security.policy=c:\path\to\mysecurity.policy
If the following unit test is run against a sandbox build of the
classlibs under SVN trunk on the IBM Apache Harmony VME with the
java.security.policy set (as above) so that the setSecurityManager
runtime permission is added, then a pass should result. It doesn't.
---snip--
package foo;
import java.security.AccessControlException;
import junit.framework.TestCase;
public class SecurityPolicyTest extends TestCase {
public void testPermissions() {
try {
System.out
.println(Trying to set the security manager the
first time...);
System.setSecurityManager(new SecurityManager());
System.out.println(Trying to set the security manager to
null...);
System.setSecurityManager(null);
assertEquals(null, System.getSecurityManager());
} catch (AccessControlException e) {
fail(Caught AccessControlException : + e.getMessage());
}
}
}
---snip--
The failure occurs because an AccessControlException is thrown on the
second call to System.setSecurityManager() when the test tries to pass a
null argument.
The problem is that after the first call to System.setSecurityManager()
has installed a security manager, there is no runtime permission to enable
the security manager to be set again. This is despite the fact that when
running the test we set the java.security.policy property to point to a
file that grants this very permission !
The reason for this buggy behaviour is the incomplete implementation of
com.ibm.oti.util.DefaultPolicy in the luni component. The readPolicy()
method needs work to actually fulfill its contract as laid out in the
Javadoc comments.
George
--
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
--
Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.
Re: [jira] Updated: (HARMONY-35) Harmony ignores java.security.policy property
Thanks Tim.
George C. Harley
Tim Ellison [EMAIL PROTECTED]
20/01/2006 10:55
Please respond to
harmony-dev@incubator.apache.org
To
harmony-dev@incubator.apache.org
cc
Subject
Re: [jira] Updated: (HARMONY-35) Harmony ignores java.security.policy
property
Good -- so what I'll do is to release George's patch to the com.ibm
version to get him working, on the understanding that the whole type
will become obsolete soon when the security2 code is integrated. Ok?
Regards,
Tim
Stepan Mishura wrote:
Hi George,
The reason for this buggy behaviour is the incomplete implementation of
com.ibm.oti.util.DefaultPolicy in the luni component. The readPolicy()
method needs work to actually fulfill its contract as laid out in the
Javadoc comments.
com.ibm.oti.util.DefaultPolicy extends java.security.Policy class that
is
from the security component.
BTW, we do have another implementation of java.security.Policy that is
org.apache.harmony.security.fortress.DefaultPolicy and
I've verified that in this particular case implementation from
'security2'
works correctly.
Thanks,
Stepan Mishura
Intel Middleware Products Division
On 1/20/06, George Harley (JIRA) [EMAIL PROTECTED] wrote:
[ http://issues.apache.org/jira/browse/HARMONY-35?page=all ]
George Harley updated HARMONY-35:
-
Attachment: HARMONY-35-patch.txt
The attached patch seems to fix it for me on Win XP. Not tested on
Linux.
Best regards,
George
Harmony ignores java.security.policy property
-
Key: HARMONY-35
URL: http://issues.apache.org/jira/browse/HARMONY-35
Project: Harmony
Type: Bug
Components: Classlib
Environment: Win32 and Linux
Reporter: George Harley
Attachments: HARMONY-35-patch.txt
Here is the complete contents of a Java security policy file called
mysecurity.policy that can be used to specify additional permissions
to a
JRE...
-snip--
grant {
// so we can remove the security manager
permission java.lang.RuntimePermission setSecurityManager;
};
-snip--
If its location is passed in the Java launch arguments with the
java.security.policy property as below then the permissions are added
to
the default set of permissions that the JRE runs with ...
-Djava.security.policy=c:\path\to\mysecurity.policy
If the following unit test is run against a sandbox build of the
classlibs under SVN trunk on the IBM Apache Harmony VME with the
java.security.policy set (as above) so that the setSecurityManager
runtime permission is added, then a pass should result. It doesn't.
---snip--
package foo;
import java.security.AccessControlException;
import junit.framework.TestCase;
public class SecurityPolicyTest extends TestCase {
public void testPermissions() {
try {
System.out
.println(Trying to set the security manager the
first time...);
System.setSecurityManager(new SecurityManager());
System.out.println(Trying to set the security manager to
null...);
System.setSecurityManager(null);
assertEquals(null, System.getSecurityManager());
} catch (AccessControlException e) {
fail(Caught AccessControlException : + e.getMessage());
}
}
}
---snip--
The failure occurs because an AccessControlException is thrown on the
second call to System.setSecurityManager() when the test tries to pass
a
null argument.
The problem is that after the first call to
System.setSecurityManager()
has installed a security manager, there is no runtime permission to
enable
the security manager to be set again. This is despite the fact that
when
running the test we set the java.security.policy property to point to a
file that grants this very permission !
The reason for this buggy behaviour is the incomplete implementation
of
com.ibm.oti.util.DefaultPolicy in the luni component. The readPolicy()
method needs work to actually fulfill its contract as laid out in the
Javadoc comments.
George
--
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
--
Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.
[classlib] Unit and performance testing (was Re: [jira] Commented: (HARMONY-31) Move peformance timing of unit tests into a decorator class.)
[I got sick of the thread subject - it blended into every other JIRA thread... ] There is a 4th option - not mix performance infrastructure with unit testing. I'm all for getting PerformanceTest out of the class hierarchy, and not having unit tests yammer out to console if we can avoid it. (I do testing in console, and don't really care about the output, but it will slew the performance numbers as console i/o is relatively expensive...) That said, I do believe in the importance of having performance numbers to help detect regressions. George outlined how to use standard JUnit mechanisms to do this. IMO, they are good because they are the canonical way using JUnit, but they also are a bit invasive too. Some other options : 1) This problem seems to be to be one of three usecases in the universe for using aspects (the other two being logging and caching, of course...) So that's one area we might investigate - we would add an interceptor for each test/suite/whatever to do the perf that we need to be done. We might be able to use it to turn debug logging on and off as well in a cheap and uninvasive way. 2) TestNG - I do want to give this a hard look, as it's annotations based, and see if there's something in there (or coming in there) for this. TestNG will also run JUnit tests as is, so playing with it is going to be easy. geir Mikhail Loenko wrote: To summarize, we have 3 options: 1. Keep PerformanceTest as a super class. Set printAllowed to false by default. 2. Remove PerformnceTest. Introduce a simple Logger that does not print by default. 3. Move performance functionality to Decorator. #1 is the most unliked. #3 as I wrote before does not work. So I can submit a script that goes through the tests replacing extends PerformanceTest with extends TestCase import PerformanceTest with import Logger and putting Logger. before logln() and other log functions Thanks, Mikhail On 1/19/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: Mikhail Loenko wrote: On 1/19/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: Mikhail Loenko wrote: The problem is unstable execution time of java programs: If you consequently run the same java program on the same computer in the same conditions, execution time may vary by 20% or even more Why? Given that computers are pretty determinstic, I'd argue that you don't have the same conditions from run to run. Did you make experiments or it's your theoretical conclusion :) ? Have done experiments. I never claim that it's the same conditions every run. That's the issue, I think. geir Try to create an application that runs 20 seconds and run it several times. Frankly, I do not exactly know why. But I know a lot of reasons that could affect this dispersion. For example, there is a number of serving threads and GC that impact on execution time. Thanks, Mikhail geir
Re: [jira] Commented: (HARMONY-27) The network related channels in java.nio.channels are not implemented
ah! Nice diagrams! Sorry I didn't look just at the JIRA... Yang Paulex wrote: Sorry for the confusion I caused, I DID write it in txt, about the red, I didn't mean the color of text, but the color of classes in the class diagram I attached:). I thought I should add the attachment link to this JIRA comments. Sorry for that. 2006/1/19, Geir Magnusson Jr [EMAIL PROTECTED]: Paulex Yang (JIRA) wrote: [ http://issues.apache.org/jira/browse/HARMONY-27?page=comments#action_12363230] Paulex Yang commented on HARMONY-27: my proposed solution: 1. Refactor the java.net Currently, the Harmony's socket structur is as below(red means API classes, others are package private). I will attach the diagram to Jira. red? I assume that you did this in HTML? Please, no HTML - it's hard for people to read who don't use HTML-enabled mail readers I for example, can't see it... geir I proposed to refactor to three packages like this: java.net: for sure includes All API classes, and includes them only public class Socket public class ServerSocket public abstract class SocketImpl public class DatagramSocket public class MulticastSocket extends DatagramSocket public abstract class DatagramSocketImpl org.apache.harmony.net: all implementation classes with a factory public class SocketImplProvider class PlainSocketImpl extends SocketImpl class PlainSocketImpl2 extends PlainSocketImpl class PlainServerSocketImpl extends PlainSocketImpl class PlainDatagramSocketImpl extends DatagramSocketImpl class PlainMulticastSocketImpl extends PlainDatagramSocketImpl some relevant small classes(Socks4Message, GenericIPMreq) org.apache.platform: currently, this package includes native file system and memory management interface, so it is a good place to include the native network interface, the INetworkSystem will encapsulate all JNI interfaces. public interface INetworkSystem public class OSNetworkSystem implements INetworkSystem 2. Implement java.nio Now it is ready to implement NIO network channels based on it: java.nio: public abstract class SocketChannel public abstract class ServerSocketChannel public abstract class DatagramSocketChannel class SocketChannelImpl class ServerSocketImpl class DatagramSocketChannelImpl class SocketAdapter class ServerSocketAdapter class DatagramSocketAdapter I will attach the result diagram into JIRA, too 3. Modulize them According to the current Harmony modulization, propose to modify the modulization as follows: luni exports: java.net, org.apache.harmony.net, org.apache.harmony.platform(move from nio to luni, and export it) nio exports: java.nio The network related channels in java.nio.channels are not implemented - Key: HARMONY-27 URL: http://issues.apache.org/jira/browse/HARMONY-27 Project: Harmony Type: Bug Components: Classlib Reporter: Paulex Yang Assignee: Geir Magnusson Jr The following classes defined by Java Spec 5.0 in java.nio.channels are not included in the class library code public abstarct class java.nio.channels.DatagramChannel public abstract class java.nio.channels.ServerSocketChannel public abstract class java.nio.channels.SocketChannel -- Paulex Yang China Software Development Labotary IBM
Re: [classlib-security2] Move to org.apache.harmony namespace complete
Tim Ellison wrote: Were you running the tests on the classlib code? Versus? I was just running security2's testsuite. I compiled the tests against a reference implementation, What do you mean by this? and had limited success running tests there. I tried switching to use the classlib code to run the tests, but I don't see an Ant target that _just_ runs the tests (it starts compiling the natives again, and that fails for me). It would be useful if the script was modified to build against the existing classlib code, and/or the tests.run target simply ran the tests if the build is up to date. No kidding. p.s. looks like the ascii/binary flag need flipping on some of the ant scripts. k Regards Tim Geir Magnusson Jr wrote: I was able to test in Ubuntu 5.1 on a VMWare partition all tests pass Geir Magnusson Jr wrote: Right - I need to put that back in... put junit and bcprov on your classpath... .or wait a few min until I redo the build again to do it automatically. evil classpath Tim Ellison wrote: Anything special required for the environment? What classpath do you have set-up? Regards, Tim [EMAIL PROTECTED]:~/Harmony/modules/security2/make$ ant tests.run Buildfile: build.xml ...snip... tests.compile: [echo] Compiling Security tests from /home/tellison/Harmony/modules/security2/test/common/unit, /home/tellison/Harmony/modules/security2/test/linux/unit tests: run: [junit] Running java.security.AccessControlExceptionTest [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 0.012 sec [junit] Running java.security.AlgorithmParameterGeneratorSpiTests [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.085 sec [junit] Running java.security.AlgorithmParameterGeneratorTest1 [junit] Tests run: 2, Failures: 1, Errors: 0, Time elapsed: 0.016 sec BUILD FAILED /home/tellison/Harmony/modules/security2/make/build.xml:396: Test java.security.AlgorithmParameterGeneratorTest1 failed Total time: 7 seconds [EMAIL PROTECTED]:~/Harmony/modules/security2/make$ Geir Magnusson Jr wrote: That took longer than I thought, but I thought it generally productive for me as I understand it a lot more, and in general because we got some good discussion and broader awareness. All tests pass on WindowsXP - someone needs to test on linux to make sure I didn't break anything. For next steps, I'd like to modify the local security2 component build to product artifacts that drop in with the rest, so we can get rid of security/ Once we have that done, we could re-structure to be like the others. But first, it would be good to have it be a first-class citizen in the classlibrary. What's the easiest way to do this? geir
Re: [classlib] Unit and performance testing (was Re: [jira] Commented: (HARMONY-31) Move peformance timing of unit tests into a decorator class.)
Formally, option #2 from my mail that was 2. Remove PerformnceTest. Introduce a simple Logger that does not print by default. does not mix any performance *infrastructure* with junit testing. I think that we do not have to find the final solution right now, we might see various ideas as people will develop and contribute thier tests and as we investigate more options. As far as the #1 task for now is integration of security2, any rather good short-term solution would be acceptable. I have not seen any other solution that is well studied and does not cut existing functionality. Thanks, Mikhail On 1/20/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: [I got sick of the thread subject - it blended into every other JIRA thread... ] There is a 4th option - not mix performance infrastructure with unit testing. I'm all for getting PerformanceTest out of the class hierarchy, and not having unit tests yammer out to console if we can avoid it. (I do testing in console, and don't really care about the output, but it will slew the performance numbers as console i/o is relatively expensive...) That said, I do believe in the importance of having performance numbers to help detect regressions. George outlined how to use standard JUnit mechanisms to do this. IMO, they are good because they are the canonical way using JUnit, but they also are a bit invasive too. Some other options : 1) This problem seems to be to be one of three usecases in the universe for using aspects (the other two being logging and caching, of course...) So that's one area we might investigate - we would add an interceptor for each test/suite/whatever to do the perf that we need to be done. We might be able to use it to turn debug logging on and off as well in a cheap and uninvasive way. 2) TestNG - I do want to give this a hard look, as it's annotations based, and see if there's something in there (or coming in there) for this. TestNG will also run JUnit tests as is, so playing with it is going to be easy. geir Mikhail Loenko wrote: To summarize, we have 3 options: 1. Keep PerformanceTest as a super class. Set printAllowed to false by default. 2. Remove PerformnceTest. Introduce a simple Logger that does not print by default. 3. Move performance functionality to Decorator. #1 is the most unliked. #3 as I wrote before does not work. So I can submit a script that goes through the tests replacing extends PerformanceTest with extends TestCase import PerformanceTest with import Logger and putting Logger. before logln() and other log functions Thanks, Mikhail On 1/19/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: Mikhail Loenko wrote: On 1/19/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: Mikhail Loenko wrote: The problem is unstable execution time of java programs: If you consequently run the same java program on the same computer in the same conditions, execution time may vary by 20% or even more Why? Given that computers are pretty determinstic, I'd argue that you don't have the same conditions from run to run. Did you make experiments or it's your theoretical conclusion :) ? Have done experiments. I never claim that it's the same conditions every run. That's the issue, I think. geir Try to create an application that runs 20 seconds and run it several times. Frankly, I do not exactly know why. But I know a lot of reasons that could affect this dispersion. For example, there is a number of serving threads and GC that impact on execution time. Thanks, Mikhail geir
[jira] Updated: (HARMONY-27) The network related channels in java.nio.channels are not implemented
[ http://issues.apache.org/jira/browse/HARMONY-27?page=all ] Paulex Yang updated HARMONY-27: --- Attachment: INetworkSystem.java OSNetworkSystem.java FileDescriptorHandler.java This files demonstrate what I mean on the JNI interface, which encapsulate network relevant functions for both NIO and LUNI component. Significant part of the method declarations are refactored from current Harmony java.net JNI methods, others are added to support NIO extension. The network related channels in java.nio.channels are not implemented - Key: HARMONY-27 URL: http://issues.apache.org/jira/browse/HARMONY-27 Project: Harmony Type: Bug Components: Classlib Reporter: Paulex Yang Assignee: Geir Magnusson Jr Attachments: FileDescriptorHandler.java, INetworkSystem.java, Nio-net Refactoring.jpg, OSNetworkSystem.java, java.net.JPG The following classes defined by Java Spec 5.0 in java.nio.channels are not included in the class library code public abstarct class java.nio.channels.DatagramChannel public abstract class java.nio.channels.ServerSocketChannel public abstract class java.nio.channels.SocketChannel -- 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: [jira] Updated: (HARMONY-35) Harmony ignores java.security.policy property
Hi Stepan,
Great. I look forward to the consolidation of the 'security' and
'security2' modules.
Best regards,
George
George C. Harley
Stepan Mishura [EMAIL PROTECTED]
20/01/2006 05:57
Please respond to
harmony-dev@incubator.apache.org
To
harmony-dev@incubator.apache.org
cc
Subject
Re: [jira] Updated: (HARMONY-35) Harmony ignores java.security.policy
property
Hi George,
The reason for this buggy behaviour is the incomplete implementation of
com.ibm.oti.util.DefaultPolicy in the luni component. The readPolicy()
method needs work to actually fulfill its contract as laid out in the
Javadoc comments.
com.ibm.oti.util.DefaultPolicy extends java.security.Policy class that is
from the security component.
BTW, we do have another implementation of java.security.Policy that is
org.apache.harmony.security.fortress.DefaultPolicy and
I've verified that in this particular case implementation from 'security2'
works correctly.
Thanks,
Stepan Mishura
Intel Middleware Products Division
On 1/20/06, George Harley (JIRA) [EMAIL PROTECTED] wrote:
[ http://issues.apache.org/jira/browse/HARMONY-35?page=all ]
George Harley updated HARMONY-35:
-
Attachment: HARMONY-35-patch.txt
The attached patch seems to fix it for me on Win XP. Not tested on
Linux.
Best regards,
George
Harmony ignores java.security.policy property
-
Key: HARMONY-35
URL: http://issues.apache.org/jira/browse/HARMONY-35
Project: Harmony
Type: Bug
Components: Classlib
Environment: Win32 and Linux
Reporter: George Harley
Attachments: HARMONY-35-patch.txt
Here is the complete contents of a Java security policy file called
mysecurity.policy that can be used to specify additional permissions to
a
JRE...
-snip--
grant {
// so we can remove the security manager
permission java.lang.RuntimePermission setSecurityManager;
};
-snip--
If its location is passed in the Java launch arguments with the
java.security.policy property as below then the permissions are added to
the default set of permissions that the JRE runs with ...
-Djava.security.policy=c:\path\to\mysecurity.policy
If the following unit test is run against a sandbox build of the
classlibs under SVN trunk on the IBM Apache Harmony VME with the
java.security.policy set (as above) so that the setSecurityManager
runtime permission is added, then a pass should result. It doesn't.
---snip--
package foo;
import java.security.AccessControlException;
import junit.framework.TestCase;
public class SecurityPolicyTest extends TestCase {
public void testPermissions() {
try {
System.out
.println(Trying to set the security manager the
first time...);
System.setSecurityManager(new SecurityManager());
System.out.println(Trying to set the security manager to
null...);
System.setSecurityManager(null);
assertEquals(null, System.getSecurityManager());
} catch (AccessControlException e) {
fail(Caught AccessControlException : + e.getMessage());
}
}
}
---snip--
The failure occurs because an AccessControlException is thrown on the
second call to System.setSecurityManager() when the test tries to pass a
null argument.
The problem is that after the first call to
System.setSecurityManager()
has installed a security manager, there is no runtime permission to
enable
the security manager to be set again. This is despite the fact that when
running the test we set the java.security.policy property to point to a
file that grants this very permission !
The reason for this buggy behaviour is the incomplete implementation
of
com.ibm.oti.util.DefaultPolicy in the luni component. The readPolicy()
method needs work to actually fulfill its contract as laid out in the
Javadoc comments.
George
--
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: [jira] Updated: (HARMONY-35) Harmony ignores java.security.policy property
pointless, but ok.
geir
Tim Ellison wrote:
I'll race ya' :-)
Geir Magnusson Jr wrote:
Tim Ellison wrote:
Good -- so what I'll do is to release George's patch to the com.ibm
version to get him working, on the understanding that the whole type
will become obsolete soon when the security2 code is integrated. Ok?
sure, but how long will it take us to integrate? We should just do that
ASAP.
geir
Regards,
Tim
Stepan Mishura wrote:
Hi George,
The reason for this buggy behaviour is the incomplete implementation of
com.ibm.oti.util.DefaultPolicy in the luni component. The readPolicy()
method needs work to actually fulfill its contract as laid out in the
Javadoc comments.
com.ibm.oti.util.DefaultPolicy extends java.security.Policy class
that is
from the security component.
BTW, we do have another implementation of java.security.Policy that is
org.apache.harmony.security.fortress.DefaultPolicy and
I've verified that in this particular case implementation from
'security2'
works correctly.
Thanks,
Stepan Mishura
Intel Middleware Products Division
On 1/20/06, George Harley (JIRA) [EMAIL PROTECTED] wrote:
[ http://issues.apache.org/jira/browse/HARMONY-35?page=all ]
George Harley updated HARMONY-35:
-
Attachment: HARMONY-35-patch.txt
The attached patch seems to fix it for me on Win XP. Not tested on
Linux.
Best regards,
George
Harmony ignores java.security.policy property
-
Key: HARMONY-35
URL: http://issues.apache.org/jira/browse/HARMONY-35
Project: Harmony
Type: Bug
Components: Classlib
Environment: Win32 and Linux
Reporter: George Harley
Attachments: HARMONY-35-patch.txt
Here is the complete contents of a Java security policy file called
mysecurity.policy that can be used to specify additional
permissions to a
JRE...
-snip--
grant {
// so we can remove the security manager
permission java.lang.RuntimePermission setSecurityManager;
};
-snip--
If its location is passed in the Java launch arguments with the
java.security.policy property as below then the permissions are
added to
the default set of permissions that the JRE runs with ...
-Djava.security.policy=c:\path\to\mysecurity.policy
If the following unit test is run against a sandbox build of the
classlibs under SVN trunk on the IBM Apache Harmony VME with the
java.security.policy set (as above) so that the setSecurityManager
runtime permission is added, then a pass should result. It doesn't.
---snip--
package foo;
import java.security.AccessControlException;
import junit.framework.TestCase;
public class SecurityPolicyTest extends TestCase {
public void testPermissions() {
try {
System.out
.println(Trying to set the security manager the
first time...);
System.setSecurityManager(new SecurityManager());
System.out.println(Trying to set the security manager to
null...);
System.setSecurityManager(null);
assertEquals(null, System.getSecurityManager());
} catch (AccessControlException e) {
fail(Caught AccessControlException : + e.getMessage());
}
}
}
---snip--
The failure occurs because an AccessControlException is thrown on the
second call to System.setSecurityManager() when the test tries to
pass a
null argument.
The problem is that after the first call to
System.setSecurityManager()
has installed a security manager, there is no runtime permission to
enable
the security manager to be set again. This is despite the fact that
when
running the test we set the java.security.policy property to point to a
file that grants this very permission !
The reason for this buggy behaviour is the incomplete
implementation of
com.ibm.oti.util.DefaultPolicy in the luni component. The readPolicy()
method needs work to actually fulfill its contract as laid out in the
Javadoc comments.
George
--
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: compiling JCHEVM with GCC/Cygwin
Enrico Migliore wrote: The bad news is that the RedHat guys hasn't ported ucontext library to Cygwin. The good one is that: 1. You call just one of the 4 ucontext library functions, and you call it in just one source file (stack.c) 2. I've found an example explaining how to port the ucontext library in Cygwin (Don't know if it works though) Good, hopefully #2 will work. The use of ucontext is pretty critical, because otherwise we could leak references and accidentally GC an object still in use. Actually there could be an alternative implementation using setjmp(), I'll look into that if time permits. zip problem I downloaded the source code of zip-2.3 and, at line 373 of zip.c, I got this: #ifdef MACOS Sorry, I meant JCHEVM's zip,c: jchevm/libjc/zip.c. Looks like the pread(3) function is not working properly under Cygwin. This error occurs on line 373 of zip.c if you want to try to debug it (sorry, I'm Windows illiterate). Yet, I can't find, in the Zip source files, the the pread( ) function that you told me about pread(3) is something that Cygwin would supply, not zip. I.e., it's part of the standard C library (per Unix98). -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com
[classlib : security[2]] security2 integrated (first cust)
I did a hacky integration of security2 to replace security. After chatting a bit w/ Tim, I took a very simpleminded approach, of just getting the master build. This only works on windows for now. 1) the main classlib script builds the java code and produces the security jar. 2) the main native scrip kicks off the full security2 make and copies the .dll out Clearly we have to improve #2, clearly, but once we verify I didn't screw up too badly, then we can do it stepwise. I'd like to propose a change in the build structure to segement by platform, so that it's very clear the pile that gets built and where, giving us the freedom to have an appropriate layout for each. /trunk/deploy/ win32/ include/ jre/ linux/ include/ jrs/ geir
[jira] Resolved: (HARMONY-35) Harmony ignores java.security.policy property
[ http://issues.apache.org/jira/browse/HARMONY-35?page=all ]
Tim Ellison resolved HARMONY-35:
Resolution: Fixed
Fixed in luni module com/ibm/oti/util/DefaultPolicy.java at repository
revision 370797.
George, please check this fully fixes the problem.
Harmony ignores java.security.policy property
-
Key: HARMONY-35
URL: http://issues.apache.org/jira/browse/HARMONY-35
Project: Harmony
Type: Bug
Components: Classlib
Environment: Win32 and Linux
Reporter: George Harley
Assignee: Tim Ellison
Attachments: HARMONY-35-patch.txt
Here is the complete contents of a Java security policy file called
mysecurity.policy that can be used to specify additional permissions to a
JRE...
-snip--
grant {
// so we can remove the security manager
permission java.lang.RuntimePermission setSecurityManager;
};
-snip--
If its location is passed in the Java launch arguments with the
java.security.policy property as below then the permissions are added to the
default set of permissions that the JRE runs with ...
-Djava.security.policy=c:\path\to\mysecurity.policy
If the following unit test is run against a sandbox build of the classlibs
under SVN trunk on the IBM Apache Harmony VME with the java.security.policy
set (as above) so that the setSecurityManager runtime permission is added,
then a pass should result. It doesn't.
---snip--
package foo;
import java.security.AccessControlException;
import junit.framework.TestCase;
public class SecurityPolicyTest extends TestCase {
public void testPermissions() {
try {
System.out
.println(Trying to set the security manager the first
time...);
System.setSecurityManager(new SecurityManager());
System.out.println(Trying to set the security manager to
null...);
System.setSecurityManager(null);
assertEquals(null, System.getSecurityManager());
} catch (AccessControlException e) {
fail(Caught AccessControlException : + e.getMessage());
}
}
}
---snip--
The failure occurs because an AccessControlException is thrown on the second
call to System.setSecurityManager() when the test tries to pass a null
argument.
The problem is that after the first call to System.setSecurityManager() has
installed a security manager, there is no runtime permission to enable the
security manager to be set again. This is despite the fact that when running
the test we set the java.security.policy property to point to a file that
grants this very permission !
The reason for this buggy behaviour is the incomplete implementation of
com.ibm.oti.util.DefaultPolicy in the luni component. The readPolicy() method
needs work to actually fulfill its contract as laid out in the Javadoc
comments.
George
--
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 : security[2]] security2 integrated (first cust)
Geir Magnusson Jr wrote: I did a hacky integration of security2 to replace security. After chatting a bit w/ Tim, I took a very simpleminded approach, hmm, not sure what to make of that comment ... ;-) of just getting the master build. This only works on windows for now. 1) the main classlib script builds the java code and produces the security jar. 2) the main native scrip kicks off the full security2 make and copies the .dll out Clearly we have to improve #2, clearly, but once we verify I didn't screw up too badly, then we can do it stepwise. I'd like to propose a change in the build structure to segement by platform, so that it's very clear the pile that gets built and where, giving us the freedom to have an appropriate layout for each. /trunk/deploy/ win32/ include/ jre/ linux/ include/ jrs/ No point. The build scripts embody which platform they are building for, there is no need to reflect that in the target (even if we _were_ doing x-compiling, which we are not). Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.
Re: [classlib : security[2]] security2 integrated (first cust)
Hi Geir, I'd like to propose a change in the build structure to segement by platform, so that it's very clear the pile that gets built and where, giving us the freedom to have an appropriate layout for each. /trunk/deploy/ win32/ include/ jre/ linux/ include/ jrs/ Sorry but I don't really see the need for this change. A developer is only going to be building on one platform at any given time and the existing build scripts are already capable of sensing that platform. My 2 euro cents. Best regards, George George C. Harley Geir Magnusson Jr [EMAIL PROTECTED] 20/01/2006 15:59 Please respond to harmony-dev@incubator.apache.org To harmony-dev@incubator.apache.org cc Subject [classlib : security[2]] security2 integrated (first cust) I did a hacky integration of security2 to replace security. After chatting a bit w/ Tim, I took a very simpleminded approach, of just getting the master build. This only works on windows for now. 1) the main classlib script builds the java code and produces the security jar. 2) the main native scrip kicks off the full security2 make and copies the .dll out Clearly we have to improve #2, clearly, but once we verify I didn't screw up too badly, then we can do it stepwise. I'd like to propose a change in the build structure to segement by platform, so that it's very clear the pile that gets built and where, giving us the freedom to have an appropriate layout for each. /trunk/deploy/ win32/ include/ jre/ linux/ include/ jrs/ geir
Re: [jira] Updated: (HARMONY-35) Harmony ignores java.security.policy property
Tim Ellison wrote:
sorry for being flippant -- I took your Ok? sure as agreement.
Oh, definitely :)
Since it is a reported bug in the existing code, with a patch that looks
good, I figured the (literally) 60 seconds it took me to release it into
HEAD may help out anyone who downloads the code in the time it takes to
merge security2.
No argument from me...
Hopefully its life-span is only a couple of hours.
Hopefully, but that assumes I didn't screw anything up. Not a sure way
to bet...
Regards,
Tim
Geir Magnusson Jr wrote:
pointless, but ok.
geir
Tim Ellison wrote:
I'll race ya' :-)
Geir Magnusson Jr wrote:
Tim Ellison wrote:
Good -- so what I'll do is to release George's patch to the com.ibm
version to get him working, on the understanding that the whole type
will become obsolete soon when the security2 code is integrated. Ok?
sure, but how long will it take us to integrate? We should just do that
ASAP.
geir
Regards,
Tim
Stepan Mishura wrote:
Hi George,
The reason for this buggy behaviour is the incomplete
implementation of
com.ibm.oti.util.DefaultPolicy in the luni component. The
readPolicy()
method needs work to actually fulfill its contract as laid out in the
Javadoc comments.
com.ibm.oti.util.DefaultPolicy extends java.security.Policy class
that is
from the security component.
BTW, we do have another implementation of java.security.Policy that is
org.apache.harmony.security.fortress.DefaultPolicy and
I've verified that in this particular case implementation from
'security2'
works correctly.
Thanks,
Stepan Mishura
Intel Middleware Products Division
On 1/20/06, George Harley (JIRA) [EMAIL PROTECTED] wrote:
[ http://issues.apache.org/jira/browse/HARMONY-35?page=all ]
George Harley updated HARMONY-35:
-
Attachment: HARMONY-35-patch.txt
The attached patch seems to fix it for me on Win XP. Not tested on
Linux.
Best regards,
George
Harmony ignores java.security.policy property
-
Key: HARMONY-35
URL: http://issues.apache.org/jira/browse/HARMONY-35
Project: Harmony
Type: Bug
Components: Classlib
Environment: Win32 and Linux
Reporter: George Harley
Attachments: HARMONY-35-patch.txt
Here is the complete contents of a Java security policy file
called
mysecurity.policy that can be used to specify additional
permissions to a
JRE...
-snip--
grant {
// so we can remove the security manager
permission java.lang.RuntimePermission setSecurityManager;
};
-snip--
If its location is passed in the Java launch arguments with the
java.security.policy property as below then the permissions are
added to
the default set of permissions that the JRE runs with ...
-Djava.security.policy=c:\path\to\mysecurity.policy
If the following unit test is run against a sandbox build of the
classlibs under SVN trunk on the IBM Apache Harmony VME with the
java.security.policy set (as above) so that the setSecurityManager
runtime permission is added, then a pass should result. It doesn't.
---snip--
package foo;
import java.security.AccessControlException;
import junit.framework.TestCase;
public class SecurityPolicyTest extends TestCase {
public void testPermissions() {
try {
System.out
.println(Trying to set the security manager the
first time...);
System.setSecurityManager(new SecurityManager());
System.out.println(Trying to set the security
manager to
null...);
System.setSecurityManager(null);
assertEquals(null, System.getSecurityManager());
} catch (AccessControlException e) {
fail(Caught AccessControlException : +
e.getMessage());
}
}
}
---snip--
The failure occurs because an AccessControlException is thrown on
the
second call to System.setSecurityManager() when the test tries to
pass a
null argument.
The problem is that after the first call to
System.setSecurityManager()
has installed a security manager, there is no runtime permission to
enable
the security manager to be set again. This is despite the fact that
when
running the test we set the java.security.policy property to point
to a
file that grants this very permission !
The reason for this buggy behaviour is the incomplete
implementation of
com.ibm.oti.util.DefaultPolicy in the luni component. The
readPolicy()
method needs work to actually fulfill its contract as laid out in the
Javadoc comments.
George
--
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] Assigned: (HARMONY-27) The network related channels in java.nio.channels are not implemented
[ http://issues.apache.org/jira/browse/HARMONY-27?page=all ] Tim Ellison reassigned HARMONY-27: -- Assign To: Tim Ellison (was: Geir Magnusson Jr) The network related channels in java.nio.channels are not implemented - Key: HARMONY-27 URL: http://issues.apache.org/jira/browse/HARMONY-27 Project: Harmony Type: Bug Components: Classlib Reporter: Paulex Yang Assignee: Tim Ellison Attachments: FileDescriptorHandler.java, INetworkSystem.java, Nio-net Refactoring.jpg, OSNetworkSystem.java, java.net.JPG The following classes defined by Java Spec 5.0 in java.nio.channels are not included in the class library code public abstarct class java.nio.channels.DatagramChannel public abstract class java.nio.channels.ServerSocketChannel public abstract class java.nio.channels.SocketChannel -- 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: [jira] Updated: (HARMONY-35) Harmony ignores java.security.policy property
sorry for being flippant -- I took your Ok? sure as agreement.
Since it is a reported bug in the existing code, with a patch that looks
good, I figured the (literally) 60 seconds it took me to release it into
HEAD may help out anyone who downloads the code in the time it takes to
merge security2. Hopefully its life-span is only a couple of hours.
Regards,
Tim
Geir Magnusson Jr wrote:
pointless, but ok.
geir
Tim Ellison wrote:
I'll race ya' :-)
Geir Magnusson Jr wrote:
Tim Ellison wrote:
Good -- so what I'll do is to release George's patch to the com.ibm
version to get him working, on the understanding that the whole type
will become obsolete soon when the security2 code is integrated. Ok?
sure, but how long will it take us to integrate? We should just do that
ASAP.
geir
Regards,
Tim
Stepan Mishura wrote:
Hi George,
The reason for this buggy behaviour is the incomplete
implementation of
com.ibm.oti.util.DefaultPolicy in the luni component. The
readPolicy()
method needs work to actually fulfill its contract as laid out in the
Javadoc comments.
com.ibm.oti.util.DefaultPolicy extends java.security.Policy class
that is
from the security component.
BTW, we do have another implementation of java.security.Policy that is
org.apache.harmony.security.fortress.DefaultPolicy and
I've verified that in this particular case implementation from
'security2'
works correctly.
Thanks,
Stepan Mishura
Intel Middleware Products Division
On 1/20/06, George Harley (JIRA) [EMAIL PROTECTED] wrote:
[ http://issues.apache.org/jira/browse/HARMONY-35?page=all ]
George Harley updated HARMONY-35:
-
Attachment: HARMONY-35-patch.txt
The attached patch seems to fix it for me on Win XP. Not tested on
Linux.
Best regards,
George
Harmony ignores java.security.policy property
-
Key: HARMONY-35
URL: http://issues.apache.org/jira/browse/HARMONY-35
Project: Harmony
Type: Bug
Components: Classlib
Environment: Win32 and Linux
Reporter: George Harley
Attachments: HARMONY-35-patch.txt
Here is the complete contents of a Java security policy file
called
mysecurity.policy that can be used to specify additional
permissions to a
JRE...
-snip--
grant {
// so we can remove the security manager
permission java.lang.RuntimePermission setSecurityManager;
};
-snip--
If its location is passed in the Java launch arguments with the
java.security.policy property as below then the permissions are
added to
the default set of permissions that the JRE runs with ...
-Djava.security.policy=c:\path\to\mysecurity.policy
If the following unit test is run against a sandbox build of the
classlibs under SVN trunk on the IBM Apache Harmony VME with the
java.security.policy set (as above) so that the setSecurityManager
runtime permission is added, then a pass should result. It doesn't.
---snip--
package foo;
import java.security.AccessControlException;
import junit.framework.TestCase;
public class SecurityPolicyTest extends TestCase {
public void testPermissions() {
try {
System.out
.println(Trying to set the security manager the
first time...);
System.setSecurityManager(new SecurityManager());
System.out.println(Trying to set the security
manager to
null...);
System.setSecurityManager(null);
assertEquals(null, System.getSecurityManager());
} catch (AccessControlException e) {
fail(Caught AccessControlException : +
e.getMessage());
}
}
}
---snip--
The failure occurs because an AccessControlException is thrown on
the
second call to System.setSecurityManager() when the test tries to
pass a
null argument.
The problem is that after the first call to
System.setSecurityManager()
has installed a security manager, there is no runtime permission to
enable
the security manager to be set again. This is despite the fact that
when
running the test we set the java.security.policy property to point
to a
file that grants this very permission !
The reason for this buggy behaviour is the incomplete
implementation of
com.ibm.oti.util.DefaultPolicy in the luni component. The
readPolicy()
method needs work to actually fulfill its contract as laid out in the
Javadoc comments.
George
--
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
--
Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.
[jira] Created: (HARMONY-37) remove() method of IdentityHashMap works incorrectly
remove() method of IdentityHashMap works incorrectly
Key: HARMONY-37
URL: http://issues.apache.org/jira/browse/HARMONY-37
Project: Harmony
Type: Bug
Components: Classlib
Reporter: Vladimir Strigun
When user try to remove unexisting key from empty hashmap, size of object
decreased to -1.
Testcase for reproducing:
import java.util.IdentityHashMap;
public class Harmony37 {
public static void main(String args[]) {
IdentityHashMap hashMap = new IdentityHashMap();
hashMap.remove(unexist);
if (hashMap.size() != 0) {
System.out.println(FAILED, because size=+hashMap.size());
}
}
}
--
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] Commented: (HARMONY-27) The network related channels in java.nio.channels are not implemented
[ http://issues.apache.org/jira/browse/HARMONY-27?page=comments#action_12363415 ] Tim Ellison commented on HARMONY-27: Thanks Paulex -- this makes sense. It fits in with the design of FileChannels that are under development already. Can you attach the native code that goes with this? Then I can create the SocketChannels and refactor the regular IO to use the o.a.h.net package. The network related channels in java.nio.channels are not implemented - Key: HARMONY-27 URL: http://issues.apache.org/jira/browse/HARMONY-27 Project: Harmony Type: Bug Components: Classlib Reporter: Paulex Yang Assignee: Tim Ellison Attachments: FileDescriptorHandler.java, INetworkSystem.java, Nio-net Refactoring.jpg, OSNetworkSystem.java, java.net.JPG The following classes defined by Java Spec 5.0 in java.nio.channels are not included in the class library code public abstarct class java.nio.channels.DatagramChannel public abstract class java.nio.channels.ServerSocketChannel public abstract class java.nio.channels.SocketChannel -- 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] Commented: (HARMONY-37) remove() method of IdentityHashMap works incorrectly
[
http://issues.apache.org/jira/browse/HARMONY-37?page=comments#action_12363416 ]
Vladimir Strigun commented on HARMONY-37:
-
I'll attach regression test for this bug. Here is diff for
/incubator/harmony/enhanced/classlib/trunk/modules/luni/src/test/java/org/apache/harmony/tests/java/util/AllTests.java
:
32a33
suite.addTestSuite(IdentityHashMapTest.class);
remove() method of IdentityHashMap works incorrectly
Key: HARMONY-37
URL: http://issues.apache.org/jira/browse/HARMONY-37
Project: Harmony
Type: Bug
Components: Classlib
Reporter: Vladimir Strigun
When user try to remove unexisting key from empty hashmap, size of object
decreased to -1.
Testcase for reproducing:
import java.util.IdentityHashMap;
public class Harmony37 {
public static void main(String args[]) {
IdentityHashMap hashMap = new IdentityHashMap();
hashMap.remove(unexist);
if (hashMap.size() != 0) {
System.out.println(FAILED, because size=+hashMap.size());
}
}
}
--
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] Updated: (HARMONY-37) remove() method of IdentityHashMap works incorrectly
[ http://issues.apache.org/jira/browse/HARMONY-37?page=all ]
Vladimir Strigun updated HARMONY-37:
Attachment: IdentityHashMapTest.java
regression test
remove() method of IdentityHashMap works incorrectly
Key: HARMONY-37
URL: http://issues.apache.org/jira/browse/HARMONY-37
Project: Harmony
Type: Bug
Components: Classlib
Reporter: Vladimir Strigun
Attachments: IdentityHashMapTest.java
When user try to remove unexisting key from empty hashmap, size of object
decreased to -1.
Testcase for reproducing:
import java.util.IdentityHashMap;
public class Harmony37 {
public static void main(String args[]) {
IdentityHashMap hashMap = new IdentityHashMap();
hashMap.remove(unexist);
if (hashMap.size() != 0) {
System.out.println(FAILED, because size=+hashMap.size());
}
}
}
--
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] Updated: (HARMONY-36) java.nio.CharBuffer does not implement java.lang.Appendable and java.lang.Readable
[ http://issues.apache.org/jira/browse/HARMONY-36?page=all ] Richard Liang updated HARMONY-36: - Attachment: CharBuffer_patch.txt CharSequenceAdapter_patch.txt CharBufferTest_patch.txt These are patch files for java.nio.CharBuffer, java.nio.CharSequenceAdapter and unit test for java.nio.CharBuffer. Could anyone verify my fix? Thanks a lot. java.nio.CharBuffer does not implement java.lang.Appendable and java.lang.Readable -- Key: HARMONY-36 URL: http://issues.apache.org/jira/browse/HARMONY-36 Project: Harmony Type: Bug Components: Classlib Reporter: Richard Liang Attachments: Appendable.java, CharBufferTest_patch.txt, CharBuffer_patch.txt, CharSequenceAdapter_patch.txt, Readable.java In Java 5, java.nio.CharBuffer are required to implement two new interfaces java.lang.Appendable and java.lang.Readable. I will attache the new interfaces and fix for java.nio.CharBuffer soon :-) -- 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 : security[2]] security2 integrated (first cust)
Tim Ellison wrote: Geir Magnusson Jr wrote: I did a hacky integration of security2 to replace security. After chatting a bit w/ Tim, I took a very simpleminded approach, hmm, not sure what to make of that comment ... ;-) LOL. of just getting the master build. This only works on windows for now. 1) the main classlib script builds the java code and produces the security jar. 2) the main native scrip kicks off the full security2 make and copies the .dll out Clearly we have to improve #2, clearly, but once we verify I didn't screw up too badly, then we can do it stepwise. I'd like to propose a change in the build structure to segement by platform, so that it's very clear the pile that gets built and where, giving us the freedom to have an appropriate layout for each. /trunk/deploy/ win32/ include/ jre/ linux/ include/ jrs/ No point. The build scripts embody which platform they are building for, there is no need to reflect that in the target (even if we _were_ doing x-compiling, which we are not). I figured that would be the answer. When I was doing the integration, I had a flash of insight about why I want this. I can't defend it now though... alas... geir Regards, Tim
[jira] Commented: (HARMONY-37) remove() method of IdentityHashMap works incorrectly
[
http://issues.apache.org/jira/browse/HARMONY-37?page=comments#action_12363462 ]
Tim Ellison commented on HARMONY-37:
Vladimir,
Good test -- thanks. ... and it's worse than that, the IdentityHashMap does
not deal with 'null' keys and values properly.
Will take a look at it.
remove() method of IdentityHashMap works incorrectly
Key: HARMONY-37
URL: http://issues.apache.org/jira/browse/HARMONY-37
Project: Harmony
Type: Bug
Components: Classlib
Reporter: Vladimir Strigun
Assignee: Tim Ellison
Attachments: IdentityHashMapTest.java
When user try to remove unexisting key from empty hashmap, size of object
decreased to -1.
Testcase for reproducing:
import java.util.IdentityHashMap;
public class Harmony37 {
public static void main(String args[]) {
IdentityHashMap hashMap = new IdentityHashMap();
hashMap.remove(unexist);
if (hashMap.size() != 0) {
System.out.println(FAILED, because size=+hashMap.size());
}
}
}
--
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] Assigned: (HARMONY-37) remove() method of IdentityHashMap works incorrectly
[ http://issues.apache.org/jira/browse/HARMONY-37?page=all ]
Tim Ellison reassigned HARMONY-37:
--
Assign To: Tim Ellison
remove() method of IdentityHashMap works incorrectly
Key: HARMONY-37
URL: http://issues.apache.org/jira/browse/HARMONY-37
Project: Harmony
Type: Bug
Components: Classlib
Reporter: Vladimir Strigun
Assignee: Tim Ellison
Attachments: IdentityHashMapTest.java
When user try to remove unexisting key from empty hashmap, size of object
decreased to -1.
Testcase for reproducing:
import java.util.IdentityHashMap;
public class Harmony37 {
public static void main(String args[]) {
IdentityHashMap hashMap = new IdentityHashMap();
hashMap.remove(unexist);
if (hashMap.size() != 0) {
System.out.println(FAILED, because size=+hashMap.size());
}
}
}
--
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
