[jira] Created: (HARMONY-100) text/BidiWrapper issue?

[Vladimir Gorr (JIRA)]

text/BidiWrapper issue?
---

 Key: HARMONY-100
 URL: http://issues.apache.org/jira/browse/HARMONY-100
 Project: Harmony
Type: Bug
Reporter: Vladimir Gorr


Let's consider the following test:

import java.text.Bidi;
public class Test {
public static void main(String[] args) throws Exception {
Bidi bd = new Bidi(new char[] { 's', 's', 's' }, 0, 
new byte[] { (byte) -7, (byte) -2, (byte) -3 }, 
0, 3, Bidi.DIRECTION_DEFAULT_LEFT_TO_RIGHT);
System.out.println(Expected 7, real  +   + 
bd.getLevelAt(0));
}
}

In my opinion the JNI implementation of Bidi (text/BidiWrapper.c file, 
ubidi_1setPara() function) contains a potential bug, namely:
1. If  the embeddingLevels  argument is not NULL then _embeddingLevels variable 
is initialized with the JNI GetByteArrayElements() function;
2. ICU function (ubidi_setPara) initializes ICU inner structure and puts the 
_embeddingLevels into it;
3. If _embeddingLevels pointer is not NULL then the JNI 
ReleaseByteArrayElements() function (with 0 as fourth parameter) is called.
This function releases the memory (according to JNI specification) the 
_embeddingLevels pointer refers to;
4. After that ICU inner structure isn't initialized properly. Call of ICU 
ubidi_getLevels() function can return incorrect values (see java test above).

It seems the JNI_COMMIT parameter instead of 0 should be passed to the 
ReleaseByteArrayElements() to avoid this problem.

I'd like to underline the test mentioned above works w/o any issues for 
Harmony-14 contribution (although it shouldn't sometimes IMHO).
Therefore if there are any doubts in my argumentation this issue can be closed 
as invalid. 


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[classlib] security moved

[Geir Magnusson Jr]

I moved modules/security to archive/modules/security and moved 
modules/security2 to modules/security.  I adjusted build scripts as needed.


I wasn't able to go further or put a snapshot up because of really awful 
network conditions in the hotel I'm in. (There seems to be something 
systemically bad about Embassy Suites - this is the second time I've had 
network problems in the last two times I stayed in one...)


Tim, do the change of the package names if you wish.  I'll do the 
snapshot based on a svn rev later today (unless someone else wants 
to...)  I suspect that it won't be a major deal if you get the new J9 VM 
up at the same time as the svn change is made...


Of to sleep for a few...

geir

[jira] Closed: (HARMONY-79) java.util.jar.Attributes.put(Object name, Object value) doesn't throw ClassCastException

[Tim Ellison (JIRA)]

 [ http://issues.apache.org/jira/browse/HARMONY-79?page=all ]
 
Tim Ellison closed HARMONY-79:
--


Verified by Svetlana


 java.util.jar.Attributes.put(Object name, Object value) doesn't throw 
 ClassCastException
 

  Key: HARMONY-79
  URL: http://issues.apache.org/jira/browse/HARMONY-79
  Project: Harmony
 Type: Bug
   Components: Classlib
 Reporter: Svetlana Samoilenko
 Assignee: Tim Ellison
  Attachments: AttributesTest.java, Attributes_patch.txt

 According to the j2se 1.4 and 1.5 specification method 
 java.util.jar.Attributes.put throws ClassCastException - if the name is not a 
 Attributes.Name or the value is not a String.
 Harmony doesn't throw ClassCastException 
 1)   if the name is not a Attributes.Name
 2)   if the value is not a String
 Code to reproduce: 
 import java.util.jar.Attributes; 
 public class test2 {  
 public static void main(String[] args) { 
 Attributes att=new Attributes(); 
 try {
 att.put(new Object(), new String() );
 } catch ( ClassCastException e) {
 System.out.println(ClassCastException if the name is not a 
 Attributes.Name ); 
 };
 try {
 att.put(new Attributes.Name(IMPLEMENTATION_VENDOR), new 
 Object()); 
 } catch ( ClassCastException e) {
 System.out.println(ClassCastException if the value is not a 
 String);
 return;
};
System.out.println(Wrong. Must be ClassCastException);
 } 
 }
 Steps to Reproduce: 
 1. Build Harmony (check-out on 2006-01-30) j2se subset as described in 
 README.txt. 
 2. Compile test2.java using BEA 1.4 javac 
  javac -d . test2.java 
 3. Run java using compatible VM (J9) 
  java -showversion test2
 Output: 
 C:\tmpC:\jrockit-j2sdk1.4.2_04\bin\java.exe -showversion test2 
 java version 1.4.2_04 
 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_04-b05) 
 BEA WebLogic JRockit(TM) 1.4.2_04 JVM (build 
 ari-31788-20040616-1132-win-ia32, Native Threads, GC strategy: parallel) 
 ClassCastException if the name is not a Attributes.Name
 ClassCastException if the value is not a String
 C:\tmpC:\harmony\trunk\deploy\jre\bin\java -showversion test2 
 (c) Copyright 1991, 2005 The Apache Software Foundation or its licensors, as 
 applicable. 
 Wrong. Must be ClassCastException
  Siggested fix: 
to change the line 232 in 
 archive/src/main/java/java/util/jar/Attributes.java as follows: 
 232  return map.put((Name) key, (String) value);
 Suggested junit test case:
  AttributesTest.java 
 - 
 import java.util.jar.*;
 import junit.framework.*; 
 public class AttributesTest extends TestCase { 
 public static void main(String[] args) { 
 junit.textui.TestRunner.run(AttributesTest.class); 
 } 
 public void test_put () { 
 Attributes att=new Attributes(); 
 // ClassCastException if the name is not a Attributes.Name
 try {
 att.put(new Object(), new String() );
 } catch ( ClassCastException e) {
 // expected
 };
 //ClassCastException if the value is not a String
 try {
 att.put(new Attributes.Name(IMPLEMENTATION_VENDOR), new 
 Object()); 
 } catch ( ClassCastException e) {
 // expected
 };
} 
 }

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Commented: (HARMONY-67) java.nio.charset.Charset.decode(ByteBuffer) throws unexpected BufferOverflowException for UTF-16BE, UTF-16LE, UTF-16 charsets.

[Tim Ellison (JIRA)]

[ 
http://issues.apache.org/jira/browse/HARMONY-67?page=comments#action_12366769 ] 

Tim Ellison commented on HARMONY-67:


Svetlana, can you explain why you think the decode behavior is wrong?

The test, as written in our SVN repository, passes on Harmony code and the Sun 
implementation of Java.
As Vladimir wrote, this may be a compatibility issue with the BEA 
implementation, and I agree that our behavior is to spec.


 java.nio.charset.Charset.decode(ByteBuffer) throws unexpected 
 BufferOverflowException  for UTF-16BE, UTF-16LE, UTF-16 charsets.
 ---

  Key: HARMONY-67
  URL: http://issues.apache.org/jira/browse/HARMONY-67
  Project: Harmony
 Type: Bug
   Components: Classlib
 Reporter: Svetlana Samoilenko
 Assignee: Tim Ellison


 According to j2se 1.4.2 specification for Charset.decode(ByteBuffer  b) the 
 method must not throw any exceptions.
 The test listed below shows that there is unexpected BufferOverflowException 
 thrown if charset name is one in the following:  UTF-16BE, UTF-16LE, UTF-16.
 BEA does not throw any exceptions.
 Code to reproduce: 
 import java.nio.charset.Charset; 
 import java.nio.ByteBuffer; 
 import java.nio.CharBuffer; 
 public class test2 {   
 public static void main(String[] args) throws Exception { 
 byte[] b = new byte[] {(byte)1}; 
 ByteBuffer buf= ByteBuffer.wrap(b); 
 CharBuffer charbuf=Charset.forName(UTF-16).decode(buf); 
 System.out.println(CharBuffer.length()=+ charbuf.length());
 } 
 }
 Steps to Reproduce: 
 1. Build Harmony (check-out on 2006-01-30) j2se subset as described in 
 README.txt. 
 2. Compile test2.java using BEA 1.4 javac 
  javac -d . test2.java 
 3. Run java using compatible VM (J9) 
  java -showversion test2 
 Output: 
 C:\tmpC:\jrockit-j2sdk1.4.2_04\bin\java.exe -showversion test2 
 java version 1.4.2_04 
 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_04-b05) 
 BEA WebLogic JRockit(TM) 1.4.2_04 JVM (build 
 ari-31788-20040616-1132-win-ia32, Native Threads, GC strategy: parallel) 
 CharBuffer.length()=0
 C:\tmpC:\harmony\trunk\deploy\jre\bin\java -showversion test2 
 (c) Copyright 1991, 2005 The Apache Software Foundation or its licensors, as 
 applicable. 
  java.nio.BufferOverflowException
 at java.nio.CharBuffer.put(CharBuffer.java:662) 
 at java.nio.CharBuffer.put(CharBuffer.java:629) 
 at java.nio.charset.CharsetDecoder.decode(CharsetDecoder.java:406) 
 at java.nio.charset.CharsetDecoder.decode(CharsetDecoder.java:243) 
 at java.nio.charset.Charset.decode(Charset.java:630) 
 at test2.main(test2.java:8)
 Suggested junit test case:
  CharsetTest.java 
 - 
 import java.nio.charset.Charset; 
 import java.nio.ByteBuffer; 
 import java.nio.CharBuffer; 
 import junit.framework.*; 
 public class CharsetTest extends TestCase { 
 public static void main(String[] args) { 
 junit.textui.TestRunner.run(CharsetTest.class); 
 } 
 public void test_decode() { 
 byte[] b = new byte[] {(byte)1}; 
 ByteBuffer buf= ByteBuffer.wrap(b); 
 CharBuffer charbuf=Charset.forName(UTF-16).decode(buf); 
 assertEquals(Assert 0: charset UTF-16,0,charbuf.length());
 
 charbuf=Charset.forName(UTF-16BE).decode(buf); 
 assertEquals(Assert 1: charset UTF-16BE,0, charbuf.length());   
  
 
 charbuf=Charset.forName(UTF-16LE).decode(buf); 
 assertEquals(Assert 2: charset UTF16LE,0, charbuf.length());
 
} 
 }

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

Re: I welcome J2SE 6's faster-splash.... re: Java speed-up

[Tim Ellison]

Geir Magnusson Jr wrote:
 This can't be a Java issue - it must be the
 design-by-committee-for-all-platforms-ever-to-be problem...
 
 I would love to see a good sound API in the style of SWT.
 
 Call it JavaAudio...

... and implement it on Harmony code, we'd be very receptive to patches
and enhancements to ensure the Harmony code works well for you.

Regards,
Tim

 Tor-Einar Jarnbjo wrote:
 Fernando Cassia wrote:

 I'm still scratching my bald head thinking why hasn't Google embraced
 desktop
 java yet. Google Talk would be a killer app written in Swing / 100% Pure
 Java.
  

 It's never stupid to stay realistic. There is no JavaSound
 implementation giving you enough control of e.g. the sound card
 latency to allow a usable telephone application to be implemented.

 H*ck, there's even a pure-java mpeg4 implementation
  

 Which doesn't work for me. A few still frames are being shown and
 updated every few seconds and then the player hangs. Apart from that,
 due to other problems with JavaSound is it not possible to implement
 reasonable quality video players in Java. The JavaSound API has
 functions to read the current position of the audio playback, to sync
 the video accordingly, but the accuracy and correctness of this
 function makes it unusable.

 Tor


 

-- 

Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.

Re: Mission impossible: new APIs without spec in Java 5.0

[Richard Liang]

Hello Anton,

Thanks a lot. Yes, we can use test to investigate the behavior of RI. :-)

Richard Liang
China Software Development Lab, IBM



Anton Avtamonov wrote:

On 2/16/06, Tim Ellison [EMAIL PROTECTED] wrote:
  

Hmm, they look to me like they could be impl methods that were
inadvertently exposed.  They don't seem to fit in to the BreakIterator bag.

If I were you I'd implement them to throw a NotYetImplementedException.

Regards,
Tim




I agree that those methods are a bit strange... Does the proposed
exception well fit to the compatibility strategy? As I know once the
method was exposed it will never be removed from spec and therefore
everyone can use it...

I did 5 min research and found that their implementation should be
very simple (sorry I provide the test not in JUnit format):

Method getInt = BreakIterator.class.getDeclaredMethod(getInt, new
Class[] {new byte[0].getClass(), Integer.TYPE});
getInt.setAccessible(true);

Object result = getInt.invoke(null, new Object[] {new byte[] {0, 0, 0,
1, 1, 0}, new Integer(0)});
System.err.println(expected 1 =  + (new Integer(1).equals(result)));

result = getInt.invoke(null, new Object[] {new byte[] {0, 0, 0, 1, 1,
0}, new Integer(1)});
System.err.println(expected 257 =  + (new Integer(257).equals(result)));

result = getInt.invoke(null, new Object[] {new byte[] {0, 0, 0, 1, 10,
0}, new Integer(1)});
System.err.println(expected 266 =  + (new Integer(266).equals(result)));

IMHO, it is not very difficult to implement.

--
Anton Avtamonov,
Intel Middleware Products Division

  

[jira] Commented: (HARMONY-67) java.nio.charset.Charset.decode(ByteBuffer) throws unexpected BufferOverflowException for UTF-16BE, UTF-16LE, UTF-16 charsets.

[Svetlana Samoilenko (JIRA)]

[ 
http://issues.apache.org/jira/browse/HARMONY-67?page=comments#action_12366771 ] 

Svetlana Samoilenko commented on HARMONY-67:


Tim, 
I agree with Vladimir,
this condition 
cs.newDecoder().onMalformedInput(CodingErrorAction.REPLACE).onUnmappableCharacter(CodingErrorAction.REPLACE).decode(bb)
 is correct, it is compatibility issue.

 java.nio.charset.Charset.decode(ByteBuffer) throws unexpected 
 BufferOverflowException  for UTF-16BE, UTF-16LE, UTF-16 charsets.
 ---

  Key: HARMONY-67
  URL: http://issues.apache.org/jira/browse/HARMONY-67
  Project: Harmony
 Type: Bug
   Components: Classlib
 Reporter: Svetlana Samoilenko
 Assignee: Tim Ellison


 According to j2se 1.4.2 specification for Charset.decode(ByteBuffer  b) the 
 method must not throw any exceptions.
 The test listed below shows that there is unexpected BufferOverflowException 
 thrown if charset name is one in the following:  UTF-16BE, UTF-16LE, UTF-16.
 BEA does not throw any exceptions.
 Code to reproduce: 
 import java.nio.charset.Charset; 
 import java.nio.ByteBuffer; 
 import java.nio.CharBuffer; 
 public class test2 {   
 public static void main(String[] args) throws Exception { 
 byte[] b = new byte[] {(byte)1}; 
 ByteBuffer buf= ByteBuffer.wrap(b); 
 CharBuffer charbuf=Charset.forName(UTF-16).decode(buf); 
 System.out.println(CharBuffer.length()=+ charbuf.length());
 } 
 }
 Steps to Reproduce: 
 1. Build Harmony (check-out on 2006-01-30) j2se subset as described in 
 README.txt. 
 2. Compile test2.java using BEA 1.4 javac 
  javac -d . test2.java 
 3. Run java using compatible VM (J9) 
  java -showversion test2 
 Output: 
 C:\tmpC:\jrockit-j2sdk1.4.2_04\bin\java.exe -showversion test2 
 java version 1.4.2_04 
 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_04-b05) 
 BEA WebLogic JRockit(TM) 1.4.2_04 JVM (build 
 ari-31788-20040616-1132-win-ia32, Native Threads, GC strategy: parallel) 
 CharBuffer.length()=0
 C:\tmpC:\harmony\trunk\deploy\jre\bin\java -showversion test2 
 (c) Copyright 1991, 2005 The Apache Software Foundation or its licensors, as 
 applicable. 
  java.nio.BufferOverflowException
 at java.nio.CharBuffer.put(CharBuffer.java:662) 
 at java.nio.CharBuffer.put(CharBuffer.java:629) 
 at java.nio.charset.CharsetDecoder.decode(CharsetDecoder.java:406) 
 at java.nio.charset.CharsetDecoder.decode(CharsetDecoder.java:243) 
 at java.nio.charset.Charset.decode(Charset.java:630) 
 at test2.main(test2.java:8)
 Suggested junit test case:
  CharsetTest.java 
 - 
 import java.nio.charset.Charset; 
 import java.nio.ByteBuffer; 
 import java.nio.CharBuffer; 
 import junit.framework.*; 
 public class CharsetTest extends TestCase { 
 public static void main(String[] args) { 
 junit.textui.TestRunner.run(CharsetTest.class); 
 } 
 public void test_decode() { 
 byte[] b = new byte[] {(byte)1}; 
 ByteBuffer buf= ByteBuffer.wrap(b); 
 CharBuffer charbuf=Charset.forName(UTF-16).decode(buf); 
 assertEquals(Assert 0: charset UTF-16,0,charbuf.length());
 
 charbuf=Charset.forName(UTF-16BE).decode(buf); 
 assertEquals(Assert 1: charset UTF-16BE,0, charbuf.length());   
  
 
 charbuf=Charset.forName(UTF-16LE).decode(buf); 
 assertEquals(Assert 2: charset UTF16LE,0, charbuf.length());
 
} 
 }

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

Re: [jira] Created: (HARMONY-95) Extract auth component from 'security2' module

[Tim Ellison]

Geir, do you want to do this or shall I?


Stepan: could you update the classlib componentization page to reflect
the new proposed modules?
http://wiki.apache.org/harmony/componentization

Thanks
Tim

Stepan Mishura (JIRA) wrote:
 Extract auth component from 'security2' module
 --
 
  Key: HARMONY-95
  URL: http://issues.apache.org/jira/browse/HARMONY-95
  Project: Harmony
 Type: Task
   Components: Classlib  
 Reporter: Stepan Mishura
 
 
 'security2' module includes API that provides authorization, authentication 
 and secure communication. As was agreed on harmony-dev list this API will be 
 formed as a separate module - auth. (for initial proposal see 
 http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200601.mbox/[EMAIL
  PROTECTED])
 
 The new module includes the following packages:
 javax.security.auth 
 javax.security.auth.callback 
 javax.security.auth.kerberos 
 javax.security.auth.login 
 javax.security.auth.spi 
 javax.security.auth.x500 
 javax.security.sasl 
 org.ietf.jgss
 
 

-- 

Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.

[classlib] policy file

[Tim Ellison]

why has our permissions policy file (in jre/lib/security) gone from
java.policy - drl.policy, lost its license etc. ?

Regards,
Tim

-- 

Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.

Re: [classlib] policy file

[Mikhail Loenko]

java.security also does not have a license...

Why do you think they have to have a license?

Thanks,
Mikhail

On 2/17/06, Tim Ellison [EMAIL PROTECTED] wrote:
 why has our permissions policy file (in jre/lib/security) gone from
 java.policy - drl.policy, lost its license etc. ?

 Regards,
 Tim

 --

 Tim Ellison ([EMAIL PROTECTED])
 IBM Java technology centre, UK.

[jira] Closed: (HARMONY-67) java.nio.charset.Charset.decode(ByteBuffer) throws unexpected BufferOverflowException for UTF-16BE, UTF-16LE, UTF-16 charsets.

[Tim Ellison (JIRA)]

 [ http://issues.apache.org/jira/browse/HARMONY-67?page=all ]
 
Tim Ellison closed HARMONY-67:
--

Resolution: Fixed

Verified by Svetlana.
(If anyone disagrees I'm happy to reopen it)


 java.nio.charset.Charset.decode(ByteBuffer) throws unexpected 
 BufferOverflowException  for UTF-16BE, UTF-16LE, UTF-16 charsets.
 ---

  Key: HARMONY-67
  URL: http://issues.apache.org/jira/browse/HARMONY-67
  Project: Harmony
 Type: Bug
   Components: Classlib
 Reporter: Svetlana Samoilenko
 Assignee: Tim Ellison


 According to j2se 1.4.2 specification for Charset.decode(ByteBuffer  b) the 
 method must not throw any exceptions.
 The test listed below shows that there is unexpected BufferOverflowException 
 thrown if charset name is one in the following:  UTF-16BE, UTF-16LE, UTF-16.
 BEA does not throw any exceptions.
 Code to reproduce: 
 import java.nio.charset.Charset; 
 import java.nio.ByteBuffer; 
 import java.nio.CharBuffer; 
 public class test2 {   
 public static void main(String[] args) throws Exception { 
 byte[] b = new byte[] {(byte)1}; 
 ByteBuffer buf= ByteBuffer.wrap(b); 
 CharBuffer charbuf=Charset.forName(UTF-16).decode(buf); 
 System.out.println(CharBuffer.length()=+ charbuf.length());
 } 
 }
 Steps to Reproduce: 
 1. Build Harmony (check-out on 2006-01-30) j2se subset as described in 
 README.txt. 
 2. Compile test2.java using BEA 1.4 javac 
  javac -d . test2.java 
 3. Run java using compatible VM (J9) 
  java -showversion test2 
 Output: 
 C:\tmpC:\jrockit-j2sdk1.4.2_04\bin\java.exe -showversion test2 
 java version 1.4.2_04 
 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_04-b05) 
 BEA WebLogic JRockit(TM) 1.4.2_04 JVM (build 
 ari-31788-20040616-1132-win-ia32, Native Threads, GC strategy: parallel) 
 CharBuffer.length()=0
 C:\tmpC:\harmony\trunk\deploy\jre\bin\java -showversion test2 
 (c) Copyright 1991, 2005 The Apache Software Foundation or its licensors, as 
 applicable. 
  java.nio.BufferOverflowException
 at java.nio.CharBuffer.put(CharBuffer.java:662) 
 at java.nio.CharBuffer.put(CharBuffer.java:629) 
 at java.nio.charset.CharsetDecoder.decode(CharsetDecoder.java:406) 
 at java.nio.charset.CharsetDecoder.decode(CharsetDecoder.java:243) 
 at java.nio.charset.Charset.decode(Charset.java:630) 
 at test2.main(test2.java:8)
 Suggested junit test case:
  CharsetTest.java 
 - 
 import java.nio.charset.Charset; 
 import java.nio.ByteBuffer; 
 import java.nio.CharBuffer; 
 import junit.framework.*; 
 public class CharsetTest extends TestCase { 
 public static void main(String[] args) { 
 junit.textui.TestRunner.run(CharsetTest.class); 
 } 
 public void test_decode() { 
 byte[] b = new byte[] {(byte)1}; 
 ByteBuffer buf= ByteBuffer.wrap(b); 
 CharBuffer charbuf=Charset.forName(UTF-16).decode(buf); 
 assertEquals(Assert 0: charset UTF-16,0,charbuf.length());
 
 charbuf=Charset.forName(UTF-16BE).decode(buf); 
 assertEquals(Assert 1: charset UTF-16BE,0, charbuf.length());   
  
 
 charbuf=Charset.forName(UTF-16LE).decode(buf); 
 assertEquals(Assert 2: charset UTF16LE,0, charbuf.length());
 
} 
 }

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

Re: [classlib] security moved

[Tim Ellison]

Geir Magnusson Jr wrote:
 I moved modules/security to archive/modules/security and moved
 modules/security2 to modules/security.  I adjusted build scripts as needed.

Thanks.  How about making the archive/ a peer of trunk/, branches/ 
tags/, then people downloading trunk won't get the archived stuff too?

 I wasn't able to go further or put a snapshot up because of really awful
 network conditions in the hotel I'm in. (There seems to be something
 systemically bad about Embassy Suites - this is the second time I've had
 network problems in the last two times I stayed in one...)

I have built the refactored code (at rev 378478) and created the snapshot
archives.  They are sitting on my disk at the moment.  Do we need a
green light from the incubator PMC before uploading a new snapshot?

 Tim, do the change of the package names if you wish.  I'll do the
 snapshot based on a svn rev later today (unless someone else wants
 to...)  I suspect that it won't be a major deal if you get the new J9 VM
 up at the same time as the svn change is made...

The plan is still on course to have the new VME version in place ready
for people to continue working seamlessly, and leave the old VME there
to run snapshots.

Regards,
Tim

-- 

Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.

Re: [classlib] policy file

[Tim Ellison]

I meant it's copyright / license block comment.

Same reason every other files does.

...and why drl.policy? any objection to changing it back?

Regards,
Tim

Mikhail Loenko wrote:
 java.security also does not have a license...
 
 Why do you think they have to have a license?
 
 Thanks,
 Mikhail
 
 On 2/17/06, Tim Ellison [EMAIL PROTECTED] wrote:
 why has our permissions policy file (in jre/lib/security) gone from
 java.policy - drl.policy, lost its license etc. ?

 Regards,
 Tim

 --

 Tim Ellison ([EMAIL PROTECTED])
 IBM Java technology centre, UK.

 

-- 

Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.

Re: newbie to project-where to start from

[Tim Ellison]

Mikhail Loenko wrote:
 depending on the bug...

actually, this is the answer I would give too (which I know is not very
helpful).

Some apparent 'bugs' are ambiguities in the spec, or a different choice
of under-specified behavior that we likely want to match to ensure
compatibility; others may be deemed implementation bugs that we should
not recreate.

Sometimes it's a tough call, we should seek consensus on the dev list.

 I would not like to be compatible with SIGSEGVs :)

We'll have our own versions ;-)

Regards,
Tim

 Thanks,
 Mikhail
 
 On 2/16/06, Alexey Petrenko [EMAIL PROTECTED] wrote:
 2006/2/16, Tim Ellison [EMAIL PROTECTED]:
 Tests should be written to the javadoc spec, rather than deducing
 behavior from any particular implementation.
 By the way...
 Do we want to be bug compatible with reference implementation?

 --
 Alexey A. Petrenko
 Intel Middleware Products Division

 

-- 

Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.

Re: newbie to project-where to start from

[Anton Avtamonov]

Just minor comment:
Many times I saw very strange behavior in jdk which I was absolutely
sure about: definitely a bug. But then... I found applications which
used those strange things!

I hust want to say that it is important to be very careful when
deciding what is bug: it is very probable to find an application
basing on it (java world is very very huge :) ).

--
Anton Avtamonov,
Intel Middleware Products Division


On 2/17/06, Tim Ellison [EMAIL PROTECTED] wrote:
 Mikhail Loenko wrote:
  depending on the bug...

 actually, this is the answer I would give too (which I know is not very
 helpful).

 Some apparent 'bugs' are ambiguities in the spec, or a different choice
 of under-specified behavior that we likely want to match to ensure
 compatibility; others may be deemed implementation bugs that we should
 not recreate.

 Sometimes it's a tough call, we should seek consensus on the dev list.

  I would not like to be compatible with SIGSEGVs :)

 We'll have our own versions ;-)

 Regards,
 Tim

  Thanks,
  Mikhail
 
  On 2/16/06, Alexey Petrenko [EMAIL PROTECTED] wrote:
  2006/2/16, Tim Ellison [EMAIL PROTECTED]:
  Tests should be written to the javadoc spec, rather than deducing
  behavior from any particular implementation.
  By the way...
  Do we want to be bug compatible with reference implementation?
 
  --
  Alexey A. Petrenko
  Intel Middleware Products Division
 
 

 --

 Tim Ellison ([EMAIL PROTECTED])
 IBM Java technology centre, UK.

[jira] Created: (HARMONY-101) NPE in java.util.regex.Pattern.compile()

[Svetlana Samoilenko (JIRA)]

NPE in java.util.regex.Pattern.compile()


 Key: HARMONY-101
 URL: http://issues.apache.org/jira/browse/HARMONY-101
 Project: Harmony
Type: Bug
  Components: Classlib  
Reporter: Svetlana Samoilenko


According to 1.4.2 and 1.5 specifications for 
java.util.regex.Pattern.matches(String regex,CharSequence input)
  
An invocation of this convenience method of the form 
Pattern.matches(regex, input);
behaves in exactly the same way as the expression 
Pattern.compile(regex).matcher(input).matches()

Harmony throws unspecified NPE for Pattern.compile and returns false instead of 
true for Pattern.matches().

Code to reproduce: 
import java.util.regex.Pattern;
public class test2 {
public static void main(String[] args) { 
System.out.println(boolean is 
true=+Pattern.matches([,\\p{Punct}], ,));
System.out.println(boolean is 
true=+Pattern.compile([,\\p{Punct}]).matcher(,).matches());  
}
}
 Steps to Reproduce: 
1. Build Harmony (check-out on 2006-01-30) j2se subset as described in 
README.txt. 
2. Compile test2.java using BEA 1.4 javac 
 javac -d . test2.java 
3. Run java using compatible VM (J9) 
 java -showversion test2

Output: 
C:\tmpC:\jrockit-j2sdk1.4.2_04\bin\java.exe -showversion test2 
java version 1.4.2_04 
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_04-b05) 
BEA WebLogic JRockit(TM) 1.4.2_04 JVM (build ari-31788-20040616-1132-win-ia32, 
Native Threads, GC strategy: parallel) 
boolean is true=true
boolean is true=true

C:\tmpC:\harmony\trunk\deploy\jre\bin\java -showversion test2 
(c) Copyright 1991, 2005 The Apache Software Foundation or its licensors, as 
applicable. 
boolean is true=false
java.lang.NullPointerException
at test2.main(test2.java:5)

Suggested junit test case:
 PatternTest.java 
- 
import junit.framework.*; 
import java.util.regex.Pattern;

public class PatternTest extends TestCase { 
public static void main(String[] args) { 
junit.textui.TestRunner.run(PatternTest.class); 
} 
public void test_compile () { 
assertTrue(Pattern.matches([,\\p{Punct}], ,));
assertTrue(Pattern.compile([,\\p{Punct}]).matcher(,).matches());  
   
 } 
}





-- 
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-100) text/BidiWrapper issue?

[Tim Ellison (JIRA)]

[ 
http://issues.apache.org/jira/browse/HARMONY-100?page=comments#action_12366777 
] 

Tim Ellison commented on HARMONY-100:
-

Vladimir,

Thanks for the observation.  I agree there is a problem here, but I don't agree 
with your conclusion.

Looking at
http://icu.sourceforge.net/apiref/icu4c/ubidi_8h.html#a22
especially the paragraph beginning Caution: A copy of this pointer

and the native code in 
Java_org_apache_harmony_text_BidiWrapper_ubidi_1setPara

The Harmony code passes in the address of a local variable '_embeddingLevels' 
which, as you point out will go out of scope at the end of this function 
(precisely the case cautioned against).  If the JNI impl is data-copying then 
obviously this can lead to subsequent invalid access, and if the JNI-impl is 
pinning then GC could move the byte array upon release of the data.

However, I don't see how committing the memory back to the java object helps?  
The memory needs to be stable until the call to 
Java_org_apache_harmony_text_BidiWrapper_ubidi_1close.  Right now it is java 
memory allocated in the BiDiWrapper:

private static long createUBiDi(char[] text, int textStart,
byte[] embeddings, int embStart, int paragraphLength, 
int flags) {
char[] realText = null;

byte[] realEmbeddings = null;


I think the solution is to allocate this realEmbeddings memory as OSMemory in 
Java and pass the address into the native call, or allocating it as VM static 
memory within the native code itself, then freeing it after closing the wrapper.


 text/BidiWrapper issue?
 ---

  Key: HARMONY-100
  URL: http://issues.apache.org/jira/browse/HARMONY-100
  Project: Harmony
 Type: Bug
 Reporter: Vladimir Gorr


 Let's consider the following test:
 import java.text.Bidi;
 public class Test {
   public static void main(String[] args) throws Exception {
   Bidi bd = new Bidi(new char[] { 's', 's', 's' }, 0, 
   new byte[] { (byte) -7, (byte) -2, (byte) -3 }, 
   0, 3, Bidi.DIRECTION_DEFAULT_LEFT_TO_RIGHT);
   System.out.println(Expected 7, real  +   + 
 bd.getLevelAt(0));
   }
 }
 In my opinion the JNI implementation of Bidi (text/BidiWrapper.c file, 
 ubidi_1setPara() function) contains a potential bug, namely:
 1. If  the embeddingLevels  argument is not NULL then _embeddingLevels 
 variable is initialized with the JNI GetByteArrayElements() function;
 2. ICU function (ubidi_setPara) initializes ICU inner structure and puts the 
 _embeddingLevels into it;
 3. If _embeddingLevels pointer is not NULL then the JNI 
 ReleaseByteArrayElements() function (with 0 as fourth parameter) is called.
 This function releases the memory (according to JNI specification) the 
 _embeddingLevels pointer refers to;
 4. After that ICU inner structure isn't initialized properly. Call of ICU 
 ubidi_getLevels() function can return incorrect values (see java test above).
 It seems the JNI_COMMIT parameter instead of 0 should be passed to the 
 ReleaseByteArrayElements() to avoid this problem.
 I'd like to underline the test mentioned above works w/o any issues for 
 Harmony-14 contribution (although it shouldn't sometimes IMHO).
 Therefore if there are any doubts in my argumentation this issue can be 
 closed as invalid. 

-- 
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-100) text/BidiWrapper issue?

[Tim Ellison (JIRA)]

[ 
http://issues.apache.org/jira/browse/HARMONY-100?page=comments#action_12366778 
] 

Tim Ellison commented on HARMONY-100:
-

What I forgot to say at the end was...   and thank you for reading it so 
closely to find this bug!

 text/BidiWrapper issue?
 ---

  Key: HARMONY-100
  URL: http://issues.apache.org/jira/browse/HARMONY-100
  Project: Harmony
 Type: Bug
 Reporter: Vladimir Gorr


 Let's consider the following test:
 import java.text.Bidi;
 public class Test {
   public static void main(String[] args) throws Exception {
   Bidi bd = new Bidi(new char[] { 's', 's', 's' }, 0, 
   new byte[] { (byte) -7, (byte) -2, (byte) -3 }, 
   0, 3, Bidi.DIRECTION_DEFAULT_LEFT_TO_RIGHT);
   System.out.println(Expected 7, real  +   + 
 bd.getLevelAt(0));
   }
 }
 In my opinion the JNI implementation of Bidi (text/BidiWrapper.c file, 
 ubidi_1setPara() function) contains a potential bug, namely:
 1. If  the embeddingLevels  argument is not NULL then _embeddingLevels 
 variable is initialized with the JNI GetByteArrayElements() function;
 2. ICU function (ubidi_setPara) initializes ICU inner structure and puts the 
 _embeddingLevels into it;
 3. If _embeddingLevels pointer is not NULL then the JNI 
 ReleaseByteArrayElements() function (with 0 as fourth parameter) is called.
 This function releases the memory (according to JNI specification) the 
 _embeddingLevels pointer refers to;
 4. After that ICU inner structure isn't initialized properly. Call of ICU 
 ubidi_getLevels() function can return incorrect values (see java test above).
 It seems the JNI_COMMIT parameter instead of 0 should be passed to the 
 ReleaseByteArrayElements() to avoid this problem.
 I'd like to underline the test mentioned above works w/o any issues for 
 Harmony-14 contribution (although it shouldn't sometimes IMHO).
 Therefore if there are any doubts in my argumentation this issue can be 
 closed as invalid. 

-- 
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: svn commit: r378390 - in /incubator/harmony/enhanced/classlib/trunk/native-src/win.IA32/auth: ./ auth_copyright.c authwin32.c authwin32.h hyauth.def hyauth.rc makefile

[Tim Ellison]

sure -- this is the C version of the jaaswin code (including some Hy
portlib-ification), with building code in the makefile format that the
other natives use.  The Linux version still needs doing, so I wanted to
stash it in SVN for discussion with Mikhail et al before linking it into
the actual build.

Thanks
Tim

Leo Simons wrote:
 On Thu, Feb 16, 2006 at 11:00:26PM -, [EMAIL PROTECTED] wrote:
 Author: tellison
 Date: Thu Feb 16 15:00:22 2006
 New Revision: 378390

 URL: http://svn.apache.org/viewcvs?rev=378390view=rev
 Log:
 Just stashing this code in svn,
 not included in the build.
 
 When you put new things in SVN, please either make sure to have some notes 
 next
 to them describing what it is for / what it does / what you will use it for 
 or,
 failing that, write a meaningful commit message that has this info.
 
 The subversion project has a great HACKING.html that describes the how and 
 the why
 and the like for this kind of thing.
 
 Thanks!
 
 Leo
 

-- 

Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.

Re: newbie to project-where to start from

[Mikhail Loenko]

I agree with Tim that we should discuss on the dev list

Later we might want to have some roadmap once we find a number
of similar issues

At this point I think we might be compatible when RI throws
wrong exceptions - for example it often mixes NPE and
IllegalArgumentException

Thanks,
Mikhail

On 2/17/06, Anton Avtamonov [EMAIL PROTECTED] wrote:
 Just minor comment:
 Many times I saw very strange behavior in jdk which I was absolutely
 sure about: definitely a bug. But then... I found applications which
 used those strange things!

 I hust want to say that it is important to be very careful when
 deciding what is bug: it is very probable to find an application
 basing on it (java world is very very huge :) ).

 --
 Anton Avtamonov,
 Intel Middleware Products Division


 On 2/17/06, Tim Ellison [EMAIL PROTECTED] wrote:
  Mikhail Loenko wrote:
   depending on the bug...
 
  actually, this is the answer I would give too (which I know is not very
  helpful).
 
  Some apparent 'bugs' are ambiguities in the spec, or a different choice
  of under-specified behavior that we likely want to match to ensure
  compatibility; others may be deemed implementation bugs that we should
  not recreate.
 
  Sometimes it's a tough call, we should seek consensus on the dev list.
 
   I would not like to be compatible with SIGSEGVs :)
 
  We'll have our own versions ;-)
 
  Regards,
  Tim
 
   Thanks,
   Mikhail
  
   On 2/16/06, Alexey Petrenko [EMAIL PROTECTED] wrote:
   2006/2/16, Tim Ellison [EMAIL PROTECTED]:
   Tests should be written to the javadoc spec, rather than deducing
   behavior from any particular implementation.
   By the way...
   Do we want to be bug compatible with reference implementation?
  
   --
   Alexey A. Petrenko
   Intel Middleware Products Division
  
  
 
  --
 
  Tim Ellison ([EMAIL PROTECTED])
  IBM Java technology centre, UK.
 
 

Re: [jira] Created: (HARMONY-100) text/BidiWrapper issue?

[Tim Ellison]

congratulations -- you are our 100th customer!  Step over here for your
special gift.

(Too bad Svetlana, you missed out after all that hard work :-) ).

Tim

Vladimir Gorr (JIRA) wrote:
 text/BidiWrapper issue?
 ---
 
  Key: HARMONY-100
  URL: http://issues.apache.org/jira/browse/HARMONY-100
  Project: Harmony
 Type: Bug
 Reporter: Vladimir Gorr
 
 
 Let's consider the following test:
 
 import java.text.Bidi;
 public class Test {
   public static void main(String[] args) throws Exception {
   Bidi bd = new Bidi(new char[] { 's', 's', 's' }, 0, 
   new byte[] { (byte) -7, (byte) -2, (byte) -3 }, 
   0, 3, Bidi.DIRECTION_DEFAULT_LEFT_TO_RIGHT);
   System.out.println(Expected 7, real  +   + 
 bd.getLevelAt(0));
   }
 }
 
 In my opinion the JNI implementation of Bidi (text/BidiWrapper.c file, 
 ubidi_1setPara() function) contains a potential bug, namely:
 1. If  the embeddingLevels  argument is not NULL then _embeddingLevels 
 variable is initialized with the JNI GetByteArrayElements() function;
 2. ICU function (ubidi_setPara) initializes ICU inner structure and puts the 
 _embeddingLevels into it;
 3. If _embeddingLevels pointer is not NULL then the JNI 
 ReleaseByteArrayElements() function (with 0 as fourth parameter) is called.
 This function releases the memory (according to JNI specification) the 
 _embeddingLevels pointer refers to;
 4. After that ICU inner structure isn't initialized properly. Call of ICU 
 ubidi_getLevels() function can return incorrect values (see java test above).
 
 It seems the JNI_COMMIT parameter instead of 0 should be passed to the 
 ReleaseByteArrayElements() to avoid this problem.
 
 I'd like to underline the test mentioned above works w/o any issues for 
 Harmony-14 contribution (although it shouldn't sometimes IMHO).
 Therefore if there are any doubts in my argumentation this issue can be 
 closed as invalid. 
 
 

-- 

Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.

Re: newbie to project-where to start from

[Anton Avtamonov]

On 2/17/06, Mikhail Loenko [EMAIL PROTECTED] wrote:
 I agree with Tim that we should discuss on the dev list

+1


 Later we might want to have some roadmap once we find a number
 of similar issues

 At this point I think we might be compatible when RI throws
 wrong exceptions - for example it often mixes NPE and
 IllegalArgumentException

Sometimes spec states IllegalArgumentException should be thrown, but
implementation produces NPE. I think that is because
IllegalArgumentException is missed in impl and algorithm just failed
somewhere...
IMHO, when spec states some exception we should be spec-compatible.

--
Anton Avtamonov,
Intel Middleware Products Division

[jira] Commented: (HARMONY-68) java.nio.charset.Charset.isSupported(String charsetName) does not throw IllegalCharsetNameException for spoiled standard sharset name

[Tim Ellison (JIRA)]

[ 
http://issues.apache.org/jira/browse/HARMONY-68?page=comments#action_12366784 ] 

Tim Ellison commented on HARMONY-68:


The test looks invalid to me.  You shoud only expect an 
java.nio.charset.IllegalCharsetNameException if the name itself contains 
disallowed characters, and both underscore and dash are permitted.

The code 
Charset.isSupported(-UTF-8)

should return false, not throw an exception.

 java.nio.charset.Charset.isSupported(String charsetName) does not throw 
 IllegalCharsetNameException for spoiled standard sharset name
 -

  Key: HARMONY-68
  URL: http://issues.apache.org/jira/browse/HARMONY-68
  Project: Harmony
 Type: Bug
   Components: Classlib
 Reporter: Svetlana Samoilenko
  Attachments: charset_patch.txt

 According to j2se 1.4.2 specification for Charset.isSupported(String 
 charsetName)  the method must throw IllegalCharsetNameException  if the 
 given charset name is illegal . 
 Legal charset name must begin with either a letter or a digit. 
 The test listed below shows that there is no the exception  if to insert - 
 or _ symbols before standard sharset name, for example -UTF-8 or 
 _US-ASCII.
 Moreover the method returns true in this case.
 BEA also does not throw the exception but returns false.
 Code to reproduce: 
 import java.nio.charset.*; 
  
 public class test2 { 
 public static void main (String[] args) {
 // string starts neither a letter nor a digit 
 boolean sup=false; 
 try{
  sup=Charset.isSupported(-UTF-8);
  System.out.println(***BAD. should be exception; sup=+sup); 
  sup=Charset.isSupported(_US-ASCII);
  System.out.println(***BAD. should be exception; sup=+sup); 
 } catch (IllegalCharsetNameException e) {  
 System.out.println(***OK. Expected IllegalCharsetNameException  
 + e); 
 }   
 } 
 } 
 Steps to Reproduce: 
 1. Build Harmony (check-out on 2006-01-30) j2se subset as described in 
 README.txt. 
 2. Compile test2.java using BEA 1.4 javac 
  javac -d . test2.java 
 3. Run java using compatible VM (J9) 
  java -showversion test2 
 Output: 
 C:\tmpC:\jrockit-j2sdk1.4.2_04\bin\java.exe -showversion test2 
 java version 1.4.2_04 
 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_04-b05) 
 BEA WebLogic JRockit(TM) 1.4.2_04 JVM (build 
 ari-31788-20040616-1132-win-ia32, Native Threads, GC strategy: parallel) 
 ***BAD. should be exception; sup=false
 ***BAD. should be exception; sup=false
 C:\tmpC:\harmony\trunk\deploy\jre\bin\java -showversion test2 
 (c) Copyright 1991, 2005 The Apache Software Foundation or its licensors, as 
 applicable. 
 ***BAD. should be exception; sup=true
 ***BAD. should be exception; sup=true
 Suggested junit test case:
  CharserTest.java 
 - 
 import java.nio.charset.*; 
 import junit.framework.*; 
 public class CharsetTest extends TestCase { 
 public static void main(String[] args) { 
 junit.textui.TestRunner.run(CharsetTest.class); 
 } 
 public void test_isSupported() { 
   boolean sup=false; 
 // string starts neither a letter nor a digit 
 try{
 sup=Charset.isSupported(-UTF-8);
 fail(***BAD. should be exception IllegalCharsetNameException); 
 } catch (IllegalCharsetNameException e) {  //expected
 }
 // string starts neither a letter nor a digit 
 try{
  sup=Charset.isSupported(_US-ASCII);
  fail(***BAD. should be exception IllegalCharsetNameException); 
  
 } catch (IllegalCharsetNameException e) {  //expected
 }
} 
 }

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

Re: newbie to project-where to start from

[karan malhi]

Anton Avtamonov wrote:

IMHO, when spec states some exception we should be spec-compatible.

+1



On 2/17/06, Mikhail Loenko [EMAIL PROTECTED] wrote:
 


I agree with Tim that we should discuss on the dev list
   



+1

 


Later we might want to have some roadmap once we find a number
of similar issues

At this point I think we might be compatible when RI throws
wrong exceptions - for example it often mixes NPE and
IllegalArgumentException
   



Sometimes spec states IllegalArgumentException should be thrown, but
implementation produces NPE. I think that is because
IllegalArgumentException is missed in impl and algorithm just failed
somewhere...
IMHO, when spec states some exception we should be spec-compatible.

--
Anton Avtamonov,
Intel Middleware Products Division

 



--
Karan Singh

[jira] Created: (HARMONY-102) java.util.Date.parse(String) throws java.lang.IllegalArgumentException for legal string

[Svetlana Samoilenko (JIRA)]

java.util.Date.parse(String) throws  java.lang.IllegalArgumentException for 
legal string


 Key: HARMONY-102
 URL: http://issues.apache.org/jira/browse/HARMONY-102
 Project: Harmony
Type: Bug
  Components: Classlib  
Reporter: Svetlana Samoilenko


According to 1.4.2 and 1.5 specifications for java.util.Date(String s) 
IllegalArgumentException is thrown if attempt to interpret the string s as a 
representation of a date and time is fails.

Harmony throws  IllegalArgumentException  on legal string: Sat, 1 Jan 1970  
+0130 00:00:00.

Code to reproduce: 
import java.util.Date; 
public class test2 { 
public static void main(String[] args) { 
long date = Date.parse(Sat, 1 Jan 1970  +0130 00:00:00); 
System.out.println(date = + date); 
} 
} 

 Steps to Reproduce: 
1. Build Harmony (check-out on 2006-01-30) j2se subset as described in 
README.txt. 
2. Compile test2.java using BEA 1.4 javac 
 javac -d . test2.java 
3. Run java using compatible VM (J9) 
 java -showversion test2

Output: 
C:\tmpC:\jrockit-j2sdk1.4.2_04\bin\java.exe -showversion test2 
java version 1.4.2_04 
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_04-b05) 
BEA WebLogic JRockit(TM) 1.4.2_04 JVM (build ari-31788-20040616-1132-win-ia32, 
Native Threads, GC strategy: parallel) 
date =-540

C:\tmpC:\harmony\trunk\deploy\jre\bin\java -showversion test2 
(c) Copyright 1991, 2005 The Apache Software Foundation or its licensors, as 
applicable. 
java.lang.IllegalArgumentException
at java.util.Date.parse(Date.java:404)
at test2.main(test2.java:4)

Suggested junit test case:
 DateTest.java 
- 
import junit.framework.*; 
import java.util.Date;

public class DateTest extends TestCase { 
public static void main(String[] args) { 
junit.textui.TestRunner.run(DateTest.class); 
} 
public void test_parse () { 
assertEquals(-540, Date.parse(Sat, 1 Jan 1970  +0130 00:00:00));  
 
 } 
}


-- 
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] policy file

[Geir Magnusson Jr]

It probably has been that way for weeks, since we switched to security2. 
 Easy fix...


Tim Ellison wrote:

why has our permissions policy file (in jre/lib/security) gone from
java.policy - drl.policy, lost its license etc. ?

Regards,
Tim

Re: [classlib] policy file

[Geir Magnusson Jr]

We historically have add the Apache License to all of our files.

We should do this here for consistency, but it's not critical - I expect 
our policies to change to eliminate this practice at some point in the 
near future.  If we do a release though before that policy change 
happens, we should be sure to get it in.


Short answer, we should prollie get it in there.. :)

Mikhail Loenko wrote:

java.security also does not have a license...

Why do you think they have to have a license?

Thanks,
Mikhail

On 2/17/06, Tim Ellison [EMAIL PROTECTED] wrote:

why has our permissions policy file (in jre/lib/security) gone from
java.policy - drl.policy, lost its license etc. ?

Regards,
Tim

--

Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.

Re: [classlib] security moved

[Geir Magnusson Jr]

Tim Ellison wrote:

Geir Magnusson Jr wrote:

I moved modules/security to archive/modules/security and moved
modules/security2 to modules/security.  I adjusted build scripts as needed.


Thanks.  How about making the archive/ a peer of trunk/, branches/ 
tags/, then people downloading trunk won't get the archived stuff too?


Hm.  I think of it still as live material in our tree, but I don't 
feel too strongly about this.  If we keep it there, we should set  a 
policy to expire it out of there at some point.





I wasn't able to go further or put a snapshot up because of really awful
network conditions in the hotel I'm in. (There seems to be something
systemically bad about Embassy Suites - this is the second time I've had
network problems in the last two times I stayed in one...)


I have built the refactored code (at rev 378478) and created the snapshot
archives.  They are sitting on my disk at the moment.  Do we need a
green light from the incubator PMC before uploading a new snapshot?


No.  I'll check to see if I promised lazy notification messages on this.

BTW, is there an ant target for this snapshot creation yet?




Tim, do the change of the package names if you wish.  I'll do the
snapshot based on a svn rev later today (unless someone else wants
to...)  I suspect that it won't be a major deal if you get the new J9 VM
up at the same time as the svn change is made...


The plan is still on course to have the new VME version in place ready
for people to continue working seamlessly, and leave the old VME there
to run snapshots.


Right -

Re: [classlib] policy file

[Geir Magnusson Jr]

I actually have an objection to *that* name, so I will if you don't...


Tim Ellison wrote:

I meant it's copyright / license block comment.

Same reason every other files does.

...and why drl.policy? any objection to changing it back?

Regards,
Tim

Mikhail Loenko wrote:

java.security also does not have a license...

Why do you think they have to have a license?

Thanks,
Mikhail

On 2/17/06, Tim Ellison [EMAIL PROTECTED] wrote:

why has our permissions policy file (in jre/lib/security) gone from
java.policy - drl.policy, lost its license etc. ?

Regards,
Tim

--

Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.

Re: [classlib] policy file

[Geir Magnusson Jr]

Mikhail Loenko wrote:

On 2/17/06, Tim Ellison [EMAIL PROTECTED] wrote:

I meant it's copyright / license block comment.

Same reason every other files does.


That is not a source code, BTW corresponding RI's files do not have copyrights.


We don't care - we put it on all resources.  See our generated HTML 
pages, for example.





...and why drl.policy? any objection to changing it back?


I'm not sure it is legal to use 'java'  unless it is explicitely
required by the spec.
'java.security' is required by the spec.

How about 'drl.policy'?


s/drl/java/

I'll sit by my mailbox waiting for the letter from Sun legal so no one 
else has to worry :)


geir



Thanks,
Mikhail


Regards,
Tim

Mikhail Loenko wrote:

java.security also does not have a license...

Why do you think they have to have a license?

Thanks,
Mikhail

On 2/17/06, Tim Ellison [EMAIL PROTECTED] wrote:

why has our permissions policy file (in jre/lib/security) gone from
java.policy - drl.policy, lost its license etc. ?

Regards,
Tim

--

Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.


--

Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.

Re: [classlib] policy file

[Geir Magnusson Jr]

Actually, looking at it, it makes no sense to have this coming from 
module/security anyway.


I'll revert to using the one from depends/files

geir


Geir Magnusson Jr wrote:



Mikhail Loenko wrote:

On 2/17/06, Tim Ellison [EMAIL PROTECTED] wrote:

I meant it's copyright / license block comment.

Same reason every other files does.


That is not a source code, BTW corresponding RI's files do not have 
copyrights.


We don't care - we put it on all resources.  See our generated HTML 
pages, for example.





...and why drl.policy? any objection to changing it back?


I'm not sure it is legal to use 'java'  unless it is explicitely
required by the spec.
'java.security' is required by the spec.

How about 'drl.policy'?


s/drl/java/

I'll sit by my mailbox waiting for the letter from Sun legal so no one 
else has to worry :)


geir



Thanks,
Mikhail


Regards,
Tim

Mikhail Loenko wrote:

java.security also does not have a license...

Why do you think they have to have a license?

Thanks,
Mikhail

On 2/17/06, Tim Ellison [EMAIL PROTECTED] wrote:

why has our permissions policy file (in jre/lib/security) gone from
java.policy - drl.policy, lost its license etc. ?

Regards,
Tim

--

Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.


--

Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.

Re: newbie to project-where to start from

[Geir Magnusson Jr]

I agree - that is why I would say that since we are new to the 
Implementation of Java Family, we'd want to mimic the bugs (yes, with 
discussion as I'm sure there will be bugs we don't want to mimic...).


The reason is that even if we're right - it's a bug - we're going not be 
successful with that argument to Sun, the EG, users, whatever for a while.


We'll need to build up user-base and momentum.  Then the story changes...

geir

Anton Avtamonov wrote:

Just minor comment:
Many times I saw very strange behavior in jdk which I was absolutely
sure about: definitely a bug. But then... I found applications which
used those strange things!

I hust want to say that it is important to be very careful when
deciding what is bug: it is very probable to find an application
basing on it (java world is very very huge :) ).

--
Anton Avtamonov,
Intel Middleware Products Division


On 2/17/06, Tim Ellison [EMAIL PROTECTED] wrote:

Mikhail Loenko wrote:

depending on the bug...

actually, this is the answer I would give too (which I know is not very
helpful).

Some apparent 'bugs' are ambiguities in the spec, or a different choice
of under-specified behavior that we likely want to match to ensure
compatibility; others may be deemed implementation bugs that we should
not recreate.

Sometimes it's a tough call, we should seek consensus on the dev list.


I would not like to be compatible with SIGSEGVs :)

We'll have our own versions ;-)

Regards,
Tim


Thanks,
Mikhail

On 2/16/06, Alexey Petrenko [EMAIL PROTECTED] wrote:

2006/2/16, Tim Ellison [EMAIL PROTECTED]:

Tests should be written to the javadoc spec, rather than deducing
behavior from any particular implementation.

By the way...
Do we want to be bug compatible with reference implementation?

--
Alexey A. Petrenko
Intel Middleware Products Division


--

Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.

Re: [classlib] security moved

[Geir Magnusson Jr]

Tim Ellison wrote:

Geir Magnusson Jr wrote:

Tim Ellison wrote:

Geir Magnusson Jr wrote:

I moved modules/security to archive/modules/security and moved
modules/security2 to modules/security.  I adjusted build scripts as
needed.

Thanks.  How about making the archive/ a peer of trunk/, branches/ 
tags/, then people downloading trunk won't get the archived stuff too?

Hm.  I think of it still as live material in our tree, but I don't
feel too strongly about this.  If we keep it there, we should set  a
policy to expire it out of there at some point.


whatever -- I don't really mind either.  We have a module called
'archive' so don't want to add to confusion about the archive in trunk.


I wasn't able to go further or put a snapshot up because of really awful
network conditions in the hotel I'm in. (There seems to be something
systemically bad about Embassy Suites - this is the second time I've had
network problems in the last two times I stayed in one...)

I have built the refactored code (at rev 378478) and created the snapshot
archives.  They are sitting on my disk at the moment.  Do we need a
green light from the incubator PMC before uploading a new snapshot?

No.  I'll check to see if I promised lazy notification messages on this.


ok -- let me know, I'll wait.



 Don't hold up for this.  This is for all practical purposes an 
automated snapshot, you being the automator...  No one will confuse this 
for a release of any sort.


We prollie should be doubly sure, and put a note in the root - 
SNAPSHOT.txt or something for next time...



BTW, is there an ant target for this snapshot creation yet?


erm, (shuffle, shuffle), no.  I run the default target and copy in the
license, notices, and readme files.  I'll add it to the list


Cool - I just was getting bleary-eyed last night so wasn't sure if I 
missed it..


thx

geir

[jira] Commented: (HARMONY-64) java.nio.charset.Charset.forName(String name) does not throw UnsupportedCharsetException if valid name starts with x-

[Tim Ellison (JIRA)]

[ 
http://issues.apache.org/jira/browse/HARMONY-64?page=comments#action_12366796 ] 

Tim Ellison commented on HARMONY-64:


Richard,

When you say icu4jni's latest code can you be more specific?  Was this HEAD 
or a release ... ?
We need to know exactly what it contains before deciding whether to use it.

Thanks,
Tim

 java.nio.charset.Charset.forName(String name) does not throw 
 UnsupportedCharsetException if valid name starts with x-
 ---

  Key: HARMONY-64
  URL: http://issues.apache.org/jira/browse/HARMONY-64
  Project: Harmony
 Type: Bug
   Components: Classlib
 Reporter: Svetlana Samoilenko
 Assignee: Tim Ellison
  Attachments: ICUInterface34.dll, libICUInterface34.so

 According to j2se 1.4.2 specification for Charset forName(String charsetName) 
  the method must throw UnsupportedCharsetException if no support for the 
 named charset is available in this instance of the Java virtual machine. The 
 method  does not throw exception if a unsupported name started with x-. For 
 example, the method throws an exception for not supported name xyz, but 
 does not for x-yz.
 Code to reproduce: 
 import java.nio.charset.*; 
 public class test2 { 
 public static void main (String[] args) {
 try{
 Charset ch=Charset.forName(x-yz);
 System.out.println(***BAD. UnsupportedCharsetException must be 
 thrown instead of creating +ch); 
 } catch (UnsupportedCharsetException e) {  
 System.out.println(***OK. Expected UnsupportedCharsetException  
 + e); 
 }
 } 
 }
 Steps to Reproduce: 
 1. Build Harmony (check-out on 2006-01-30) j2se subset as described in 
 README.txt. 
 2. Compile test2.java using BEA 1.4 javac 
  javac -d . test2.java 
 3. Run java using compatible VM (J9) 
  java -showversion test2 
 Output: 
 C:\tmpC:\jrockit-j2sdk1.4.2_04\bin\java.exe -showversion test2 
 java version 1.4.2_04 
 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_04-b05) 
 BEA WebLogic JRockit(TM) 1.4.2_04 JVM (build 
 ari-31788-20040616-1132-win-ia32, Native Threads, GC strategy: parallel) 
 ***OK. Expected UnsupportedCharsetException 
 java.nio.charset.UnsupportedCharsetException: x-yz
 C:\tmpC:\harmony\trunk\deploy\jre\bin\java -showversion test2 
 (c) Copyright 1991, 2005 The Apache Software Foundation or its licensors, as 
 applicable. 
 ***BAD. UnsupportedCharsetException must be thrown instead of creating 
 Charset[x-yz]
 Suggested junit test case:
  CharsetTest.java 
 - 
 import java.nio.charset.*; 
 import junit.framework.*; 
 public class CharsetTest extends TestCase { 
 public static void main(String[] args) { 
 junit.textui.TestRunner.run(CharsetTest.class); 
 } 
 public void test_forName() { 
 try {
 Charset ch=Charset.forName(x-yz);
 fail(Assert 0: UnsupportedCharsetException must be thrown 
 instead of creating:  + ch); 
 } catch (UnsupportedCharsetException 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

[Fwd: svn commit: r378514 - /incubator/harmony/enhanced/classlib/trunk/make/build-java.xml]

[Tim Ellison]

 (I need to go back and make sure the content from
 modules/security drl.policy that I removed is represented
 in depends/files )

yeah it is, I did that already.

Regards,
Tim



 Original Message 
Subject: svn commit: r378514 -
/incubator/harmony/enhanced/classlib/trunk/make/build-java.xml
Date: Fri, 17 Feb 2006 14:02:31 -
From: [EMAIL PROTECTED]
Reply-To: harmony-dev@incubator.apache.org
To: [EMAIL PROTECTED]

Author: geirm
Date: Fri Feb 17 06:02:29 2006
New Revision: 378514

URL: http://svn.apache.org/viewcvs?rev=378514view=rev
Log:
restore taking java.policy from depends/files since it spans the
whole classlib

(I need to go back and make sure the content from modules/security
drl.policy
that I removed is represented in depends/files )


Modified:
incubator/harmony/enhanced/classlib/trunk/make/build-java.xml

Modified: incubator/harmony/enhanced/classlib/trunk/make/build-java.xml
URL:
http://svn.apache.org/viewcvs/incubator/harmony/enhanced/classlib/trunk/make/build-java.xml?rev=378514r1=378513r2=378514view=diff
==
--- incubator/harmony/enhanced/classlib/trunk/make/build-java.xml (original)
+++ incubator/harmony/enhanced/classlib/trunk/make/build-java.xml Fri
Feb 17 06:02:29 2006
@@ -265,7 +265,12 @@
 /fileset
 /copy

-   
+copy todir=${target.output}/jre/lib/security overwrite=yes
+ fileset dir=${depends.files}
+ include name=java.policy /
+ /fileset
+ /copy
+   
 copy todir=${target.output}/jre/lib/security overwrite=yes
 fileset dir=../modules/security/src/java.home/lib/security/
 include name=drl.policy /




-- 

Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.

Re: Platform dependent code placement (was: Re: repo layout again)

[Oliver Deakin]

Tim Ellison wrote:

Andrey Chernyshev wrote:
  
  

snip

On the other hand, having a separate source trees like linux32.sparc,
solaris64.sparc, win.IA32 for each specific platform combination may
lead to a huge code duplication. We may need to be able to share the
code through the certain, but not through all platform combinations.



Agreed.  The existing code layout for the classlib natives is certainly
not a viable way to scale across multiple platforms.

(The 'in-house' mechanism for managing multi-platform code is particular
to IBM so not of great interest here, suffice to say that the win.IA32
and linux.IA32 trees in classlib/trunk/native-code are the product of
that mechanism with some manual tidy-up).

  
Also agree. The current layout will not scale well when we move to a 
broader range of platforms.



To address that issue, I can suggest a pretty straightforward scheme
for platform-dependent code placement which looks as follows:

1. There is a fixed set of attributes which denotes a specific target
configuration. As a starter set, we may have OS (for operating system)
and, say ARCH (for architecture) attributes. This set can be extended
later, but, as it was suggested, let's don't cross that bridge if we
come to it.



Yes, the principal distinction is probably on OS  ARCH.

  

2. Files in the source tree are selected for compilation based on the
OS or ARCH attribute values which may (or may not appear) in a file or
directory name.
Some examples are:

src\main\native\solaris\foo.cpp
- means file is applicable for whatever system running Solaris;



yep (that was foo.c, right ;-) -- only teasing)

  

src\main\native\win\foo_ia32.cpp
- file is applicable only for  Windows / IA32;



why has the ARCH flipped onto the file name?  why not win_ia32 ?

  

src\main\native\foo_ia32_em64t.cpp
- file can be compiled for whatever OS on either IA32 or EM64T
architecture, but nothing else.



I agree with the approach, but left wondering why it is not something like:
   src\main\native\
   common\
   unix\
   windows\
   zos\
   solaris\
   solaris_x86\
   solaris_sparc\
   windows_ifp\

i.e. a taxonomy covering families of code (common, unix-like,
windows-like) and increasingly specific discriminators.
  
The idea is good, however I think including both the OS and arch in the 
directory name is preferable.
It is just as simple a convention, gives the coder an at-a-glance view 
of which OS/arch's have platform specific code associated with them

and keeps the actual source filenames consistent across platforms.

Was there a particular reason for attaching the architecture to the 
filename and not the directory Andrey?
  

The formal file selection rule may look like:

(1) File is applicable for the given OS value if its pathname contains regexp
[\W_]${OS}[\W_], or pathname doesn't contain any OS value;

(2) File is applicable for the given ARCH value if its pathname contains regexp
[\W_]${ARCH}[\W_], or pathname doesn't contain any ARCH value;

(3) File is selected for a compilation if it satisfies both (1) and
(2) criteria.



If we restrict the OS and ARCH identifiers to directories then it will
allow us to use the gmake VPATH functionality to select the right file,
so compiling on solaris x86 will have a
VPATH='solaris_x86:solaris:unix:common' and so on.
  
I agree that is a perfect scenario to use VPATH for. I think this would 
probably be a simpler solution
than using ant (as suggested later) and also would not require you to 
have a JVM to build the native code.


  

One can see that this naming convention gives developers enough
freedom to layout their code in a most convenient way (actually,
experience shows that the meaning of convenient may differ
significantly depending on a component type :). On the other hand, it
gives well defined (and hopefully intuitive enough) rule showing
whether the particular file is picked up by the compiler or not,
depending on a configuration.



I like the idea -- if we agree to use gmake throughout then I think we
get this functionality 'for free'.

  

In addition to the above, the code could also be selected for
compilation by means of #defines directives in C/C++ files (it is
convenient when the most of a file is platform-independent, with the
exception of just a few lines of code). The building system could set
up the OS and ARCH attributes as appropriate defines for the C/C++
code.
For example, for Windows/IA32 config, the following defines could be set:

 #define OS WIN
 #define WIN
 #define ARCH IA32
 #define IA32

Then the platform-dependent code sections may look like:

#ifdef WIN
….
#endif

which is essentially same as:

#if OS == WIN
….
#endif

It is important that OS/ARCH (or whatever additional) attribute names
and values are used consistently in the file names and 

[classlib] Snapshot build 378478 available

[Tim Ellison]

A new class library snapshot build is available on the Harmony binary
downloads page:

http://cvs.apache.org/dist/incubator/harmony/snapshots/

This is the state of the classlib code at repository revision 378478,
and is made available as a convenience for those who do not have the
required tool chain to build the code themselves.  There are different
downloads for windows and linux:

   harmony-classlib-r378478-linux-x86-snapshot.tgz
   harmony-classlib-r378478-win-x86-snapshot.zip

Details of how to rebuild these binaries from source and how to obtain a
compatible VM to run the code are given here:

http://incubator.apache.org/harmony/subcomponents/classlibrary/build_classlib.html

There are a number of bug fixes and enhancements in this new snapshot.
Please download it and try it, and if there are any problems send a note
to the dev list.

Thanks to everyone who has contributed.

Regards,
Tim

-- 

Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.

Re: [classlib] security moved

[Geir Magnusson Jr]

Really.. It's a snapshot.  Please.  That way you can get the refactoring 
in and new VM up  T


The PMC had been advised that we are doing shapshots...


Geir Magnusson Jr wrote:



Tim Ellison wrote:

Geir Magnusson Jr wrote:

Tim Ellison wrote:

Geir Magnusson Jr wrote:

I moved modules/security to archive/modules/security and moved
modules/security2 to modules/security.  I adjusted build scripts as
needed.

Thanks.  How about making the archive/ a peer of trunk/, branches/ 
tags/, then people downloading trunk won't get the archived stuff too?

Hm.  I think of it still as live material in our tree, but I don't
feel too strongly about this.  If we keep it there, we should set  a
policy to expire it out of there at some point.


whatever -- I don't really mind either.  We have a module called
'archive' so don't want to add to confusion about the archive in trunk.

I wasn't able to go further or put a snapshot up because of really 
awful

network conditions in the hotel I'm in. (There seems to be something
systemically bad about Embassy Suites - this is the second time 
I've had

network problems in the last two times I stayed in one...)
I have built the refactored code (at rev 378478) and created the 
snapshot

archives.  They are sitting on my disk at the moment.  Do we need a
green light from the incubator PMC before uploading a new snapshot?

No.  I'll check to see if I promised lazy notification messages on this.


ok -- let me know, I'll wait.



 Don't hold up for this.  This is for all practical purposes an 
automated snapshot, you being the automator...  No one will confuse this 
for a release of any sort.


We prollie should be doubly sure, and put a note in the root - 
SNAPSHOT.txt or something for next time...



BTW, is there an ant target for this snapshot creation yet?


erm, (shuffle, shuffle), no.  I run the default target and copy in the
license, notices, and readme files.  I'll add it to the list


Cool - I just was getting bleary-eyed last night so wasn't sure if I 
missed it..


thx

geir

Re: I welcome J2SE 6's faster-splash.... re: Java speed-up

[Thorbjørn Ravn Andersen]

Stefano Mazzocchi wrote:



But look at the bright side: there are probably many other really 
simple yet useful things that can be done to make java more useful on 
the desktop and this will be a marketing win for alternative JVMs.


That would be to be able to write small java programs which start fast, 
and which does not have a massive JVM overhead for each.


Basically pull the same trick that Microsoft did with their JVM - have 
the preloaded Java environment being able to spin off new instances 
fast, giving the end user the impression that this is just another 
little program. 


Personally I think it would be great for Linux desktops and utilities.

--
 Thorbjørn

Re: compiling JCHEVM with GCC/Cygwin

[Enrico Migliore]

snowdosker wrote:


Thank you Enrico and Archie.

So now with assertions disabled  I faced next problem, Enrico 
mentioned in his email.

The same
failed to open native library 
/usr/local/classpath/lib/classpath/libjavanio.dll.a: permission denied


I'm trying to run it under XP professional so I had no problem to set 
exec flags in permissions

but this do not help.
Still the same problem.

Please, let me know if you will find solution.

Thanks, Ivan



Hi Ivan,

are you saying that, even though the permissions of libjavanio.dll.a are 
-r-xr-xr-x,

you got the same message? Please, let me know.

If so, then I think we have to ask for help in the Classpath mailing list,
because I really got no clue :-)


In the mean time, I'm studying the JCHEVM source code, in order to 
figure out:


 1. JCHEVM' OS dependancies
 2. the way JCHEVM access the Classpath library

The study would much easies if I could use the debugger, and I think I'm 
gonna

have to set up a Linux machine.


Enrico

[jira] Assigned: (HARMONY-63) java.text.MessageFormat.parse(String): incorrect size of Object array parsed from the string

[Tim Ellison (JIRA)]

 [ http://issues.apache.org/jira/browse/HARMONY-63?page=all ]

Tim Ellison reassigned HARMONY-63:
--

Assign To: Tim Ellison

 java.text.MessageFormat.parse(String): incorrect size of Object array parsed 
 from the string
 

  Key: HARMONY-63
  URL: http://issues.apache.org/jira/browse/HARMONY-63
  Project: Harmony
 Type: Bug
   Components: Classlib
 Reporter: tatyana doubtsova
 Assignee: Tim Ellison
  Attachments: MessageFormat_patch.txt

 Problem details:
 Method java.text.MessageFormat.parse(String) returns the array of 10 elements 
 when parsing string 1,00,00' using pattern {0,number,#,}. It should 
 return array of 1 element.
 Code for reproducing Test.java:
 import java.text.MessageFormat;
 import java.util.Locale;
 public class Test {
 public static void main(String[] args) {
 try {
 MessageFormat mf = new MessageFormat({0,number,#,}, 
 Locale.US);
 Object[] res = mf.parse(1,00,00);
 System.out.println(result's length:  + res.length);
   for (int i = 0; i  res.length; i++) {
 System.out.println(result is:  + res[0]);
 }
 } catch (Exception e) {
 e.printStackTrace();
 }
 }
 }
 Steps to Reproduce:
 1. Build Harmony (check-out on 2006-01-30) j2se subset as described in 
 README.txt.
 2. Compile Test.java using BEA 1.4 javac
  javac -d . Test.java
 3. Run java using compatible VM (J9)
  java -showversion Test
 Output:
 java version 1.4.2 (subset)
 (c) Copyright 1991, 2005 The Apache Software Foundation or its licensors, as 
 applicable.
 result's length: 10
 result is: 1
 result is: 1
 result is: 1
 result is: 1
 result is: 1
 result is: 1
 result is: 1
 result is: 1
 result is: 1
 result is: 1
 Output on BEA 1.4.2 to compare with:
 result's length: 1
 result is: 1
 Suggested junit test case:
 package org.apache.harmony.tests.java.text;
 import java.text.MessageFormat;
 import java.util.Locale;
 import junit.framework.TestCase;
 public class MessageFormatTest extends TestCase {
 public static void main(String[] args) {
 junit.textui.TestRunner.run(MessageFormatTest.class);
}
 public void test_parse() {
 try {
 MessageFormat mf = new MessageFormat({0,number,#,}, 
 Locale.US);
 Object[] res = mf.parse(1,00,00);
 assertEquals(Assert 0: incorrect size of parsed data , 1, 
 res.length);
 } catch (Exception e) {
   fail(Assert 0: Unexpected exception  + e);
 
 }
 }
 }

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

Re: [jira] Commented: (HARMONY-64) java.nio.charset.Charset.forName(String name) does not throw UnsupportedCharsetException if valid name starts with x-

[Richard Liang]

Hello Tim,

Sorry for my carelessness :-) The icu4jni's latest code is the CVS 
HEAD checked out on Feb. 16, 2006. There is no new icu4jni release since 
version 3.4.


Richard Liang
China Software Development Lab, IBM



Tim Ellison (JIRA) wrote:
[ http://issues.apache.org/jira/browse/HARMONY-64?page=comments#action_12366796 ] 


Tim Ellison commented on HARMONY-64:


Richard,

When you say icu4jni's latest code can you be more specific?  Was this HEAD 
or a release ... ?
We need to know exactly what it contains before deciding whether to use it.

Thanks,
Tim

  

java.nio.charset.Charset.forName(String name) does not throw UnsupportedCharsetException 
if valid name starts with x-
---

 Key: HARMONY-64
 URL: http://issues.apache.org/jira/browse/HARMONY-64
 Project: Harmony
Type: Bug
  Components: Classlib
Reporter: Svetlana Samoilenko
Assignee: Tim Ellison
 Attachments: ICUInterface34.dll, libICUInterface34.so

According to j2se 1.4.2 specification for Charset forName(String charsetName)  the method must throw 
UnsupportedCharsetException if no support for the named charset is available in this instance of the Java virtual 
machine. The method  does not throw exception if a unsupported name started with x-. For example, the 
method throws an exception for not supported name xyz, but does not for x-yz.
Code to reproduce: 
import java.nio.charset.*; 
public class test2 { 
public static void main (String[] args) {

try{
Charset ch=Charset.forName(x-yz);
System.out.println(***BAD. UnsupportedCharsetException must be thrown instead of creating +ch); 
} catch (UnsupportedCharsetException e) {  
System.out.println(***OK. Expected UnsupportedCharsetException  + e); 
}
} 
}
Steps to Reproduce: 
1. Build Harmony (check-out on 2006-01-30) j2se subset as described in README.txt. 
2. Compile test2.java using BEA 1.4 javac 

javac -d . test2.java 
  
3. Run java using compatible VM (J9) 

java -showversion test2 
  
Output: 
C:\tmpC:\jrockit-j2sdk1.4.2_04\bin\java.exe -showversion test2 
java version 1.4.2_04 
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_04-b05) 
BEA WebLogic JRockit(TM) 1.4.2_04 JVM (build ari-31788-20040616-1132-win-ia32, Native Threads, GC strategy: parallel) 
***OK. Expected UnsupportedCharsetException java.nio.charset.UnsupportedCharsetException: x-yz
C:\tmpC:\harmony\trunk\deploy\jre\bin\java -showversion test2 
(c) Copyright 1991, 2005 The Apache Software Foundation or its licensors, as applicable. 
***BAD. UnsupportedCharsetException must be thrown instead of creating Charset[x-yz]

Suggested junit test case:
 CharsetTest.java - 
import java.nio.charset.*; 
import junit.framework.*; 
public class CharsetTest extends TestCase { 
public static void main(String[] args) { 
junit.textui.TestRunner.run(CharsetTest.class); 
} 
public void test_forName() { 
try {

Charset ch=Charset.forName(x-yz);
fail(Assert 0: UnsupportedCharsetException must be thrown instead of creating:  + ch); 
} catch (UnsupportedCharsetException e) {

}
   } 
}



  

[jira] Assigned: (HARMONY-65) java.text.MessageFormat.applyPattern(String pattern) and two MessageFormat constructors fail to detect unmatched braces in the pattern

[Tim Ellison (JIRA)]

 [ http://issues.apache.org/jira/browse/HARMONY-65?page=all ]

Tim Ellison reassigned HARMONY-65:
--

Assign To: Tim Ellison

 java.text.MessageFormat.applyPattern(String pattern) and two MessageFormat 
 constructors fail to detect unmatched braces in the pattern
 --

  Key: HARMONY-65
  URL: http://issues.apache.org/jira/browse/HARMONY-65
  Project: Harmony
 Type: Bug
   Components: Classlib
 Reporter: tatyana doubtsova
 Assignee: Tim Ellison


 Problem details:
 According to j2se 1.4.2 constructors MessageFormat(String pattern),  
 MessageFormat(String pattern, Locale) and method applyPattern(String pattern) 
 should throw IllegalArgumantException, if the pattern is invalid. Harmony 
 implementation doesn't throw IAE, when there are unmatched braces in the 
 pattern
 Code for reproducing Test.java:
 import java.text.*;
 import java.util.Locale;
 public class Test {
 public static void main(String[] args) throws Exception {
   MessageFormat mf = new MessageFormat({0,number,integer});
   String badpattern = {0,number,#;
   try{
   mf.applyPattern(badpattern);
   System.out.println(pattern =  + mf.toPattern());  
   System.out.println(applyPattern(String) FAILED to detect 
 invalid pattern);
   } catch (IllegalArgumentException e) {
   System.out.println(e.getMessage());
   System.out.println(applyPattern(String) PASSED);
   System.out.println(e.getMessage());
   }
   try {
   mf = new MessageFormat({0,number,integer);
   System.out.println(pattern =  + mf.toPattern());  
   System.out.println(MessageFormat(String) FAILED to detect 
 invalid pattern);
   } catch (IllegalArgumentException e) {
   System.out.println(e.getMessage());
   System.out.println(MessageFormat(String) PASSED);
   }
   try {
   mf = new MessageFormat({0,number,integer, Locale.US);
   System.out.println(pattern =  + mf.toPattern());  
   System.out.println(MessageFormat(String, Locale) FAILED to 
 detect invalid pattern);
   } catch (IllegalArgumentException e) {
   System.out.println(e.getMessage());
   System.out.println(MessageFormat(String, Locale) PASSED);
   }
 }
 }
 Steps to Reproduce:
 1. Build Harmony (check-out on 2006-01-30) j2se subset as described in 
 README.txt.
 2. Compile Test.java using BEA 1.4 javac
  javac -d . Test.java
 3. Run java using compatible VM (J9)
  java -showversion Test
 Output:
 java version 1.4.2 (subset)
 (c) Copyright 1991, 2005 The Apache Software Foundation or its licensors, as 
 applicable.
 pattern = {0,number,#}
 applyPattern(String) FAILED to detect invalid pattern
 pattern = {0,number,integer#}
 MessageFormat(String) FAILED to detect invalid pattern
 pattern = {0,number,integer#}
 MessageFormat(String, Locale) FAILED to detect invalid pattern
 Output on BEA 1.4.2 to compare with:
 Unmatched braces in the pattern.
 applyPattern(String) PASSED
 Unmatched braces in the pattern.
 Unmatched braces in the pattern.
 MessageFormat(String) PASSED
 Unmatched braces in the pattern.
 MessageFormat(String, Locale) PASSED
 Suggested junit test case:
 package org.apache.harmony.tests.java.text;
 import java.text.MessageFormat;
 import java.util.Locale;
 import junit.framework.TestCase;
 public class MessageFormatTest extends TestCase {
 public static void main(String[] args) {
   junit.textui.TestRunner.run(MessageFormatTest.class);
 }
 public void test_MessageFormatString() {  
   try {
   MessageFormat mf = new MessageFormat({0,number,integer);
   fail(Assert 0: Failed to detect unmatched brackets.); 
 
   } catch (IllegalArgumentException e) {
   }
 }
 
 public void test_MessageFormatStringLocale() {
   try {
   MessageFormat mf = new MessageFormat({0,number,integer, 
 Locale.US);
   fail(Assert 0: Failed to detect unmatched brackets.); 
 
   } catch (IllegalArgumentException e) {
   }   
 }
 public void test_applyPatternString() {
   MessageFormat mf = new MessageFormat({0,number,integer});
   String badpattern = {0,number,#;
   try{
   mf.applyPattern(badpattern);
   fail(Assert 0: Failed to detect unmatched brackets.); 
 
   } catch (IllegalArgumentException 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 

Re: [jira] Commented: (HARMONY-68) java.nio.charset.Charset.isSupported(String charsetName) does not throw IllegalCharsetNameException for spoiled standard sharset name

[Richard Liang]

Hello Tim,

I think this is caused by different understanding of the java spec:

A charset name **must** begin with either a letter or a digit. The empty 
string is not a legal charset name


What do think the implication of must here? :-)

Richard Liang
China Software Development Lab, IBM



Tim Ellison (JIRA) wrote:
[ http://issues.apache.org/jira/browse/HARMONY-68?page=comments#action_12366784 ] 


Tim Ellison commented on HARMONY-68:


The test looks invalid to me.  You shoud only expect an 
java.nio.charset.IllegalCharsetNameException if the name itself contains 
disallowed characters, and both underscore and dash are permitted.

The code 
Charset.isSupported(-UTF-8)


should return false, not throw an exception.

  

java.nio.charset.Charset.isSupported(String charsetName) does not throw 
IllegalCharsetNameException for spoiled standard sharset name
-

 Key: HARMONY-68
 URL: http://issues.apache.org/jira/browse/HARMONY-68
 Project: Harmony
Type: Bug
  Components: Classlib
Reporter: Svetlana Samoilenko
 Attachments: charset_patch.txt

According to j2se 1.4.2 specification for Charset.isSupported(String charsetName)  the method must throw IllegalCharsetNameException  if the given charset name is illegal . 
Legal charset name must begin with either a letter or a digit. 
The test listed below shows that there is no the exception  if to insert - or _ symbols before standard sharset name, for example -UTF-8 or _US-ASCII.

Moreover the method returns true in this case.
BEA also does not throw the exception but returns false.
Code to reproduce: 
import java.nio.charset.*; 
 
public class test2 { 
public static void main (String[] args) {
// string starts neither a letter nor a digit 
boolean sup=false; 
try{

 sup=Charset.isSupported(-UTF-8);
 System.out.println(***BAD. should be exception; sup=+sup); 
 sup=Charset.isSupported(_US-ASCII);
 System.out.println(***BAD. should be exception; sup=+sup); 
} catch (IllegalCharsetNameException e) {  
System.out.println(***OK. Expected IllegalCharsetNameException  + e); 
}   
} 
} 
Steps to Reproduce: 
1. Build Harmony (check-out on 2006-01-30) j2se subset as described in README.txt. 
2. Compile test2.java using BEA 1.4 javac 

javac -d . test2.java 
  
3. Run java using compatible VM (J9) 

java -showversion test2 
  
Output: 
C:\tmpC:\jrockit-j2sdk1.4.2_04\bin\java.exe -showversion test2 
java version 1.4.2_04 
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_04-b05) 
BEA WebLogic JRockit(TM) 1.4.2_04 JVM (build ari-31788-20040616-1132-win-ia32, Native Threads, GC strategy: parallel) 
***BAD. should be exception; sup=false

***BAD. should be exception; sup=false
C:\tmpC:\harmony\trunk\deploy\jre\bin\java -showversion test2 
(c) Copyright 1991, 2005 The Apache Software Foundation or its licensors, as applicable. 
***BAD. should be exception; sup=true

***BAD. should be exception; sup=true
Suggested junit test case:
 CharserTest.java - 
import java.nio.charset.*; 
import junit.framework.*; 
public class CharsetTest extends TestCase { 
public static void main(String[] args) { 
junit.textui.TestRunner.run(CharsetTest.class); 
} 
public void test_isSupported() { 
  boolean sup=false; 
// string starts neither a letter nor a digit 
try{

sup=Charset.isSupported(-UTF-8);
fail(***BAD. should be exception IllegalCharsetNameException); 
} catch (IllegalCharsetNameException e) {  //expected

}
// string starts neither a letter nor a digit 
try{

 sup=Charset.isSupported(_US-ASCII);
 fail(***BAD. should be exception IllegalCharsetNameException);  
} catch (IllegalCharsetNameException e) {  //expected

}
   } 
}



  

Re: Platform dependent code placement (was: Re: repo layout again)

[Andrey Chernyshev]

  src\main\native\win\foo_ia32.cpp
  - file is applicable only for  Windows / IA32;

 why has the ARCH flipped onto the file name?  why not win_ia32 ?

Well, let's see - if I have a file which is shared between Windows and
Linux, but it is IA32 specific, then I'll have to duplicate it in
win_ia32 and linux_ia32 dirs. It means having both ARCH and OS in a
file name isn't always convenient.

Another case, if I have only one file in my component which is
IA32-specific, it could be more convenient just to rename it like
foo.c - foo_ia32.c and keep it at the same location, rather than move
to some other directory. One sort of problems coming here is that
every additional directory may need to be registered appropriately as
a source search path in development / debugging tools (you'd face this
if you try to debug with MSVC, for example). I just thought that
giving a freedom to choose between naming files or directories will
help people to work in the most convenient way.


  src\main\native\foo_ia32_em64t.cpp
  - file can be compiled for whatever OS on either IA32 or EM64T
  architecture, but nothing else.

 I agree with the approach, but left wondering why it is not something like:
   src\main\native\
   common\
   unix\
   windows\
   zos\
   solaris\
   solaris_x86\
   solaris_sparc\
   windows_ifp\

 i.e. a taxonomy covering families of code (common, unix-like,
 windows-like) and increasingly specific discriminators.

Well, this directory structure does fit to the scheme I proposed, it
is a particular case of it.  Some people probably will want also to
play with the file names within a single directory in the same style: 
foo_solaris.c, foo_solaris_sparc.c, ...
I guess if  a component contains only 3 platform dependent c files,
someone would be frustrated to create 3 different directories for
them.


  The formal file selection rule may look like:
 
  (1) File is applicable for the given OS value if its pathname contains 
  regexp
  [\W_]${OS}[\W_], or pathname doesn't contain any OS value;
 
  (2) File is applicable for the given ARCH value if its pathname contains 
  regexp
  [\W_]${ARCH}[\W_], or pathname doesn't contain any ARCH value;
 
  (3) File is selected for a compilation if it satisfies both (1) and
  (2) criteria.

 If we restrict the OS and ARCH identifiers to directories then it will
 allow us to use the gmake VPATH functionality to select the right file,
 so compiling on solaris x86 will have a
 VPATH='solaris_x86:solaris:unix:common' and so on.

I see. Possibly vpath (small letters) could address the filenames?
Perhaps something like this should work:
vpath %solaris%.c
vpath %.c  soalris:unix:common

 I like the idea -- if we agree to use gmake throughout then I think we
 get this functionality 'for free'.

I guess the same could be done relatively easy for Ant as well, with
help of filesets and containsregex selectors.

 Using the names consistently will definitely help, but choosing whether
 to create a separate copy of the file in a platform-specific
 sub-directory, or to use #define's within a file in a shared-family
 sub-directory will likely come down to a case by case decision.  For
 example, 32-bit vs. 64-bit code may be conveniently #ifdef'ed in some .c
 files, but a .h file that defines pointer types etc. may need different
 versions of the entire file to keep things readable.

Yes, I agree. This is why I suggest to keep both selection mechanisms
- sometimes #define is more efficient, and sometimes dir/filename is
much more clear.


  Finally, I'd suggest that the platform dependent code can be organized
  in 3 different ways:
 
  (1) Explicitly, via defining the appropriate file list. For example,
  Ant xml file may choose either one or another fileset, depending on
  the current OS and ARCH property values. This approach is most
  convenient, for example,  whenever a third-party code is compiled or
  the file names could not be changed for some reason.

 Ant ?!  ;-)  or platform-specific makefile #includes?

Let's consider both for now :)


 There will be files that it makes sense to share for sure (like vmi.h
 and jni.h etc.) but they should be stable-API types that can be
 refreshed across the boundary as required if necessary.

Agreed. I think it would be great if  we can keep our inter-component
interfaces (like vmi.h) platform independent.


Thank you,
Andrey Chernyshev
Intel Middleware Products Division



  Hence, the most efficient (in terms of code
  sharing and readability) code placement would require a maximum
  flexibility, though preserving some well-defined rules. The scheme
  based on file dir/name matching seems to be flexible enough.
 
  How does the above proposal sound?

 Cool, perhaps we can discuss if it should be gmake + vpath or ant.

 Thanks for resurrecting this thread.

 Regards,
 Tim


  Maybe in some components we 

Re: I welcome J2SE 6's faster-splash.... re: Java speed-up

[Stefano Mazzocchi]

Geir Magnusson Jr wrote:
This can't be a Java issue - it must be the 
design-by-committee-for-all-platforms-ever-to-be problem...


I would love to see a good sound API in the style of SWT.


It's called quicktime for java and has been there for years :-)

--
Stefano.

Re: [classlib] Snapshot build 378478 available

[Stefano Mazzocchi]

Tim Ellison wrote:

A new class library snapshot build is available on the Harmony binary
downloads page:

http://cvs.apache.org/dist/incubator/harmony/snapshots/

This is the state of the classlib code at repository revision 378478,
and is made available as a convenience for those who do not have the
required tool chain to build the code themselves.  There are different
downloads for windows and linux:

   harmony-classlib-r378478-linux-x86-snapshot.tgz
   harmony-classlib-r378478-win-x86-snapshot.zip

Details of how to rebuild these binaries from source and how to obtain a
compatible VM to run the code are given here:

http://incubator.apache.org/harmony/subcomponents/classlibrary/build_classlib.html

There are a number of bug fixes and enhancements in this new snapshot.
Please download it and try it, and if there are any problems send a note
to the dev list.

Thanks to everyone who has contributed.


I more and more think it's time to make gump chew on this too bad I 
have *zero* time these days :-/


Leo?

--
Stefano.

[jira] Resolved: (HARMONY-65) java.text.MessageFormat.applyPattern(String pattern) and two MessageFormat constructors fail to detect unmatched braces in the pattern

[Tim Ellison (JIRA)]

 [ http://issues.apache.org/jira/browse/HARMONY-65?page=all ]
 
Tim Ellison resolved HARMONY-65:


Resolution: Fixed

Tatyana,

Fixed in TEXT module in java.text.Format and java.text.MessageFormat at repo 
revision 378567.

Please check that this fully resolves your problem.

 java.text.MessageFormat.applyPattern(String pattern) and two MessageFormat 
 constructors fail to detect unmatched braces in the pattern
 --

  Key: HARMONY-65
  URL: http://issues.apache.org/jira/browse/HARMONY-65
  Project: Harmony
 Type: Bug
   Components: Classlib
 Reporter: tatyana doubtsova
 Assignee: Tim Ellison


 Problem details:
 According to j2se 1.4.2 constructors MessageFormat(String pattern),  
 MessageFormat(String pattern, Locale) and method applyPattern(String pattern) 
 should throw IllegalArgumantException, if the pattern is invalid. Harmony 
 implementation doesn't throw IAE, when there are unmatched braces in the 
 pattern
 Code for reproducing Test.java:
 import java.text.*;
 import java.util.Locale;
 public class Test {
 public static void main(String[] args) throws Exception {
   MessageFormat mf = new MessageFormat({0,number,integer});
   String badpattern = {0,number,#;
   try{
   mf.applyPattern(badpattern);
   System.out.println(pattern =  + mf.toPattern());  
   System.out.println(applyPattern(String) FAILED to detect 
 invalid pattern);
   } catch (IllegalArgumentException e) {
   System.out.println(e.getMessage());
   System.out.println(applyPattern(String) PASSED);
   System.out.println(e.getMessage());
   }
   try {
   mf = new MessageFormat({0,number,integer);
   System.out.println(pattern =  + mf.toPattern());  
   System.out.println(MessageFormat(String) FAILED to detect 
 invalid pattern);
   } catch (IllegalArgumentException e) {
   System.out.println(e.getMessage());
   System.out.println(MessageFormat(String) PASSED);
   }
   try {
   mf = new MessageFormat({0,number,integer, Locale.US);
   System.out.println(pattern =  + mf.toPattern());  
   System.out.println(MessageFormat(String, Locale) FAILED to 
 detect invalid pattern);
   } catch (IllegalArgumentException e) {
   System.out.println(e.getMessage());
   System.out.println(MessageFormat(String, Locale) PASSED);
   }
 }
 }
 Steps to Reproduce:
 1. Build Harmony (check-out on 2006-01-30) j2se subset as described in 
 README.txt.
 2. Compile Test.java using BEA 1.4 javac
  javac -d . Test.java
 3. Run java using compatible VM (J9)
  java -showversion Test
 Output:
 java version 1.4.2 (subset)
 (c) Copyright 1991, 2005 The Apache Software Foundation or its licensors, as 
 applicable.
 pattern = {0,number,#}
 applyPattern(String) FAILED to detect invalid pattern
 pattern = {0,number,integer#}
 MessageFormat(String) FAILED to detect invalid pattern
 pattern = {0,number,integer#}
 MessageFormat(String, Locale) FAILED to detect invalid pattern
 Output on BEA 1.4.2 to compare with:
 Unmatched braces in the pattern.
 applyPattern(String) PASSED
 Unmatched braces in the pattern.
 Unmatched braces in the pattern.
 MessageFormat(String) PASSED
 Unmatched braces in the pattern.
 MessageFormat(String, Locale) PASSED
 Suggested junit test case:
 package org.apache.harmony.tests.java.text;
 import java.text.MessageFormat;
 import java.util.Locale;
 import junit.framework.TestCase;
 public class MessageFormatTest extends TestCase {
 public static void main(String[] args) {
   junit.textui.TestRunner.run(MessageFormatTest.class);
 }
 public void test_MessageFormatString() {  
   try {
   MessageFormat mf = new MessageFormat({0,number,integer);
   fail(Assert 0: Failed to detect unmatched brackets.); 
 
   } catch (IllegalArgumentException e) {
   }
 }
 
 public void test_MessageFormatStringLocale() {
   try {
   MessageFormat mf = new MessageFormat({0,number,integer, 
 Locale.US);
   fail(Assert 0: Failed to detect unmatched brackets.); 
 
   } catch (IllegalArgumentException e) {
   }   
 }
 public void test_applyPatternString() {
   MessageFormat mf = new MessageFormat({0,number,integer});
   String badpattern = {0,number,#;
   try{
   mf.applyPattern(badpattern);
   fail(Assert 0: Failed to detect unmatched brackets.); 
 
   } catch (IllegalArgumentException e) {
   }
 }

 }

-- 
This message is automatically generated by JIRA.
-

Re: Platform dependent code placement (was: Re: repo layout again)

[Andrey Chernyshev]

 The idea is good, however I think including both the OS and arch in the
 directory name is preferable.
 It is just as simple a convention, gives the coder an at-a-glance view
 of which OS/arch's have platform specific code associated with them
 and keeps the actual source filenames consistent across platforms.

 Was there a particular reason for attaching the architecture to the
 filename and not the directory Andrey?

I think there is no particular reason except just a convenience. 
People may not wish to create extra directory and go there each time
because of a few platform-dependent files. Also, as I mentioned in my
previous message, every extra source directory may additionally
complicate the setup of debugging tools and IDE's.

 I agree that is a perfect scenario to use VPATH for. I think this would
 probably be a simpler solution
 than using ant (as suggested later) and also would not require you to
 have a JVM to build the native code.

We have a lots of Java code in a source base, right?:) Therefore one
will need a JVM anyways to be able to build something runnable.

 This is a tricky one. I think in most cases the difference between
 32/64bit code should be minor and
 mostly confined to header defines as Tim suggests. For this ifdef's will

Let's don't forget about the different OS'es and architectures. For
example, I'd expect significant difference in implementations for AWT
on Win/X11 and JIT compiler on IA32/Sparc/IPF. The whole design of the
code could be different, not just implementations of certain functions
or classes. Using #defines only could be almost nightmare in this
case...

 be sufficient. I would simply suggest
 that we adopt a policy of always marking all #else and #endif's clearly
 to indicate which condition
 they relate to.
 However, there may be instances where using ifdef's obfuscates the code.
 I think most of the time this
 will be a judgement call on the part of the coder - if you look at a
 piece of code and cannot tell what
 the preprocessor is going to give you on a particular platform, you're
 probably looking at a candidate
 for code separation.

I agree, this seems to be a good criteria for choosing between defines
and dir/file names.


Thank you,
Andrey Chernyshev
Intel Middleware Products Division


 
  Finally, I'd suggest that the platform dependent code can be organized
  in 3 different ways:
 
  (1) Explicitly, via defining the appropriate file list. For example,
  Ant xml file may choose either one or another fileset, depending on
  the current OS and ARCH property values. This approach is most
  convenient, for example,  whenever a third-party code is compiled or
  the file names could not be changed for some reason.
 
 
  Ant ?!  ;-)  or platform-specific makefile #includes?
 
 
  (2) Via the file path naming convention. This is the preferred
  approach and works well whenever distinctive files for different
  platforms can be identified.
 
 
  yep (modulo discussion of filenames vs. dir names to enable vpath)
 
 
  (3) By means of the preprocessor directives. This could be convenient
  if only few lines of code need to vary across the platforms. However,
  preprocessor directives would make the code less readable, hence this
  should be used with care.
 
  In terms of building process, it means that the code has to pass all 3
  stages of filtering before it is selected for the compilation.
 
 
  I like it.  Let's just discuss what tools do the selection -- but I
  agree with the approach.
 
 
  The point is that components at Harmony could be very different,
  especially if we take into account that they may belong both to Class
  Libraries and VM world.
 
 
  There will be files that it makes sense to share for sure (like vmi.h
  and jni.h etc.) but they should be stable-API types that can be
  refreshed across the boundary as required if necessary.
 
 
  Hence, the most efficient (in terms of code
  sharing and readability) code placement would require a maximum
  flexibility, though preserving some well-defined rules. The scheme
  based on file dir/name matching seems to be flexible enough.
 
  How does the above proposal sound?
 
 
 
 Sounds good :) It makes a lot of sense to organise the code in a way
 that promotes reuse across platforms.
 +1 from me


 --
 Oliver Deakin
 IBM United Kingdom Limited



  Cool, perhaps we can discuss if it should be gmake + vpath or ant.
 
  Thanks for resurrecting this thread.
 
  Regards,
  Tim
 
 
 
  Maybe in some components we would want to include a window manager
  family too, though let's cross that bridge...
 
  I had a quick hunt round for a recognized standard or convention for OS
  and CPU family names, but it seems there are enough subtle differences
  around that we should just define them for ourselves.
 
 
  My VM's config script maintains CPU type, OS name, and word size as three
  independent values.  These are combined in various ways in the source code
  and support scripts depending on the 

Re: compiling JCHEVM with GCC/Cygwin

[snowdosker]

Hello, Enrico



are you saying that, even though the permissions of libjavanio.dll.a 
are -r-xr-xr-x,

you got the same message? Please, let me know.


Yes,  I just set all x  rights /usr/local/classpath/lib/classpath/
on all files in  and up directory tree  (on winXP logged with full admin 
rights)


$ ls -l /usr/local/classpath/lib/classpath/

-rwxr-xr-x 1 ivan None77520 Feb 16 01:17 cygjavaio-0.dll
-rwxr-xr-x 1 ivan None   209670 Feb 16 01:17 cygjavalang-0.dll
-rwxr-xr-x 1 ivan None36069 Feb 16 01:17 cygjavalangreflect-0.dll
-rwxr-xr-x 1 ivan None   103623 Feb 16 01:18 cygjavanet-0.dll
-rwxr-xr-x 1 ivan None   121948 Feb 16 01:18 cygjavanio-0.dll
-rwxr-xr-x 1 ivan None42354 Feb 16 01:18 cygjavautil-0.dll
-rwxr-xr-x 1 ivan None 11183676 Feb 16 01:18 libgtkpeer.a
-rwxr-xr-x 1 ivan None 1345 Feb 16 01:18 libgtkpeer.la
-rwxr-xr-x 1 ivan None25836 Feb 16 01:17 libjavaio.dll.a
-rwxr-xr-x 1 ivan None  802 Feb 16 01:17 libjavaio.la
-rwxr-xr-x 1 ivan None67398 Feb 16 01:17 libjavalang.dll.a
-rwxr-xr-x 1 ivan None  810 Feb 16 01:17 libjavalang.la
-rwxr-xr-x 1 ivan None 1688 Feb 16 01:17 libjavalangreflect.dll.a
-rwxr-xr-x 1 ivan None  838 Feb 16 01:17 libjavalangreflect.la
-rwxr-xr-x 1 ivan None38220 Feb 16 01:18 libjavanet.dll.a
-rwxr-xr-x 1 ivan None  806 Feb 16 01:18 libjavanet.la
-rwxr-xr-x 1 ivan None38852 Feb 16 01:18 libjavanio.dll.a
-rwxr-xr-x 1 ivan None  827 Feb 16 01:18 libjavanio.la
-rwxr-xr-x 1 ivan None 1632 Feb 16 01:18 libjavautil.dll.a
-rwxr-xr-x 1 ivan None  810 Feb 16 01:18 libjavautil.la
-rwxr-xr-x 1 ivan None52886 Feb 16 01:19 libjawtgnu.a
-rwxr-xr-x 1 ivan None 1394 Feb 16 01:19 libjawtgnu.la

Still have  the same  exception

java.lang.UnsatisfiedLinkError: failed to open native library 
`/usr/local/classpath/lib/classpath/libjavanio.dll.a': Per

mission denied
   at java.lang.VMThrowable.fillInStackTrace(Native Method)
   at java.lang.Throwable.fillInStackTrace(Throwable.java:498)
   at java.lang.Throwable.init(Throwable.java:159)
   at java.lang.Error.init(Error.java:81)
   at java.lang.LinkageError.init(LinkageError.java:72)
   at 
java.lang.UnsatisfiedLinkError.init(UnsatisfiedLinkError.java:72)

   at java.lang.VMRuntime.nativeLoad(Native Method)
   at java.lang.Runtime.loadLib(Runtime.java:698)
   at java.lang.Runtime.loadLibrary(Runtime.java:760)
   at java.lang.System.loadLibrary(System.java:512)
   at 
gnu.java.nio.channels.FileChannelImpl.clinit(FileChannelImpl.java:86)

   at java.io.FileDescriptor.clinit(FileDescriptor.java:63)
   at java.lang.VMSystem.makeStandardInputStream(VMSystem.java)
   at java.lang.System.clinit(System.java)
   at java.lang.Math.clinit(Math.java:70)
   at java.util.WeakHashMap.hash(WeakHashMap.java)
   at java.util.WeakHashMap.internalGet(WeakHashMap.java:655)
   at java.util.WeakHashMap.get(WeakHashMap.java:763)
   at java.lang.VMString.intern(VMString.java:77)
   at java.lang.String.intern(String.java)
   at java.lang.String.clinit(String.java)
jc: failed to create VM

Any thougths?
May be the problem is in *.dll.a extension so under win it's not treated 
as executable?

Re: Platform dependent code placement (was: Re: repo layout again)

[Tim Ellison]

Andrey Chernyshev wrote:
 src\main\native\win\foo_ia32.cpp
 - file is applicable only for  Windows / IA32;
 why has the ARCH flipped onto the file name?  why not win_ia32 ?
 
 Well, let's see - if I have a file which is shared between Windows and
 Linux, but it is IA32 specific, then I'll have to duplicate it in
 win_ia32 and linux_ia32 dirs. It means having both ARCH and OS in a
 file name isn't always convenient.
 
 Another case, if I have only one file in my component which is
 IA32-specific, it could be more convenient just to rename it like
 foo.c - foo_ia32.c and keep it at the same location, rather than move
 to some other directory. One sort of problems coming here is that
 every additional directory may need to be registered appropriately as
 a source search path in development / debugging tools (you'd face this
 if you try to debug with MSVC, for example). I just thought that
 giving a freedom to choose between naming files or directories will
 help people to work in the most convenient way.
 
 src\main\native\foo_ia32_em64t.cpp
 - file can be compiled for whatever OS on either IA32 or EM64T
 architecture, but nothing else.
 I agree with the approach, but left wondering why it is not something like:
   src\main\native\
   common\
   unix\
   windows\
   zos\
   solaris\
   solaris_x86\
   solaris_sparc\
   windows_ifp\

 i.e. a taxonomy covering families of code (common, unix-like,
 windows-like) and increasingly specific discriminators.
 
 Well, this directory structure does fit to the scheme I proposed, it
 is a particular case of it.  Some people probably will want also to
 play with the file names within a single directory in the same style: 
 foo_solaris.c, foo_solaris_sparc.c, ...

Ah, I see.  I hadn't appreciated that you can mix-n-match the dir names
and file names encoding.

 I guess if  a component contains only 3 platform dependent c files,
 someone would be frustrated to create 3 different directories for
 them.
 
 The formal file selection rule may look like:

 (1) File is applicable for the given OS value if its pathname contains 
 regexp
 [\W_]${OS}[\W_], or pathname doesn't contain any OS value;

 (2) File is applicable for the given ARCH value if its pathname contains 
 regexp
 [\W_]${ARCH}[\W_], or pathname doesn't contain any ARCH value;

 (3) File is selected for a compilation if it satisfies both (1) and
 (2) criteria.
 If we restrict the OS and ARCH identifiers to directories then it will
 allow us to use the gmake VPATH functionality to select the right file,
 so compiling on solaris x86 will have a
 VPATH='solaris_x86:solaris:unix:common' and so on.
 
 I see. Possibly vpath (small letters) could address the filenames?
 Perhaps something like this should work:
 vpath %solaris%.c
 vpath %.c  soalris:unix:common
 
 I like the idea -- if we agree to use gmake throughout then I think we
 get this functionality 'for free'.
 
 I guess the same could be done relatively easy for Ant as well, with
 help of filesets and containsregex selectors.

do you have any examples (i.e. snippets of a non-trivial Ant script)
that show what it would end up like?  I'm trying to figure out in my own
head whether it would be a few general regex selectors, or a load of
them!  I think you may be do it with just a few, right?

Regards,
Tim

 Using the names consistently will definitely help, but choosing whether
 to create a separate copy of the file in a platform-specific
 sub-directory, or to use #define's within a file in a shared-family
 sub-directory will likely come down to a case by case decision.  For
 example, 32-bit vs. 64-bit code may be conveniently #ifdef'ed in some .c
 files, but a .h file that defines pointer types etc. may need different
 versions of the entire file to keep things readable.
 
 Yes, I agree. This is why I suggest to keep both selection mechanisms
 - sometimes #define is more efficient, and sometimes dir/filename is
 much more clear.
 
 Finally, I'd suggest that the platform dependent code can be organized
 in 3 different ways:

 (1) Explicitly, via defining the appropriate file list. For example,
 Ant xml file may choose either one or another fileset, depending on
 the current OS and ARCH property values. This approach is most
 convenient, for example,  whenever a third-party code is compiled or
 the file names could not be changed for some reason.
 Ant ?!  ;-)  or platform-specific makefile #includes?
 
 Let's consider both for now :)
 
 There will be files that it makes sense to share for sure (like vmi.h
 and jni.h etc.) but they should be stable-API types that can be
 refreshed across the boundary as required if necessary.
 
 Agreed. I think it would be great if  we can keep our inter-component
 interfaces (like vmi.h) platform independent.
 
 
 Thank you,
 Andrey Chernyshev
 Intel Middleware Products Division
 
 
 Hence, the most 

Re: [jira] Commented: (HARMONY-68) java.nio.charset.Charset.isSupported(String charsetName) does not throw IllegalCharsetNameException for spoiled standard sharset name

[Tim Ellison]

Richard Liang wrote:
 Hello Tim,
 
 I think this is caused by different understanding of the java spec:
 
 A charset name **must** begin with either a letter or a digit. The empty
 string is not a legal charset name
 
 What do think the implication of must here? :-)

But the name isn't empty, it is -UTF-8 ?  I must be missing something...

Regards,
Tim


 
 
 Tim Ellison (JIRA) wrote:
 [
 http://issues.apache.org/jira/browse/HARMONY-68?page=comments#action_12366784
 ]
 Tim Ellison commented on HARMONY-68:
 

 The test looks invalid to me.  You shoud only expect an
 java.nio.charset.IllegalCharsetNameException if the name itself
 contains disallowed characters, and both underscore and dash are
 permitted.

 The code Charset.isSupported(-UTF-8)

 should return false, not throw an exception.

  
 java.nio.charset.Charset.isSupported(String charsetName) does not
 throw IllegalCharsetNameException for spoiled standard sharset name
 -


  Key: HARMONY-68
  URL: http://issues.apache.org/jira/browse/HARMONY-68
  Project: Harmony
 Type: Bug
   Components: Classlib
 Reporter: Svetlana Samoilenko
  Attachments: charset_patch.txt

 According to j2se 1.4.2 specification for Charset.isSupported(String
 charsetName)  the method must throw IllegalCharsetNameException  if
 the given charset name is illegal . Legal charset name must begin
 with either a letter or a digit. The test listed below shows that
 there is no the exception  if to insert - or _ symbols before
 standard sharset name, for example -UTF-8 or _US-ASCII.
 Moreover the method returns true in this case.
 BEA also does not throw the exception but returns false.
 Code to reproduce: import java.nio.charset.*;  
 public class test2 { public static void main (String[] args) {
 // string starts neither a letter nor a digit boolean
 sup=false; try{
  sup=Charset.isSupported(-UTF-8);
  System.out.println(***BAD. should be exception;
 sup=+sup);  sup=Charset.isSupported(_US-ASCII);
  System.out.println(***BAD. should be exception;
 sup=+sup); } catch (IllegalCharsetNameException e) { 
 System.out.println(***OK. Expected
 IllegalCharsetNameException  + e); }   } } Steps to
 Reproduce: 1. Build Harmony (check-out on 2006-01-30) j2se subset as
 described in README.txt. 2. Compile test2.java using BEA 1.4 javac
 javac -d . test2.java   
 3. Run java using compatible VM (J9)
 java -showversion test2   
 Output: C:\tmpC:\jrockit-j2sdk1.4.2_04\bin\java.exe -showversion
 test2 java version 1.4.2_04 Java(TM) 2 Runtime Environment,
 Standard Edition (build 1.4.2_04-b05) BEA WebLogic JRockit(TM)
 1.4.2_04 JVM (build ari-31788-20040616-1132-win-ia32, Native Threads,
 GC strategy: parallel) ***BAD. should be exception; sup=false
 ***BAD. should be exception; sup=false
 C:\tmpC:\harmony\trunk\deploy\jre\bin\java -showversion test2 (c)
 Copyright 1991, 2005 The Apache Software Foundation or its licensors,
 as applicable. ***BAD. should be exception; sup=true
 ***BAD. should be exception; sup=true
 Suggested junit test case:
  CharserTest.java
 - import
 java.nio.charset.*; import junit.framework.*; public class
 CharsetTest extends TestCase { public static void main(String[]
 args) { junit.textui.TestRunner.run(CharsetTest.class); }
 public void test_isSupported() {   boolean sup=false;
 // string starts neither a letter nor a digit try{
 sup=Charset.isSupported(-UTF-8);
 fail(***BAD. should be exception
 IllegalCharsetNameException); } catch
 (IllegalCharsetNameException e) {  //expected
 }
 // string starts neither a letter nor a digit try{
  sup=Charset.isSupported(_US-ASCII);
  fail(***BAD. should be exception
 IllegalCharsetNameException);  } catch
 (IllegalCharsetNameException e) {  //expected
 }
} }
 

   
 

-- 

Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.

Re: [jira] Commented: (HARMONY-64) java.nio.charset.Charset.forName(String name) does not throw UnsupportedCharsetException if valid name starts with x-

[Tim Ellison]

Richard Liang wrote:
 Hello Tim,
 
 Sorry for my carelessness :-) The icu4jni's latest code is the CVS
 HEAD checked out on Feb. 16, 2006. There is no new icu4jni release since
 version 3.4.

Not a problem.  So do people think we should take HEAD from ICU4JNI to
fix this problem, or wait for the next ICU release?

Unless this bug is hurting somebody I'm inclined to defer it, since I'm
assuming HEAD is the code du jour, and we probably only want the stable
stuff! (no slur on the good folk at ICU, obviously)

Regards,
Tim

 Tim Ellison (JIRA) wrote:
 [
 http://issues.apache.org/jira/browse/HARMONY-64?page=comments#action_12366796
 ]
 Tim Ellison commented on HARMONY-64:
 

 Richard,

 When you say icu4jni's latest code can you be more specific?  Was
 this HEAD or a release ... ?
 We need to know exactly what it contains before deciding whether to
 use it.

 Thanks,
 Tim

  
 java.nio.charset.Charset.forName(String name) does not throw
 UnsupportedCharsetException if valid name starts with x-
 ---


  Key: HARMONY-64
  URL: http://issues.apache.org/jira/browse/HARMONY-64
  Project: Harmony
 Type: Bug
   Components: Classlib
 Reporter: Svetlana Samoilenko
 Assignee: Tim Ellison
  Attachments: ICUInterface34.dll, libICUInterface34.so

 According to j2se 1.4.2 specification for Charset forName(String
 charsetName)  the method must throw UnsupportedCharsetException if
 no support for the named charset is available in this instance of the
 Java virtual machine. The method  does not throw exception if a
 unsupported name started with x-. For example, the method throws an
 exception for not supported name xyz, but does not for x-yz.
 Code to reproduce: import java.nio.charset.*; public class test2 {
 public static void main (String[] args) {
 try{
 Charset ch=Charset.forName(x-yz);
 System.out.println(***BAD. UnsupportedCharsetException
 must be thrown instead of creating +ch); } catch
 (UnsupportedCharsetException e) { 
 System.out.println(***OK. Expected UnsupportedCharsetException  +
 e); }
 } }
 Steps to Reproduce: 1. Build Harmony (check-out on 2006-01-30) j2se
 subset as described in README.txt. 2. Compile test2.java using BEA
 1.4 javac
 javac -d . test2.java   
 3. Run java using compatible VM (J9)
 java -showversion test2   
 Output: C:\tmpC:\jrockit-j2sdk1.4.2_04\bin\java.exe -showversion
 test2 java version 1.4.2_04 Java(TM) 2 Runtime Environment,
 Standard Edition (build 1.4.2_04-b05) BEA WebLogic JRockit(TM)
 1.4.2_04 JVM (build ari-31788-20040616-1132-win-ia32, Native Threads,
 GC strategy: parallel) ***OK. Expected UnsupportedCharsetException
 java.nio.charset.UnsupportedCharsetException: x-yz
 C:\tmpC:\harmony\trunk\deploy\jre\bin\java -showversion test2 (c)
 Copyright 1991, 2005 The Apache Software Foundation or its licensors,
 as applicable. ***BAD. UnsupportedCharsetException must be thrown
 instead of creating Charset[x-yz]
 Suggested junit test case:
  CharsetTest.java
 - import
 java.nio.charset.*; import junit.framework.*; public class
 CharsetTest extends TestCase { public static void main(String[]
 args) { junit.textui.TestRunner.run(CharsetTest.class); }
 public void test_forName() { try {
 Charset ch=Charset.forName(x-yz);
 fail(Assert 0: UnsupportedCharsetException must be
 thrown instead of creating:  + ch); } catch
 (UnsupportedCharsetException e) {
 }
} }
 

   
 

-- 

Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.

Re: [jira] Commented: (HARMONY-64) java.nio.charset.Charset.forName(String name) does not throw UnsupportedCharsetException if valid name starts with x-

[Tim Ellison]

BTW: I see there is an ICU4J 3.4.2 available now -- we may want to grab
that.

Regards,
Tim

Richard Liang wrote:
 Hello Tim,
 
 Sorry for my carelessness :-) The icu4jni's latest code is the CVS
 HEAD checked out on Feb. 16, 2006. There is no new icu4jni release since
 version 3.4.
 
 Richard Liang
 China Software Development Lab, IBM
 
 
 
 Tim Ellison (JIRA) wrote:
 [
 http://issues.apache.org/jira/browse/HARMONY-64?page=comments#action_12366796
 ]
 Tim Ellison commented on HARMONY-64:
 

 Richard,

 When you say icu4jni's latest code can you be more specific?  Was
 this HEAD or a release ... ?
 We need to know exactly what it contains before deciding whether to
 use it.

 Thanks,
 Tim

  
 java.nio.charset.Charset.forName(String name) does not throw
 UnsupportedCharsetException if valid name starts with x-
 ---


  Key: HARMONY-64
  URL: http://issues.apache.org/jira/browse/HARMONY-64
  Project: Harmony
 Type: Bug
   Components: Classlib
 Reporter: Svetlana Samoilenko
 Assignee: Tim Ellison
  Attachments: ICUInterface34.dll, libICUInterface34.so

 According to j2se 1.4.2 specification for Charset forName(String
 charsetName)  the method must throw UnsupportedCharsetException if
 no support for the named charset is available in this instance of the
 Java virtual machine. The method  does not throw exception if a
 unsupported name started with x-. For example, the method throws an
 exception for not supported name xyz, but does not for x-yz.
 Code to reproduce: import java.nio.charset.*; public class test2 {
 public static void main (String[] args) {
 try{
 Charset ch=Charset.forName(x-yz);
 System.out.println(***BAD. UnsupportedCharsetException
 must be thrown instead of creating +ch); } catch
 (UnsupportedCharsetException e) { 
 System.out.println(***OK. Expected UnsupportedCharsetException  +
 e); }
 } }
 Steps to Reproduce: 1. Build Harmony (check-out on 2006-01-30) j2se
 subset as described in README.txt. 2. Compile test2.java using BEA
 1.4 javac
 javac -d . test2.java   
 3. Run java using compatible VM (J9)
 java -showversion test2   
 Output: C:\tmpC:\jrockit-j2sdk1.4.2_04\bin\java.exe -showversion
 test2 java version 1.4.2_04 Java(TM) 2 Runtime Environment,
 Standard Edition (build 1.4.2_04-b05) BEA WebLogic JRockit(TM)
 1.4.2_04 JVM (build ari-31788-20040616-1132-win-ia32, Native Threads,
 GC strategy: parallel) ***OK. Expected UnsupportedCharsetException
 java.nio.charset.UnsupportedCharsetException: x-yz
 C:\tmpC:\harmony\trunk\deploy\jre\bin\java -showversion test2 (c)
 Copyright 1991, 2005 The Apache Software Foundation or its licensors,
 as applicable. ***BAD. UnsupportedCharsetException must be thrown
 instead of creating Charset[x-yz]
 Suggested junit test case:
  CharsetTest.java
 - import
 java.nio.charset.*; import junit.framework.*; public class
 CharsetTest extends TestCase { public static void main(String[]
 args) { junit.textui.TestRunner.run(CharsetTest.class); }
 public void test_forName() { try {
 Charset ch=Charset.forName(x-yz);
 fail(Assert 0: UnsupportedCharsetException must be
 thrown instead of creating:  + ch); } catch
 (UnsupportedCharsetException e) {
 }
} }
 

   
 

-- 

Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.

Re: compiling JCHEVM with GCC/Cygwin

[Enrico Migliore]

Hi Salikh ,


Do you have cygwin1.dll in the PATH?
 


yes


you may want to use 'depends.exe' or  'dumpbin.exe /dependents' from
Microsoft
SDK or 'objdump --private-headers' from Cygwin distribution to find out
what specific dynamic libraries jc.exe depends on.
 


 Thanks for the suggestion. I'll use them during the weekend.

Enrico

re: I welcome J2SE 6's faster-splash.... re: Java speed-up

[Fernando Cassia]

Stefano,

Are you a Mac user, per chance? Because you sound like one...
See below:

On 2/17/06, Stefano Mazzocchi [EMAIL PROTECTED] wrote:

 Geir Magnusson Jr wrote:
  This can't be a Java issue - it must be the
  design-by-committee-for-all-platforms-ever-to-be problem...
 
  I would love to see a good sound API in the style of SWT.

 It's called quicktime for java and has been there for years :-)
 --
 Stefano.


Oh, that contraption? Last time I looked, it relied on
Quicktime-for-target-OS being available as well.
Try to find a Quicktime for Linux or Quicktime for Solaris

I might as well use jffmpeg which interfaces to FFMPEG, which IS available
for almost every OS on Earth, unlike Steve's closed little toy.

==
SourceForge.net: Project Info - JMF wrapper for
ffmpeghttp://sourceforge.net/projects/jffmpeg/
http://sourceforge.net/projects/jffmpeg/

Very nice, JMF needs a refresher (an understatement) and it is nice to open
source implementations picking up on it (especially since Apple has no idea
what they are doing to QuickTime for Java).
From the site:
This is a Java wrapper for ffmpeg compression library. It exports ffmpeg
codecs functions as a JMF (Java Media Framework) codec. You can use this
codec from JMStudio and then you'll have a video player able to play mpeg1,
h263, mpeg4 (divX), etc. streams.
==
^quoted from http://www.walking-productions.com/slop/000609.html

FC

Re: I welcome J2SE 6's faster-splash.... re: Java speed-up

[Tor-Einar Jarnbjo]

Stefano Mazzocchi schrieb:


It's called quicktime for java and has been there for years :-)


Sure, Quicktime for Java is not that bad, but unfortunately using 
heavyweight native GUI widgets, which are difficult to integrate without 
side effects in a Swing application. If platform dependency is accepted, 
there are also a lot of e.g. ActiveX-bridges allowing ActiveX-enabled 
media components (also GUI or video widgets) to be integrated in a Java 
application.


Tor

Re: I welcome J2SE 6's faster-splash.... re: Java speed-up

[Fernando Cassia]

On 2/17/06, Tor-Einar Jarnbjo [EMAIL PROTECTED] wrote:

 If platform dependency is accepted,
 there are also a lot of e.g. ActiveX-bridges allowing ActiveX-enabled
 media components (also GUI or video widgets) to be integrated in a Java
 application.

 Tor


Which defeats the whole purpose of cross-platform java in the first place.
So why not do it win32 / linux /Gtk then?

FC

Java-ffmpeg wrapper

[Fernando Cassia]

FYI:
http://fobs.sourceforge.net/

http://sourceforge.net/project/showfiles.php?group_id=105646package_id=117443release_id=352645

FOBS is an object oriented wrapper for *ffmpeg* library. Build easily object
oriented applications that work with MultiMedia files in multiplatform
environments.
FOBS are Ffmpeg OBjectS. It is a set of object oriented APIs to deal with
media. It relies in the ffmpeg library, but provides developers with a much
simpler programming interface.
FOBS is currently available in C++.

The Java API is being developed and the current version already includes a
JMF plugin. It has been successfully tested in a range of platforms (Linux,
MacOS X, Win32(MinGW)).

About FFMPEG
 http://ffmpeg.sourceforge.net/index.php

Re: I welcome J2SE 6's faster-splash.... re: Java speed-up

[Tor-Einar Jarnbjo]

Fernando Cassia schrieb:


Which defeats the whole purpose of cross-platform java in the first place.
So why not do it win32 / linux /Gtk then?
 

Because Java as a programming language has other advantages than 
platform independence.


Tor

Re: I welcome J2SE 6's faster-splash.... re: Java speed-up

[Fernando Cassia]

On 2/17/06, Tor-Einar Jarnbjo [EMAIL PROTECTED] wrote:

 Fernando Cassia schrieb:

 Which defeats the whole purpose of cross-platform java in the first
 place.
 So why not do it win32 / linux /Gtk then?
 
 
 Because Java as a programming language has other advantages than
 platform independence.

 Tor


I'm personally not very interested in the programming language advantages.
It's the cross-platform independence of java bytecode that makes it special
and different from others.

Just my $0.02
FC

Re: newbie to project-where to start from

[James Pluck]

Geir Magnusson Jr wrote:
 
 
 James Pluck wrote:
 Just piggybacking on this.  I've been on the mailing list for some
 months now and have downloaded the code and been brwosing through it.
 I'm a reasonably adept programmer but this is a very major project and
 it's a little daunting to know just where to begin.  I'd appreciate
 any suggestions of where I might be best able to contribute my time.
 I'd prefer to work on the actual implementation rather than just
 testing if possible but I'm keen to help out anywhere that might be
 useful.
 
 What would you like to work on?  We clearly need bunches of things,
 including the standard included utilities, so start thinking about an
 area that you would really enjoy to work on

Personally I'm a bit of a Math geek so perhaps the math or bigmath areas
would be a good place for me to start.  I would be keen to talk with
anyone who is already working on this area so that we can minimise
duplication of work.

 (I'd love to see someone get our compiler-launcher done, so we would
 have javac using the eclipse compiler.)

Unfortunately I have very little knowledge and experience in writing
compilers so I would be of limited use here - except perhaps as a beta
tester.

James Pluck

Re: newbie to project-where to start from

[Matt Benson]

--- James Pluck [EMAIL PROTECTED] wrote:
 Geir Magnusson Jr wrote:
[SNIP]
  (I'd love to see someone get our compiler-launcher
 done, so we would
  have javac using the eclipse compiler.)
 
 Unfortunately I have very little knowledge and
 experience in writing
 compilers so I would be of limited use here - except
 perhaps as a beta
 tester.

Know that the current plan is to use Eclipse's JDT
compiler, so a launcher for it, and any assisting
massaging needed to make it behave identically to 1.5
javac, is all that is needed, as I understand it.

-Matt

 
 James Pluck
 


__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: Increasing Java Startup Performance

[Wes Felter]

Stefano Mazzocchi wrote:


http://www.research.ibm.com/people/m/marnold/arnold-welc-rajan.final.pdf

which implements a very interesting trick to speed up java startup 
performance: save the hotspot information in a repository (at JVM shut 
down) so that the JIT doesn't have to wait when it starts until it knows 
what is a hotspot to start compiling it. the performance improvements 
are not likely to change the perception that java is awefully slow to 
start up on the desktop, but it's a clever idea.


I'm surprised there's been so little discussion of the Java Executable 
File Format (JEFF) (unfortunately, the Web site for it seems to have 
disappeared), which should reduce memory usage and cold-start time by 
allowing core classes to be mmap'ed. This would be mostly orthogonal to 
the above paper.


Wes Felter - [EMAIL PROTECTED]

Re: I welcome J2SE 6's faster-splash.... re: Java speed-up

[Stefano Mazzocchi]

Fernando Cassia wrote:

Stefano,

Are you a Mac user, per chance? Because you sound like one...


Do you have a problem with that?

--
Stefano.

Re: I welcome J2SE 6's faster-splash.... re: Java speed-up

[Fernando Cassia]

On 2/17/06, Stefano Mazzocchi [EMAIL PROTECTED] wrote:

 Fernando Cassia wrote:
  Stefano,
 
  Are you a Mac user, per chance? Because you sound like one...

 Do you have a problem with that?

 --
 Stefano.


No, but I figured because you mentioned Quicktime for Java. Which nobody
outside the Mac faithful ever took seriously.

Back when the first version was released, a lot of OS/2 folks -myself
included- had a lot of hope in the product, and some even asked Apple to do
a 100% java version of the codecs and player, that is a TRUE quicktime for
java, not a silly wrapper that just interfaces java apps to it and needs the
native code player to be available on the target platform, but nobody ever
got an official reply (to my knowledge).

Over the years, then, the product went nowhere as it was really a solution
looking for a problem.
FC

RE: [classlib] Snapshot build 378478 available

[Nathan Beyer]

I tried to download this:
http://cvs.apache.org/dist/incubator/harmony/snapshots/harmony-classlib-r378
478-win-x86-snapshot.zip and I was given a 403 Forbidden response. I can
still access the previous version though.

Anyone else have this issue?

-Original Message-
From: Tim Ellison [mailto:[EMAIL PROTECTED] 
Sent: Friday, February 17, 2006 9:01 AM
To: harmony-dev
Subject: [classlib] Snapshot build 378478 available

A new class library snapshot build is available on the Harmony binary
downloads page:

http://cvs.apache.org/dist/incubator/harmony/snapshots/

This is the state of the classlib code at repository revision 378478,
and is made available as a convenience for those who do not have the
required tool chain to build the code themselves.  There are different
downloads for windows and linux:

   harmony-classlib-r378478-linux-x86-snapshot.tgz
   harmony-classlib-r378478-win-x86-snapshot.zip

Details of how to rebuild these binaries from source and how to obtain a
compatible VM to run the code are given here:

http://incubator.apache.org/harmony/subcomponents/classlibrary/build_classli
b.html

There are a number of bug fixes and enhancements in this new snapshot.
Please download it and try it, and if there are any problems send a note
to the dev list.

Thanks to everyone who has contributed.

Regards,
Tim

-- 

Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.

Re: [classlib] Snapshot build 378478 available

[Geir Magnusson Jr]

fixed - thx for pointing it out...

Nathan Beyer wrote:

I tried to download this:
http://cvs.apache.org/dist/incubator/harmony/snapshots/harmony-classlib-r378
478-win-x86-snapshot.zip and I was given a 403 Forbidden response. I can
still access the previous version though.

Anyone else have this issue?

-Original Message-
From: Tim Ellison [mailto:[EMAIL PROTECTED] 
Sent: Friday, February 17, 2006 9:01 AM

To: harmony-dev
Subject: [classlib] Snapshot build 378478 available

A new class library snapshot build is available on the Harmony binary
downloads page:

http://cvs.apache.org/dist/incubator/harmony/snapshots/

This is the state of the classlib code at repository revision 378478,
and is made available as a convenience for those who do not have the
required tool chain to build the code themselves.  There are different
downloads for windows and linux:

   harmony-classlib-r378478-linux-x86-snapshot.tgz
   harmony-classlib-r378478-win-x86-snapshot.zip

Details of how to rebuild these binaries from source and how to obtain a
compatible VM to run the code are given here:

http://incubator.apache.org/harmony/subcomponents/classlibrary/build_classli
b.html

There are a number of bug fixes and enhancements in this new snapshot.
Please download it and try it, and if there are any problems send a note
to the dev list.

Thanks to everyone who has contributed.

Regards,
Tim

Re: newbie to project-where to start from

[Geir Magnusson Jr]

Matt Benson wrote:

--- James Pluck [EMAIL PROTECTED] wrote:

Geir Magnusson Jr wrote:

[SNIP]

(I'd love to see someone get our compiler-launcher

done, so we would

have javac using the eclipse compiler.)

Unfortunately I have very little knowledge and
experience in writing
compilers so I would be of limited use here - except
perhaps as a beta
tester.


Know that the current plan is to use Eclipse's JDT
compiler, so a launcher for it, and any assisting
massaging needed to make it behave identically to 1.5
javac, is all that is needed, as I understand it.


Yep



-Matt


James Pluck




__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com