[jira] Assigned: (HARMONY-113) java.nio.charset.Charset should regard empty charset name properly as Illegal CharsetName
[ http://issues.apache.org/jira/browse/HARMONY-113?page=all ]
Tim Ellison reassigned HARMONY-113:
---
Assign To: Tim Ellison
java.nio.charset.Charset should regard empty charset name properly as Illegal
CharsetName
-
Key: HARMONY-113
URL: http://issues.apache.org/jira/browse/HARMONY-113
Project: Harmony
Type: Bug
Components: Classlib
Reporter: Richard Liang
Assignee: Tim Ellison
Attachments: charset_patch.txt
I think it's caused by the different between RI 1.4.2 and RI 5.0. Three test
cases in JIRA#57 should be updated accordingly.
public void testIsSupported_EmptyString() {
try {
Charset.isSupported();
fail(Should throw IllegalCharsetNameException!);
} catch (IllegalCharsetNameException e) {
//
}
}
public void testConstructor_EmptyCanonicalName() {
try {
new MockCharset(, new String[0]);
fail(Should throw IllegalCharsetNameException!);
} catch (IllegalCharsetNameException e) {
//
}
}
public void testConstructor_EmptyAliases() {
try {
new MockCharset(mockChar, new String[] { });
fail(Should throw IllegalCharsetNameException!);
} catch (IllegalCharsetNameException 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
[jira] Assigned: (HARMONY-96) Two new methods need to be implemented by java.nio.charset.Charset
[ http://issues.apache.org/jira/browse/HARMONY-96?page=all ] Tim Ellison reassigned HARMONY-96: -- Assign To: Tim Ellison Two new methods need to be implemented by java.nio.charset.Charset -- Key: HARMONY-96 URL: http://issues.apache.org/jira/browse/HARMONY-96 Project: Harmony Type: Improvement Components: Classlib Reporter: Richard Liang Assignee: Tim Ellison Attachments: charset_patch.txt There are two new methods added since Java 5.0 1. public static Charset defaultCharset() 2. public final int compareTo(Charset that) I'd like to implement the two methods and attach my code 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
[jira] Resolved: (HARMONY-96) Two new methods need to be implemented by java.nio.charset.Charset
[ http://issues.apache.org/jira/browse/HARMONY-96?page=all ] Tim Ellison resolved HARMONY-96: Resolution: Fixed Thanks for the patch Richard. Applied in NIO_CHAR module java.nio.charset.Charset at repo revision 380639. Please check that the patch was applied as you expected. Two new methods need to be implemented by java.nio.charset.Charset -- Key: HARMONY-96 URL: http://issues.apache.org/jira/browse/HARMONY-96 Project: Harmony Type: Improvement Components: Classlib Reporter: Richard Liang Assignee: Tim Ellison Attachments: charset_patch.txt There are two new methods added since Java 5.0 1. public static Charset defaultCharset() 2. public final int compareTo(Charset that) I'd like to implement the two methods and attach my code 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
[jira] Assigned: (HARMONY-112) native-src/build.xml should have clean-overlay-oss target
[ http://issues.apache.org/jira/browse/HARMONY-112?page=all ] Tim Ellison reassigned HARMONY-112: --- Assign To: Tim Ellison native-src/build.xml should have clean-overlay-oss target - Key: HARMONY-112 URL: http://issues.apache.org/jira/browse/HARMONY-112 Project: Harmony Type: Improvement Components: Classlib Reporter: Mark Hindess Assignee: Tim Ellison Attachments: improved.native.clean.diff There should really be a clean-overlay-oss target to remove the files generated by the overlay-oss target. -- 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] Resolved: (HARMONY-112) native-src/build.xml should have clean-overlay-oss target
[ http://issues.apache.org/jira/browse/HARMONY-112?page=all ] Tim Ellison resolved HARMONY-112: - Resolution: Fixed Thanks for the patch Mark. I agree that putting the third-party code into a separate sub-dir makes sense. I'll create the svn:ignore property for the 'dist' dirs. Applied to native-src at repo revision 380640. Please check that it was applied as you expected. native-src/build.xml should have clean-overlay-oss target - Key: HARMONY-112 URL: http://issues.apache.org/jira/browse/HARMONY-112 Project: Harmony Type: Improvement Components: Classlib Reporter: Mark Hindess Assignee: Tim Ellison Attachments: improved.native.clean.diff There should really be a clean-overlay-oss target to remove the files generated by the overlay-oss target. -- 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-124) java.nio.charset.CharsetDecoder doesn't throw CoderMalfunctionError exception when decodeLoop threw unexpected exception.
[ http://issues.apache.org/jira/browse/HARMONY-124?page=all ]
Richard Liang updated HARMONY-124:
--
Attachment: Charset_patch.txt
CharsetDecoder_patch.txt
The patches are attached.
java.nio.charset.Charset.java and java.nio.charset.CharsetDecoder.java are
modified.
Could you please take a try to apply patches ?
Charset_patch.txt is for java.nio.charset.Charset.java , and
CharsetDecoder_patch.txt is for java.nio.charset.CharsetDecoder.java.
You could simply click team-apply patch to apply these patches.
Java spec doesn't point out clearly which expections are unexpected. To be
compatible with RI, BufferOverflowException and BufferUnderflowException
are treated as unexpected exception currently.
Thank you!
java.nio.charset.CharsetDecoder doesn't throw CoderMalfunctionError exception
when decodeLoop threw unexpected exception.
-
Key: HARMONY-124
URL: http://issues.apache.org/jira/browse/HARMONY-124
Project: Harmony
Type: Bug
Components: Classlib
Reporter: Richard Liang
Attachments: CharsetDecoder_patch.txt, Charset_patch.txt
public final CoderResult decode(ByteBuffer in, CharBuffer out, boolean
endOfInput)
As spec says, the method throws CoderMalfunctionError if an invocation of the
decodeLoop method threw an unexpected exception.
However, Harmony doesn't throws CoderMalfunctionError when decodeLoop method
threw an unexpected exception.
The following test cases pass on RI , but fail on Harmony.
/*
* Test malfunction decode(ByteBuffer)
*/
public void testDecode_CoderMalfunctionError() throws Exception {
MockMalfunctionCharset cs = new MockMalfunctionCharset(mock,
null);
try{
cs.newDecoder().onMalformedInput(CodingErrorAction.REPLACE)
.onUnmappableCharacter(CodingErrorAction.REPLACE).decode(ByteBuffer.wrap(new
byte[]{0x00,0x11}));
fail(should throw CoderMalfunctionError);//NON-NLS-1$
}catch(CoderMalfunctionError e){
//expected
}
}
/*
* Test malfunction decode(ByteBuffer)
*/
public void testDecode_NoCoderMalfunctionError() throws Exception {
MockMalfunctionCharset cs = new MockMalfunctionCharset(mock,
null);
try{
cs.decode(ByteBuffer.wrap(new byte[]{0x00,0x11}));
}catch(CoderMalfunctionError e){
fail(Charset.decode should return
silently);//NON-NLS-1
}
}
/*
* Mock charset class with malfunction decode encode.
*/
static final class MockMalfunctionCharset extends Charset {
public MockMalfunctionCharset(String canonicalName, String[]
aliases) {
super(canonicalName, aliases);
}
public boolean contains(Charset cs) {
return false;
}
public CharsetDecoder newDecoder() {
return new MockMalfunctionDecoder(this);
}
public CharsetEncoder newEncoder() {
return new MockMalfunctionEncoder(this);
}
}
/*
* Mock decoder. decodeLoop always throws unexpected exception.
*/
static class MockMalfunctionDecoder extends
java.nio.charset.CharsetDecoder {
public MockMalfunctionDecoder(Charset cs) {
super(cs, 1, 10);
}
protected CoderResult decodeLoop(ByteBuffer in, CharBuffer out)
{
throw new BufferOverflowException();
}
}
/*
* Mock encoder. encodeLoop always throws unexpected exception.
*/
static class MockMalfunctionEncoder extends
java.nio.charset.CharsetEncoder {
public MockMalfunctionEncoder(Charset cs) {
super(cs, 1, 3, new byte[] { (byte) '?' });
}
protected CoderResult encodeLoop(CharBuffer in, ByteBuffer out)
{
throw new BufferOverflowException();
}
}
--
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-112) native-src/build.xml should have clean-overlay-oss target
[ http://issues.apache.org/jira/browse/HARMONY-112?page=comments#action_12367643 ] Mark Hindess commented on HARMONY-112: -- Looks good. Since clean wasn't really complete before it's probably best if people make sure they manually wipe and recheck out both the zlib and fdlibm directories to avoid picking up obsolete files. (Aside: when looking at the comment history I see the text I'll create the svn:ignore proper200 OKhe 'dist' dirs.. ;-( ) native-src/build.xml should have clean-overlay-oss target - Key: HARMONY-112 URL: http://issues.apache.org/jira/browse/HARMONY-112 Project: Harmony Type: Improvement Components: Classlib Reporter: Mark Hindess Assignee: Tim Ellison Attachments: improved.native.clean.diff There should really be a clean-overlay-oss target to remove the files generated by the overlay-oss target. -- 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] Created: (HARMONY-125) Removed duplicate header files.
Removed duplicate header files. --- Key: HARMONY-125 URL: http://issues.apache.org/jira/browse/HARMONY-125 Project: Harmony Type: Improvement Components: Classlib Reporter: Mark Hindess Priority: Trivial The header files: win.IA32/archive/jcl.h win.IA32/math/jcl.h linux.IA32/nio/jcl.h are duplicates of the *.IA32/common/jcl.h header files and can be removed without affecting the resulting code. I wont attach a patch since it's too trivial. -- 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-112) native-src/build.xml should have clean-overlay-oss target
[ http://issues.apache.org/jira/browse/HARMONY-112?page=all ] Tim Ellison closed HARMONY-112: --- Verified by Mark. native-src/build.xml should have clean-overlay-oss target - Key: HARMONY-112 URL: http://issues.apache.org/jira/browse/HARMONY-112 Project: Harmony Type: Improvement Components: Classlib Reporter: Mark Hindess Assignee: Tim Ellison Attachments: improved.native.clean.diff There should really be a clean-overlay-oss target to remove the files generated by the overlay-oss target. -- 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-84) java.net.InetAddress() shouldn't perform reverse name lookup
[ http://issues.apache.org/jira/browse/HARMONY-84?page=all ]
Tim Ellison reassigned HARMONY-84:
--
Assign To: Tim Ellison
java.net.InetAddress() shouldn't perform reverse name lookup
Key: HARMONY-84
URL: http://issues.apache.org/jira/browse/HARMONY-84
Project: Harmony
Type: Bug
Components: Classlib
Reporter: Paulex Yang
Assignee: Tim Ellison
Priority: Minor
Currently, the java.net.InetAddress.toString() is as below:
code
public String toString() {
return getHostName() + / + getHostAddress();
}
/code
But actually the toString() should behave differently with getHostName()!
the Java spec for toString():
spec
Converts this IP address to a String. The string returned is of the
form: hostname / literal IP address. If the host name is unresolved, no
reverse name service loopup is performed. The hostname part will be
represented by an empty string.
/spec
and the spec for getHostName() says:
spec
If this InetAddress was created with a host name, this host name will be
remembered and returned; otherwise, a reverse name lookup will be performed
and the result will be returned based on the system configured name lookup
service.
/spec
Spec shows that toString() shouldn't perform reverse name lookup while
getHostName() should!
A simple test show this bug:
code
public class ToStringTest{
public static void main(String[] args) throws Exception{
InetAddress addr = InetAddress.getByName(localhost);
System.out.println(addr);
InetAddress addr2 = InetAddress.getByAddress(new byte[]{127, 0, 0,
1});
System.out.println(addr2);
}
}
/code
on RI, it outputs:
localhost/127.0.0.1
/127.0.0.1
and on Harmony, it outputs:
localhost/127.0.0.1
localhost/127.0.0.1
--
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] Resolved: (HARMONY-84) java.net.InetAddress() shouldn't perform reverse name lookup
[ http://issues.apache.org/jira/browse/HARMONY-84?page=all ]
Tim Ellison resolved HARMONY-84:
Resolution: Fixed
Paulex,
Fixed in LUNI module at repo revision 380663.
Please check that this fully resolves your problem.
java.net.InetAddress() shouldn't perform reverse name lookup
Key: HARMONY-84
URL: http://issues.apache.org/jira/browse/HARMONY-84
Project: Harmony
Type: Bug
Components: Classlib
Reporter: Paulex Yang
Assignee: Tim Ellison
Priority: Minor
Currently, the java.net.InetAddress.toString() is as below:
code
public String toString() {
return getHostName() + / + getHostAddress();
}
/code
But actually the toString() should behave differently with getHostName()!
the Java spec for toString():
spec
Converts this IP address to a String. The string returned is of the
form: hostname / literal IP address. If the host name is unresolved, no
reverse name service loopup is performed. The hostname part will be
represented by an empty string.
/spec
and the spec for getHostName() says:
spec
If this InetAddress was created with a host name, this host name will be
remembered and returned; otherwise, a reverse name lookup will be performed
and the result will be returned based on the system configured name lookup
service.
/spec
Spec shows that toString() shouldn't perform reverse name lookup while
getHostName() should!
A simple test show this bug:
code
public class ToStringTest{
public static void main(String[] args) throws Exception{
InetAddress addr = InetAddress.getByName(localhost);
System.out.println(addr);
InetAddress addr2 = InetAddress.getByAddress(new byte[]{127, 0, 0,
1});
System.out.println(addr2);
}
}
/code
on RI, it outputs:
localhost/127.0.0.1
/127.0.0.1
and on Harmony, it outputs:
localhost/127.0.0.1
localhost/127.0.0.1
--
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] Created: (HARMONY-126) fdlbm and zlib clean is incomplete
fdlbm and zlib clean is incomplete -- Key: HARMONY-126 URL: http://issues.apache.org/jira/browse/HARMONY-126 Project: Harmony Type: Improvement Components: Classlib Reporter: Mark Hindess Priority: Trivial Oops. The clean targets are incomplete after HARMONY-116. Sorry. Will attach a patch. -- 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-126) fdlbm and zlib clean is incomplete
[ http://issues.apache.org/jira/browse/HARMONY-126?page=all ]
Mark Hindess updated HARMONY-126:
-
Attachment: fix.makefiles.to.remove.dist.object.files.diff
This patch fixes my oversight of not cleaning {zlib,fdlibm}/dist/*.{o,obj}.
(md5sum=16cc8589ce738e4891471a1b3d86c1ac)
fdlbm and zlib clean is incomplete
--
Key: HARMONY-126
URL: http://issues.apache.org/jira/browse/HARMONY-126
Project: Harmony
Type: Improvement
Components: Classlib
Reporter: Mark Hindess
Priority: Trivial
Attachments: fix.makefiles.to.remove.dist.object.files.diff
Oops. The clean targets are incomplete after HARMONY-116. Sorry.
Will attach a patch.
--
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-126) fdlbm and zlib clean is incomplete
[ http://issues.apache.org/jira/browse/HARMONY-126?page=all ] Tim Ellison reassigned HARMONY-126: --- Assign To: Tim Ellison fdlbm and zlib clean is incomplete -- Key: HARMONY-126 URL: http://issues.apache.org/jira/browse/HARMONY-126 Project: Harmony Type: Improvement Components: Classlib Reporter: Mark Hindess Assignee: Tim Ellison Priority: Trivial Attachments: fix.makefiles.to.remove.dist.object.files.diff Oops. The clean targets are incomplete after HARMONY-116. Sorry. Will attach a patch. -- 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] Resolved: (HARMONY-126) fdlbm and zlib clean is incomplete
[ http://issues.apache.org/jira/browse/HARMONY-126?page=all ] Tim Ellison resolved HARMONY-126: - Resolution: Fixed Yep, we both missed that target. Patch applied to native-src at repo revision 380668. Please check that it was applied as you expected. fdlbm and zlib clean is incomplete -- Key: HARMONY-126 URL: http://issues.apache.org/jira/browse/HARMONY-126 Project: Harmony Type: Improvement Components: Classlib Reporter: Mark Hindess Assignee: Tim Ellison Priority: Trivial Attachments: fix.makefiles.to.remove.dist.object.files.diff Oops. The clean targets are incomplete after HARMONY-116. Sorry. Will attach a patch. -- 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-126) fdlbm and zlib clean is incomplete
[ http://issues.apache.org/jira/browse/HARMONY-126?page=comments#action_12367656 ] Mark Hindess commented on HARMONY-126: -- Looks good. At least one of us spotted it before anyone else noticed. ;-) fdlbm and zlib clean is incomplete -- Key: HARMONY-126 URL: http://issues.apache.org/jira/browse/HARMONY-126 Project: Harmony Type: Improvement Components: Classlib Reporter: Mark Hindess Assignee: Tim Ellison Priority: Trivial Attachments: fix.makefiles.to.remove.dist.object.files.diff Oops. The clean targets are incomplete after HARMONY-116. Sorry. Will attach a patch. -- 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-126) fdlbm and zlib clean is incomplete
[ http://issues.apache.org/jira/browse/HARMONY-126?page=all ] Tim Ellison closed HARMONY-126: --- Verified by Mark fdlbm and zlib clean is incomplete -- Key: HARMONY-126 URL: http://issues.apache.org/jira/browse/HARMONY-126 Project: Harmony Type: Improvement Components: Classlib Reporter: Mark Hindess Assignee: Tim Ellison Priority: Trivial Attachments: fix.makefiles.to.remove.dist.object.files.diff Oops. The clean targets are incomplete after HARMONY-116. Sorry. Will attach a patch. -- 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] Created: (HARMONY-128) windows makefile housekeeping
windows makefile housekeeping - Key: HARMONY-128 URL: http://issues.apache.org/jira/browse/HARMONY-128 Project: Harmony Type: Improvement Components: Classlib Reporter: Mark Hindess Priority: Trivial I've cleaned up the windows makefiles to make the changes to the linux ones. I'll attach a patch shortly. -- 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-129) README should not mention the old native-src/*/build.log file
[ http://issues.apache.org/jira/browse/HARMONY-129?page=all ] Mark Hindess updated HARMONY-129: - Attachment: fix.readme.to.reflect.build.log.removal.diff I suppose I could have removed the example completely but it seemed wrong to remove potentially useful information. (md5sum=40635c3da68bf19b50cf57295c85b0b9) README should not mention the old native-src/*/build.log file - Key: HARMONY-129 URL: http://issues.apache.org/jira/browse/HARMONY-129 Project: Harmony Type: Improvement Components: Classlib Reporter: Mark Hindess Priority: Trivial Attachments: fix.readme.to.reflect.build.log.removal.diff I'll attach a patch to fix the README. -- 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
Security module layout
Hi, Earlier on today I spent some time following the instructions for developing Harmony Java code inside Eclipse [1]. After experimenting with archive, luni and nio I decided to check out modules/security and found that, in its current form, it can't be brought into an Eclipse workspace and used like the other modules. One obvious difference is that it doesn't have any Eclipse project metadata in there (e.g. .project and .classpath files). After adding these in (in my private workspace), I began to look at other differences between security and its peer modules in particular the difference in source layouts. Recalling some ideas for layouts that have been kicked around this list, I started to move things around a little to try and make things a little more uniform with respect to those peer modules. Things were made more interesting by virtue of the following security module distinctions : * it has platform-specific Java code * it contains native code for both Windows and Linux Eventually I arrived at a structure that is more attuned to the other modules in the repository. As a bonus, Eclipse pointed out several missing import entries from the META-INF/MANIFEST.MF file - including one that cannot presently be satisfied with what is in the Harmony repository (org.apache.harmony.security.test.SecurityTest wants to import java.util.logging.LoggingPermission which doesn't exist in the repository - although an implementation has been contributed [2]). In addition to moving source around, I also made the necessary tweaks to the Ant scripts contained in the security module plus the top level Java build file trunk/make/build-java.xml so the Ant builds still work as before. Keeping my fingers crossed that the next bit of this note renders alright in your mail client, here is the modules/security structure that I ended up with (minus all of the package sub-folders for clarity) : SECURITY ROOT | | +---src | | | +---main | | | | | +---java | | | | | | | +---common | | | | | | | +---linux.IA32 | | | | | | | \---win.IA32 | | | | | +---native | | | | | | | +---linux.IA32 | | | | | | | \---win.IA32 | | | | | \---resources | | | | | \---common | | | +---test | | | +---java | | | +---common | | | +---linux.IA32 | | | \---win.IA32 | +---doc | | | \---images | +---make | | | \---native | | | +---linux | | | \---windows | +---META-INF All of the leaf folders under src have been declared to Eclipse as source folders (i.e. I have 9 source folders called src/main/java/common, src/main/resources/common, src/main/native/linux.IA32, src/test/java/common and so on...). I would be really keen to hear what people think of this prototype re-structuring. It would be great if we could make the security module as simple to work with inside Eclipse as the other modules are. Best regards, George IBM UK [1] http://incubator.apache.org/harmony/subcomponents/classlibrary/dev_eclipse.html [2] http://issues.apache.org/jira/browse/HARMONY-88
[jira] Assigned: (HARMONY-78) SecurityKeySpec.getEncoded returns incorrect value
[ http://issues.apache.org/jira/browse/HARMONY-78?page=all ] Tim Ellison reassigned HARMONY-78: -- Assign To: Tim Ellison SecurityKeySpec.getEncoded returns incorrect value -- Key: HARMONY-78 URL: http://issues.apache.org/jira/browse/HARMONY-78 Project: Harmony Type: Bug Components: Classlib Reporter: Mikhail Loenko Assignee: Tim Ellison Priority: Minor Attachments: test.java Constructor SecretKeySpec(byte[] key, int offset, int len, String alg) should create an instance of the class with key material of size 'len'. In fact it creates key material of size 'key.length' the patch: Index: modules/security2/src/common/javasrc/javax/crypto/spec/SecretKeySpec.java === --- modules/security2/src/common/javasrc/javax/crypto/spec/SecretKeySpec.java (revision 374613) +++ modules/security2/src/common/javasrc/javax/crypto/spec/SecretKeySpec.java (working copy) @@ -60,7 +60,7 @@ throw BADPARAMS_EXC; } this.algorithm = algorithm; -this.key = new byte[key.length]; +this.key = new byte[len]; System.arraycopy(key, offset, this.key, 0, len); } -- 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] Resolved: (HARMONY-78) SecurityKeySpec.getEncoded returns incorrect value
[ http://issues.apache.org/jira/browse/HARMONY-78?page=all ] Tim Ellison resolved HARMONY-78: Resolution: Fixed Mikhail, Fixed in SECURITY module in repository revision 380832. Please check that this fully resolves your problem. SecurityKeySpec.getEncoded returns incorrect value -- Key: HARMONY-78 URL: http://issues.apache.org/jira/browse/HARMONY-78 Project: Harmony Type: Bug Components: Classlib Reporter: Mikhail Loenko Assignee: Tim Ellison Priority: Minor Attachments: test.java Constructor SecretKeySpec(byte[] key, int offset, int len, String alg) should create an instance of the class with key material of size 'len'. In fact it creates key material of size 'key.length' the patch: Index: modules/security2/src/common/javasrc/javax/crypto/spec/SecretKeySpec.java === --- modules/security2/src/common/javasrc/javax/crypto/spec/SecretKeySpec.java (revision 374613) +++ modules/security2/src/common/javasrc/javax/crypto/spec/SecretKeySpec.java (working copy) @@ -60,7 +60,7 @@ throw BADPARAMS_EXC; } this.algorithm = algorithm; -this.key = new byte[key.length]; +this.key = new byte[len]; System.arraycopy(key, offset, this.key, 0, len); } -- 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-40) FileChannel assotiated with FileOutputStream not closed after closing output stream
[ http://issues.apache.org/jira/browse/HARMONY-40?page=all ] Tim Ellison reassigned HARMONY-40: -- Assign To: Tim Ellison FileChannel assotiated with FileOutputStream not closed after closing output stream --- Key: HARMONY-40 URL: http://issues.apache.org/jira/browse/HARMONY-40 Project: Harmony Type: Bug Components: Classlib Reporter: Vladimir Strigun Assignee: Tim Ellison When I receive FileChannel from file output stream, write something to stream and then close it, channel, assotiated with the stream is still open. I'll attach unit test for the issue. -- 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] Resolved: (HARMONY-40) FileChannel assotiated with FileOutputStream not closed after closing output stream
[ http://issues.apache.org/jira/browse/HARMONY-40?page=all ] Tim Ellison resolved HARMONY-40: Resolution: Cannot Reproduce Vladimir, As you say, the bug cannot be reproduced, it has been fixed by HARMONY-42. I've added the regression test to NIO module at repo revision 380839. Please confirm that the problem is fixed for you. FileChannel assotiated with FileOutputStream not closed after closing output stream --- Key: HARMONY-40 URL: http://issues.apache.org/jira/browse/HARMONY-40 Project: Harmony Type: Bug Components: Classlib Reporter: Vladimir Strigun Assignee: Tim Ellison When I receive FileChannel from file output stream, write something to stream and then close it, channel, assotiated with the stream is still open. I'll attach unit test for the issue. -- 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-120) -lhycommon is listed twice in linux luni link command
[ http://issues.apache.org/jira/browse/HARMONY-120?page=all ] Tim Ellison reassigned HARMONY-120: --- Assign To: Tim Ellison -lhycommon is listed twice in linux luni link command - Key: HARMONY-120 URL: http://issues.apache.org/jira/browse/HARMONY-120 Project: Harmony Type: Improvement Components: Classlib Reporter: Mark Hindess Assignee: Tim Ellison Priority: Trivial If we were happy assuming GNU make we could avoid inconsistency errors like this by deriving the -l options from the library dependency list with something like: MDLLIBFILES = \ ../lib/libhycommon.a ../libhysig.so ../lib/libhyzip.a ../libhyzlib.so \ ../lib/libhypool.a ../lib/libhyfdlibm.a ../libhythr.so ../libvmi.so LIBS = $(subst ../lib,-l,$(subst ../lib/lib,-l,$(basename $(MDLLIBFILES Patch to remove the duplication is trivial so I wont bother to attach it - just delete the second -lhycommon line. -- 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] Resolved: (HARMONY-120) -lhycommon is listed twice in linux luni link command
[ http://issues.apache.org/jira/browse/HARMONY-120?page=all ] Tim Ellison resolved HARMONY-120: - Resolution: Fixed Mark, Fixed in linux.IA32/luni/makefile at repo revision 380846. How many times can you say 'linux luni link command'? -lhycommon is listed twice in linux luni link command - Key: HARMONY-120 URL: http://issues.apache.org/jira/browse/HARMONY-120 Project: Harmony Type: Improvement Components: Classlib Reporter: Mark Hindess Assignee: Tim Ellison Priority: Trivial If we were happy assuming GNU make we could avoid inconsistency errors like this by deriving the -l options from the library dependency list with something like: MDLLIBFILES = \ ../lib/libhycommon.a ../libhysig.so ../lib/libhyzip.a ../libhyzlib.so \ ../lib/libhypool.a ../lib/libhyfdlibm.a ../libhythr.so ../libvmi.so LIBS = $(subst ../lib,-l,$(subst ../lib/lib,-l,$(basename $(MDLLIBFILES Patch to remove the duplication is trivial so I wont bother to attach it - just delete the second -lhycommon line. -- 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: Harmony and the future of Java
Stefano Mazzocchi wrote: Santiago Gala wrote: El jue, 23-02-2006 a las 20:44 -0500, Stefano Mazzocchi escribió: (...) A good friend of mine used to have cat juggler as his title and I was thinking about using software plumber as mine at one point. Fair enough, I used to have problem solver or I solve your problems for a fee as mine. I tend to prefer somebody who admits to be a religiously attached to something than those who pretend to be objective about it and deep inside they are not. Not sure this is the case, but that's how I read it. OK, I just got surprised. I'm giving a talk on Software and Artistic Expression in two weeks, so I kind of understand code as speech. From there to code as scripture there is just some sliding slope. I can grok evangelist as a metaphor, but being a Theologian would in my view mean that src.zip is some sort of holy scripture, thing that I'm far from believing. Oh, and heresy outside of the JCP church. :-P What is more, such a title helps building on the tradition of java as a mono(theistic)culture, together with the .NET. one Just yesterday I got squeak/smalltalk communities criticized (and I agree) for being too closed in themselves, and it rang bells about java being sort of the same. Having been part of both communities, I can't but sympathise with Ben Hyde's Small Gods post: http://enthusiasm.cozy.org/archives/2003/06/small-gods Getting closer to topic, I wonder if someone can post here a subjective summary of the ideas on support for dynamic languages in future java. I'm concerned about the stagnation of jython (barely commits since 2.2a1) and I would also like to know how far is support for dynamic languages going to be. In particular, things like smalltalk's primitive anObject become: anotherObject, which will turn all references to an object to references to a different one seem difficult to mix with the static typing nature of java, and I would like to know more about the approach they are going to take for such kind of problems. I agree with you (and Ben) about the fact that monoculture brings stagnation, but I don't think this is a good place for talking about java innovations. hat type=project mentor This project is about implement a JVM as specified by the JCP, of which the ASF is part of. Changing and influencing that JVM spec is out of scope it if brings incompatibilities that will preclude passing the certification stage. /hat This said, it is not impossible for Harmony to be instrumental in showing that additions to the JVM might be beneficial for the outside world and therefore submit them for review to the JCP. There is *nothing* that prevents us from implementing harmony-specific features, if this doesn't stop us from passing the TCK. Yes, well put. Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.
[jira] Created: (HARMONY-130) linux.ia32 auth natives are build as a background task
linux.ia32 auth natives are build as a background task -- Key: HARMONY-130 URL: http://issues.apache.org/jira/browse/HARMONY-130 Project: Harmony Type: Improvement Components: Classlib Reporter: Mark Hindess Priority: Trivial I was going to suggest simply changing the single '' to a double '' in the line : ( cd auth $(MAKE) cd .. ) but since the brackets start a subshell then the cd .. is redundant so I'll submit a patch to remove them and fix the bug. -- 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-130) linux.ia32 auth natives are build as a background task
[ http://issues.apache.org/jira/browse/HARMONY-130?page=all ] Mark Hindess updated HARMONY-130: - Attachment: do.not.background.auth.make.diff Fix background job and clean up redundant cd .. commands. (md5sum=e7e0bda74870b56caa283ea1295fe2ff) linux.ia32 auth natives are build as a background task -- Key: HARMONY-130 URL: http://issues.apache.org/jira/browse/HARMONY-130 Project: Harmony Type: Improvement Components: Classlib Reporter: Mark Hindess Priority: Trivial Attachments: do.not.background.auth.make.diff I was going to suggest simply changing the single '' to a double '' in the line : ( cd auth $(MAKE) cd .. ) but since the brackets start a subshell then the cd .. is redundant so I'll submit a patch to remove them and fix the bug. -- 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: Harmony and the future of Java
Stefano Mazzocchi wrote:
I agree with you (and Ben) about the fact that monoculture brings
stagnation, but I don't think this is a good place for talking about
java innovations.
hat type=project mentor
This project is about implement a JVM as specified by the JCP, of
which the ASF is part of.
Changing and influencing that JVM spec is out of scope it if brings
incompatibilities that will preclude passing the certification stage.
/hat
This said, it is not impossible for Harmony to be instrumental in
showing that additions to the JVM might be beneficial for the outside
world and therefore submit them for review to the JCP.
There is *nothing* that prevents us from implementing harmony-specific
features, if this doesn't stop us from passing the TCK.
This is my cue;
I joined the list a few days ago and I got here as a result of reading the
Java: Dead Like COBOL, Not Like Elvis? thread on TheServerside
http://www.theserverside.com/news/thread.tss?thread_id=39066.
In a couple of posts by Dalibor Topic (a developer on GNU Classpath
and Kaffe OpenVM) he asserted that Java developers will move on to
.NET and he used this phrase just like how applets were replaced by
Flash. He also said
For example, you can write neat GUI applications for Windows today
using Java5 and/or SWT. Once Vista ships with bundled Whidbey, though,
GUI application developers on Windows will be facing an interesting
choice: n MB for a C# application on Whidbey, or n MB + sizeof(Sun JRE
1.6) for a Java application. As we've seen with applets vs flash,
there is a very simple answer: the ubiquitous one wins. See Netscape
vs IE, which was decided the moment Microsoft bundled the browser with
the OS.
I started to wonder if I should switch to c# .NET. I would rather
stick with Java but the 16MB JRE download is a killer. Unless Java
Applets are as easy for the user as other technologies then they will
be second choice for developers. I believe there is a solution but it
means changing the way classes are loaded, but it may take the JVM
out of spec, I don't know.
The problem is that before you start to run your applet you have to
download and install everything that makes up the JRE including
classes, programs and dlls that your applet will never use. A better
solution would be to download and install the core JVM and the classes
your applet uses only. Everything else should be downloaded on
demand e.g.
package javax.sql.rowset;
public abstract class BaseRowSet implements Serializable, Cloneable {
public static String classSourceURL =
http://www.mydistribution-server.com/cgi-bin/classServer.cgi;;
// nothing else defined in this stub class.
}
The class loader finds a class with only the classSourceURL field and
uses the URL in the field to download the real class passing the fully
qualified class name as an argument. The class server can return a
zip file with the named class and all the classes it depends on.
If most/all of the classes were like this then the class library zip
file would be very small. The same goes for the other programs and
dlls, if they are not part of the JVM core and needed by every
applet/application that runs then make them stubs that download the
real thing when they are used the first time.
So I found my way to Harmony in the hope that I can help and this is
the area I would like to get involved in.
BTW My 2 cents on the local (HTTP/FTP/SMTP) server issue is to
implement the servers as Java classes, the protocols are simple and a
lot of that code exists in apacheland anyway.
regards
damian
