Re: [jira] Created: (HARMONY-152) Security module native build incorrectly use PATH variable

[Alexey Petrenko]

2006/3/3, Mikhail Loenko <[EMAIL PROTECTED]>:
> 'Path', 'Include', etc are common e.g. for Windows 2000,
Really? Neve heard about this... Is it documented somewhere?

> see also http://ant.apache.org/manual/CoreTasks/property.html
What part of this document you talking about?

--
Alexey A. Petrenko
Intel Middleware Products Division

[jira] Updated: (HARMONY-149) java.nio.charset.Charset.forName(name) return different reference value when requiring the same Charset.

[Richard Liang (JIRA)]

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

Richard Liang updated HARMONY-149:
--

Attachment: Charset_patch_149.txt

Would you please have a try and apply the patch on Charset.java ? Thanks a lot!
To apply patch, simply click "Team"->"Apply patch...".

> java.nio.charset.Charset.forName(name) return different reference value when 
> requiring the same Charset.
> 
>
>  Key: HARMONY-149
>  URL: http://issues.apache.org/jira/browse/HARMONY-149
>  Project: Harmony
> Type: Bug
>   Components: Classlib
> Reporter: Richard Liang
>  Attachments: Charset_patch_149.txt
>
> java.nio.charset.Charset.forName(name) returns different reference value when 
> requiring the same Charset.
> However, RI always returns the same reference for the same Charset, no matter 
> using "alias" or "canonical" name as parameter. 
> RI 5.0 passes the following test case, while Harmony fails.
> === Test case 
>  /*
>* test forName: invoke forName two times with the same canonical name,
>* it should return the same reference.
>*/
>   public void testForName_TwoSameRef1(){
>   Charset cs1 = Charset.forName("UTF-8");
>   Charset cs2 = Charset.forName("UTF-8");
>   assertSame(cs1,cs2);
>   }
>   
>   /*
>* test forName: invoke forName two times for the same Charset using 
> canonical name and alias,
>* it should return the same reference.
>*/
>   public void testForName_TwoSameRef2(){
>   Charset cs1 = Charset.forName("ASCII");
>   Charset cs2 = Charset.forName("US-ASCII");
>   assertSame(cs1,cs2);
>   }

-- 
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

Archive component comparison result between Harmony and JSE 5 spec

[Paulex Yang]

I did some comparison about archive component between Harmony codes and 
JSE 5 spec, and the difference has been raised as JIRA issues just now. 
I will provides patches for them soon :-) .


--
Paulex Yang
China Software Development Lab
IBM

Re: [jira] Commented: (HARMONY-141) Constructors of java.nio.charset.CharsetEncoder do not validate arguments

[Mark Hindess]

Obviously we should encourage submission of patches but the committers
should remember that tthere are non-committers around who are happy to
help get worthwhile contributions in shape!

Perhaps just adding a comment to the JIRI suggesting the submitter
provide a patch or ask for help on the list?

I've been spending a little time fixing up contributions that I think
are worthwhile - mostly patches that have been broken by the recent
shared native code moves that Tim committed.  I'm willing to do this
because I broke them ;-) but mostly because I know it helps reduce the
load on committers and because having your patch broken/delayed can be
discouraging for new contributors.

For me this is a good way to become more familiar with the code base. 
I'm sure that will be true for others joining the project.  I don't
think there is any harm in having plenty of obvious tasks for
potential new contributors.

Our committers shouldn't be slow to ask for help either.  For
instance, a number of the recent large contributions aren't going to
be trivial to integrate in to subversion, but I'm sure there are many
people - at least one anyway! - looking forward to seeing them in
subversion who would be willing to help create patches [0] from
contributions if it helped move them forward.

Regards,
 Mark.

[0] More likely a tar with the new files and a patch to existing
build.xml files.

On 02/03/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote:
> maybe we should reject things not in patch format, as it puts
> unnecessary load on the committers.
>
> Feel free to drop the code into comment or email so that we can discuss,
> but patch is much easier for everyone involved
>
>
> Tim Ellison wrote:
> > p.s.  I accept test cases in patch format too ;-)
> >
> > Regards,
> > Tim
> >
> > Richard Liang (JIRA) wrote:
> >> [ 
> >> http://issues.apache.org/jira/browse/HARMONY-141?page=comments#action_12368097
> >>  ]
> >>
> >> Richard Liang commented on HARMONY-141:
> >> ---
> >>
> >> Here are the test cases which will pass on RI but fail on Harmony.
> >>
> >> public void testConstructorIlegalAverageBytesPerChar() {
> >> try {
> >> Charset cs = Charset.forName("UTF-8"); //$NON-NLS-1$
> >> CharsetEncoder encoder = new 
> >> MockCharsetEncoderForHarmony141(cs, 1.1f, 1);
> >> fail("Should throw IllegalArgumentException."); //$NON-NLS-1$
> >> } catch (IllegalArgumentException e) {
> >> // expected
> >> }
> >> }
> >>
> >> public void testConstructorIlegalAverageBytesPerChar2() {
> >> try {
> >> Charset cs = Charset.forName("ISO8859-1"); //$NON-NLS-1$
> >> CharsetEncoder encoder = new 
> >> MockCharsetEncoderForHarmony141(cs, 1.1f, 1,
> >> new byte[] { 0x1a});
> >> fail("Should throw IllegalArgumentException."); //$NON-NLS-1$
> >> } catch (IllegalArgumentException e) {
> >> // expected
> >> }
> >> }
> >>
> >> public static class MockCharsetEncoderForHarmony141 extends 
> >> CharsetEncoder {
> >>
> >> protected MockCharsetEncoderForHarmony141(Charset cs, float 
> >> averageBytesPerChar,
> >> float maxBytesPerChar) {
> >> super(cs, averageBytesPerChar, maxBytesPerChar);
> >> }
> >>
> >> public MockCharsetEncoderForHarmony141(Charset cs, float 
> >> averageBytesPerChar,
> >> float maxBytesPerChar, byte[] replacement) {
> >> super(cs, averageBytesPerChar, maxBytesPerChar, replacement);
> >> }
> >>
> >> protected CoderResult encodeLoop(CharBuffer in, ByteBuffer out) {
> >> return null;
> >> }
> >>
> >> }
> >>
> >>
> >>> Constructors of java.nio.charset.CharsetEncoder do not validate arguments
> >>> -
> >>>
> >>>  Key: HARMONY-141
> >>>  URL: http://issues.apache.org/jira/browse/HARMONY-141
> >>>  Project: Harmony
> >>> Type: Bug
> >>> Reporter: Richard Liang
> >>> Constructors of java.nio.charset.CharsetEncoder should throw 
> >>> IllegalArgumentException when averageBytesPerChar exceeds maxBytesPerChar.
> >
>


--
Mark Hindess <[EMAIL PROTECTED]>
IBM Java Technology Centre, UK.

[jira] Created: (HARMONY-163) Three types in java.util.jar are not implemented in Harmony

[Paulex Yang (JIRA)]

Three types in java.util.jar are not implemented in Harmony
---

 Key: HARMONY-163
 URL: http://issues.apache.org/jira/browse/HARMONY-163
 Project: Harmony
Type: Bug
  Components: Classlib  
Reporter: Paulex Yang


Three types:
public abstract class java/util/jar/Pack200
public interface java/util/jar/Pack200$Packer
public interface java/util/jar/Pack200$Unpacker
are introduced in JSE 5, but not implemented in Harmony

-- 
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-156) InputStreamReader.getEncoding() and OutputStreamWriter.getEncoding() should return a historical charset name.

[Paulex Yang]

Ah, thank you very much, but...I have some concerns whether we can look 
at the Sun's bug database. Any official ideas from Harmony PPMC?  ;-)


karan malhi wrote:
You might want to look at this 
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6201170


Paulex Yang (JIRA) wrote:

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

Paulex Yang commented on HARMONY-156:
-

All the spec about Charset historical name is:
" Some charsets have an historical name that is defined for 
compatibility with previous versions of the Java platform. A 
charset's historical name is either its canonical name or one of its 
aliases."


From this paragraph, I personally think the historical name is 
specific to RI without any public standard:(,  so the only way to be 
compatible with RI is write testcases to get all historical names of 
RI supported Charsets, and store them in an map.


I can provide the patch of tests(to get all historical name) and the 
mapping implementation, but before that, I hope I can get some better 
idea from the mailing list to avoid this ugly solution:-\.


 

InputStreamReader.getEncoding() and OutputStreamWriter.getEncoding() 
should return a historical charset name.
- 



Key: HARMONY-156
URL: http://issues.apache.org/jira/browse/HARMONY-156
Project: Harmony
   Type: Bug
 Components: Classlib
   Reporter: Dmitry M. Kononov
   Priority: Minor
  


 

InputStreamReader.getEncoding() and OutputStreamWriter.getEncoding() 
return canonical names on the given charsets instead of historical 
ones. For example,
   new OutputStreamWriter(new ByteArrayOutputStream(), 
"UTF-16BE").getEncoding()
has to return the "UnicodeBigUnmarked" string as a historical name. 
But it returns "UTF-16BE", that is a canonical name.
The java spec reads the historical names as the charset names 
defined for compatibility with previous versions of the Java platform.
  


 






--
Paulex Yang
China Software Development Lab
IBM

[jira] Created: (HARMONY-162) One JSE 5 method are not implemented in java/util/jar/JarEntry

[Paulex Yang (JIRA)]

One JSE 5 method are not implemented in java/util/jar/JarEntry
--

 Key: HARMONY-162
 URL: http://issues.apache.org/jira/browse/HARMONY-162
 Project: Harmony
Type: Bug
  Components: Classlib  
Reporter: Paulex Yang


java/util/jar/JarEntry public getCodeSigners() is introduced by JSE 5, but not 
implemented in Harmony.

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

[jira] Created: (HARMONY-161) Improper override method in java/util/zip/GZIPOutputStream.close()

[Paulex Yang (JIRA)]

Improper override method in java/util/zip/GZIPOutputStream.close()
--

 Key: HARMONY-161
 URL: http://issues.apache.org/jira/browse/HARMONY-161
 Project: Harmony
Type: Bug
  Components: Classlib  
Reporter: Paulex Yang


java/util/zip/DeflaterOutputStream.close() is overriden by 
java/util/zip/GZIPOutputStream in Harmony while it isn't in spec.

-- 
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-156) InputStreamReader.getEncoding() and OutputStreamWriter.getEncoding() should return a historical charset name.

[karan malhi]

You might want to look at this 
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6201170


Paulex Yang (JIRA) wrote:

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


Paulex Yang commented on HARMONY-156:
-

All the spec about Charset historical name is:
" Some charsets have an historical name that is defined for compatibility with 
previous versions of the Java platform. A charset's historical name is either its 
canonical name or one of its aliases."


From this paragraph, I personally think the historical name is specific to RI 
without any public standard:(,  so the only way to be compatible with RI is 
write testcases to get all historical names of RI supported Charsets, and store 
them in an map.


I can provide the patch of tests(to get all historical name) and the mapping 
implementation, but before that, I hope I can get some better idea from the 
mailing list to avoid this ugly solution:-\.

 


InputStreamReader.getEncoding() and OutputStreamWriter.getEncoding() should 
return a historical charset name.
-

Key: HARMONY-156
URL: http://issues.apache.org/jira/browse/HARMONY-156
Project: Harmony
   Type: Bug
 Components: Classlib
   Reporter: Dmitry M. Kononov
   Priority: Minor
   



 


InputStreamReader.getEncoding() and OutputStreamWriter.getEncoding() return 
canonical names on the given charsets instead of historical ones. For example,
   new OutputStreamWriter(new ByteArrayOutputStream(), "UTF-16BE").getEncoding()
has to return the "UnicodeBigUnmarked" string as a historical name. But it returns 
"UTF-16BE", that is a canonical name.
The java spec reads the historical names as the charset names defined for 
compatibility with previous versions of the Java platform.
   



 



--
Karan Singh

[jira] Created: (HARMONY-160) Three JSE 5 methods are not implemented in java.util.zip.InflaterInputStream

[Paulex Yang (JIRA)]

Three JSE 5 methods are not implemented in java.util.zip.InflaterInputStream


 Key: HARMONY-160
 URL: http://issues.apache.org/jira/browse/HARMONY-160
 Project: Harmony
Type: Bug
  Components: Classlib  
Reporter: Paulex Yang


Three methods:
java/util/zip/InflaterInputStream public markSupported()Z,
java/util/zip/InflaterInputStream public mark(I)V,
java/util/zip/InflaterInputStream public reset()V,
are overridden in JSE 5,  but they not implemented in Harmony

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

[jira] Created: (HARMONY-159) Two JSE 5 methods are not implemented in java.util.zip.Inflator

[Paulex Yang (JIRA)]

Two JSE 5 methods are not implemented in java.util.zip.Inflator
---

 Key: HARMONY-159
 URL: http://issues.apache.org/jira/browse/HARMONY-159
 Project: Harmony
Type: Bug
Reporter: Paulex Yang


 Two methods:
java/util/zip/Inflater public getBytesRead()J
java/util/zip/Inflater public getBytesWritten()J
are introduced by JSE 5, but they are not been implemented by Harmony yet. 

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

[jira] Created: (HARMONY-158) Two JSE 5 methods are not implemented in java.util.zip.Deflator

[Paulex Yang (JIRA)]

Two JSE 5 methods are not implemented in java.util.zip.Deflator
---

 Key: HARMONY-158
 URL: http://issues.apache.org/jira/browse/HARMONY-158
 Project: Harmony
Type: Bug
Reporter: Paulex Yang


Two methods:
java/util/zip/Deflater public getBytesRead()J
java/util/zip/Deflater public getBytesWritten()J 
are introduced by JSE 5, but they are not been implemented by Harmony yet. 

-- 
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-156) InputStreamReader.getEncoding() and OutputStreamWriter.getEncoding() should return a historical charset name.

[Paulex Yang (JIRA)]

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

Paulex Yang commented on HARMONY-156:
-

All the spec about Charset historical name is:
" Some charsets have an historical name that is defined for compatibility with 
previous versions of the Java platform. A charset's historical name is either 
its canonical name or one of its aliases."

>From this paragraph, I personally think the historical name is specific to RI 
>without any public standard:(,  so the only way to be compatible with RI is 
>write testcases to get all historical names of RI supported Charsets, and 
>store them in an map.

I can provide the patch of tests(to get all historical name) and the mapping 
implementation, but before that, I hope I can get some better idea from the 
mailing list to avoid this ugly solution:-\.

> InputStreamReader.getEncoding() and OutputStreamWriter.getEncoding() should 
> return a historical charset name.
> -
>
>  Key: HARMONY-156
>  URL: http://issues.apache.org/jira/browse/HARMONY-156
>  Project: Harmony
> Type: Bug
>   Components: Classlib
> Reporter: Dmitry M. Kononov
> Priority: Minor

>
> InputStreamReader.getEncoding() and OutputStreamWriter.getEncoding() return 
> canonical names on the given charsets instead of historical ones. For example,
> new OutputStreamWriter(new ByteArrayOutputStream(), 
> "UTF-16BE").getEncoding()
> has to return the "UnicodeBigUnmarked" string as a historical name. But it 
> returns "UTF-16BE", that is a canonical name.
> The java spec reads the historical names as the charset names defined for 
> compatibility with previous versions of the Java platform.

-- 
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-152) Security module native build incorrectly use PATH variable

[Mikhail Loenko]

'Path', 'Include', etc are common e.g. for Windows 2000, see also
http://ant.apache.org/manual/CoreTasks/property.html

Well, I can fix *my* XP but a lot of people will download Harmony, try
and throw out

I think ALL common environment variables should be spelled all standard ways.

Thanks,
Mikhail


2006/3/2, Tim Ellison <[EMAIL PROTECTED]>:
> I agree.
>
> Tim
>
> Alexey Petrenko wrote:
> > 2006/3/2, Mikhail Loenko <[EMAIL PROTECTED]>:
> >> They are really case sensitive, but e.g. on my XP the variable's name is
> >> 'Path'
> > Probably you should fix your XP in this case :)
> >
> > If we will treat PATH variable this way (use ALL the variants) then
> > why we will not use ALL variants of all other evironment variables?
> >
> > I think that PATH variable should be spelled as PATH without variants.
> >
> > --
> > Alexey A. Petrenko
> > Intel Middleware Products Division
>
> --
>
> Tim Ellison ([EMAIL PROTECTED])
> IBM Java technology centre, UK.
>

[jira] Updated: (HARMONY-148) java.nio.charset.CharsetDecoder: decode(in,out,endOfInput) method doesn't preserve replace string for successive decode invocation while "out" doesn't have engouh space f

[Richard Liang (JIRA)]

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

Richard Liang updated HARMONY-148:
--

Attachment: CharsetDecoder_patch_148.txt

This patch fixes bug Harmony 148. Would you please have a try ? 
The patch could be simply applied by clicking "team"->"apply patch...".
Thank you very much!

> java.nio.charset.CharsetDecoder: decode(in,out,endOfInput) method doesn't 
> preserve replace string for successive decode invocation while "out" doesn't 
> have engouh space for replace string.
> 
>
>  Key: HARMONY-148
>  URL: http://issues.apache.org/jira/browse/HARMONY-148
>  Project: Harmony
> Type: Bug
>   Components: Classlib
> Reporter: Richard Liang
> Priority: Minor
>  Attachments: CharsetDecoder_patch_148.txt
>
> Consider following senario:
> During the invocation of method 
> java.nio.charset.CharsetDecoder.decode(in,out,false), method "decodeLoop" 
> returns malformed CoderResult, and the action is set as 
> "CodingErrorAction.REPLACE". So replace action should be taken, but "out" 
> doesn't hold enough space for the replace string. Therefore, 
> CoderResult.OVERFLOW should be returned. Harmony does return OVERFLOW 
> currently, but the replace string won't put into new allocated output any 
> more. In other words, the replace string is missing from the view of "stream 
> decoding". Therefore, replace string should be preserved for successive 
> decode(in,out,endOfInput) invacation.
> Both RI5.0 and Harmony fails on the following test case. However, according 
> to the spec, we think it is a defect of RI5.0.
> == Test Case==
> /*
>* Test the method decode(ByteBuffer) .
>*/
>   public void testDecode_ReplaceOverflow() throws Exception {
>   String replaceString = "a";
>   Charset cs = Charset.forName("UTF-8");
>   MockMalformedDecoder decoder = new MockMalformedDecoder(cs);
>   decoder.onMalformedInput(CodingErrorAction.REPLACE);
>   decoder.replaceWith(replaceString);
>   CharBuffer out = CharBuffer.allocate(1);
>   // MockMalformedDecoder treats the second byte '0x38' as 
> malformed, 
>   // but "out" doesn't have enough space for replace string.
>   ByteBuffer in = ByteBuffer.wrap(new 
> byte[]{0x45,0x38,0x45,0x45});
>   CoderResult result = decoder.decode(in,out,false);
>   assertTrue(result.isOverflow());
>   
>   // allocate enough space for "out"
>   out = CharBuffer.allocate(10);
>   // replace string should be put into "out" firstly,
>   // and then decode "in". 
>   result =decoder.decode(in,out,true);
>   out.flip();
>   assertTrue(result.isUnderflow());
>   assertEquals("abb",out.toString());
>   }
>   /*
>* Mock decoder. It treats byte whose value is less than "0x40" as 
> malformed.
>*/
>   static class MockMalformedDecoder extends 
> java.nio.charset.CharsetDecoder {
>   public MockMalformedDecoder(Charset cs) {
>   super(cs, 1, 10);
>   }
>   /*
>* It treats byte whose value is less than "0x40" as malformed.
>* Otherwise, it's decoded as 'b'.
>*/
>   protected CoderResult decodeLoop(ByteBuffer in, CharBuffer out) 
> {
>   System.out.println("Using MockMalformedDecoder");
>   while (in.hasRemaining()) {
>   byte b = in.get();
>   if(b < 0x40){
>   return 
> CoderResult.malformedForLength(1);
>   }
>   if(!out.hasRemaining()){
>   return CoderResult.OVERFLOW;
>   }
>   out.put((char)'b');
>   }
>   return CoderResult.UNDERFLOW;
>   }
>   }

-- 
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: [VOTE] Accept HARMONY-88 : Contribution of code and unit tests for jndi, logging, prefs and sql plus unit tests only for beans, crypto, math, regex and security

[Nathan Beyer]

+1

-Original Message-
From: Geir Magnusson Jr [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, March 01, 2006 6:05 AM
To: harmony-dev@incubator.apache.org
Subject: [VOTE] Accept HARMONY-88 : Contribution of code and unit tests for
jndi, logging, prefs and sql plus unit tests only for beans, crypto, math,
regex and security

All paperwork has been received.  I'll be getting that into SVN today, 
but lest get the voting kicked off...

Please vote on acceptance of the donation of Contribution of code and 
unit tests for jndi, logging, prefs and sql plus unit tests only for 
beans, crypto, math, regex and security :

[ ] +1 Accept
[ ] -1 Don't accept (provide reason)

Vote will run 3 days or until all committers have voted.

[jchevm] workarounds for Cygwin zip/jar problems that makes "hello world" work

[Weldon Washburn]

Archie,
I finally got JCHEVM to compile and run "hello world" with gnu
classpath.  My next step is to replace gnu classpath with harmony
class lib.   For anyone interested, below is the workarounds I used:

1)
Unzip /usr/local/classpath/share/classpath/glibj.zip to
/usr/local/unzipped_glibj
2)
Unzip ../jchevm/java/jc.zip to /usr/local/unzipped_jc
3)
In .../jchevm/libjc/native/Makefile, replace the line:
JAVAH_CMD = $(JAVAH) -classpath $(top_srcdir)/java/jc.zip:$(cpdir)/glibj.zip
with:
JAVAH_CMD = $(JAVAH) -classpath /usr/local/unzipped_jc:/usr/local/unzipped_glibj
The above now allows ./jchevm/Makefile to build jc.exe.  In
specific, jcjavah.exe generates the expected *.h files and no longer
causes the build to abort.
4)
Running jc.exe with jc.zip and glibj.zip does not work, however,
running jc.exe with unzipped classes does work.  I put hello.class in
the same directory as jc.exe and use the following invocation line:

"./jc.exe --classpath=.
--bootclasspath=/usr/local/unzipped_glibj:/usr/local/unzipped_jc:.
hello"

I don't know what the specific problem is.  But it probably has
something to do with how zip.c is making Cygwin calls.

--
Weldon Washburn
Intel Middleware Products Division

Re: [VOTE] Accept HARMONY-57 : Contribution of unit test code for a number of components

[Paulex Yang]

Nathan,

Seems currently in SVN, the test cases are distributed to the various 
classlib modules. How about we create a project named as 
common/base/whatever to contain the common/base/whatever utilities/tests 
which are very frequently used by many modules?


Nathan Beyer wrote:

+1

What's the plan on putting this in SVN? Will this be its own project or will
it be distributed to the various classlib modules? The reason I ask is that
there are a number of common classes and base classes, which would make
splitting the tests up a bit more challenging.

Assuming this gets checked in, let the list know if you'd like some
assistance refactoring and/or whatever to get this in the appropriate shape.

-Nathan
-Original Message-
From: Geir Magnusson Jr [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, March 01, 2006 6:07 AM

To: harmony-dev@incubator.apache.org
Subject: [VOTE] Accept HARMONY-57 : Contribution of unit test code for a
number of components

All paperwork has been received.  I'll be getting that into SVN today, 
but lets get the voting kicked off...


Please vote on acceptance of the donation of ontribution of unit test 
code for a number of components :


[ ] +1 Accept
[ ] -1 Don't accept (provide reason)

Vote will run 3 days or until all committers have voted.


  



--
Paulex Yang
China Software Development Lab
IBM

RE: [VOTE] Accept HARMONY-57 : Contribution of unit test code for a number of components

[Nathan Beyer]

+1

What's the plan on putting this in SVN? Will this be its own project or will
it be distributed to the various classlib modules? The reason I ask is that
there are a number of common classes and base classes, which would make
splitting the tests up a bit more challenging.

Assuming this gets checked in, let the list know if you'd like some
assistance refactoring and/or whatever to get this in the appropriate shape.

-Nathan
-Original Message-
From: Geir Magnusson Jr [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, March 01, 2006 6:07 AM
To: harmony-dev@incubator.apache.org
Subject: [VOTE] Accept HARMONY-57 : Contribution of unit test code for a
number of components

All paperwork has been received.  I'll be getting that into SVN today, 
but lets get the voting kicked off...

Please vote on acceptance of the donation of ontribution of unit test 
code for a number of components :

[ ] +1 Accept
[ ] -1 Don't accept (provide reason)

Vote will run 3 days or until all committers have voted.

Re: [jira] Commented: (HARMONY-141) Constructors of java.nio.charset.CharsetEncoder do not validate arguments

[Richard Liang]

Agree ;-)

Richard Liang
China Software Development Lab, IBM



Geir Magnusson Jr wrote:
maybe we should reject things not in patch format, as it puts 
unnecessary load on the committers.


Feel free to drop the code into comment or email so that we can 
discuss, but patch is much easier for everyone involved



Tim Ellison wrote:

p.s.  I accept test cases in patch format too ;-)

Regards,
Tim

Richard Liang (JIRA) wrote:
[ 
http://issues.apache.org/jira/browse/HARMONY-141?page=comments#action_12368097 
]

Richard Liang commented on HARMONY-141:
---

Here are the test cases which will pass on RI but fail on Harmony.

public void testConstructorIlegalAverageBytesPerChar() {
try {
Charset cs = Charset.forName("UTF-8"); //$NON-NLS-1$
CharsetEncoder encoder = new 
MockCharsetEncoderForHarmony141(cs, 1.1f, 1);
fail("Should throw IllegalArgumentException."); 
//$NON-NLS-1$

} catch (IllegalArgumentException e) {
// expected
}
}

public void testConstructorIlegalAverageBytesPerChar2() {
try {
Charset cs = Charset.forName("ISO8859-1"); //$NON-NLS-1$
CharsetEncoder encoder = new 
MockCharsetEncoderForHarmony141(cs, 1.1f, 1,

new byte[] { 0x1a});
fail("Should throw IllegalArgumentException."); 
//$NON-NLS-1$

} catch (IllegalArgumentException e) {
// expected
}
}

public static class MockCharsetEncoderForHarmony141 extends 
CharsetEncoder {


protected MockCharsetEncoderForHarmony141(Charset cs, float 
averageBytesPerChar,

float maxBytesPerChar) {
super(cs, averageBytesPerChar, maxBytesPerChar);
}

public MockCharsetEncoderForHarmony141(Charset cs, float 
averageBytesPerChar,

float maxBytesPerChar, byte[] replacement) {
super(cs, averageBytesPerChar, maxBytesPerChar, 
replacement);

}

protected CoderResult encodeLoop(CharBuffer in, ByteBuffer 
out) {

return null;
}

}


Constructors of java.nio.charset.CharsetEncoder do not validate 
arguments
- 



 Key: HARMONY-141
 URL: http://issues.apache.org/jira/browse/HARMONY-141
 Project: Harmony
Type: Bug
Reporter: Richard Liang
Constructors of java.nio.charset.CharsetEncoder should throw 
IllegalArgumentException when averageBytesPerChar exceeds 
maxBytesPerChar.

Re: Sorry for making trouble for vote

[Richard Liang]

Thanks a lot for your encouragement, Stefano. I will try to participate 
as much as possible ;-)


Richard Liang
China Software Development Lab, IBM



Stefano Mazzocchi wrote:

Richard Liang wrote:

Dear Geir,

Just realize I'm not a committers after I'm too impertinent to read 
your notes clearly. :-) Sorry again.


Richard,

committers make 'binding' votes, but votes from the community are as 
important because they stimulate participation and signal information 
to those steering the ship forward.


If somebody sees an iceberg while dancing on the deck of the titanic, 
I would want the captains to know sooner rather than later ;-)

Re: running builds on classlib (was: Re: [jira] Commented: (HARMONY-116) strange exec behaviour with harmony vme/classlib)

[Mark Hindess]

On 02/03/06, Tim Ellison <[EMAIL PROTECTED]> wrote:
>
> Mark Hindess wrote:
> >
> > On 02/03/06, Tim Ellison <[EMAIL PROTECTED]> wrote:
> >>> The build now completes with the Eclipse compiler.
> >> Great, so are the classlib builds now running on the classlib code +
> >> eclipse compiler + IBM VME?
> >
> > Yes!  So now I'm hoping to change our internal builds to:
>
> So that's ant & the eclipse compiler running on Harmony classlib, but
> presumably continuum itself is still running on a 'regular' jdk?

At the moment, but I'm planning to try continuum on Harmony + IBM VME
again tomorrow.  It was previously failing with an error that looked
very much like another instance of this exec problem.

> >   1) Build with IBM jdk.
> >   2) Build with the resulting Harmony classlib + eclipse compiler + IBM VME
>
> Why not just build using the latest classlib snapshot?  What does (1)
> get you?   (mmm, dog food).

1) is doing what most people coming to the project will try first so
it's nice if it works.
2) is dog food.

Granted it's unlikely that we'd break 1 without breaking 2 but
diversity never a bad thing IMHO.

> > which might break things more often
>
> You're all a bunch of pessimists at the moment ;-)

What do you mean at the moment? ;-)

Regards,
 Mark.

--
Mark Hindess <[EMAIL PROTECTED]>
IBM Java Technology Centre, UK.

Re: any donations expected for awt and swing?

[Geir Magnusson Jr]

Tim Ellison wrote:

Probably best to put the 'concerted work in progress' description on the
wiki, so anyone can join in; the website status page was intended to be
more of a current state of the code overview.  We should also start to
set ourselves some goals, in terms of applications to run, etc.


Why not have "started" on the webpage, and then a like to the wiki page 
if there is one?


Or just encourage people to ask here on the dev list...



If you want to make a start on the wiki page that would be good, or if
anyone else has an idea for tracking intent...

It's also worth mentioning that I don't believe we should be exclusive
about areas of work within, and contribution to, Harmony. 


Absolutely.


While I
understand that the goal is to minimize redundant work, we may find
ourselves in the situation of having more than one implementation of the
same APIs (we already saw this happen with 'security' and 'security2'
contributions).  This is no bad thing as it allows us to evaluate the
best technical option (quickly) and proceed with the combined group of
experts collaborating on a single code base.  I hope we can continue to
do so 'harmoniously'.


Choice and competition is good.  This isn't "live or die" competition, 
but "we can choose best of breed" competition, and we all benefit. 
There are no losers.


geir



Regards,
Tim

karan malhi wrote:

Hi,

I am writing the interfaces for the javax.accessibility package. Some of
the interfaces are dependent on classes from the awt package. Are we
expecting any donations for awt, swing packages?
If donations are not expected then what approach should I take? Should I
start writing stuff for  awt and swing (on which accessibility depends
on) so that accessibility classes compile during a build in harmony?
Please guide me here.

Secondly, once a volunteer starts working on a "Missing" module as
stated on 
http://incubator.apache.org/harmony/subcomponents/classlibrary/status.html

, should the status be changed to something else like "Work in progress"
or something?

Re: [VOTE] Accept HARMONY-57 : Contribution of unit test code for a number of components

[Geir Magnusson Jr]

Leo Simons wrote:

On Thu, Mar 02, 2006 at 09:50:02AM -0500, Geir Magnusson Jr wrote:

Stefano Mazzocchi wrote:

can I vote a "blank statement +1" that you can use to move code into SVN?
I think that if you would like to make a +1 blanket statement, then 
we'll count that in the future.


In my mind, in terms of "people that have reviewed what is going on and
what is going into SVN and that the paperwork is ok", it doesn't count.
No statement in that case is better.

I mean, if we have the paperwork, let's move the code in, whether or not 
we end up releasing it will require another vote anyway.
However, for awareness, oversight and participation, I think we still 
should be voting code in.


+1. "I trust Geir got it right" is bad since it creates a dependency on Geir
and moreover doesn't scale well (and scaling, we need...). However, changing
to a commit-then-review mode might help, and might scale better.


I understand what you mean but I assume that the "lump" contributions 
will stop as work effort converts to be entirely w/in the project.  (And 
no "Geir got it right" is the wrong way to go...)


Also, as a podling, post-start code contributions have been the subject 
of recent Incubator PMC concern and scrutiny, so lets keep the oversight.


We have a 3 day timeout for these, so if someone missed the vote, it's 
ok, we just ensure that there are no vetos and 3 +1s.


geir

Re: any donations expected for awt and swing?

[Tim Ellison]

Probably best to put the 'concerted work in progress' description on the
wiki, so anyone can join in; the website status page was intended to be
more of a current state of the code overview.  We should also start to
set ourselves some goals, in terms of applications to run, etc.

If you want to make a start on the wiki page that would be good, or if
anyone else has an idea for tracking intent...

It's also worth mentioning that I don't believe we should be exclusive
about areas of work within, and contribution to, Harmony.  While I
understand that the goal is to minimize redundant work, we may find
ourselves in the situation of having more than one implementation of the
same APIs (we already saw this happen with 'security' and 'security2'
contributions).  This is no bad thing as it allows us to evaluate the
best technical option (quickly) and proceed with the combined group of
experts collaborating on a single code base.  I hope we can continue to
do so 'harmoniously'.

Regards,
Tim

karan malhi wrote:
> Hi,
> 
> I am writing the interfaces for the javax.accessibility package. Some of
> the interfaces are dependent on classes from the awt package. Are we
> expecting any donations for awt, swing packages?
> If donations are not expected then what approach should I take? Should I
> start writing stuff for  awt and swing (on which accessibility depends
> on) so that accessibility classes compile during a build in harmony?
> Please guide me here.
> 
> Secondly, once a volunteer starts working on a "Missing" module as
> stated on 
> http://incubator.apache.org/harmony/subcomponents/classlibrary/status.html
> , should the status be changed to something else like "Work in progress"
> or something?
> 

-- 

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

running builds on classlib (was: Re: [jira] Commented: (HARMONY-116) strange exec behaviour with harmony vme/classlib)

[Tim Ellison]

Mark Hindess wrote:
> On 02/03/06, Tim Ellison <[EMAIL PROTECTED]> wrote:
>>> The build now completes with the Eclipse compiler.
>> Great, so are the classlib builds now running on the classlib code +
>> eclipse compiler + IBM VME?
> 
> Yes!  So now I'm hoping to change our internal builds to:

So that's ant & the eclipse compiler running on Harmony classlib, but
presumably continuum itself is still running on a 'regular' jdk?

>   1) Build with IBM jdk.
>   2) Build with the resulting Harmony classlib + eclipse compiler + IBM VME

Why not just build using the latest classlib snapshot?  What does (1)
get you?   (mmm, dog food).

> which might break things more often

You're all a bunch of pessimists at the moment ;-)

Regards,
Tim

> Regards,
>  Mark
> 
> --
> Mark Hindess <[EMAIL PROTECTED]>
> IBM Java Technology Centre, UK.
> 

-- 

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

[jira] Closed: (HARMONY-157) snapshot tar.gz has wrong permissions on java executable

[Tim Ellison (JIRA)]

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


Verified by Mark

> snapshot tar.gz has wrong permissions on java executable
> 
>
>  Key: HARMONY-157
>  URL: http://issues.apache.org/jira/browse/HARMONY-157
>  Project: Harmony
> Type: Bug
>   Components: Classlib
> Reporter: Mark Hindess
> Assignee: Tim Ellison
> Priority: Minor
>  Attachments: snapshot.file.mode.fix.diff
>
> I'll attach a patch to fix the snapshot target make/build.xml.

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

[jira] Closed: (HARMONY-154) Files in native-src/linux.IA32/sig should be renamed with prefix hy

[Tim Ellison (JIRA)]

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


Verified by Oliver

> Files in native-src/linux.IA32/sig should be renamed with prefix hy
> ---
>
>  Key: HARMONY-154
>  URL: http://issues.apache.org/jira/browse/HARMONY-154
>  Project: Harmony
> Type: Improvement
>   Components: Classlib
> Reporter: Oliver Deakin
> Assignee: Tim Ellison
> Priority: Minor
>  Attachments: hysig.renames.diff
>
> The source files in native-src/linux.IA32/sig are named with different prefix 
> to those in native-src/win.IA32/sig. They should have the hy prefix (as the 
> Windows ones do). This requires 4 renames and a couple of small 
> source/makefile changes. Its easier to just describe the renames instead of 
> producing a patch for them, so they are:
>jsig_copyright.c --> hysig_copyright.c
>jsiglinux.c --> hysiglinux.c
>jsigunix.c --> hysigunix.c
>jsigunix.h --> hysigunix.h
> I will attach a patch for the necessary source/makefile modifications.

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

[jira] Closed: (HARMONY-155) Native code tidy up - comments and casts

[Tim Ellison (JIRA)]

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


Verified by Oliver

> Native code tidy up - comments and casts
> 
>
>  Key: HARMONY-155
>  URL: http://issues.apache.org/jira/browse/HARMONY-155
>  Project: Harmony
> Type: Improvement
>   Components: Classlib
> Reporter: Oliver Deakin
> Assignee: Tim Ellison
> Priority: Minor
>  Attachments: code.comment.cleanup.diff
>
> Ive been doing a bit of general tidy up of the code in 
> classlib/trunk/native-src, and will be attaching a patch describing all the 
> changes. The work Ive done covers:
>  - Tidy up of comments, and transfer of useful comments from windows->linux 
> and vice versa where they are missing.
>  - Transfer of type casts that existed in one platform's code and not the 
> others. This is done with a view to unifying more code in native-src/shared.
>  - Addition of missing copyrights to .nls files under linux.IA32/zip.
>  - Removal of unused local variables.
>  - Some minor source formatting.

-- 
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: [VOTE] Accept HARMONY-57 : Contribution of unit test code for a number of components

[Leo Simons]

On Thu, Mar 02, 2006 at 09:50:02AM -0500, Geir Magnusson Jr wrote:
> Stefano Mazzocchi wrote:
> >can I vote a "blank statement +1" that you can use to move code into SVN?
> 
> I think that if you would like to make a +1 blanket statement, then 
> we'll count that in the future.

In my mind, in terms of "people that have reviewed what is going on and
what is going into SVN and that the paperwork is ok", it doesn't count.
No statement in that case is better.

> >I mean, if we have the paperwork, let's move the code in, whether or not 
> >we end up releasing it will require another vote anyway.
> 
> However, for awareness, oversight and participation, I think we still 
> should be voting code in.

+1. "I trust Geir got it right" is bad since it creates a dependency on Geir
and moreover doesn't scale well (and scaling, we need...). However, changing
to a commit-then-review mode might help, and might scale better.

LSD

Re: [VOTE] Accept HARMONY-127 : Eclipse plug-in for Harmony JRE support

[Leo Simons]

Man, I didn't even know it was coming. Too much email (and lots of real
life stuff to do, I must say, moving house is a lot of work!) for me to
keep track. Way cool though. I need to sort-of get "off" the PPMC, back
into my "just mentoring" role, and then we need some more people on that
PPMC who actually have the time for all the proper audit and review.

+0.5 seems cool but have not reviewed extensively enough to give a +1.

On Wed, Mar 01, 2006 at 07:02:05AM -0500, Geir Magnusson Jr wrote:
> All paperwork has been received.  I'll be getting that into SVN today, 
> but lest get the voting kicked off...
> 
> Please vote on acceptance of the donation of the eclipse plug-in for 
> Harmony JRE Support :
> 
> [ ] +1 Accept
> [ ] -1 Don't accept (provide reason)

- LSD

any donations expected for awt and swing?

[karan malhi]

Hi,

I am writing the interfaces for the javax.accessibility package. Some of 
the interfaces are dependent on classes from the awt package. Are we 
expecting any donations for awt, swing packages?
If donations are not expected then what approach should I take? Should I 
start writing stuff for  awt and swing (on which accessibility depends 
on) so that accessibility classes compile during a build in harmony?

Please guide me here.

Secondly, once a volunteer starts working on a "Missing" module as 
stated on  
http://incubator.apache.org/harmony/subcomponents/classlibrary/status.html 
, should the status be changed to something else like "Work in progress" 
or something?


--
Karan Singh

[jira] Commented: (HARMONY-157) snapshot tar.gz has wrong permissions on java executable

[Mark Hindess (JIRA)]

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

Mark Hindess commented on HARMONY-157:
--

Looks good. Thanks Tim.


> snapshot tar.gz has wrong permissions on java executable
> 
>
>  Key: HARMONY-157
>  URL: http://issues.apache.org/jira/browse/HARMONY-157
>  Project: Harmony
> Type: Bug
>   Components: Classlib
> Reporter: Mark Hindess
> Assignee: Tim Ellison
> Priority: Minor
>  Attachments: snapshot.file.mode.fix.diff
>
> I'll attach a patch to fix the snapshot target make/build.xml.

-- 
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-116) strange exec behaviour with harmony vme/classlib

[Mark Hindess]

On 02/03/06, Tim Ellison <[EMAIL PROTECTED]> wrote:
> > The build now completes with the Eclipse compiler.
>
> Great, so are the classlib builds now running on the classlib code +
> eclipse compiler + IBM VME?

Yes!  So now I'm hoping to change our internal builds to:

  1) Build with IBM jdk.
  2) Build with the resulting Harmony classlib + eclipse compiler + IBM VME

which might break things more often

Regards,
 Mark

--
Mark Hindess <[EMAIL PROTECTED]>
IBM Java Technology Centre, UK.

[jira] Commented: (HARMONY-154) Files in native-src/linux.IA32/sig should be renamed with prefix hy

[Oliver Deakin (JIRA)]

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

Oliver Deakin commented on HARMONY-154:
---

Looks good, thanks.

> Files in native-src/linux.IA32/sig should be renamed with prefix hy
> ---
>
>  Key: HARMONY-154
>  URL: http://issues.apache.org/jira/browse/HARMONY-154
>  Project: Harmony
> Type: Improvement
>   Components: Classlib
> Reporter: Oliver Deakin
> Assignee: Tim Ellison
> Priority: Minor
>  Attachments: hysig.renames.diff
>
> The source files in native-src/linux.IA32/sig are named with different prefix 
> to those in native-src/win.IA32/sig. They should have the hy prefix (as the 
> Windows ones do). This requires 4 renames and a couple of small 
> source/makefile changes. Its easier to just describe the renames instead of 
> producing a patch for them, so they are:
>jsig_copyright.c --> hysig_copyright.c
>jsiglinux.c --> hysiglinux.c
>jsigunix.c --> hysigunix.c
>jsigunix.h --> hysigunix.h
> I will attach a patch for the necessary source/makefile modifications.

-- 
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-155) Native code tidy up - comments and casts

[Oliver Deakin (JIRA)]

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

Oliver Deakin commented on HARMONY-155:
---

Looks good, thanks.

> Native code tidy up - comments and casts
> 
>
>  Key: HARMONY-155
>  URL: http://issues.apache.org/jira/browse/HARMONY-155
>  Project: Harmony
> Type: Improvement
>   Components: Classlib
> Reporter: Oliver Deakin
> Assignee: Tim Ellison
> Priority: Minor
>  Attachments: code.comment.cleanup.diff
>
> Ive been doing a bit of general tidy up of the code in 
> classlib/trunk/native-src, and will be attaching a patch describing all the 
> changes. The work Ive done covers:
>  - Tidy up of comments, and transfer of useful comments from windows->linux 
> and vice versa where they are missing.
>  - Transfer of type casts that existed in one platform's code and not the 
> others. This is done with a view to unifying more code in native-src/shared.
>  - Addition of missing copyrights to .nls files under linux.IA32/zip.
>  - Removal of unused local variables.
>  - Some minor source formatting.

-- 
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: jiritus

[Geir Magnusson Jr]

Tim Ellison wrote:

Geir Magnusson Jr wrote:

Um.  Sorry - I take back the first part.  I misread it.  I thought you
were putting it in yourself...  Never mind.  There's nothing to see
here.  Look!  An eagle!  Over there!


Where? where?  looks like a sparrow to me.


My [friendly] rant about JIRA still stands tho... :)


I actually don't mind discussions via JIRA, they all come out threaded
on the dev- list for me anyways so it doesn't look much different to the
normal banter.  And I prefer to take in fixes etc. via JIRA so we have
traceability where they were not authored by card-carrying ACQ people
(should we ever need to back them out).


Two different issues.  Fixes should come in via JIRA from 
non-committers.  THen we have a clear record.


But JIRA output is pretty ugly.

Can we please try to have the tech discussions here when possible?

geir



Regards,
Tim


geir


Geir Magnusson Jr wrote:

Please note that there's no need to pre-JIRA something you're about to
do, unless your short term memory is so shot that you might forget and
wander away from your desk, humming Oh Canada! in a minor key while
looking for the body of Jimmy Hoffa

Just do it.  Maybe a quick note to the mail list, but just note it.



I think we're overusing JIRA.  It seems the discussions get buried in
there.   Clearly it's a great way to note things we don't want to
forget about, or submit patches and features, but can we try to get
some of the tech discussions out and onto the list?

I filter JIRA email automatically, as I consider harmony-dev@ as the
place to discuss things...

Just my $0.02



geir


Tim Ellison (JIRA) wrote:

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

Tim Ellison reassigned HARMONY-153:
---

Assign To: Tim Ellison


mark deprecated API
---

 Key: HARMONY-153
 URL: http://issues.apache.org/jira/browse/HARMONY-153
 Project: Harmony
Type: Improvement
  Components: Classlib
Reporter: Mikhail Loenko
Assignee: Tim Ellison
Priority: Minor
 Attachments: deprecated.txt

As agreed on the mailing list deprecated classes, methods, etc
should be marked
I'm going to provide a patch shortly

[jira] Closed: (HARMONY-116) strange exec behaviour with harmony vme/classlib

[Tim Ellison (JIRA)]

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


Verified by Mark

> strange exec behaviour with harmony vme/classlib
> 
>
>  Key: HARMONY-116
>  URL: http://issues.apache.org/jira/browse/HARMONY-116
>  Project: Harmony
> Type: Bug
>  Environment: Linux, VME v1, classlib r379730
> Reporter: Mark Hindess
> Assignee: Tim Ellison
>  Attachments: ExecWithEnvTest.java, exec-path-broken.tar.gz, exec.fix.diff
>
> I'm seeing very odd behaviour from ant exec tasks that set environment 
> variables - such as the one in the security natives.  The exec is failing 
> with failed to execute command.  Worse still if I create a matching 
> executable in the basedir then that gets executed even if basedir is not in 
> the path.  This would be a potential security problem in other situations.  
> I'll attach a test case shortly.

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

Re: [jira] Commented: (HARMONY-116) strange exec behaviour with harmony vme/classlib

[Tim Ellison]

> The build now completes with the Eclipse compiler.

Great, so are the classlib builds now running on the classlib code +
eclipse compiler + IBM VME?

Regards,
Tim



Mark Hindess (JIRA) wrote:
> [ 
> http://issues.apache.org/jira/browse/HARMONY-116?page=comments#action_12368528
>  ] 
> 
> Mark Hindess commented on HARMONY-116:
> --
> 
> Looks good.  The build now completes with the Eclipse compiler.
> 
> 
>> strange exec behaviour with harmony vme/classlib
>> 
>>
>>  Key: HARMONY-116
>>  URL: http://issues.apache.org/jira/browse/HARMONY-116
>>  Project: Harmony
>> Type: Bug
>>  Environment: Linux, VME v1, classlib r379730
>> Reporter: Mark Hindess
>> Assignee: Tim Ellison
>>  Attachments: ExecWithEnvTest.java, exec-path-broken.tar.gz, exec.fix.diff
>>
>> I'm seeing very odd behaviour from ant exec tasks that set environment 
>> variables - such as the one in the security natives.  The exec is failing 
>> with failed to execute command.  Worse still if I create a matching 
>> executable in the basedir then that gets executed even if basedir is not in 
>> the path.  This would be a potential security problem in other situations.  
>> I'll attach a test case shortly.
> 

-- 

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

[jira] Resolved: (HARMONY-154) Files in native-src/linux.IA32/sig should be renamed with prefix hy

[Tim Ellison (JIRA)]

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

Resolution: Fixed

Oliver,

Fixed in native-src/linux.IA32/sig at repo revision 382448.

Please check that the patch was applied as you expected.


> Files in native-src/linux.IA32/sig should be renamed with prefix hy
> ---
>
>  Key: HARMONY-154
>  URL: http://issues.apache.org/jira/browse/HARMONY-154
>  Project: Harmony
> Type: Improvement
>   Components: Classlib
> Reporter: Oliver Deakin
> Assignee: Tim Ellison
> Priority: Minor
>  Attachments: hysig.renames.diff
>
> The source files in native-src/linux.IA32/sig are named with different prefix 
> to those in native-src/win.IA32/sig. They should have the hy prefix (as the 
> Windows ones do). This requires 4 renames and a couple of small 
> source/makefile changes. Its easier to just describe the renames instead of 
> producing a patch for them, so they are:
>jsig_copyright.c --> hysig_copyright.c
>jsiglinux.c --> hysiglinux.c
>jsigunix.c --> hysigunix.c
>jsigunix.h --> hysigunix.h
> I will attach a patch for the necessary source/makefile modifications.

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

[jira] Assigned: (HARMONY-154) Files in native-src/linux.IA32/sig should be renamed with prefix hy

[Tim Ellison (JIRA)]

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

Tim Ellison reassigned HARMONY-154:
---

Assign To: Tim Ellison

> Files in native-src/linux.IA32/sig should be renamed with prefix hy
> ---
>
>  Key: HARMONY-154
>  URL: http://issues.apache.org/jira/browse/HARMONY-154
>  Project: Harmony
> Type: Improvement
>   Components: Classlib
> Reporter: Oliver Deakin
> Assignee: Tim Ellison
> Priority: Minor
>  Attachments: hysig.renames.diff
>
> The source files in native-src/linux.IA32/sig are named with different prefix 
> to those in native-src/win.IA32/sig. They should have the hy prefix (as the 
> Windows ones do). This requires 4 renames and a couple of small 
> source/makefile changes. Its easier to just describe the renames instead of 
> producing a patch for them, so they are:
>jsig_copyright.c --> hysig_copyright.c
>jsiglinux.c --> hysiglinux.c
>jsigunix.c --> hysigunix.c
>jsigunix.h --> hysigunix.h
> I will attach a patch for the necessary source/makefile modifications.

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

[jira] Resolved: (HARMONY-157) snapshot tar.gz has wrong permissions on java executable

[Tim Ellison (JIRA)]

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

Resolution: Fixed

Thanks Mark,

Applied patch to make/build.xml at repo revision 382447.

Please check that the patch was applied as you expected.


> snapshot tar.gz has wrong permissions on java executable
> 
>
>  Key: HARMONY-157
>  URL: http://issues.apache.org/jira/browse/HARMONY-157
>  Project: Harmony
> Type: Bug
>   Components: Classlib
> Reporter: Mark Hindess
> Assignee: Tim Ellison
> Priority: Minor
>  Attachments: snapshot.file.mode.fix.diff
>
> I'll attach a patch to fix the snapshot target make/build.xml.

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

[jira] Assigned: (HARMONY-157) snapshot tar.gz has wrong permissions on java executable

[Tim Ellison (JIRA)]

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

Tim Ellison reassigned HARMONY-157:
---

Assign To: Tim Ellison

> snapshot tar.gz has wrong permissions on java executable
> 
>
>  Key: HARMONY-157
>  URL: http://issues.apache.org/jira/browse/HARMONY-157
>  Project: Harmony
> Type: Bug
>   Components: Classlib
> Reporter: Mark Hindess
> Assignee: Tim Ellison
> Priority: Minor
>  Attachments: snapshot.file.mode.fix.diff
>
> I'll attach a patch to fix the snapshot target make/build.xml.

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

[jira] Resolved: (HARMONY-155) Native code tidy up - comments and casts

[Tim Ellison (JIRA)]

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

Resolution: Fixed

Thanks for the patch Oliver,

Applied to native-src/ at repo revision 382442.

Please check that the patch was applied as you expected.


> Native code tidy up - comments and casts
> 
>
>  Key: HARMONY-155
>  URL: http://issues.apache.org/jira/browse/HARMONY-155
>  Project: Harmony
> Type: Improvement
>   Components: Classlib
> Reporter: Oliver Deakin
> Assignee: Tim Ellison
> Priority: Minor
>  Attachments: code.comment.cleanup.diff
>
> Ive been doing a bit of general tidy up of the code in 
> classlib/trunk/native-src, and will be attaching a patch describing all the 
> changes. The work Ive done covers:
>  - Tidy up of comments, and transfer of useful comments from windows->linux 
> and vice versa where they are missing.
>  - Transfer of type casts that existed in one platform's code and not the 
> others. This is done with a view to unifying more code in native-src/shared.
>  - Addition of missing copyrights to .nls files under linux.IA32/zip.
>  - Removal of unused local variables.
>  - Some minor source formatting.

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

[jira] Assigned: (HARMONY-155) Native code tidy up - comments and casts

[Tim Ellison (JIRA)]

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

Tim Ellison reassigned HARMONY-155:
---

Assign To: Tim Ellison

> Native code tidy up - comments and casts
> 
>
>  Key: HARMONY-155
>  URL: http://issues.apache.org/jira/browse/HARMONY-155
>  Project: Harmony
> Type: Improvement
>   Components: Classlib
> Reporter: Oliver Deakin
> Assignee: Tim Ellison
> Priority: Minor
>  Attachments: code.comment.cleanup.diff
>
> Ive been doing a bit of general tidy up of the code in 
> classlib/trunk/native-src, and will be attaching a patch describing all the 
> changes. The work Ive done covers:
>  - Tidy up of comments, and transfer of useful comments from windows->linux 
> and vice versa where they are missing.
>  - Transfer of type casts that existed in one platform's code and not the 
> others. This is done with a view to unifying more code in native-src/shared.
>  - Addition of missing copyrights to .nls files under linux.IA32/zip.
>  - Removal of unused local variables.
>  - Some minor source formatting.

-- 
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: auth natives

[Tim Ellison]

Ok Stepan, I've unhooked the old .cpp natives (to avoid confusion) in
repo revision 382441.

Regards,
Tim

Stepan Mishura wrote:
> Thanks Tim, Mark -- I've verified that tests pass
> 
> Thanks,
> Stepan
> 
> 
> On 3/2/06, Tim Ellison <[EMAIL PROTECTED]> wrote:
>> Thanks Stepan -- I've applied your patch in repo revision 382161.
>>
>> We can migrate the auth code with the other natives into whatever
>> platform layout we end up with.
>>
>> I'll remove the jaas* code building now it is no longer referenced.
>>
>> Regards,
>> Tim
>>
>> Stepan Mishura wrote:
>>> Hi Tim,
>>>
>>> I've attached a patch to run tests for login modules with 'hyauth'
>>> libraries. The tests pass with new libraries on Windows and Linux
>> builds.
>>> I've updated native-src/linux.IA32/auth/makefile to add 'vmi' library to
>>> be linked because loading 'hyauth' failed with the next diagnostics:
>>> java.lang.UnsatisfiedLinkError: hyauth
>>> (/deploy/jre/bin/libhyauth.so: undefined symbol:
>>> VMI_GetVMIFromJNIEnv
>>>
>>> I'm not confident whether it is the right way to do this or not. So
>>> please correct me if I'm wrong.
>>>
>>> Also I found that on Linux it is required to specify explicitly:
>>> LD_LIBRARY_PATH=/deploy/jre/bin
>>> and
>>> JAVA_HOME==/deploy/jre
>>>
>>> Otherwise VM fails to start. For example, unit test for LUNI module
>>> failed because ant script file for them contains the following line:
>>> 
>>>
>>> On Windows it is OK to unset both variables.
>>>
 was the small fix just the loadLibrary call, or more?

>>> It is just a typo in NTUserPrincipal.java (see attachment)
>>>
>>> Thanks,
>>> Stepan
>>>
>>>
>>> On 2/28/06, *Tim Ellison* <[EMAIL PROTECTED]
>>> > wrote:
>>>
>>> sure thanks Stepan -- was the small fix just the loadLibrary call,
>>> or more?
>>>
>>> Talk to you tomorrow,
>>> Tim
>>>
>>> Stepan Mishura wrote:
>>> > Hi Tim,
>>> >
>>> > I reviewed source files: they look OK for me. Also I successfully
>>> (after
>>> > small fix in java code:-)) run the test for login module on
>>> Windows with
>>> > 'hyauth' library. Currently I'm trying to build Harmony and run
>>> the similar
>>> > test on Linux. Hope to finish it tomorrow. Does it works for you?
>>> >
>>> > Thanks,
>>> > Stepan.
>>> >
>>> >
>>> > On 2/28/06, Tim Ellison < [EMAIL PROTECTED]
>>> > wrote:
>>> >> Stepan,
>>> >>
>>> >> Have you completed your review?  If things look ok I'll change
>> the
>>> >> loadlibray calls to use 'hyauth'.
>>> >>
>>> >> (As I mentioned before, this is simply to bring the code in line
>> with
>>> >> the other natives as a stepping-stone to the final native code
>> layout
>>> >> within each module.)
>>> >>
>>> >> Thanks
>>> >> Tim
>>> >>
>>> >> Stepan Mishura wrote:
>>> >>> I've just checked out your update (have problems with network)
>>> and going
>>> >> to
>>> >>> review it. I'll let you know if I have questions or comments to
>>> your
>>> >> update.
>>> >>> BTW, we developed small tests for login modules that use these
>>> libraries
>>> >>> see:
>>> >>> 1)
>>> >>>
>>> >>
>>>
>> modules\security\test\windows\unit\org\apache\harmony\security\x\security\auth\module\NTLoginModuleTest.java
>>> >>> 2)
>>> >>>
>>> >>
>>>
>> modules\security\test\linux\unit\org\apache\harmony\security\x\security\auth\module\UnixLoginModuleTest.java
>>> >>> Thanks,
>>> >>> Stepan Mishura
>>> >>> Intel Middleware Products Division
>>> >>>
>>> >>>
>>> >>>
>>> >>> On 2/22/06, Tim Ellison <[EMAIL PROTECTED]
>>> > wrote:
>>>  FYI: I have added the C versions of the auth natives into the
>>> build.
>>>  They are building as hyayth.dll | libhyauth.so into jre/bin.
>>> 
>>>  However, I *haven't* removed the jaaswin.dll | libjaasnix.so
>>> code (and
>>>  these are still being loaded by NTSystem.java |
>>> UnixSystem.java) until
>>>  I've tested the new libraries.
>>> 
>>>  Regards,
>>>  Tim
>>> 
>>>  Tim Ellison wrote:
>>> > 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
>>> >>

[jira] Created: (HARMONY-157) snapshot tar.gz has wrong permissions on java executable

[Mark Hindess (JIRA)]

snapshot tar.gz has wrong permissions on java executable


 Key: HARMONY-157
 URL: http://issues.apache.org/jira/browse/HARMONY-157
 Project: Harmony
Type: Bug
  Components: Classlib  
Reporter: Mark Hindess
Priority: Minor
 Attachments: snapshot.file.mode.fix.diff

I'll attach a patch to fix the snapshot target make/build.xml.


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

[jira] Updated: (HARMONY-157) snapshot tar.gz has wrong permissions on java executable

[Mark Hindess (JIRA)]

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

Mark Hindess updated HARMONY-157:
-

Attachment: snapshot.file.mode.fix.diff

Fixes mode of deploy/jre/bin/java in snapshot tar.


> snapshot tar.gz has wrong permissions on java executable
> 
>
>  Key: HARMONY-157
>  URL: http://issues.apache.org/jira/browse/HARMONY-157
>  Project: Harmony
> Type: Bug
>   Components: Classlib
> Reporter: Mark Hindess
> Priority: Minor
>  Attachments: snapshot.file.mode.fix.diff
>
> I'll attach a patch to fix the snapshot target make/build.xml.

-- 
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-116) strange exec behaviour with harmony vme/classlib

[Mark Hindess (JIRA)]

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

Mark Hindess commented on HARMONY-116:
--

Looks good.  The build now completes with the Eclipse compiler.


> strange exec behaviour with harmony vme/classlib
> 
>
>  Key: HARMONY-116
>  URL: http://issues.apache.org/jira/browse/HARMONY-116
>  Project: Harmony
> Type: Bug
>  Environment: Linux, VME v1, classlib r379730
> Reporter: Mark Hindess
> Assignee: Tim Ellison
>  Attachments: ExecWithEnvTest.java, exec-path-broken.tar.gz, exec.fix.diff
>
> I'm seeing very odd behaviour from ant exec tasks that set environment 
> variables - such as the one in the security natives.  The exec is failing 
> with failed to execute command.  Worse still if I create a matching 
> executable in the basedir then that gets executed even if basedir is not in 
> the path.  This would be a potential security problem in other situations.  
> I'll attach a test case shortly.

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

Re: Sorry for making trouble for vote

[Mark Hindess]

On 02/03/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote:
>
> Stefano Mazzocchi wrote:
> >
> > If somebody sees an iceberg while dancing on the deck of the titanic, I
> > would want the captains to know sooner rather than later ;-)
>
> Now there's a positive thought...
>
> Maybe that will be the 'codename' for our first milestone when we have
> the VM and things clicking...
>
>  Apache Harmony "Titanic"
>
> Maybe we can work on a general theme of "Great Maritime Disasters".  We
> could have the Edmund Fitzgerald, the Sultana, 

LOL!

If naming milestones after disasters is a "positive thought", I dread
to think what your "negative thoughts" might be like. ;-)

-Mark.

--
Mark Hindess <[EMAIL PROTECTED]>
IBM Java Technology Centre, UK.

[jira] Resolved: (HARMONY-116) strange exec behaviour with harmony vme/classlib

[Tim Ellison (JIRA)]

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

Resolution: Fixed

Thanks Mark,

Patch applied in native-src/linux.IA32/luni/procimpl.c at repo revision 382415.

Please check that the patch was applied as you expected.


> strange exec behaviour with harmony vme/classlib
> 
>
>  Key: HARMONY-116
>  URL: http://issues.apache.org/jira/browse/HARMONY-116
>  Project: Harmony
> Type: Bug
>  Environment: Linux, VME v1, classlib r379730
> Reporter: Mark Hindess
> Assignee: Tim Ellison
>  Attachments: ExecWithEnvTest.java, exec-path-broken.tar.gz, exec.fix.diff
>
> I'm seeing very odd behaviour from ant exec tasks that set environment 
> variables - such as the one in the security natives.  The exec is failing 
> with failed to execute command.  Worse still if I create a matching 
> executable in the basedir then that gets executed even if basedir is not in 
> the path.  This would be a potential security problem in other situations.  
> I'll attach a test case shortly.

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

[jira] Assigned: (HARMONY-116) strange exec behaviour with harmony vme/classlib

[Tim Ellison (JIRA)]

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

Tim Ellison reassigned HARMONY-116:
---

Assign To: Tim Ellison

> strange exec behaviour with harmony vme/classlib
> 
>
>  Key: HARMONY-116
>  URL: http://issues.apache.org/jira/browse/HARMONY-116
>  Project: Harmony
> Type: Bug
>  Environment: Linux, VME v1, classlib r379730
> Reporter: Mark Hindess
> Assignee: Tim Ellison
>  Attachments: ExecWithEnvTest.java, exec-path-broken.tar.gz, exec.fix.diff
>
> I'm seeing very odd behaviour from ant exec tasks that set environment 
> variables - such as the one in the security natives.  The exec is failing 
> with failed to execute command.  Worse still if I create a matching 
> executable in the basedir then that gets executed even if basedir is not in 
> the path.  This would be a potential security problem in other situations.  
> I'll attach a test case shortly.

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

Re: [jira] Created: (HARMONY-62) java.text.BreakIterator.getSentenceInstance().next() treats '\n' as the end of the sentence

[Tim Ellison]

Art,

(Found your note languishing in my reader -- sorry it took so long to
reply.)

While the wording of the Java spec may allow us to vary the behavior of
the break iterator, it will be of cold comfort to any apps that we
disrupt if the results are significantly different.

As Richard points out, we are relying upon the fine folk in the ICU
project to implement the break algorithms, and I know that they have
done a lot of work to conform to the latest Unicode specs.  However,
where there is a significant difference (and this bug report may well be
one of those cases) I believe we should tune ICU's default break
iterator with some custom rules to better match the reference
implementation behavior.

Do you have any examples of applications that layout text which we could
use as test cases?

Regards,
Tim

Art - Arthit Suriyawongkul wrote:
>> As you may know, our (Harmony) implementation just wraps ICU4J's
>> BreakIterator. And the rules of ICU4J's BreakIterator is compliant with
>> Unicode TR29 which is different with the rules of RI.
>>
>> This is a common issue for most of the classes in "text". If we want
>> implementation to have the same behavior as RI, we should get the rules
>> of RI. However, I think the rules must be controlled by some kinds of
>> license. So a better solution may be wrapping icu4j's implementation for
>> all text (internationalization) classes. As I know, ICU4J is special for
>> i18n.
> 
> Imho, I don't think that different BreakIterator implementations have
> to produce exactly the result ("boundary analysis").
> 
> What I meant is, the "Behavior" of them should be all the same,
> conform to what described in the Java API doc
>   http://java.sun.com/j2se/1.5.0/docs/api/java/text/BreakIterator.html
> 
>  Line boundary analysis determines where ...
>  Sentence boundary analysis allows ...
>  Word boundary analysis is ...
>  Character boundary analysis ...
> 
> But their result, the "Boundary Analysis", need not to be the same,
> just depends on how good each implementation could perform.
> 
> That's my opinion.
> 
> cheers,
> Art
> 
> --
> :: Art / Arthit Suriyawongkul
> :: Applied Computational Linguistics Lab, Uni Potsdam
> :: http://www.ling.uni-potsdam.de/acl-lab/
> :: http://bact.blogspot.com/
> 
> **  Impeach Thaksin   http://tuthaprajan.org

-- 

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

jiritus (was: Re: [jira] Assigned: (HARMONY-153) mark deprecated API)

[Tim Ellison]

Geir Magnusson Jr wrote:
> Um.  Sorry - I take back the first part.  I misread it.  I thought you
> were putting it in yourself...  Never mind.  There's nothing to see
> here.  Look!  An eagle!  Over there!

Where? where?  looks like a sparrow to me.

> My [friendly] rant about JIRA still stands tho... :)

I actually don't mind discussions via JIRA, they all come out threaded
on the dev- list for me anyways so it doesn't look much different to the
normal banter.  And I prefer to take in fixes etc. via JIRA so we have
traceability where they were not authored by card-carrying ACQ people
(should we ever need to back them out).

Regards,
Tim

> geir
> 
> 
> Geir Magnusson Jr wrote:
>> Please note that there's no need to pre-JIRA something you're about to
>> do, unless your short term memory is so shot that you might forget and
>> wander away from your desk, humming Oh Canada! in a minor key while
>> looking for the body of Jimmy Hoffa
>>
>> Just do it.  Maybe a quick note to the mail list, but just note it.
>>
>> 
>>
>> I think we're overusing JIRA.  It seems the discussions get buried in
>> there.   Clearly it's a great way to note things we don't want to
>> forget about, or submit patches and features, but can we try to get
>> some of the tech discussions out and onto the list?
>>
>> I filter JIRA email automatically, as I consider harmony-dev@ as the
>> place to discuss things...
>>
>> Just my $0.02
>>
>> 
>>
>> geir
>>
>>
>> Tim Ellison (JIRA) wrote:
>>>  [ http://issues.apache.org/jira/browse/HARMONY-153?page=all ]
>>>
>>> Tim Ellison reassigned HARMONY-153:
>>> ---
>>>
>>> Assign To: Tim Ellison
>>>
 mark deprecated API
 ---

  Key: HARMONY-153
  URL: http://issues.apache.org/jira/browse/HARMONY-153
  Project: Harmony
 Type: Improvement
   Components: Classlib
 Reporter: Mikhail Loenko
 Assignee: Tim Ellison
 Priority: Minor
  Attachments: deprecated.txt

 As agreed on the mailing list deprecated classes, methods, etc
 should be marked
 I'm going to provide a patch shortly
>>>
>>
>>
> 

-- 

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

[jira] Resolved: (HARMONY-152) Security module native build incorrectly use PATH variable

[Tim Ellison (JIRA)]

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

Resolution: Fixed

Alexey,

Modified as you suggest to better support case sensitive env var platforms.
Fixed in SECURITY module make/build.xml at repo revision 382403.

Please check this fix fully resolves your problem.


> Security module native build incorrectly use PATH variable
> --
>
>  Key: HARMONY-152
>  URL: http://issues.apache.org/jira/browse/HARMONY-152
>  Project: Harmony
> Type: Bug
>   Components: Classlib
>  Environment: WinXP
> Reporter: Alexey Petrenko
> Assignee: Tim Ellison

>
> modules/security/make/build.xml, line 163
> 
> Should be probably changed to 
> 
> Since environment variables are case sensitive.

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

[jira] Assigned: (HARMONY-152) Security module native build incorrectly use PATH variable

[Tim Ellison (JIRA)]

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

Tim Ellison reassigned HARMONY-152:
---

Assign To: Tim Ellison

> Security module native build incorrectly use PATH variable
> --
>
>  Key: HARMONY-152
>  URL: http://issues.apache.org/jira/browse/HARMONY-152
>  Project: Harmony
> Type: Bug
>   Components: Classlib
>  Environment: WinXP
> Reporter: Alexey Petrenko
> Assignee: Tim Ellison

>
> modules/security/make/build.xml, line 163
> 
> Should be probably changed to 
> 
> Since environment variables are case sensitive.

-- 
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-152) Security module native build incorrectly use PATH variable

[Tim Ellison]

I agree.

Tim

Alexey Petrenko wrote:
> 2006/3/2, Mikhail Loenko <[EMAIL PROTECTED]>:
>> They are really case sensitive, but e.g. on my XP the variable's name is
>> 'Path'
> Probably you should fix your XP in this case :)
> 
> If we will treat PATH variable this way (use ALL the variants) then
> why we will not use ALL variants of all other evironment variables?
> 
> I think that PATH variable should be spelled as PATH without variants.
> 
> --
> Alexey A. Petrenko
> Intel Middleware Products Division

-- 

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

Re: [jira] Assigned: (HARMONY-153) mark deprecated API

[Geir Magnusson Jr]

Um.  Sorry - I take back the first part.  I misread it.  I thought you 
were putting it in yourself...  Never mind.  There's nothing to see 
here.  Look!  An eagle!  Over there!


My [friendly] rant about JIRA still stands tho... :)

geir


Geir Magnusson Jr wrote:
Please note that there's no need to pre-JIRA something you're about to 
do, unless your short term memory is so shot that you might forget and 
wander away from your desk, humming Oh Canada! in a minor key while 
looking for the body of Jimmy Hoffa


Just do it.  Maybe a quick note to the mail list, but just note it.



I think we're overusing JIRA.  It seems the discussions get buried in 
there.   Clearly it's a great way to note things we don't want to forget 
about, or submit patches and features, but can we try to get some of the 
tech discussions out and onto the list?


I filter JIRA email automatically, as I consider harmony-dev@ as the 
place to discuss things...


Just my $0.02



geir


Tim Ellison (JIRA) wrote:

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

Tim Ellison reassigned HARMONY-153:
---

Assign To: Tim Ellison


mark deprecated API
---

 Key: HARMONY-153
 URL: http://issues.apache.org/jira/browse/HARMONY-153
 Project: Harmony
Type: Improvement
  Components: Classlib
Reporter: Mikhail Loenko
Assignee: Tim Ellison
Priority: Minor
 Attachments: deprecated.txt

As agreed on the mailing list deprecated classes, methods, etc should 
be marked

I'm going to provide a patch shortly

[jira] Resolved: (HARMONY-153) mark deprecated API

[Tim Ellison (JIRA)]

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

Resolution: Fixed

Mikhail,

I've fixed the problem at repo revision 382400, but to fit in with common 
convention I have added some explanations to the deprecation tag.  Please 
review and check that they are reasonable.

Thanks,
Tim

> mark deprecated API
> ---
>
>  Key: HARMONY-153
>  URL: http://issues.apache.org/jira/browse/HARMONY-153
>  Project: Harmony
> Type: Improvement
>   Components: Classlib
> Reporter: Mikhail Loenko
> Assignee: Tim Ellison
> Priority: Minor
>  Attachments: deprecated.txt
>
> As agreed on the mailing list deprecated classes, methods, etc should be 
> marked
> I'm going to provide a patch shortly

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

Re: [jira] Commented: (HARMONY-141) Constructors of java.nio.charset.CharsetEncoder do not validate arguments

[Geir Magnusson Jr]

maybe we should reject things not in patch format, as it puts 
unnecessary load on the committers.


Feel free to drop the code into comment or email so that we can discuss, 
but patch is much easier for everyone involved



Tim Ellison wrote:

p.s.  I accept test cases in patch format too ;-)

Regards,
Tim

Richard Liang (JIRA) wrote:
[ http://issues.apache.org/jira/browse/HARMONY-141?page=comments#action_12368097 ] 


Richard Liang commented on HARMONY-141:
---

Here are the test cases which will pass on RI but fail on Harmony.

public void testConstructorIlegalAverageBytesPerChar() {
try {
Charset cs = Charset.forName("UTF-8"); //$NON-NLS-1$
CharsetEncoder encoder = new MockCharsetEncoderForHarmony141(cs, 
1.1f, 1);
fail("Should throw IllegalArgumentException."); //$NON-NLS-1$
} catch (IllegalArgumentException e) {
// expected
}
}

public void testConstructorIlegalAverageBytesPerChar2() {
try {
Charset cs = Charset.forName("ISO8859-1"); //$NON-NLS-1$
CharsetEncoder encoder = new MockCharsetEncoderForHarmony141(cs, 
1.1f, 1,
new byte[] { 0x1a});
fail("Should throw IllegalArgumentException."); //$NON-NLS-1$
} catch (IllegalArgumentException e) {
// expected
}
}

public static class MockCharsetEncoderForHarmony141 extends CharsetEncoder {

protected MockCharsetEncoderForHarmony141(Charset cs, float 
averageBytesPerChar,
float maxBytesPerChar) {
super(cs, averageBytesPerChar, maxBytesPerChar);
}

public MockCharsetEncoderForHarmony141(Charset cs, float 
averageBytesPerChar,
float maxBytesPerChar, byte[] replacement) {
super(cs, averageBytesPerChar, maxBytesPerChar, replacement);
}

protected CoderResult encodeLoop(CharBuffer in, ByteBuffer out) {
return null;
}

}



Constructors of java.nio.charset.CharsetEncoder do not validate arguments
-

 Key: HARMONY-141
 URL: http://issues.apache.org/jira/browse/HARMONY-141
 Project: Harmony
Type: Bug
Reporter: Richard Liang
Constructors of java.nio.charset.CharsetEncoder should throw 
IllegalArgumentException when averageBytesPerChar exceeds maxBytesPerChar.

Re: [jira] Assigned: (HARMONY-153) mark deprecated API

[Geir Magnusson Jr]

Please note that there's no need to pre-JIRA something you're about to 
do, unless your short term memory is so shot that you might forget and 
wander away from your desk, humming Oh Canada! in a minor key while 
looking for the body of Jimmy Hoffa


Just do it.  Maybe a quick note to the mail list, but just note it.



I think we're overusing JIRA.  It seems the discussions get buried in 
there.   Clearly it's a great way to note things we don't want to forget 
about, or submit patches and features, but can we try to get some of the 
tech discussions out and onto the list?


I filter JIRA email automatically, as I consider harmony-dev@ as the 
place to discuss things...


Just my $0.02



geir


Tim Ellison (JIRA) wrote:

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

Tim Ellison reassigned HARMONY-153:
---

Assign To: Tim Ellison


mark deprecated API
---

 Key: HARMONY-153
 URL: http://issues.apache.org/jira/browse/HARMONY-153
 Project: Harmony
Type: Improvement
  Components: Classlib
Reporter: Mikhail Loenko
Assignee: Tim Ellison
Priority: Minor
 Attachments: deprecated.txt

As agreed on the mailing list deprecated classes, methods, etc should be marked
I'm going to provide a patch shortly

Re: [jira] Commented: (HARMONY-141) Constructors of java.nio.charset.CharsetEncoder do not validate arguments

[Tim Ellison]

p.s.  I accept test cases in patch format too ;-)

Regards,
Tim

Richard Liang (JIRA) wrote:
> [ 
> http://issues.apache.org/jira/browse/HARMONY-141?page=comments#action_12368097
>  ] 
> 
> Richard Liang commented on HARMONY-141:
> ---
> 
> Here are the test cases which will pass on RI but fail on Harmony.
> 
> public void testConstructorIlegalAverageBytesPerChar() {
> try {
> Charset cs = Charset.forName("UTF-8"); //$NON-NLS-1$
> CharsetEncoder encoder = new MockCharsetEncoderForHarmony141(cs, 
> 1.1f, 1);
> fail("Should throw IllegalArgumentException."); //$NON-NLS-1$
> } catch (IllegalArgumentException e) {
> // expected
> }
> }
> 
> public void testConstructorIlegalAverageBytesPerChar2() {
> try {
> Charset cs = Charset.forName("ISO8859-1"); //$NON-NLS-1$
> CharsetEncoder encoder = new MockCharsetEncoderForHarmony141(cs, 
> 1.1f, 1,
> new byte[] { 0x1a});
> fail("Should throw IllegalArgumentException."); //$NON-NLS-1$
> } catch (IllegalArgumentException e) {
> // expected
> }
> }
> 
> public static class MockCharsetEncoderForHarmony141 extends 
> CharsetEncoder {
> 
> protected MockCharsetEncoderForHarmony141(Charset cs, float 
> averageBytesPerChar,
> float maxBytesPerChar) {
> super(cs, averageBytesPerChar, maxBytesPerChar);
> }
> 
> public MockCharsetEncoderForHarmony141(Charset cs, float 
> averageBytesPerChar,
> float maxBytesPerChar, byte[] replacement) {
> super(cs, averageBytesPerChar, maxBytesPerChar, replacement);
> }
> 
> protected CoderResult encodeLoop(CharBuffer in, ByteBuffer out) {
> return null;
> }
> 
> }
> 
> 
>> Constructors of java.nio.charset.CharsetEncoder do not validate arguments
>> -
>>
>>  Key: HARMONY-141
>>  URL: http://issues.apache.org/jira/browse/HARMONY-141
>>  Project: Harmony
>> Type: Bug
>> Reporter: Richard Liang
> 
>> Constructors of java.nio.charset.CharsetEncoder should throw 
>> IllegalArgumentException when averageBytesPerChar exceeds maxBytesPerChar.
> 

-- 

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

Re: Sorry for making trouble for vote

[Geir Magnusson Jr]

Stefano Mazzocchi wrote:

Richard Liang wrote:

Dear Geir,

Just realize I'm not a committers after I'm too impertinent to read 
your notes clearly. :-) Sorry again.


Richard,

committers make 'binding' votes, but votes from the community are as 
important because they stimulate participation and signal information to 
those steering the ship forward.


If somebody sees an iceberg while dancing on the deck of the titanic, I 
would want the captains to know sooner rather than later ;-)


Now there's a positive thought...

Maybe that will be the 'codename' for our first milestone when we have 
the VM and things clicking...


Apache Harmony "Titanic"

Maybe we can work on a general theme of "Great Maritime Disasters".  We 
could have the Edmund Fitzgerald, the Sultana, 


geir

[jira] Assigned: (HARMONY-153) mark deprecated API

[Tim Ellison (JIRA)]

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

Tim Ellison reassigned HARMONY-153:
---

Assign To: Tim Ellison

> mark deprecated API
> ---
>
>  Key: HARMONY-153
>  URL: http://issues.apache.org/jira/browse/HARMONY-153
>  Project: Harmony
> Type: Improvement
>   Components: Classlib
> Reporter: Mikhail Loenko
> Assignee: Tim Ellison
> Priority: Minor
>  Attachments: deprecated.txt
>
> As agreed on the mailing list deprecated classes, methods, etc should be 
> marked
> I'm going to provide a patch shortly

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

Re: [VOTE] Accept HARMONY-57 : Contribution of unit test code for a number of components

[Geir Magnusson Jr]

Stefano Mazzocchi wrote:

Geir Magnusson Jr wrote:
All paperwork has been received.  I'll be getting that into SVN today, 
but lets get the voting kicked off...


Please vote on acceptance of the donation of ontribution of unit test 
code for a number of components :


[ ] +1 Accept
[ ] -1 Don't accept (provide reason)

Vote will run 3 days or until all committers have voted.


+1

can I vote a "blank statement +1" that you can use to move code into SVN?


I think that if you would like to make a +1 blanket statement, then 
we'll count that in the future.




I mean, if we have the paperwork, let's move the code in, whether or not 
we end up releasing it will require another vote anyway.




However, for awareness, oversight and participation, I think we still 
should be voting code in.


geir

Re: [VOTE] Accept HARMONY-57 : Contribution of unit test code for a number of components

[karan malhi]

+1

Geir Magnusson Jr wrote:

All paperwork has been received.  I'll be getting that into SVN today, 
but lets get the voting kicked off...


Please vote on acceptance of the donation of ontribution of unit test 
code for a number of components :


[ ] +1 Accept
[ ] -1 Don't accept (provide reason)

Vote will run 3 days or until all committers have voted.




--
Karan Singh

Re: [VOTE] Accept HARMONY-88 : Contribution of code and unit tests for jndi, logging, prefs and sql plus unit tests only for beans, crypto, math, regex and security

[karan malhi]

+1

Geir Magnusson Jr wrote:

All paperwork has been received.  I'll be getting that into SVN today, 
but lest get the voting kicked off...


Please vote on acceptance of the donation of Contribution of code and 
unit tests for jndi, logging, prefs and sql plus unit tests only for 
beans, crypto, math, regex and security :


[ ] +1 Accept
[ ] -1 Don't accept (provide reason)

Vote will run 3 days or until all committers have voted.



--
Karan Singh

Re: [VOTE] Accept HARMONY-127 : Eclipse plug-in for Harmony JRE support

[karan malhi]

+1

Geir Magnusson Jr wrote:

All paperwork has been received.  I'll be getting that into SVN today, 
but lest get the voting kicked off...


Please vote on acceptance of the donation of the eclipse plug-in for 
Harmony JRE Support :


[ ] +1 Accept
[ ] -1 Don't accept (provide reason)




--
Karan Singh

Re: Sorry for making trouble for vote

[Stefano Mazzocchi]

Richard Liang wrote:

Dear Geir,

Just realize I'm not a committers after I'm too impertinent to read your 
notes clearly. :-) Sorry again.


Richard,

committers make 'binding' votes, but votes from the community are as 
important because they stimulate participation and signal information to 
those steering the ship forward.


If somebody sees an iceberg while dancing on the deck of the titanic, I 
would want the captains to know sooner rather than later ;-)


--
Stefano.

Re: [VOTE] Accept HARMONY-57 : Contribution of unit test code for a number of components

[Stefano Mazzocchi]

Geir Magnusson Jr wrote:
All paperwork has been received.  I'll be getting that into SVN today, 
but lets get the voting kicked off...


Please vote on acceptance of the donation of ontribution of unit test 
code for a number of components :


[ ] +1 Accept
[ ] -1 Don't accept (provide reason)

Vote will run 3 days or until all committers have voted.


+1

can I vote a "blank statement +1" that you can use to move code into SVN?

I mean, if we have the paperwork, let's move the code in, whether or not 
we end up releasing it will require another vote anyway.


--
Stefano.

Re: [VOTE] Accept HARMONY-88 : Contribution of code and unit tests for jndi, logging, prefs and sql plus unit tests only for beans, crypto, math, regex and security

[Stefano Mazzocchi]

Geir Magnusson Jr wrote:
All paperwork has been received.  I'll be getting that into SVN today, 
but lest get the voting kicked off...


Please vote on acceptance of the donation of Contribution of code and 
unit tests for jndi, logging, prefs and sql plus unit tests only for 
beans, crypto, math, regex and security :


[ ] +1 Accept
[ ] -1 Don't accept (provide reason)

Vote will run 3 days or until all committers have voted.


+1

--
Stefano.

Re: [VOTE] Accept HARMONY-127 : Eclipse plug-in for Harmony JRE support

[Stefano Mazzocchi]

Geir Magnusson Jr wrote:
All paperwork has been received.  I'll be getting that into SVN today, 
but lest get the voting kicked off...


Please vote on acceptance of the donation of the eclipse plug-in for 
Harmony JRE Support :


[ ] +1 Accept
[ ] -1 Don't accept (provide reason)


+1

--
Stefano.

[jira] Resolved: (HARMONY-141) Constructors of java.nio.charset.CharsetEncoder do not validate arguments

[Tim Ellison (JIRA)]

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

Resolution: Fixed

Richard,

Thanks for the patch.  Applied to NIO_CHAR module at repo revision 382383 with 
minor modification to the test case (to bring naming in line with test case 
conventions) and removing invlid NON-NLS tags.

Please check that the problem is fully resolved.


> Constructors of java.nio.charset.CharsetEncoder do not validate arguments
> -
>
>  Key: HARMONY-141
>  URL: http://issues.apache.org/jira/browse/HARMONY-141
>  Project: Harmony
> Type: Bug
> Reporter: Richard Liang
> Assignee: Tim Ellison
>  Attachments: CharsetEncoder_patch.txt
>
> Constructors of java.nio.charset.CharsetEncoder should throw 
> IllegalArgumentException when averageBytesPerChar exceeds maxBytesPerChar.

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

[jira] Created: (HARMONY-156) InputStreamReader.getEncoding() and OutputStreamWriter.getEncoding() should return a historical charset name.

[Dmitry M. Kononov (JIRA)]

InputStreamReader.getEncoding() and OutputStreamWriter.getEncoding() should 
return a historical charset name.
-

 Key: HARMONY-156
 URL: http://issues.apache.org/jira/browse/HARMONY-156
 Project: Harmony
Type: Bug
  Components: Classlib  
Reporter: Dmitry M. Kononov
Priority: Minor


InputStreamReader.getEncoding() and OutputStreamWriter.getEncoding() return 
canonical names on the given charsets instead of historical ones. For example,
new OutputStreamWriter(new ByteArrayOutputStream(), 
"UTF-16BE").getEncoding()
has to return the "UnicodeBigUnmarked" string as a historical name. But it 
returns "UTF-16BE", that is a canonical name.
The java spec reads the historical names as the charset names defined for 
compatibility with previous versions of the Java platform.


-- 
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: build problems

[Alexey Petrenko]

> How can I fugure out which javac is used? JAVA_HOME points to JDK1.5 (have
> tried 1.4 also - same result)
Try ant -verbose it prints out a lot of info...
--
Alexey A. Petrenko
Intel Middleware Products Division

[jira] Assigned: (HARMONY-141) Constructors of java.nio.charset.CharsetEncoder do not validate arguments

[Tim Ellison (JIRA)]

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

Tim Ellison reassigned HARMONY-141:
---

Assign To: Tim Ellison

> Constructors of java.nio.charset.CharsetEncoder do not validate arguments
> -
>
>  Key: HARMONY-141
>  URL: http://issues.apache.org/jira/browse/HARMONY-141
>  Project: Harmony
> Type: Bug
> Reporter: Richard Liang
> Assignee: Tim Ellison
>  Attachments: CharsetEncoder_patch.txt
>
> Constructors of java.nio.charset.CharsetEncoder should throw 
> IllegalArgumentException when averageBytesPerChar exceeds maxBytesPerChar.

-- 
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-152) Security module native build incorrectly use PATH variable

[Alexey Petrenko]

2006/3/2, Mikhail Loenko <[EMAIL PROTECTED]>:
> They are really case sensitive, but e.g. on my XP the variable's name is
> 'Path'
Probably you should fix your XP in this case :)

If we will treat PATH variable this way (use ALL the variants) then
why we will not use ALL variants of all other evironment variables?

I think that PATH variable should be spelled as PATH without variants.

--
Alexey A. Petrenko
Intel Middleware Products Division

[jira] Updated: (HARMONY-155) Native code tidy up - comments and casts

[Oliver Deakin (JIRA)]

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

Oliver Deakin updated HARMONY-155:
--

Attachment: code.comment.cleanup.diff

Attached patch describing code changes

> Native code tidy up - comments and casts
> 
>
>  Key: HARMONY-155
>  URL: http://issues.apache.org/jira/browse/HARMONY-155
>  Project: Harmony
> Type: Improvement
>   Components: Classlib
> Reporter: Oliver Deakin
> Priority: Minor
>  Attachments: code.comment.cleanup.diff
>
> Ive been doing a bit of general tidy up of the code in 
> classlib/trunk/native-src, and will be attaching a patch describing all the 
> changes. The work Ive done covers:
>  - Tidy up of comments, and transfer of useful comments from windows->linux 
> and vice versa where they are missing.
>  - Transfer of type casts that existed in one platform's code and not the 
> others. This is done with a view to unifying more code in native-src/shared.
>  - Addition of missing copyrights to .nls files under linux.IA32/zip.
>  - Removal of unused local variables.
>  - Some minor source formatting.

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

[jira] Created: (HARMONY-155) Native code tidy up - comments and casts

[Oliver Deakin (JIRA)]

Native code tidy up - comments and casts


 Key: HARMONY-155
 URL: http://issues.apache.org/jira/browse/HARMONY-155
 Project: Harmony
Type: Improvement
  Components: Classlib  
Reporter: Oliver Deakin
Priority: Minor
 Attachments: code.comment.cleanup.diff

Ive been doing a bit of general tidy up of the code in 
classlib/trunk/native-src, and will be attaching a patch describing all the 
changes. The work Ive done covers:
 - Tidy up of comments, and transfer of useful comments from windows->linux and 
vice versa where they are missing.
 - Transfer of type casts that existed in one platform's code and not the 
others. This is done with a view to unifying more code in native-src/shared.
 - Addition of missing copyrights to .nls files under linux.IA32/zip.
 - Removal of unused local variables.
 - Some minor source formatting.


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

[jira] Updated: (HARMONY-154) Files in native-src/linux.IA32/sig should be renamed with prefix hy

[Oliver Deakin (JIRA)]

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

Oliver Deakin updated HARMONY-154:
--

Attachment: hysig.renames.diff

Patch for source/makefile changes - this patch should be applied after the 
renames have been carried out.

> Files in native-src/linux.IA32/sig should be renamed with prefix hy
> ---
>
>  Key: HARMONY-154
>  URL: http://issues.apache.org/jira/browse/HARMONY-154
>  Project: Harmony
> Type: Improvement
>   Components: Classlib
> Reporter: Oliver Deakin
> Priority: Minor
>  Attachments: hysig.renames.diff
>
> The source files in native-src/linux.IA32/sig are named with different prefix 
> to those in native-src/win.IA32/sig. They should have the hy prefix (as the 
> Windows ones do). This requires 4 renames and a couple of small 
> source/makefile changes. Its easier to just describe the renames instead of 
> producing a patch for them, so they are:
>jsig_copyright.c --> hysig_copyright.c
>jsiglinux.c --> hysiglinux.c
>jsigunix.c --> hysigunix.c
>jsigunix.h --> hysigunix.h
> I will attach a patch for the necessary source/makefile modifications.

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

[jira] Created: (HARMONY-154) Files in native-src/linux.IA32/sig should be renamed with prefix hy

[Oliver Deakin (JIRA)]

Files in native-src/linux.IA32/sig should be renamed with prefix hy
---

 Key: HARMONY-154
 URL: http://issues.apache.org/jira/browse/HARMONY-154
 Project: Harmony
Type: Improvement
  Components: Classlib  
Reporter: Oliver Deakin
Priority: Minor


The source files in native-src/linux.IA32/sig are named with different prefix 
to those in native-src/win.IA32/sig. They should have the hy prefix (as the 
Windows ones do). This requires 4 renames and a couple of small source/makefile 
changes. Its easier to just describe the renames instead of producing a patch 
for them, so they are:
   jsig_copyright.c --> hysig_copyright.c
   jsiglinux.c --> hysiglinux.c
   jsigunix.c --> hysigunix.c
   jsigunix.h --> hysigunix.h

I will attach a patch for the necessary source/makefile modifications.

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

[jira] Resolved: (HARMONY-142) java.nio.charset.CharsetDecoder constructor doesn't throw IllegalArgumentException when averageCharsPerByte is greater than maxCharsPerByte.

[Tim Ellison (JIRA)]

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

Resolution: Fixed

Richard,

Thanks for the patch, applied to NIO_CHAR module 
java.nio.charset.CharsetDecoder at repo revision 382380.

I made a couple of minor modifications to rename the test method in keeping 
with the tests naming convention, and unmark the exception description as 
NON-NLS because it should in fact be NLS'd via the Msg type.

Please check that this fix fully resolves your problem.


> java.nio.charset.CharsetDecoder constructor doesn't throw 
> IllegalArgumentException when averageCharsPerByte is greater than 
> maxCharsPerByte.
> 
>
>  Key: HARMONY-142
>  URL: http://issues.apache.org/jira/browse/HARMONY-142
>  Project: Harmony
> Type: Bug
>   Components: Classlib
> Reporter: Richard Liang
> Assignee: Tim Ellison
>  Attachments: CharsetDecoder_patch.txt
>
> As spec says, constructor throws IllegalArgumentException when parameters are 
> illegal. It should be considered as illegal parameters when 
> averageCharsPerByte is greater than maxCharsPerByte.

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

[jira] Assigned: (HARMONY-142) java.nio.charset.CharsetDecoder constructor doesn't throw IllegalArgumentException when averageCharsPerByte is greater than maxCharsPerByte.

[Tim Ellison (JIRA)]

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

Tim Ellison reassigned HARMONY-142:
---

Assign To: Tim Ellison

> java.nio.charset.CharsetDecoder constructor doesn't throw 
> IllegalArgumentException when averageCharsPerByte is greater than 
> maxCharsPerByte.
> 
>
>  Key: HARMONY-142
>  URL: http://issues.apache.org/jira/browse/HARMONY-142
>  Project: Harmony
> Type: Bug
>   Components: Classlib
> Reporter: Richard Liang
> Assignee: Tim Ellison
>  Attachments: CharsetDecoder_patch.txt
>
> As spec says, constructor throws IllegalArgumentException when parameters are 
> illegal. It should be considered as illegal parameters when 
> averageCharsPerByte is greater than maxCharsPerByte.

-- 
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-146) doxygen build is broken

[Mark Hindess]

On 01/03/06, Stuart Ballard <[EMAIL PROTECTED]> wrote:
> Mark Hindess  googlemail.com> writes:
>
> > Since these are generated files they probably shouldn't be in svn in
> > the first place.  Though I can see why it is handy to have them there.
> >  Perhaps we need a "snapshot" on the web site?
> >
> > > Was it something the automated build process have informed us about ?
> >
> > The build is currently only doing "cd make; ant".  I can add the doc
> > build but at the moment the ant tasks are configured to ignore
> > failures so the build wouldn't actually break.
>
> I thought the results of the builds were already in
> http://cvs.apache.org/dist/incubator/harmony/snapshots/
>
> That's what I've been using for Japi results. I did notice that the last run
> was from Feb 17th, but I thought that was just because no automated build was
> running.
>
> If there *is* an automated build running, could its output be made available
> somewhere so the Japi results can be based on the latest CVS rather than two
> weeks old?

Hi Stuart,

Sorry for the confusion.

George was referring to the builds I'm running.  These are not public.
 But I have configured them to send status emails to the list just to
help catch build breaks early - though they aren't getting through
yet.

As Geir has said, the builds for the project should be running on
Apache infrastructure and then the jars can be published on Apache
servers but AFAIK there are no firm plans to do this yet.

In the meantime,  Tim will continue to make periodic snapshots with
announcements sent to this list.  Any JAPI results you produce based
on these snapshots will be very much appreciated.

Regards,
 Mark.

--
Mark Hindess <[EMAIL PROTECTED]>
IBM Java Technology Centre, UK.

[jira] Updated: (HARMONY-153) mark deprecated API

[Mikhail Loenko (JIRA)]

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

Mikhail Loenko updated HARMONY-153:
---

Attachment: deprecated.txt

patch

> mark deprecated API
> ---
>
>  Key: HARMONY-153
>  URL: http://issues.apache.org/jira/browse/HARMONY-153
>  Project: Harmony
> Type: Improvement
>   Components: Classlib
> Reporter: Mikhail Loenko
> Priority: Minor
>  Attachments: deprecated.txt
>
> As agreed on the mailing list deprecated classes, methods, etc should be 
> marked
> I'm going to provide a patch shortly

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

[jira] Created: (HARMONY-153) mark deprecated API

[Mikhail Loenko (JIRA)]

mark deprecated API
---

 Key: HARMONY-153
 URL: http://issues.apache.org/jira/browse/HARMONY-153
 Project: Harmony
Type: Improvement
  Components: Classlib  
Reporter: Mikhail Loenko
Priority: Minor


As agreed on the mailing list deprecated classes, methods, etc should be marked

I'm going to provide a patch shortly

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

[jira] Commented: (HARMONY-151) RI docs does not specify values for constant fields in javax.accessibility.AccessibleAction interface

[Tim Ellison (JIRA)]

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

Tim Ellison commented on HARMONY-151:
-

Yes, that is a reasonable approach -- I expect that the lack of specification 
for these values is an oversight.

> RI docs does not specify values for constant fields in 
> javax.accessibility.AccessibleAction interface
> -
>
>  Key: HARMONY-151
>  URL: http://issues.apache.org/jira/browse/HARMONY-151
>  Project: Harmony
> Type: Bug
>   Components: Classlib
> Reporter: karan singh malhi

>
> The RI docs do not specify the Constant field values for the three fields 
> defined in the javax.accessibility.AccessibleAction interface
> However, the following code displays the values in those fields:
> 
> public class AccessibleActionTest {
> public static void main(String[] args) {
> System.out.println(AccessibleAction.DECREMENT );
> System.out.println(AccessibleAction.INCREMENT );
> System.out.println(AccessibleAction.TOGGLE_EXPAND);
> }
> }
> 
> The output is :
> decrement
> increment
> toggle expand
> Should we go ahead and initialize the fields of the AccessibleAction 
> interface with the values obtained from the above output ?

-- 
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: build problems

[Mikhail Loenko]

When I'm checking out from scratch on my old machine everything works well.
The new machine was originally pure, i'm populating it with various
soft right now.

I go 'cd enhanced/classlib/trunk/make' and there type 'ant'.

How can I fugure out which javac is used? JAVA_HOME points to JDK1.5 (have
tried 1.4 also - same result)

All other class files compiled at the moment of build failure also have extra
elements in the package name.

Thanks,
Mikhail

2006/3/2, Tim Ellison <[EMAIL PROTECTED]>:
> Mikhail,
>
> I've just checked everything out from scratch and it builds ok for me.
> That is a type that was moved recently but the extra elements in the
> package name certainly look weird.  Are you running the stock build.xml,
> and a regular javac?
>
> Regards,
> Tim
>
> Mikhail Loenko wrote:
> > Hello
> >
> > I've created a new workspace on a pure machine and trying to build classlib.
> >
> > I get the following error:
> >
> > compile:
> > [javac] Compiling 663 source files to H:\workspace\harmony\bin
> > [javac] 
> > H:\workspace\harmony\modules\luni\src\main\java\java\util\Locale.java:31:
> > cannot access org.apache.harmony.luni.internal.locale.Country
> > [javac] bad class file:
> > H:\workspace\harmony\bin\org\apache\harmony\luni\internal\locale\Country.class
> > [javac] class file contains wrong class:
> > modules.luni.src.main.java.org.apache.harmony.luni.internal.locale.Country
> > [javac] Please remove or make sure it appears in the correct
> > subdirectory of the classpath.
> > [javac] import org.apache.harmony.luni.internal.locale.Country;
> > [javac]^
> > [javac] 1 error
> >
> > BUILD FAILED
> > H:\workspace\harmony\make\build.xml:36: The following error occurred
> > while executing this line:
> > H:\workspace\harmony\make\build-java.xml:173: Compile failed; see the
> > compiler error output for details.
> >
> >
> > I'm trying to disassemble that class and see that it indeed has a wrong 
> > package:
> >
> >
> > H:\workspace\harmony\bin>javap 
> > org.apache.harmony.luni.internal.locale.Country
> > Compiled from "Country.java"
> > public class 
> > modules.luni.src.main.java.org.apache.harmony.luni.internal.locale.Country
> > extends java.util.ListResourceBundle{
> > public 
> > modules.luni.src.main.java.org.apache.harmony.luni.internal.locale.Country();
> > protected java.lang.Object[][] getContents();
> > }
> >
> >
> > What am I doing wrong? On my old machine everything works just fine.
> >
> > Thanks,
> > Mikhail.
> >
>
> --
>
> Tim Ellison ([EMAIL PROTECTED])
> IBM Java technology centre, UK.
>

Re: build problems

[Tim Ellison]

Mikhail,

I've just checked everything out from scratch and it builds ok for me.
That is a type that was moved recently but the extra elements in the
package name certainly look weird.  Are you running the stock build.xml,
and a regular javac?

Regards,
Tim

Mikhail Loenko wrote:
> Hello
> 
> I've created a new workspace on a pure machine and trying to build classlib.
> 
> I get the following error:
> 
> compile:
> [javac] Compiling 663 source files to H:\workspace\harmony\bin
> [javac] 
> H:\workspace\harmony\modules\luni\src\main\java\java\util\Locale.java:31:
> cannot access org.apache.harmony.luni.internal.locale.Country
> [javac] bad class file:
> H:\workspace\harmony\bin\org\apache\harmony\luni\internal\locale\Country.class
> [javac] class file contains wrong class:
> modules.luni.src.main.java.org.apache.harmony.luni.internal.locale.Country
> [javac] Please remove or make sure it appears in the correct
> subdirectory of the classpath.
> [javac] import org.apache.harmony.luni.internal.locale.Country;
> [javac]^
> [javac] 1 error
> 
> BUILD FAILED
> H:\workspace\harmony\make\build.xml:36: The following error occurred
> while executing this line:
> H:\workspace\harmony\make\build-java.xml:173: Compile failed; see the
> compiler error output for details.
> 
> 
> I'm trying to disassemble that class and see that it indeed has a wrong 
> package:
> 
> 
> H:\workspace\harmony\bin>javap org.apache.harmony.luni.internal.locale.Country
> Compiled from "Country.java"
> public class 
> modules.luni.src.main.java.org.apache.harmony.luni.internal.locale.Country
> extends java.util.ListResourceBundle{
> public 
> modules.luni.src.main.java.org.apache.harmony.luni.internal.locale.Country();
> protected java.lang.Object[][] getContents();
> }
> 
> 
> What am I doing wrong? On my old machine everything works just fine.
> 
> Thanks,
> Mikhail.
> 

-- 

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

Re: svn commit: r382185 - in /incubator/harmony/enhanced/classlib/trunk/native-src/linux.IA32: ./ fdlibm/ include/ lib/ text/ zlib/

[Tim Ellison]

Oops, thanks -- I already had lib/*.a so have just removed
linux.IA32/lib/ from the ignores.

Regards,
Tim

Mark Hindess wrote:
> On 01/03/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>> Author: tellison
>> Date: Wed Mar  1 14:35:08 2006
>> New Revision: 382185
>>
>> URL: http://svn.apache.org/viewcvs?rev=382185&view=rev
>> Log:
>> Refine SVN ignore property
>>
>>
>> Modified:
>> incubator/harmony/enhanced/classlib/trunk/native-src/linux.IA32/   
>> (props changed)
>  [SNIP]
>> Propchange: incubator/harmony/enhanced/classlib/trunk/native-src/linux.IA32/
>> --
>> --- svn:ignore (added)
>> +++ svn:ignore Wed Mar  1 14:35:08 2006
>> @@ -0,0 +1,4 @@
>> +*.so
>> +lib
>> +java
>> +
> 
> I know it's just a placeholder, but we probably shouldn't ignore lib
> since it contains a checked in file.  Fix is obviously to ignore
> lib*.a on lib instead.
> 
> -Mark.
> 

-- 

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

Re: [jira] Created: (HARMONY-152) Security module native build incorrectly use PATH variable

[Mikhail Loenko]

They are really case sensitive, but e.g. on my XP the variable's name is
'Path'

I think it should include all various pathes, like Path, PATH, and path
and do not include PAth and PatH

Thanks,
Mikhail

2006/3/2, Alexey Petrenko (JIRA) <[EMAIL PROTECTED]>:
> Security module native build incorrectly use PATH variable
> --
>
> Key: HARMONY-152
> URL: http://issues.apache.org/jira/browse/HARMONY-152
> Project: Harmony
>Type: Bug
>  Components: Classlib
>  Environment: WinXP
>Reporter: Alexey Petrenko
>
>
> modules/security/make/build.xml, line 163
> 
>
> Should be probably changed to
> 
>
> Since environment variables are case sensitive.
>
>
>
> --
> This message is automatically generated by JIRA.
> -
> If you think it was sent incorrectly contact one of the administrators:
>   http://issues.apache.org/jira/secure/Administrators.jspa
> -
> For more information on JIRA, see:
>   http://www.atlassian.com/software/jira
>
>

[jira] Created: (HARMONY-152) Security module native build incorrectly use PATH variable

[Alexey Petrenko (JIRA)]

Security module native build incorrectly use PATH variable
--

 Key: HARMONY-152
 URL: http://issues.apache.org/jira/browse/HARMONY-152
 Project: Harmony
Type: Bug
  Components: Classlib  
 Environment: WinXP
Reporter: Alexey Petrenko


modules/security/make/build.xml, line 163


Should be probably changed to 


Since environment variables are case sensitive.



-- 
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

build problems

[Mikhail Loenko]

Hello

I've created a new workspace on a pure machine and trying to build classlib.

I get the following error:

compile:
[javac] Compiling 663 source files to H:\workspace\harmony\bin
[javac] 
H:\workspace\harmony\modules\luni\src\main\java\java\util\Locale.java:31:
cannot access org.apache.harmony.luni.internal.locale.Country
[javac] bad class file:
H:\workspace\harmony\bin\org\apache\harmony\luni\internal\locale\Country.class
[javac] class file contains wrong class:
modules.luni.src.main.java.org.apache.harmony.luni.internal.locale.Country
[javac] Please remove or make sure it appears in the correct
subdirectory of the classpath.
[javac] import org.apache.harmony.luni.internal.locale.Country;
[javac]^
[javac] 1 error

BUILD FAILED
H:\workspace\harmony\make\build.xml:36: The following error occurred
while executing this line:
H:\workspace\harmony\make\build-java.xml:173: Compile failed; see the
compiler error output for details.


I'm trying to disassemble that class and see that it indeed has a wrong package:


H:\workspace\harmony\bin>javap org.apache.harmony.luni.internal.locale.Country
Compiled from "Country.java"
public class 
modules.luni.src.main.java.org.apache.harmony.luni.internal.locale.Country
extends java.util.ListResourceBundle{
public 
modules.luni.src.main.java.org.apache.harmony.luni.internal.locale.Country();
protected java.lang.Object[][] getContents();
}


What am I doing wrong? On my old machine everything works just fine.

Thanks,
Mikhail.

Re: Security module layout

[George Harley]

Hi Stepan,

Thanks for raising this. I agree with you that accomplishing the 
separate goals of HARMONY-95 and HARMONY-147 would probably be easier if 
security was first moved to the new layout (assuming it gets the 
blessing of the committers) before auth gets separated out.


Best regards,
George
IBM UK


Stepan Mishura wrote:

George, we are going to extract auth module (see HARMONY-95) and all
platform-specific java code will go into the new module.

To avoid patches conflict will we define a sequence in which we will apply
them? IMHO, it makes sense to adjust to proposed layout first and then to
perform auth module extraction. What do you think?

Thanks,
Stepan Mishura
Intel Middleware Products Division


On 3/1/06, George Harley <[EMAIL PROTECTED]> wrote:
  

Mikhail Loenko wrote:


Hi George

if you restructured the stuff on your computer, could you submit a
  

patch?


Thanks,
Mikhail

  

Hi Mikhail,

Yes, it has always been my hope to do so. Given the amount of change
involved, I just wanted to run things by the broader community before
proceeding to open a JIRA on the matter. Your feedback has been very
helpful and I will work towards getting the patch submitted today.

Best regards,
George
IBM UK




2006/2/27, Mikhail Loenko <[EMAIL PROTECTED]>:

  

2006/2/27, George Harley <[EMAIL PROTECTED]>:



Mikhail Loenko wrote:

  

Hi George

actually the native code we have in security should work on both
IA32 and IPF

So, it seems that with your suggestion we will have to have
two copies of that code. Please correct me if I'm wrong

What is about the following str:

+-win/
|  |
|  +--IA32/
|  |
|  +--IPF/
|  |
|  +-- common1.cpp
|  |
|  +-- common2.cpp
|  |
...

Thanks,
Mikhail




Looks good to me. And it's the same story under the "linux" folder ?

  

Exactly.

Thanks,
Mikhail





Best regards,
George
IBM UK


  

2006/2/27, George Harley <[EMAIL PROTECTED]>:




Jean-frederic Clere wrote:


  

Mikhail Loenko wrote:





Hi George,

why e.g. 'win.IA32' not just 'win'?




  

Because there will be a posix.apr that will do the portable part


;-)


Correct me if I am wrong.




...er...well, I'm not sure that it was foremost in my thoughts when
  

I


was working through the layout changes :-)

I simply wanted to have a way of differentiating between code
  

written


for 32-bit and 64-bit Windows on Intel architecture. I am assuming
  

that


the Windows code there today is for 32 bit. I did wonder about
  

splitting


those directory names up so that instead of a folder called "
  

win.IA32"


we had a "win" folder with a "IA32" sub-folder (and likewise for
  

Linux).


i.e.

java
 |
 +-common
 |
 +-win
 |  |
 |  \---IA32
 |
 +-linux
 |  |
 |  \---IA32
 |
 ...


The above approach leaves the way open for other variants (e.g.
  

64-bit


code) to be added in new sub-folders beneath "win" and "linux". In
  

the


end I opted for consistency with the "win.IA32" and "linux.IA32"
  

names


that are currently being used under the trunk/native-src folder in
  

SVN.


Best regards,
George
IBM UK



  

Cheers

Jean-Frederic





Thanks,
Mikhail

2006/2/24, George Harley <[EMAIL PROTECTED]>:




  

Hi,

Redrawing the proposed layout as it didn't render quite correctly
for me
when I read over the sent note (sigh).


 
   |
   |
   +---src
   |   |
   |   +---main
   |   |   |
   |   |   +---java
   |   |   |   |
   |   |   |   +---common
   |   |   |   |
   |   |   |   +---linux.IA32
   |   |   |   |
   |   |   |   \---win.IA32
   |   |   |
   |   |   +---native
   |   |   |   |
   |   |   |   +---linux.IA32
   |   |   |   |
   |   |   |   \---win.IA32
   |   |   |
   |   |   \---resources
   |   |   |
   |   |   \---common
   |   |
   |   +---test
   |   |
   |   +---java
   |   |
   |   +---common
   |   |
   |   +---linux.IA32
   |   |
   |   \---win.IA32
   |
   +---doc
   |   |
   |   \---images
   |
   +---make
   |   |
   |   \---native
   |   |
   |   +---linux
   |   |
   |   \---windows
   |
   +---META-INF



Best regards,
George
IBM UK



George Harley wrote:





Hi,

Earlier on today I spent some time following the instructions
  

for


developing Harmony Java code inside Eclipse [1]. After
  

experimenting


with archive, luni and nio I decided to check out
   

Re: Security module layout

[Stepan Mishura]

George, we are going to extract auth module (see HARMONY-95) and all
platform-specific java code will go into the new module.

To avoid patches conflict will we define a sequence in which we will apply
them? IMHO, it makes sense to adjust to proposed layout first and then to
perform auth module extraction. What do you think?

Thanks,
Stepan Mishura
Intel Middleware Products Division


On 3/1/06, George Harley <[EMAIL PROTECTED]> wrote:
>
> Mikhail Loenko wrote:
> > Hi George
> >
> > if you restructured the stuff on your computer, could you submit a
> patch?
> >
> > Thanks,
> > Mikhail
> >
> Hi Mikhail,
>
> Yes, it has always been my hope to do so. Given the amount of change
> involved, I just wanted to run things by the broader community before
> proceeding to open a JIRA on the matter. Your feedback has been very
> helpful and I will work towards getting the patch submitted today.
>
> Best regards,
> George
> IBM UK
>
>
> > 2006/2/27, Mikhail Loenko <[EMAIL PROTECTED]>:
> >
> >> 2006/2/27, George Harley <[EMAIL PROTECTED]>:
> >>
> >>> Mikhail Loenko wrote:
> >>>
>  Hi George
> 
>  actually the native code we have in security should work on both
>  IA32 and IPF
> 
>  So, it seems that with your suggestion we will have to have
>  two copies of that code. Please correct me if I'm wrong
> 
>  What is about the following str:
> 
>  +-win/
>  |  |
>  |  +--IA32/
>  |  |
>  |  +--IPF/
>  |  |
>  |  +-- common1.cpp
>  |  |
>  |  +-- common2.cpp
>  |  |
>  ...
> 
>  Thanks,
>  Mikhail
> 
> 
> >>> Looks good to me. And it's the same story under the "linux" folder ?
> >>>
> >> Exactly.
> >>
> >> Thanks,
> >> Mikhail
> >>
> >>
> >>
> >>> Best regards,
> >>> George
> >>> IBM UK
> >>>
> >>>
>  2006/2/27, George Harley <[EMAIL PROTECTED]>:
> 
> 
> > Jean-frederic Clere wrote:
> >
> >
> >> Mikhail Loenko wrote:
> >>
> >>
> >>
> >>> Hi George,
> >>>
> >>> why e.g. 'win.IA32' not just 'win'?
> >>>
> >>>
> >>>
> >>>
> >> Because there will be a posix.apr that will do the portable part
> ;-)
> >> Correct me if I am wrong.
> >>
> >>
> > ...er...well, I'm not sure that it was foremost in my thoughts when
> I
> > was working through the layout changes :-)
> >
> > I simply wanted to have a way of differentiating between code
> written
> > for 32-bit and 64-bit Windows on Intel architecture. I am assuming
> that
> > the Windows code there today is for 32 bit. I did wonder about
> splitting
> > those directory names up so that instead of a folder called "
> win.IA32"
> > we had a "win" folder with a "IA32" sub-folder (and likewise for
> Linux).
> > i.e.
> >
> > java
> >  |
> >  +-common
> >  |
> >  +-win
> >  |  |
> >  |  \---IA32
> >  |
> >  +-linux
> >  |  |
> >  |  \---IA32
> >  |
> >  ...
> >
> >
> > The above approach leaves the way open for other variants (e.g.
> 64-bit
> > code) to be added in new sub-folders beneath "win" and "linux". In
> the
> > end I opted for consistency with the "win.IA32" and "linux.IA32"
> names
> > that are currently being used under the trunk/native-src folder in
> SVN.
> >
> > Best regards,
> > George
> > IBM UK
> >
> >
> >
> >> Cheers
> >>
> >> Jean-Frederic
> >>
> >>
> >>
> >>> Thanks,
> >>> Mikhail
> >>>
> >>> 2006/2/24, George Harley <[EMAIL PROTECTED]>:
> >>>
> >>>
> >>>
> >>>
>  Hi,
> 
>  Redrawing the proposed layout as it didn't render quite correctly
>  for me
>  when I read over the sent note (sigh).
> 
> 
>   
> |
> |
> +---src
> |   |
> |   +---main
> |   |   |
> |   |   +---java
> |   |   |   |
> |   |   |   +---common
> |   |   |   |
> |   |   |   +---linux.IA32
> |   |   |   |
> |   |   |   \---win.IA32
> |   |   |
> |   |   +---native
> |   |   |   |
> |   |   |   +---linux.IA32
> |   |   |   |
> |   |   |   \---win.IA32
> |   |   |
> |   |   \---resources
> |   |   |
> |   |   \---common
> |   |
> |   +---test
> |   |
> |   +---java
> |   |
> |   +---common
> |   |
> |   +---linux.IA32
> |   |
> |   \---win.IA32
> |
> +---do