date:20060814

[classlib][luni] Serialization problem with EnumSet

2006-08-14 Thread Spark Shen


Hi All:
After reading the serialized form of EnumSet, I found an inner class

java.util.EnumSet.SerializationProxy.

This class does not have any extra explaination. Does any one has any 
suggestion on how to deal with it?


Best regards

--
Spark Shen
China Software Development Lab, IBM


-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: svn commit: r424890 - in /incubator/harmony/enhanced/classlib/trunk/modules/luni/src: main/java/java/io/BufferedInputStream.java test/java/tests/api/java/io/BufferedInputStreamTest.java

2006-08-14 Thread Richard Liang




Richard Liang wrote:



Vladimir Ivanov wrote:

No, this test will be fail if the issue 667 returns back :)


I see. Thanks a lot. I will try to provide a patch to fix this issue.

Harmony-1140 was raised. And Paulex had applied my patch. Thanks a lot.

Best regards,
Richard


Richard

Thanks, Vladimir


On 8/10/06, Richard Liang [EMAIL PROTECTED] wrote:




Paulex Yang wrote:
 Oops, it's my fault that missed to find this. Would you mind to
 provide a patch for this? or I'll fix it myself.
let me fix it. But I'm not sure if Vladimir Ivanov has any concerns
about this issue.

Richard.

 Richard Liang wrote:
 Hello Paulex,

 It seems that the test case is invalid, because the tests will 
always

 pass whether buf.close() throws IOException or not.

 +try {
 +buf.close();
 +} catch (IOException e) {
 +//expected
 +} }


 Please have a look at the following tests which passes on RI, but
 fails on Harmony.

 public void test_close() throws IOException {//regression 
for

 HARMONY-667
BufferedInputStream buf = new BufferedInputStream(null, 5);
buf.close();
}

 Thanks a lot.

 Best regards,
 Richard.

 [EMAIL PROTECTED] wrote:
 Author: pyang
 Date: Sun Jul 23 20:29:14 2006
 New Revision: 424890

 URL: http://svn.apache.org/viewvc?rev=424890view=rev
 Log:
 Fix for HARMONY-667 (
 [classlib][io]java.io.BufferedInputStream.skip(int n) unexpected 
NPE)


 Modified:


incubator/harmony/enhanced/classlib/trunk/modules/luni/src/main/java/java/io/BufferedInputStream.java 





incubator/harmony/enhanced/classlib/trunk/modules/luni/src/test/java/tests/api/java/io/BufferedInputStreamTest.java 




 Modified:

incubator/harmony/enhanced/classlib/trunk/modules/luni/src/main/java/java/io/BufferedInputStream.java 



 URL:

http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/modules/luni/src/main/java/java/io/BufferedInputStream.java?rev=424890r1=424889r2=424890view=diff 




== 



 ---

incubator/harmony/enhanced/classlib/trunk/modules/luni/src/main/java/java/io/BufferedInputStream.java 


 (original)
 +++

incubator/harmony/enhanced/classlib/trunk/modules/luni/src/main/java/java/io/BufferedInputStream.java 


 Sun Jul 23 20:29:14 2006
 @@ -1,4 +1,4 @@
 -/* Copyright 1998, 2005 The Apache Software Foundation or its
 licensors, as applicable
 +/* Copyright 1998, 2006 The Apache Software Foundation or its
 licensors, as applicable
   *   * Licensed under the Apache License, Version 2.0 (the
License);
   * you may not use this file except in compliance with the 
License.

 @@ -109,6 +109,9 @@
   * If an error occurs attempting to close this
stream.
   */
  public synchronized void close() throws IOException {
 +if(null == in){
 +throw new
 IOException(org.apache.harmony.luni.util.Msg.getString(K0059));
 +}
  super.close();
  buf = null;
  }
 @@ -311,6 +314,9 @@
   * occurs.
   */
  public synchronized long skip(long amount) throws 
IOException {

 +if(null == in){
 +throw new
 IOException(org.apache.harmony.luni.util.Msg.getString(K0059));
 +}
  if (amount  1)
  return 0;


 Modified:

incubator/harmony/enhanced/classlib/trunk/modules/luni/src/test/java/tests/api/java/io/BufferedInputStreamTest.java 



 URL:

http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/modules/luni/src/test/java/tests/api/java/io/BufferedInputStreamTest.java?rev=424890r1=424889r2=424890view=diff 




== 



 ---

incubator/harmony/enhanced/classlib/trunk/modules/luni/src/test/java/tests/api/java/io/BufferedInputStreamTest.java 


 (original)
 +++

incubator/harmony/enhanced/classlib/trunk/modules/luni/src/test/java/tests/api/java/io/BufferedInputStreamTest.java 


 Sun Jul 23 20:29:14 2006
 @@ -1,4 +1,4 @@
 -/* Copyright 1998, 2005 The Apache Software Foundation or its
 licensors, as applicable
 +/* Copyright 1998, 2006 The Apache Software Foundation or its
 licensors, as applicable
   *   * Licensed under the Apache License, Version 2.0 (the
License);
   * you may not use this file except in compliance with the 
License.

 @@ -120,6 +120,14 @@
  // Test for method void 
java.io.BufferedInputStream.close()

  new BufferedInputStream(isFile);
  new BufferedInputStream(isFile);
 +   +//regression for HARMONY-667
 +BufferedInputStream buf = new BufferedInputStream(null, 
5);

 +try {
 +buf.close();
 +} catch (IOException e) {
 +//expected
 +}  }

  /**
 @@ -310,6 +318,14 @@
  } catch (java.io.IOException e) {
  fail(Exception during skip test);
  }
 +
 +//regression

Re: Re: [general] compatibility packages

2006-08-14 Thread Alex Blewitt


On 14/08/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote:


3) Clearly there's value in providing these [sun.* classes], as other 
implementations
(BEA, IBM, Apple) include them.


Possibly true, but for different reasons. They license the source code
bulk from Sun, not re-implement their own. (They have patches etc.
that sit on top of them, of course.) As a result, there's a bunch of
internal stuff that is exactly the same as Sun's, and so depends on
the sun.* classes.

The value (to them) is that they don't have to spend time re-writing
the sun.* classes instead of something else. There's no value
necessarily to the end user; it's a selfish decision on their part,
nothing more.

Alex.

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [classlib][summary] Exception throwing compatibility

2006-08-14 Thread Richard Liang

Harmony-1170 has been raised to reflect our conclusion. I have attached 
a patch for site/xdocs/subcomponents/classlibrary/compat.xml


Best regards,
Richard

Richard Liang wrote:

Hello All,

I'd like to update our Exception-throwing compatibility[1] to 
reflect our discussion in several threads recently. I just created a 
wiki page here[2], please kindly comment or update the wiki page 
directly. If there is no objection, I will provide a patch for 
site/xdocs/subcomponents/classlibrary/compat.xml


Thanks a lot.

[1] 
http://incubator.apache.org/harmony/subcomponents/classlibrary/compat.html 


[2] http://wiki.apache.org/harmony/Exception-throwing_compatibility



--
Richard Liang
China Software Development Lab, IBM 




-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [jira] Created: (HARMONY-1113) [classlib][beans]Harmony does not throw IllegalArgumentException for java.beans.PropertyEditorSupport.setAsText() while RI does.

2006-08-14 Thread Mikhail Loenko


Hi Ilya

Is it significant that the test code is in bootclasspath, or it can
work from classpath?

There were some discussions around the tests that might be interesting,
please look at [1].

Please look at the section
Utilize JUnit's assert/fail methods and exception handling for clean test code

This also might be useful [2]

Thanks,
Mikhail

[1] 
http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200603.mbox/[EMAIL
 PROTECTED]

[2] 
http://incubator.apache.org/harmony/subcomponents/classlibrary/agreements.html


2006/8/9, Ilya Okomin (JIRA) [EMAIL PROTECTED]:

[classlib][beans]Harmony does not throw IllegalArgumentException for 
java.beans.PropertyEditorSupport.setAsText() while RI does.


Key: HARMONY-1113
URL: http://issues.apache.org/jira/browse/HARMONY-1113
Project: Harmony
 Issue Type: Bug
 Components: Classlib
   Reporter: Ilya Okomin
   Priority: Minor
Attachments: PropertyEditorSupport.patch, 
PropertyEditorSupportTest.patch

Harmony does not throw IllegalArgumentException for 
java.beans.PropertyEditorSupport.setAsText(String) when parameter is invalid
while RI throws IllegalArgumentException.
Java 1.5.0 spec says:May raise java.lang.IllegalArgumentException if either the 
String is badly formatted or if this kind of property can't be expressed as text.
=test.java==
import java.beans.PropertyEditorSupport;

public class test {

   public static void main(String args[]) {
   PropertyEditorSupport undefPropertyEditorSupport = new
PropertyEditorSupport();
   try {
   System.err.print(value is null: );
   undefPropertyEditorSupport.setAsText(string);
   System.err.println(failed: IllegalArgumentException expected, but
nothing was thrown!\n);
   } catch (IllegalArgumentException eE) {
   System.err.println(success!);
   eE.printStackTrace();
   }

   PropertyEditorSupport defPropertyEditorSupport = new
PropertyEditorSupport();
   try {
   defPropertyEditorSupport.setValue(new Object());

   System.err.print(value is Object: );
   defPropertyEditorSupport.setAsText(string);
   System.err.println(failed: IllegalArgumentException expected, but
nothing was thrown!\n);
   } catch (IllegalArgumentException eE) {
   System.err.println(success!);
   eE.printStackTrace();
   }

   defPropertyEditorSupport = new PropertyEditorSupport();
   try {
   defPropertyEditorSupport.setValue(new String());
   System.err.print(value is String: );
   defPropertyEditorSupport.setAsText(string);
   System.err.println(success!);
   } catch (IllegalArgumentException eE) {
   System.err.println(failed!);
   eE.printStackTrace();
   }

   }

}
===
Output:

Harmony:
java version 1.5.0
pre-alpha : not complete or compatible
svn = r424571, (Jul 22 2006), Windows/ia32/msvc 1310, release build
http://incubator.apache.org/harmony

value is null: failed: IllegalArgumentException expected, but nothing was
thrown!

value is Object: failed: IllegalArgumentException expected, but nothing was
thrown!

value is String: success!

RI:
java version 1.5.0
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-b64)
BEA WebLogic JRockit(R) (build dra-38972-20041208-2001-win-ia32, R25.0.0-75,
GC: System optimized over throughput (initial strategy singleparpar))

value is null: success!
java.lang.IllegalArgumentException: string
   at
java.beans.PropertyEditorSupport.setAsText(PropertyEditorSupport.java:166)
   at bugzilla.Test9433.main(Test9433.java:11)
value is Object: success!
java.lang.IllegalArgumentException: string
   at
java.beans.PropertyEditorSupport.setAsText(PropertyEditorSupport.java:166)
   at bugzilla.Test9433.main(Test9433.java:23)
value is String: success!

For this reason, suggested solution is to check in setAsText() method if the
value is instanse of String, in case of true - setValue, otherwise - throw an
IAE following the spec, ...this kind of property can't be expressed as text.

Suggested patch and regression test can be found in the attach


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





-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [testing] metadata approach

2006-08-14 Thread Oliver Deakin

Alexei Zakharov wrote:

Hi Oliver,

So perhaps the build system should be changed temporarily so that
we dont self host the test harness? i.e. until we get
java.util.concurrent,

run Ant and the subsequent TestNG process with RI or other non-Harmony
VM, and launch the tests with Harmony VM using the jvm option.

The bad news is that TestNG requires j.u.c stuff even for single test
execution (i.e. in any case if jvm=path to harmony). :( So if we
want to run annotated tests with TestNG (even from the command line)
we need j.u.c.

then we could run TestNG with the RI (which has j.u.c) and use the
jvm option to specify the Harmony VM (which would not need j.u.c).
Please correct me if Im wrong - I'm just trying to explore our options in
the hope that we can start to move to TestNG soon.

That's odd - Thread.class in luni-kernel (VME v4) definitely contains a
getId() method.

May be I did something wrong - I will check tomorrow.

I do like them - in fact I was going to link his mail after that point
but couldn't find it.

Here is the link:
http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200607.mbox/[EMAIL PROTECTED]

Thanks - it was good to reread.

As far as I remember there was additions to the George's list like
using @Test (groups={os.any} ) rather than simple @Test for API
tests that run on any platform.

Yes agreed, it is good to make group membership explicit as it facilitates
inclusion/exclusion of groups, and makes it obvious which group tests
belong to. Perhaps the same should be done for api tests, so we have a
type.api group?
I thought I had sent a mail out on this in the original thread, but I guess
I never did (unless Thunderbird is hiding mail from me again!).

We have had discussions on the list about platform specific native
code organisation, and I think organisation of platform specific tests
can be handled in a similar way.
So we would have an os.shared (or os.any, Im just going with shared
as that is what we use for the native code) group that would run on all
platforms. If there are platform specific tests, they would be grouped
by os, then architecture (and then possibly word size).
So, for example, if we were on a Windows x86 32bit machine, the Ant
scripts would run test groups os.shared, os.windows, os.windows.x86
and (if we ever get any 32/64bit specific tests) os.windows.x86.32bit,
or something similar.

I think this tallies with what George was suggesting, and makes sense to
me. Are there any objections to this approach?

Regards,
Oliver

I really mean that we should make sure that everyone is happy with
a certain set of group names before going ahead and applying them.
Once they are decided upon, they should be added to the testing
conventions webpage.

Yes, agree.

With Best Regards,

2006/8/10, Oliver Deakin [EMAIL PROTECTED]:

Alexei Zakharov wrote:
We now have this, so let the TestNG debate continue :)
Unfortunately, we still need java.util.concurrent :-(

Yeah, TestNG 5.0 still throws java.lang.NoClassDefFoundError :
java.util.concurrent.LinkedBlockingQueue on Harmony+j9v4.

So perhaps the build system should be changed temporarily so that
we dont self host the test harness? i.e. until we get
java.util.concurrent,

run Ant and the subsequent TestNG process with RI or other non-Harmony
VM, and launch the tests with Harmony VM using the jvm option.
At least it will allow us to move forward with TestNG (if that's what we
decide) without having to wait for java.util.concurrent. Then when
we have j.u.c, start self-hosting again.
Comments?

I've also got an error while trying to compile TestNG 5.0 tests with
Harmony+j9v4+ecj: The method getId() is undefined for the type Thread

That's odd - Thread.class in luni-kernel (VME v4) definitely contains a
getId() method. I don't know anything about the TestNG tests - how are
they run? is luni-kernel.jar definitely at the front of the
bootclasspath?

- If we go ahead with TestNG, we need to select a set of group
names

to use to indicate exclusion, platform specificness etc.

Don't you like the names suggested by George?

I do like them - in fact I was going to link his mail after that point
but couldn't
find it. I really mean that we should make sure that everyone is
happy with

a certain set of group names before going ahead and applying them.
Once they are decided upon, they should be added to the testing
conventions webpage.

- Decide whether some physical separation of tests on disk is
necessary, for instance to separate classpath and bootclasspath
tests

IMHO it is ok to separate classpath and bootclasspath tests because it
will be easer to implement such solution technically.

I agree, although I don't feel strongly about it.

Regards,

Re: [classlib][luni] Serialization problem with EnumSet

2006-08-14 Thread Oleg Khaschansky


It looks like EnumSet.SerializationProxy is the class that is
serialized instead of EnumSet, since it overrides readResolve method
and contains the information, essential for re-creation of EnumSet.
Probably, the scheme looks like this:
1) EnumSet overrides writeReplace which returns appropriate
EnumSet.SerializationProxy object, which is serialized.
2) When EnumSet.SerializationProxy is deserialized, readResolve method
is called to replace deserialized instance of
EnumSet.SerializationProxy with appropriate EnumSet object. This
method constructs EnumSet object with one of its factory methods
(noneOf suits for this, probably) and initializes it properly.

See API specification for Serializable interface for the description
of readResolve/writeReplace.

I am not an expert in serialization, so I am not sure if we need to
copy this behavior to be compatible with RI or it is possible just to
use SerialVersionUID and serialized form of EnumSet.SerializationProxy
for our EnumSet.

On 8/14/06, Spark Shen [EMAIL PROTECTED] wrote:

Hi All:
After reading the serialized form of EnumSet, I found an inner class

java.util.EnumSet.SerializationProxy.

This class does not have any extra explaination. Does any one has any
suggestion on how to deal with it?

Best regards

--
Spark Shen
China Software Development Lab, IBM


-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [classlib] [ldap] support for multiple VMs?

2006-08-14 Thread Oliver Deakin


Alexey Varlamov wrote:

2006/8/11, Gregory Shimansky [EMAIL PROTECTED]:

2006/8/11, Tim Ellison [EMAIL PROTECTED]:

 Daniel Gandara wrote:
  Hi all,
 
  We are working on the javax.naming.ldap and we are facing the
  following issue when thinking about supporting multiple VMs.
  Following the SPEC there is a method createExtendedResponse in the
  StartTlsRequest class which states that the returning object must be
  an instance of a concrete subclass of StartTlsResponse and must have
  a public zero-argument constructor. The concrete subclass is
  determined by reading the configuration file located in
  META-INF/services/javax.naming.ldap.StartTlsResponse (see
 
 
http://java.sun.com/j2se/1.5.0/docs/api/javax/naming/ldap/StartTlsRequest.html 


 )
 
  The search for this configuration file is done by looking in the
  classpath, java.home and user.dir; also the Xbootclasspath should be
  inspected, and that seems to be a problematic situation, since there
  is not a standard property to look for its value. Different VM
  implementations have different property names for the boot class 
path

  value. In the old Harmony VM implementation was
  com.ibm.oti.system.class.path; in the new one is
  org.apache.harmony.boot.class. The property name in the Sun's VM is
  sun.boot.class.path. We are wondering which property name to use in
  the code. At first sight the Harmony new VM implementation property
  seems to be the better option, but maybe looking for the other
  properties will be interesting for compatibility purposes.
 
  We would be very interested in opinions.

 I'd ignore the com.ibm property and look through the path defined by
 org.apache.harmony.boot.class.path

 I don't know what property is set by the DRLVM / JCHEVM / etc., but it
 would be good if they set the same property (maybe in addition to 
their

 current property).


DRLVM sets two propeties with the same value. The one which is used 
by VM is

vm.boot.class.path and another added for compatibility with some
applications is sun.boot.class.path. It is not used inside of VM. I 
compared
values with org.apache.harmony.boot.class.path with is set in 
classlib luni

and foind that the only difference is with kernel.jar absent in it and
present in DRLVM properties. It is logical because they both read the 
same
bootclasspath.properties file but VM also adds kernel.jar before 
everything.


I wonder if DRLVM starts to use the same
org.apache.harmony.boot.class.pathproperty wouldn't it be overwritten
with luni initialization with value
wihout kernel.jar?



Besides, the luni init only recognizes -Xbootclasspath: runtime
parameter, but not append/prepend variants
(-Xbootclasspath[/a|/p]:). Yet another argument to unify and share
such code. Is there any reason to do this in classlib?


Where else would you do it?
As Tim mentioned earlier in this thread, we cannot do this in the launcher.
Remember that the Harmony java launcher is not the only launcher that will
ever run with Harmony code. If we put the bootclasspath.properties
parsing code into the launcher, then that means anyone who writes their own
launcher will get an empty bootclasspath unless they parse the file 
themselves.


IMHO, I would say that:
- the launcher should not too Harmony specific. Anything special we do 
there

may well have consequences for other more generic launchers.
- the bootclasspath.properties file is read by classlib because it 
relates to the
classlib component. It is a file that is specific to the Harmony 
classlib, and we should

not expect any other component (launcher/VM) to have knowledge of it. If
bootclasspath.properties parsing is moved out of classlib, there will also
be a knock-on effect for VMs that use the Harmony classlib via 
classlibadapter,

as they will no longer get the correct bootclasspath for free.
- the VM should prepend its kernel jars to the bootclasspath. They are 
a part of the
VM half of the Harmony runtime (i.e. any other VM provider would have to 
provide
them in its VM bundle, as the IBM VME does), and thus should be handled 
by the
VM itself. At the moment the kernel jars are called luni-kernel.jar and 
security-kernel.jar,
but there is nothing to stop another VM wanting to call them something 
different and
still use Harmony classlib. If the addition of the kernel jars to the 
bootclasspath was
done in classlib, then only the hardcoded names would be valid. I think 
this adds
another contract between the classlib and VM that is unnecessary. All 
classlib should

expect is that the VM will provide those classes at runtime.

I think that what really needs to be done is to improve the code that is 
already, IMO,

in the right place, rather than move it elsewhere.

Regards,
Oliver



--
Alexey




If you want the code to run on the Sun implementation too then you
 should *also* search the sun.boot.class.path, and of course be 
tolerant
 of o.a.harmony... or sun.boot... being absent.  Is running on Sun a 
goal

 for you?  It's not

75 matches

Mail list logo