Re: [ot] getting silly
>> Вы можете пойти здесь http://babelfish.altavista.com/. Будет сериями >> потехи! Как наблюдать рыбу те велосипед. :-) He bought the English-Russian dictionary and studied the English-Russian language... :-) Yes, back to work. Regards, 17.11.06, Stefano Mazzocchi<[EMAIL PROTECTED]> написал(а): Geir Magnusson Jr. wrote: > You know someone is going to spin this... "see, they even do all their > development discussion in Russian..." lol > geir > > > Tim Ellison wrote: >> Вы можете пойти здесь http://babelfish.altavista.com/. Будет сериями >> потехи! Как наблюдать рыбу те велосипед. :-) >> >> Time to get back to the code me thinks. >> >> Tim >> >> Alexei Zakharov wrote: >>> +1 >>> >>> "Intelovskiye" is just the exact spelling of the russian >>> pronunciation. It is interesting how it translates this back to >>> Russian. :-D >>> >>> 17.11.06, Mikhail Loenko<[EMAIL PROTECTED]> написал(а): >>>> LOL >>>> >>>> 17.11.06, Tim Ellison<[EMAIL PROTECTED]> написал(а): >>>>> Orlov, Alexander M wrote: >>>>>> Folks, >>>>>> >>>>>> I'm awfully sorry, that should have been personal letter. If you >>>>>> don't understand Russian just ignore it. If you understand it please >>>>>> ignore it too. >>>>>> >>>>>> My favorite mistake to Reply to the mailing list and not change the >>>>>> recipient. :) >>>>> Don't worry, we all do it. And for fun of course I had to paste it >>>> into >>>>> BabelFish (I learnt Russian at school for two years, but that was a >>>>> _long_ time ago). >>>>> >>>>> I don't wish to embarrass you, I just thought it was funny that you >>>> said >>>>> (apparently): >>>>> >>>>> "Antokha, I can make mistakes, but like COO and >>>>> the code is scan - these are such internal >>>>> Intelovskiye pribambasy." >>>>> >>>>> I particularly like "Intelovskiye" :-) -- Alexei Zakharov, Intel Enterprise Solutions Software Division
Re: [general] Harmony Todo list
+1 "Intelovskiye" is just the exact spelling of the russian pronunciation. It is interesting how it translates this back to Russian. :-D 17.11.06, Mikhail Loenko<[EMAIL PROTECTED]> написал(а): LOL 17.11.06, Tim Ellison<[EMAIL PROTECTED]> написал(а): > Orlov, Alexander M wrote: > > Folks, > > > > I'm awfully sorry, that should have been personal letter. If you > > don't understand Russian just ignore it. If you understand it please > > ignore it too. > > > > My favorite mistake to Reply to the mailing list and not change the > > recipient. :) > > Don't worry, we all do it. And for fun of course I had to paste it into > BabelFish (I learnt Russian at school for two years, but that was a > _long_ time ago). > > I don't wish to embarrass you, I just thought it was funny that you said > (apparently): > > "Antokha, I can make mistakes, but like COO and > the code is scan - these are such internal > Intelovskiye pribambasy." > > I particularly like "Intelovskiye" :-) -- Alexei Zakharov, Intel Enterprise Solutions Software Division
Re: [classlib][sql] SerialJavaObject constructor throws SerialException when the object is unserializable?
Hi,
It is interesting question. What are advantages of such serialization
model? IMHO majority of Java classes in the world have static fields.
:-) What are usage patterns of this class?
Thanks,
2006/11/16, Andrew Zhang <[EMAIL PROTECTED]>:
On 11/13/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote:
>
> I guess that Sun has implemented some behavior and some exception
> could be thrown by that implementation.
Sorry for my late reply... Just back from travelling. :)
I don't quite get the point. What does "that implementation" mean? Is it
invoked in SerialJavaObject constructor?
Then they wrapped that exception
> by SerialException and documented in the spec ;)
>
> You might want to implement it without exception throwing and if we find
> an
> inconsistency later -- fix it
ya, I'd like to follow this way. If we find any problem, fix it then. :-)
If no one objects, I'll ignore static/transient check in the constructor.
Thanks!
Thanks,
> Mikhail
>
> 2006/11/12, Andrew Zhang <[EMAIL PROTECTED]>:
> > Hi folks,
> >
> > I'm confused by javax.sql.rowset.serial.SerialJavaObject spec. The spec
> of
> > SerialJavaObject constructor says "throws SerialException if the object
> is
> > found to be unserializable". It also mentions "Static or transient
> fields
> > cannot be serialized; an attempt to serialize them will result in a
> > SerialException object being thrown. ". Does it mean to throw
> > SerialException if the object doesn't implement Serializable or it
> contains
> > static/transient fields? I tried some tests[1], but SerialException is
> never
> > thrown. Am I missing something? Thank you in advance for your help!
> >
> > [1] SerialJavaObject constructor test case:
> > public void test_Constructor() throws Exception {
> > Object obj = new NonSerializableClass();
> > SerialJavaObject sjo = new SerialJavaObject(obj);
> > }
> >
> > static class NonSerializableClass {
> > public static int i;
> > public static Thread t;
> > public transient String s;
> > NonSerializableClass() {
> >
> > }
> > }
--
Alexei Zakharov,
Intel Enterprise Solutions Software Division
Re: [classlib][beans] analyzing indexed properties
Thanks for the review Tim. I'm going to file "non-bug" JIRA if no one objects.
Regards,
2006/11/17, Tim Ellison <[EMAIL PROTECTED]>:
Looks like an RI bug to me. I'd expect it to return the property:
public String[] getProp1()
public void setProp1(String[] val)
Regards,
Tim
Alexei Zakharov wrote:
> Hi all,
>
> I'd like to propose another [beans] topic for discussion. IMHO RI's
> Introspector behaves oddly during analyzing some exotic beans. Let's
> look at the following piece of code for example:
>
> ---
> import java.beans.*;
>
> public class TestIntrospector2 {
>
>public static class MyParent {
>public Integer getProp1(int i) {
>return new Integer(1);
>}
>
>public void setProp1(int i, Integer val) {}
>}
>
>public static class MyClass extends MyParent {
>public String[] getProp1() {
>return new String[2];
>}
>
>public void setProp1(String[] val) {}
>}
>
>public static void main(String[] argv) throws Exception {
>BeanInfo binfo = Introspector.getBeanInfo(MyClass.class,
> Object.class);
>PropertyDescriptor[] pds = binfo.getPropertyDescriptors();
>
>for (PropertyDescriptor pd : pds) {
>System.out.println("Name: " + pd.getName());
>System.out.println("Descriptor type: " +
> pd.getClass().getName());
>System.out.println("Property type: " + pd.getPropertyType());
>if (pd instanceof IndexedPropertyDescriptor) {
>System.out.println("Property indexed type: " +
>((IndexedPropertyDescriptor)
> pd).getIndexedPropertyType());
>}
>}
>}
> }
> ---
>
> The output on RI is the following:
>
> Name: prop1
> Descriptor type: java.beans.IndexedPropertyDescriptor
> Property type: null
> Property indexed type: class java.lang.Integer
>
> So it identifies an indexed property here. But it is nonsense since
> array accessor methods have the type that differs from the one of
> regular accessor methods. More formal: this is against the design
> patterns for indexed properties described in JavaBeans spec (§ 8.3.3,
> pages 55-56). So my assumption is we should report the regular
> property that has String[] type here. Any thoughts, objections?
>
> Thanks.
--
Alexei Zakharov,
Intel Enterprise Solutions Software Division
Re: [drlvm] [testing] Excluding commit tests until the problem is fixed
Hi Vladimir,
It seems everybody likes this approach. In that case, I have another
idea for exclude lists. Can't we go further and extend the current
exclude list functionality a bit more? And forget about TestNG and
friends for a while I mean.
For example, we can put exclude lists into something like:
exclude.xml:
---
...
exclude.linux.drlvm.xml:
---
And etc. ${hy.platfrom}and ${hy.harmony.vm.name} can be passed to the
controller test suite by ant. By the controller test suite I mean the
java class that knows how to parse the above files (using simple SAX
parser for example - it is easy, I can help if needed) and implements
junit TestSuite model to get fine-grained control over the testing
process.
IMHO this can be a nice solution for now. It's more powerful since it
allows to exclude individual tests rather that whole classes. What do
you think?
Thanks,
2006/11/15, Vladimir Ivanov <[EMAIL PROTECTED]>:
Seems, we says about different things :)
First of all, we have no TestNG (or other harness) yet but we need now
different exclude lists for different platforms.
Also, in my vision these exclude-lists are like a buffer before we mark test
by correct tags.
When the test fails on some platform we update the corresponding x-list and
investigate this failure.
As the result of investigation we mark the test or fix it.
Thanks, Vladimir
On 11/15/06, Alexei Zakharov <[EMAIL PROTECTED]> wrote:
>
> Things become more and more complicated. Can anyone say why we
> rejected to use TestSuites for this purpose from the very beginning?
> Well, I can't say I am against using xml lists here. But the next step
> will be to keep list of individual failing test methods in the xml
> file. Then to create separate xml lists for api and impl tests and so
> on. If we can't run original TestNG on Harmony then we invent it by
> ourselves. :-)
>
> Thanks,
>
> 2006/11/15, Vladimir Ivanov <[EMAIL PROTECTED]>:
> > As part of solution for this issue the
> > *HARMONY-2197*<http://issues.apache.org/jira/browse/HARMONY-2197> was
> > created.
> >
> > I suggest using the separate exclude list for each platform. I hope in
> this
> > case the test enabling for the different platforms will be easy. Please,
> > look at it.
> >
> > Any comments are welcome :)
> >
> >
> >
> > Thanks, Vladimir
> >
> >
> > On 11/15/06, Alexei Fedotov <[EMAIL PROTECTED]> wrote:
> > >
> > > Pavel, you are correct. Rana, sorry for confusion. Both issues block
> > > passing class library unit tests.
> > >
> > > http://issues.apache.org/jira/browse/HARMONY-2070 [drlvm][thread]
> > > Unhandled exception in java.exe while java.util.jar module tests
> > > execution
> > >
> > > http://issues.apache.org/jira/browse/HARMONY-2073 [drlvm][unit]
> > > org.apache.harmony.beans.tests.java.beans.PersistenceDelegateTest
> > >
> > > I've used a debugger and caught an assert in
> > > exn_raise_by_name_internal for the second one. The first one contains
> > > three diffrent issues, and I cannot say where exactly the problem is.
> > >
> > > On 11/15/06, Pavel Afremov < [EMAIL PROTECTED]> wrote:
> > > > As I understand Alexey means HARMONY-2073, but not HARMONY-2070.
> > > >
> > > > Alexei, is it correct? If not, could you clarify the point about
> > > > exn_raise_by_name_internal in your initial letter, please?
> > > >
> > > >
> > > > Pavel Afremov.
> > > >
> > > >
> > > > On 11/8/06, Rana Dasgupta <[EMAIL PROTECTED]> wrote:
> > > > >
> > > > > OK thanks Pavel, I'll try the patch today.
> > > > >
> > > > > Rana
> > > > >
> > > > >
> > > > > On 11/8/06, Pavel Afremov <[EMAIL PROTECTED]> wrote:
> > > > > >
> > > > > > Hi Rana.
> > > > > >
> > > > > >
> > > > > >
> > > > > > I extend guard region as work around. It's only one way, which
> "fix"
> > > SOE
> > > > > > on
> > > > > > my SuSE Linux, without potential regression of your fix. On my
> Linux
> > >
> > > > > > machine
> > > > > > violation access signals happen one page before protected page
> on
> > > the
> > > > > > stack.
> > > > > > It's it.
> > > > > >
> > > > > >
> > > > > >
> &
[classlib][beans] analyzing indexed properties
Hi all,
I'd like to propose another [beans] topic for discussion. IMHO RI's
Introspector behaves oddly during analyzing some exotic beans. Let's
look at the following piece of code for example:
---
import java.beans.*;
public class TestIntrospector2 {
public static class MyParent {
public Integer getProp1(int i) {
return new Integer(1);
}
public void setProp1(int i, Integer val) {}
}
public static class MyClass extends MyParent {
public String[] getProp1() {
return new String[2];
}
public void setProp1(String[] val) {}
}
public static void main(String[] argv) throws Exception {
BeanInfo binfo = Introspector.getBeanInfo(MyClass.class, Object.class);
PropertyDescriptor[] pds = binfo.getPropertyDescriptors();
for (PropertyDescriptor pd : pds) {
System.out.println("Name: " + pd.getName());
System.out.println("Descriptor type: " + pd.getClass().getName());
System.out.println("Property type: " + pd.getPropertyType());
if (pd instanceof IndexedPropertyDescriptor) {
System.out.println("Property indexed type: " +
((IndexedPropertyDescriptor)
pd).getIndexedPropertyType());
}
}
}
}
---
The output on RI is the following:
Name: prop1
Descriptor type: java.beans.IndexedPropertyDescriptor
Property type: null
Property indexed type: class java.lang.Integer
So it identifies an indexed property here. But it is nonsense since
array accessor methods have the type that differs from the one of
regular accessor methods. More formal: this is against the design
patterns for indexed properties described in JavaBeans spec (§ 8.3.3,
pages 55-56). So my assumption is we should report the regular
property that has String[] type here. Any thoughts, objections?
Thanks.
--
Alexei Zakharov,
Intel Enterprise Solutions Software Division
Re: [drlvm] [testing] Excluding commit tests until the problem is fixed
Things become more and more complicated. Can anyone say why we rejected to use TestSuites for this purpose from the very beginning? Well, I can't say I am against using xml lists here. But the next step will be to keep list of individual failing test methods in the xml file. Then to create separate xml lists for api and impl tests and so on. If we can't run original TestNG on Harmony then we invent it by ourselves. :-) Thanks, 2006/11/15, Vladimir Ivanov <[EMAIL PROTECTED]>: As part of solution for this issue the *HARMONY-2197*<http://issues.apache.org/jira/browse/HARMONY-2197> was created. I suggest using the separate exclude list for each platform. I hope in this case the test enabling for the different platforms will be easy. Please, look at it. Any comments are welcome :) Thanks, Vladimir On 11/15/06, Alexei Fedotov <[EMAIL PROTECTED]> wrote: > > Pavel, you are correct. Rana, sorry for confusion. Both issues block > passing class library unit tests. > > http://issues.apache.org/jira/browse/HARMONY-2070 [drlvm][thread] > Unhandled exception in java.exe while java.util.jar module tests > execution > > http://issues.apache.org/jira/browse/HARMONY-2073 [drlvm][unit] > org.apache.harmony.beans.tests.java.beans.PersistenceDelegateTest > > I've used a debugger and caught an assert in > exn_raise_by_name_internal for the second one. The first one contains > three diffrent issues, and I cannot say where exactly the problem is. > > On 11/15/06, Pavel Afremov < [EMAIL PROTECTED]> wrote: > > As I understand Alexey means HARMONY-2073, but not HARMONY-2070. > > > > Alexei, is it correct? If not, could you clarify the point about > > exn_raise_by_name_internal in your initial letter, please? > > > > > > Pavel Afremov. > > > > > > On 11/8/06, Rana Dasgupta <[EMAIL PROTECTED]> wrote: > > > > > > OK thanks Pavel, I'll try the patch today. > > > > > > Rana > > > > > > > > > On 11/8/06, Pavel Afremov <[EMAIL PROTECTED]> wrote: > > > > > > > > Hi Rana. > > > > > > > > > > > > > > > > I extend guard region as work around. It's only one way, which "fix" > SOE > > > > on > > > > my SuSE Linux, without potential regression of your fix. On my Linux > > > > > machine > > > > violation access signals happen one page before protected page on > the > > > > stack. > > > > It's it. > > > > > > > > > > > > > > > > I ran all tests, and everything was OK. But strange misprint was > fount > > > in > > > > the new test. > > > > > > > > So I attach new fixed patch. > > > > > > > > > > > > > > > > Pavel Afremov. > > > > > > > > > > > > On 11/8/06, Rana Dasgupta <[EMAIL PROTECTED]> wrote: > > > > > > > > > > Though I tried several times, I could not repro 2070 or Alexey's > > > > specific > > > > > problems. The test attached to 2018 repros, and that I think is > > > enough. > > > > > > > > > > Pavel, > > > > > 1. The patch looks good, but I could not apply and try it since > my > > > > Linux > > > > > box is down. > > > > > 2. Did you run all tests ( smoke, cuint, kernel, and classlib )? > > > > Since > > > > > this fully turns on lazy exceptions, we need to ensure that all > tests > > > > > pass, > > > > > or at least have identical behaviour before and after the pacth. > > > > > 3. Adding a finalizer based stack test to smoke is a good idea. > > > > > 4. On Linux you extend the guard region up ( or down whatever ) > by a > > > > > page. Did you find a good reason for it, or is this just being > > > careful? > > > > > > > > > > Rana > > > > > > > > > > > > > > > > > > > > > > > > > On 11/7/06, Pavel Afremov < [EMAIL PROTECTED]> wrote: > > > > > > > > > > > > Rana, > > > > > > > > > > > > Everything is correct in you description, but it looks like that > * > > > > > > HARMONY-2018* < > https://issues.apache.org/jira/browse/HARMONY-2018> > > > > > should > > > > > > fix described bug. I think Alexei will have a chance to check > it. -- Alexei Zakharov, Intel Enterprise Solutions Software Division
Re: [jira][attachments] Is it possible to mark attachments as obsolete?
I prefer to name the updated patch "some.patch_updated" (if the name of the original patch was "some.patch"). I am always puzzled when I see two identical names in attachments. Thanks, 2006/11/15, Salikh Zakirov <[EMAIL PROTECTED]>: Alexey Petrenko wrote: > Is it possible to configure JIRA to let people to mark issue > attachments as obsolete? Like in Bugzilla? > This is very useful feature when issue has few iterations of the fix. Trick: upload the file with exactly the same name, then the latest one will be marked as "latest" (in mouse-over baloon), and earlier versions will be shown in gray. I use this trick for some time. However, I've seen cases when other contributors ignored "gray" color of the attachment and reviewed/tested/committed incorrect patch. So, probably, some care from the reviewers/committers is also needed. -- Alexei Zakharov, Intel Enterprise Solutions Software Division
Re: [classlib] Using Aspects for Tracing
I'm not entirely sure what you mean by application-level logging.
Well, I mean the situation when log calls are scattered around the
code. Something like this:
---
void dataExchange() throws Exception {
boolean handshakePerformed = false;
log("in performConnection"); // log point 1
...
for (int i = 0; i < 5; i++) {
int k = performHandshake();
if (k == NEED_MORE_DATA) {
log("server responded: needs more data"); // log point 2
addSomeDataForServer();
} else if (k == NEED_MORE_SECURITY) {
log("server responded: needs more security"); // log point 3
addMoreSecurity();
} else if (k == OK) {
handshakePerformed = true;
log("handshake OK"); // log point 4
break;
}
}
if (!handshakePerformed) {
log("give up: unable to handshake"); // log point 5
throw new Exception("unable to handshake");
}
log("ready to send data"); // log point 6
log("leaving performConnection"); // log point 7
}
---
From your explanation I've understood that aspects can be used for
points one and seven. Is it possible to cover other log points with
aspects? What should be done for this (if so)?
Thanks,
2006/11/14, Sian January <[EMAIL PROTECTED]>:
Hi Alexei,
I'm not entirely sure what you mean by application-level logging. It is
possible to get more fine-grained information using aspects if that's what
you mean, such as tracing individual methods, logging field reads and
writes, logging when Exceptions are caught and logging when certain methods
are called and where from. You can't use aspects to add logging into the
middle of a method, unless it's at a well defined point. If there was some
specific information you wanted to add at a specific place there's no
problem using a combination of aspects and hand-coded logging. Does that
answer your question at all?
Thanks,
Sian
On 14/11/06, Alexei Zakharov <[EMAIL PROTECTED]> wrote:
>
> Sian,
>
> Cool! Thanks for this. Can AspectJ be used for something more
> sophisticated than just tracing? For application-level logging for
> example?
>
> Thanks,
>
> 2006/11/14, Sian January <[EMAIL PROTECTED]>:
> > Hello,
> >
> > Following a recent discussion on this list I have been looking into how
> > aspects could be used for tracing in the Harmony class library code. I
> have
> > been using AspectJ and have written a really simple tracing aspect for
> the
> > math module, adapted the build.xml script and written some instructions
> on
> > how to apply it. At the moment the aspect just does entry and exit
> tracing
> > and prints to System.out, but this is because it's a first draft - it is
> > possible to do more targeted tracing and to use frameworks such as
> > java.util.logging with aspects.
> >
> > Steps to follow:
> >
> >
> > 1. Download AspectJ from
> > http://www.eclipse.org/aspectj/downloads.php
> >
> > 2. Copy aspectjrt.jar to /depends/jars/aspectj/
> >
> > 3. Copy aspectjtools.jar and aspectjrt.jar to ANT_HOME/lib and if using
> > Eclipse add both of these to your ant runtime configuration (Window >
> > Preferences > Ant > Runtime > Add...)
> >
> > 4. Edit build file to use iajc* instead of javac and include aspect
> class
> > files (or apply the buildxmlpatch.txt to build.xml in the math module)
> >
> > 5. Write a tracing aspect (or copy the one attached to
> > modules\math\src\main\java\org\apache\harmony\tracing)
> >
> > 6. Re-build the module
> >
> > 7. Make sure to add aspectjrt.jar to the runtime classpath of whatever
> > program you are running.
> >
> >
> > * - iajc isn't incremental like javac in ant, it will always do a total
> > rebuild. Also if you switch from using iajc back to javac you will need
> to
> > do a clean before you do a rebuild.
> > Please also note that it's not possible to use this kind of tracing for
> any
> > classes that are depended on by the AspectJ runtime or there will be
> errors
> > initializing the classes because of circular dependencies. However I
> think
> > most modules apart from luni should be safe. Also it's important to not
> > trace methods that are called (directly or indirectly) by your tracing
> > methods otherwise you will end up in an endless loop.
> >
> > If anyone thinks this information might be useful to have available
> > somewhere I would be happy to expand it a bit for a web page or a Wiki
> page.
--
Alexei Zakharov,
Intel Enterprise Solutions Software Division
Re: [classlib] Using Aspects for Tracing
Sian, Cool! Thanks for this. Can AspectJ be used for something more sophisticated than just tracing? For application-level logging for example? Thanks, 2006/11/14, Sian January <[EMAIL PROTECTED]>: Hello, Following a recent discussion on this list I have been looking into how aspects could be used for tracing in the Harmony class library code. I have been using AspectJ and have written a really simple tracing aspect for the math module, adapted the build.xml script and written some instructions on how to apply it. At the moment the aspect just does entry and exit tracing and prints to System.out, but this is because it's a first draft - it is possible to do more targeted tracing and to use frameworks such as java.util.logging with aspects. Steps to follow: 1. Download AspectJ from http://www.eclipse.org/aspectj/downloads.php 2. Copy aspectjrt.jar to /depends/jars/aspectj/ 3. Copy aspectjtools.jar and aspectjrt.jar to ANT_HOME/lib and if using Eclipse add both of these to your ant runtime configuration (Window > Preferences > Ant > Runtime > Add...) 4. Edit build file to use iajc* instead of javac and include aspect class files (or apply the buildxmlpatch.txt to build.xml in the math module) 5. Write a tracing aspect (or copy the one attached to modules\math\src\main\java\org\apache\harmony\tracing) 6. Re-build the module 7. Make sure to add aspectjrt.jar to the runtime classpath of whatever program you are running. * - iajc isn't incremental like javac in ant, it will always do a total rebuild. Also if you switch from using iajc back to javac you will need to do a clean before you do a rebuild. Please also note that it's not possible to use this kind of tracing for any classes that are depended on by the AspectJ runtime or there will be errors initializing the classes because of circular dependencies. However I think most modules apart from luni should be safe. Also it's important to not trace methods that are called (directly or indirectly) by your tracing methods otherwise you will end up in an endless loop. If anyone thinks this information might be useful to have available somewhere I would be happy to expand it a bit for a web page or a Wiki page. Regards, Sian -- Alexei Zakharov, Intel Enterprise Solutions Software Division
Re: [classlib][swing] Serialization of Swing classes
I also agree, +1 for defining SUIDs externally.
Thanks,
2006/11/14, Stepan Mishura <[EMAIL PROTECTED]>:
On 11/13/06, Ivanov, Alexey A wrote:
>
> >-Original Message-
> >From: Tim Ellison
> >Sent: Sunday, November 12, 2006 1:12 AM
> >To: harmony-dev@incubator.apache.org
> >Subject: Re: [classlib][swing] Serialization of Swing classes
> >
> >Nathan Beyer wrote:
> >> Runtime optimization - I'm not positive of this, nor do I completely
> >> understand the actual affect, but wouldn't explicit
> 'serialVersionUID'
> >> fields mean that when those classes are actually serialized, a UID
> >> wouldn't need to be generated at runtime, correct? Now, I'll be the
> >> first to admit, this is a micro optimization, so it doesn't carry to
> >> much weight. However, I am curious about the details of the reality
> >> behind this thought, so if anyone knows, please post.
> >
> >Take a look at the effect of "java.io.ObjectStreamClass#lookup(Class)"
> >for types that have a SUID field and those that don't.
> >
> >The actual work is done in
> >ObjectStreamClass#computeSerialVersionUID(Class, Field[]), which scans
> >the fields looking for a serialVersionUID field first, and computing it
> >if not found using some non-trivial algorithm.
> >
> >The lookup result is cached, so any saving will be only on the first
> >time the class is seen. Whether the computation is noticeable will
> >depend upon the set of classes of objects being serialized as well as
> >the presence (or absence) of the SUID field.
>
> Actually I don't mind having SUIDs declared in classes. Though IMHO
> without declaring this field, we communicate to developers serialized
> form of this class is not guaranteed to deserialize correctly. OTOH
> having looked through the methods Tim pointed, I can say that if classes
> declare SUID and one tries to serialize an object, there'll be no time
> spent to compute SUID during execution thus improving performance a
> little.
>
> Therefore I'm inclined to declare SUID rather than using
> @SuppressWarning("serial"). However it may be worth to add a comment
> similar to that in the JavaDoc. What do you think?
+1
--
Alexei Zakharov,
Intel Enterprise Solutions Software Division
Re: Re: Re: [classlib][pack200] Status update
Also note that the list of packages that are listed at the URL you gave specify the full set of packages that can be overridden, and the pack200 classes aren't on there :-) Don't look at this list. Endorsed dirs actually works for any classes that aren't compiled into VM indeed (in RI). :-) The Pack200 stuff is supposed to be like the JDBC stuff, in that you should be able to substitute different implementations at a later stage. Aha, I see. But in JDBC you can at least call Class.forName(MyJDBCDriverClass, true, *MyClassLoader*). Regards, 2006/11/14, Alex Blewitt <[EMAIL PROTECTED]>: No, it's a bug (see http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6489723). Also note that the list of packages that are listed at the URL you gave specify the full set of packages that can be overridden, and the pack200 classes aren't on there :-) The Pack200 stuff is supposed to be like the JDBC stuff, in that you should be able to substitute different implementations at a later stage. The problem with the current implementation is that the factory is loaded via the system classloader rather than the context classloader (mainly because it's a static method, I think) and thus the bootclasspath is the only one that has been changed. In any case, ideally you'd want to be able to substitute a different implementation without having to do special things on the classpath, either via the bootclasspath or endorsed directories, in order to deploy it with your own VM or applications. Alex. On 13/11/06, Alexei Zakharov <[EMAIL PROTECTED]> wrote: > > Oh, and I've discovered that the default Sun implementation doesn't > > actually allow you to replace it with another implementation unless > > it's on the boot classpath. > > Have you tried endorsed dirs "-Djava.endorsed.dirs=..." [1]? Seems it > was specially designed for this purpose. > > [1] http://java.sun.com/j2se/1.5.0/docs/guide/standards/index.html > > Regards, > > 2006/11/11, Alex Blewitt <[EMAIL PROTECTED]>: > > A call of frustration at times perhaps :-) > > > > It's going along. I'm hoping to get to a stage where I can get a > > better patch together and get it into the harmony subversion codebase > > in the near future. But sometimes it's just slow progress. > > > > One thing I'd like to get sorted is moving the pack200 code into its > > own module in the near future, perhaps after the next patch bomb. > > > > Oh, and I've discovered that the default Sun implementation doesn't > > actually allow you to replace it with another implementation unless > > it's on the boot classpath. D'oh! Fortunately, I've raised it as a bug > > with Sun: > > > > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6489723 > > > > We should ensure that it doesn't happen with Harmony too :-) > > > > Alex. > > > > On 10/11/06, Tim Ellison <[EMAIL PROTECTED]> wrote: > > > Thanks for the update Alex. I assume from this description (and please > > > don't take this the wrong way) that you are happy to be left alone to > > > work on this for the moment, rather than it be read as a call for help? > > > > > > Keep up the good work. > > > Tim > > > > > > Alex Blewitt wrote: > > > > I'm still lurking around in the background, but I'm busier than ever > > > > what with having to keep posting at EclipseZone where I'm editor now > > > > ... but I'm still managing to plod along with the Pack200 code. The > > > > last patch (1994, IIRC) went down pretty badly; the subclipse plugin > > > > didn't seem to capture all the newly created classes that I had put > > > > together for a bit of refactoring that I did. It's also a nightmare > > > > submitting newly created files; once they've been uploaded to JIRA > > > > into the patch queue, I effectively have to stop work until they're > > > > applied, because there's no way of getting SVN to figure out that the > > > > file called ClassFile.java is the same as the ClassFile.java that's > > > > been added by someone else on my behalf, and I have to overwrite my > > > > local copy to update. Kinda prevents doing any sensible work on newly > > > > created files between submission and application to be honest. > > > > > > > > Instead, I plan to sprint (well, jog, at least) to the next stable > > > > point, and then upload a whole wodge of code and leave it for a week > > > > or two to be applied before picking up a
Re: Re: [classlib][pack200] Status update
Oh, and I've discovered that the default Sun implementation doesn't actually allow you to replace it with another implementation unless it's on the boot classpath. Have you tried endorsed dirs "-Djava.endorsed.dirs=..." [1]? Seems it was specially designed for this purpose. [1] http://java.sun.com/j2se/1.5.0/docs/guide/standards/index.html Regards, 2006/11/11, Alex Blewitt <[EMAIL PROTECTED]>: A call of frustration at times perhaps :-) It's going along. I'm hoping to get to a stage where I can get a better patch together and get it into the harmony subversion codebase in the near future. But sometimes it's just slow progress. One thing I'd like to get sorted is moving the pack200 code into its own module in the near future, perhaps after the next patch bomb. Oh, and I've discovered that the default Sun implementation doesn't actually allow you to replace it with another implementation unless it's on the boot classpath. D'oh! Fortunately, I've raised it as a bug with Sun: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6489723 We should ensure that it doesn't happen with Harmony too :-) Alex. On 10/11/06, Tim Ellison <[EMAIL PROTECTED]> wrote: > Thanks for the update Alex. I assume from this description (and please > don't take this the wrong way) that you are happy to be left alone to > work on this for the moment, rather than it be read as a call for help? > > Keep up the good work. > Tim > > Alex Blewitt wrote: > > I'm still lurking around in the background, but I'm busier than ever > > what with having to keep posting at EclipseZone where I'm editor now > > ... but I'm still managing to plod along with the Pack200 code. The > > last patch (1994, IIRC) went down pretty badly; the subclipse plugin > > didn't seem to capture all the newly created classes that I had put > > together for a bit of refactoring that I did. It's also a nightmare > > submitting newly created files; once they've been uploaded to JIRA > > into the patch queue, I effectively have to stop work until they're > > applied, because there's no way of getting SVN to figure out that the > > file called ClassFile.java is the same as the ClassFile.java that's > > been added by someone else on my behalf, and I have to overwrite my > > local copy to update. Kinda prevents doing any sensible work on newly > > created files between submission and application to be honest. > > > > Instead, I plan to sprint (well, jog, at least) to the next stable > > point, and then upload a whole wodge of code and leave it for a week > > or two to be applied before picking up again. I'm fairly close to > > being at that stage, but not quite. Where I am at is being able to > > generate (abstract) methods with exceptions and fields with constant > > (integer) values, so a bit further forward than last time. On the one > > hand, it means that I understand what needs to be done (no mean feat!) > > but on the other hand, there's still a fair bit to go. For a start, > > I'm going to need to process the actual bytecode for non-abstract > > methods (or indeed, any classes) before there's any point in it trying > > to be used for real, and there's still a few missing bits (Longs, > > Doubles, Floats) from the constant pools. I'm pretty sure Strings > > would work, but I've not tried them yet. > > > > Unfortunately, the code is really awful. The Segment.java is getting > > on for 1500 lines of code in a single class; and the attribute parsing > > contains both duplicated code and isn't as generic as it needs to be > > to handle other attributes; and the (in)visible annotations like > > @Overrides and similar are going to be a bit of a nightmare ... > > > > My plan is to get the code to a stage where it can start to be useful > > for extracting simple classes from a pack file, and then start > > generating test data which can be used for regressions. (There's a bit > > there at the moment, but it's not exactly a large coverage.) Once I've > > done that, I'll start tackling some of the refactoring which will > > result in less duplicated code and hopefully something that will be > > easier to look after in the future. > > > > Anyway, excuse the long rambling but I've been a bit quiet for a while > > and wanted to let people know I was still alive and kicking the code > > :-) -- Alexei Zakharov, Intel Enterprise Solutions Software Division
Re: [testing] harmonytest.org new features
Works fine now. Thanks! Regards, 2006/11/10, Anton Luht <[EMAIL PROTECTED]>: Hello, Alexei, > One little remark: I've got the following screen after trying to > search for "beans" and clicking the first link: It was because of bad/broken data - I've removed it and now the link works. -- Alexei Zakharov, Intel Enterprise Solutions Software Division
Re: [testing] harmonytest.org new features
estProcessor.process(RequestProcessor.java:241) at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1196) at org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:414) at javax.servlet.http.HttpServlet.service(HttpServlet.java:696) at javax.servlet.http.HttpServlet.service(HttpServlet.java:809) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:200) at org.apache.catalina.core.ApplicationFilterChain.access$000(ApplicationFilterChain.java:51) at org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:129) at java.security.AccessController.doPrivileged(Native Method) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:125) at org.apache.harmony.testinfra.filters.HibernateSessionRequestFilter.doFilter(HibernateSessionRequestFilter.java:49) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:166) at org.apache.catalina.core.ApplicationFilterChain.access$000(ApplicationFilterChain.java:51) at org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:129) at java.security.AccessController.doPrivileged(Native Method) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:125) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:209) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:596) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:433) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:948) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:144) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:596) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:433) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:948) at org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2358) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:133) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:596) at org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve.java:118) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:594) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:116) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:594) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:433) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:948) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:127) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:596) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:433) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:948) at org.apache.ajp.tomcat4.Ajp13Processor.process(Ajp13Processor.java:409) at org.apache.ajp.tomcat4.Ajp13Processor.run(Ajp13Processor.java:528) at java.lang.Thread.run(Thread.java:534) 2006/11/10, Anton Luht <[EMAIL PROTECTED]>: Hello, Yesterday I've deployed a new version to harmonytest.org New features include: - packages/suites/tests tree-like navigation (as in local JUnit html results).Tree navigation populated to old results, too. - the first page only includes 50 latest test runs, link to archive search added (includes search by uploader's name - request by Tony Wu) - filter diff results by test name (request by Alexei Fedotov) - detection of crashes - sometimes when suite crashes, there is an empty TEST-.xml file in the run results. If such file is found, all tests from this suite (detected from previous runs) are marked as crashed in this run. Bugs fixed: - duplicates in the results (if any) are merged (bug report by Tony Wu - test count on the site was bigger than real one) - there was a problem in uploading large files - >~ 5Mb - the results were not imported - playing with the configuration solved this problem - at least my test 11Mb file that broke the upload now uploads correctly. Please report bugs and send feature requests. -- Alexei Zakharov, Intel Enterprise Solutions Software Division
Re: [drlvm] release vs. debug
Sure, contributors should check debug or even both debug and release builds and comment about this in JIRA. As far as I understand the only person who answers for the commit is a committer. So I don't think that establishing a policy that shifts a part of responsibility from the committer is a good idea. Well, I have another silly question to gurus indeed. Is there any possibility that some piece of code can break / hang the release build if it passes ok on the debug build? Thanks, 2006/11/10, Pavel Ozhdikhin <[EMAIL PROTECTED]>: Sure, contributors should check debug or even both debug and release builds and comment about this in JIRA. I'm talking about committers, will they test debug build which takes 5 times more time? And does it mean they will be able to apply 5 times less patches? Actually I'm fine if the committers will check both debug and release builds and I encourage them to check on all supported platforms. But I'm not a committer. :) Thanks, Pavel On 11/10/06, Rana Dasgupta <[EMAIL PROTECTED]> wrote: > > I can understand that the contributor may not have access to multiple > platforms, but surely he can test using both debug and release builds :-) > What do we gain by asking the contributor to test less? > > Rana > > > On 11/9/06, Pavel Ozhdikhin <[EMAIL PROTECTED]> wrote: > > > > +1 for debug testing before submitting a patch. > > > > But, for pre-commit testing we should be careful saying we'll test all > the > > patches in debug mode. Though it imprves quality of checks, debug build > is > > significantly slower then release, especially when running with > > interpreter > > or Jitrino.OPT. I ran "build test" on the DRLVM built in debug mode and > it > > takes about 5 times more time than release version on my laptop, The > times > > were as follows: > > > > "build test", Windows XP/ IA32: > > DRLVM release: 22 min 55 sec > > DRLVM debug: 99 min 23 sec > > > > So, may be the good choice will be to ask patch submitters to check > their > > patches on the debug build and, if the JIRA issue contains comments that > > this check is passed, committers may test it on release build only. > > > > Thanks, > > Pavel > > > > On 11/10/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: > > > > > > Well, since the problem is repeatable :) > > > > > > > > > Gregory Shimansky wrote: > > > > Geir Magnusson Jr. wrote: > > > >> > > > >> > > > >> Alexei Zakharov wrote: > > > >>> Hi DRLVM fans, > > > >>> > > > >>> I encountered a rather strange problem while working on some class > > > >>> library tests. At least two tests from the beans module hang (or > > > >>> crash) while running on DRLVM debug builds but work fine on DRLVM > > > >>> release builds. I thought that debug build is something about > adding > > > >>> debug symbols to VM binaries and this should not affect the > > > >>> functionality. Can someone shed a light on this? > > > >> > > > >> I would think it's just an assertion firing... > > > > > > > > Actually it is more than that. In debug mode TRACE statements are > > > > compiled and therefore produce executable code. There may also be > some > > > > bugs in compiler generating code in different modes (although this > > > > usually happens for release). > > > > > > > > I don't know why hanging happens, but the difference in generated > code > > > > is actually quite big. Also assertions or any crashes go to > > > > exceptions/signal handlers which may happen to loop infinitely, > there > > > > were bugs like this happening on the current version of sources, > look > > at > > > > HARMONY-2018 and HADMONY-2006. > > > > > > > >>> This is the first > > > >>> question. The second question - what we should do with such tests. > > The > > > >>> tests pass on the downloadable HDK and JRE snapshots as well as on > > > >>> classlib + j9. What should be the commit criteria for DRLVM – i.e. > > > >>> what is the *true* build? :) I think many people here currently > use > > > >>> snapshots to test their patches. > > > >> > > > >> debug :) don't sweep the problems under the rug... > > > > > > > > +1 -- Alexei Zakharov, Intel Enterprise Solutions Software Division
Re: svn commit: r472149 - /incubator/harmony/enhanced/classlib/trunk/modules/beans/src/test/java/org/apache/harmony/beans/tests/java/beans/PersistenceDelegateTest.java
I've reverted my changes and put the whole test back to the exclude list. Thanks, 2006/11/8, Tim Ellison <[EMAIL PROTECTED]>: Stepan Mishura wrote: > Hi Alexei, > > Sorry, I don't understand your logic. Is the test case valid? If there was > another bug (for example: "[another_VM][unit] half of classlib beans tests > crashes VM"), would you agree to comment out a half of beans tests? Thanks Stepan, I had also intended to point out this commit. I agree that it is masking a problem elsewhere which should be fixed, and I'd also point out that commenting out test code is not the preferred way to exclude a test since it will be very difficult to find the excluded test and include it again. We have been using the build scripts to exclude test classes. Regards, Tim -- Alexei Zakharov, Intel Enterprise Solutions Software Division
Re: [drlvm] release vs. debug
I would think it's just an assertion firing... Yes, but why it hangs? 2006/11/9, Geir Magnusson Jr. <[EMAIL PROTECTED]>: Alexei Zakharov wrote: > Hi DRLVM fans, > > I encountered a rather strange problem while working on some class > library tests. At least two tests from the beans module hang (or > crash) while running on DRLVM debug builds but work fine on DRLVM > release builds. I thought that debug build is something about adding > debug symbols to VM binaries and this should not affect the > functionality. Can someone shed a light on this? I would think it's just an assertion firing... > This is the first > question. The second question - what we should do with such tests. The > tests pass on the downloadable HDK and JRE snapshots as well as on > classlib + j9. What should be the commit criteria for DRLVM – i.e. > what is the *true* build? :) I think many people here currently use > snapshots to test their patches. debug :) don't sweep the problems under the rug... -- Alexei Zakharov, Intel Enterprise Solutions Software Division
[drlvm] release vs. debug
Hi DRLVM fans, I encountered a rather strange problem while working on some class library tests. At least two tests from the beans module hang (or crash) while running on DRLVM debug builds but work fine on DRLVM release builds. I thought that debug build is something about adding debug symbols to VM binaries and this should not affect the functionality. Can someone shed a light on this? This is the first question. The second question - what we should do with such tests. The tests pass on the downloadable HDK and JRE snapshots as well as on classlib + j9. What should be the commit criteria for DRLVM – i.e. what is the *true* build? :) I think many people here currently use snapshots to test their patches. Thanks, -- Alexei Zakharov, Intel Enterprise Solutions Software Division
Re: svn commit: r472149 - /incubator/harmony/enhanced/classlib/trunk/modules/beans/src/test/java/org/apache/harmony/beans/tests/java/beans/PersistenceDelegateTest.java
The all we have is the single HARMONY-2073 JIRA that is currently unassigned. I am going to create the new thread with [drlvm] in subject to attract more DRLVM fans to this. Regards, 2006/11/9, Geir Magnusson Jr. <[EMAIL PROTECTED]>: That's fine. Do we know what the problems are in DRLVM for those tests in debug? I don't recall seeing any discussion here... geir Alexei Zakharov wrote: > Eventually we get more and more arguments to start doing test grouping > somehow. TestNG, JUnit TestSuites or whatever but be we definitely > need it. And sooner is better. > > Regards, > > 2006/11/9, Geir Magnusson Jr. <[EMAIL PROTECTED]>: >> >> >> Alexei Zakharov wrote: >> > Let me rephrase my question a little bit. What should we do in this >> > particular case when some test passes on J9 and HDK (DRLVM with >> > BUILD_CFG=release) and fails/crashes on DRLVM with BUILD_CFG=debug? I >> > have two examples of such tests already. >> >> 1) Fix DRLVM. >> >> 2) conditionally not execute that test when running DRLVM so that it >> completes. >> >> But we don't want to comment out tests in the code, just not run them >> for certain environments. >> >> geir >> >> > >> > Thanks, >> > >> > 2006/11/9, Alexei Zakharov <[EMAIL PROTECTED]>: >> >> Stepan, Tim, >> >> >> >> Well, I am not sure here. All tests passes both on J9 and DLRVM Relase >> >> build (HDK is a RELEASE build is far as I understand). But it crashes >> >> on DRLVM DEBUG - this makes our drlvm guys a bit nervous. As far as I >> >> understand the reason is too complex to be fixed promptly. Probably >> >> the solution I have chosen is not the best one. So I am open for >> >> proposals here. Should we exclude the whole test? In my opinion DRLVM >> >> is not just "another_VM" - it is something we should care about. IMHO. >> >> >> >> Thanks, >> >> >> >> 2006/11/8, Tim Ellison <[EMAIL PROTECTED]>: >> >> > Stepan Mishura wrote: >> >> > > Hi Alexei, >> >> > > >> >> > > Sorry, I don't understand your logic. Is the test case valid? If >> >> there was >> >> > > another bug (for example: "[another_VM][unit] half of classlib >> >> beans tests >> >> > > crashes VM"), would you agree to comment out a half of beans >> tests? >> >> > >> >> > Thanks Stepan, I had also intended to point out this commit. I >> agree >> >> > that it is masking a problem elsewhere which should be fixed, and >> I'd >> >> > also point out that commenting out test code is not the preferred >> >> way to >> >> > exclude a test since it will be very difficult to find the excluded >> >> test >> >> > and include it again. We have been using the build scripts to >> exclude >> >> > test classes. -- Alexei Zakharov, Intel Enterprise Solutions Software Division
Re: [classlib][testing] need to run classlib tests over DRLVM
Well, my scenario is to make sure that my fixes in beans don't introduce new hangs/failures on DRLVM. This means running AWT and SWING tests on top of DRLVM that was a painful process before. Regards, 2006/11/9, Vladimir Ivanov <[EMAIL PROTECTED]>: On 11/9/06, Alexei Zakharov <[EMAIL PROTECTED]> wrote: > > So the best practice to run classlib tests on DRLVM is now: > ant -Dhy.test.mode="perTest" [-Dbuild.module=blah-blah] test > ? Actually, it depends on your choice :) The mode -Dhy.test.forkmode=perTestwill be useful: - to identify crashed/ hang up tests - to run tests under CC But of cause we should work to pass all tests on DRLVM in the default mode (-Dhy.test.forkmode=once). Thanks, Vladimir > Regards, > > 2006/11/9, Alexey Petrenko <[EMAIL PROTECTED]>: > > I'll take a look. > > > > SY, Alexey > > > > 2006/11/9, Vladimir Ivanov <[EMAIL PROTECTED]>: > > > Hello committers, > > > > > > could somebody take care about > > > *HARMONY-2107*<http://issues.apache.org/jira/browse/HARMONY-2107>? > > > > > > It is trivial to fix issue allows easily identify tests that leads to > vm > > > hang up/crash in the process of enabling classlib tests over VM. -- Alexei Zakharov, Intel Enterprise Solutions Software Division
Re: svn commit: r472149 - /incubator/harmony/enhanced/classlib/trunk/modules/beans/src/test/java/org/apache/harmony/beans/tests/java/beans/PersistenceDelegateTest.java
Eventually we get more and more arguments to start doing test grouping somehow. TestNG, JUnit TestSuites or whatever but be we definitely need it. And sooner is better. Regards, 2006/11/9, Geir Magnusson Jr. <[EMAIL PROTECTED]>: Alexei Zakharov wrote: > Let me rephrase my question a little bit. What should we do in this > particular case when some test passes on J9 and HDK (DRLVM with > BUILD_CFG=release) and fails/crashes on DRLVM with BUILD_CFG=debug? I > have two examples of such tests already. 1) Fix DRLVM. 2) conditionally not execute that test when running DRLVM so that it completes. But we don't want to comment out tests in the code, just not run them for certain environments. geir > > Thanks, > > 2006/11/9, Alexei Zakharov <[EMAIL PROTECTED]>: >> Stepan, Tim, >> >> Well, I am not sure here. All tests passes both on J9 and DLRVM Relase >> build (HDK is a RELEASE build is far as I understand). But it crashes >> on DRLVM DEBUG - this makes our drlvm guys a bit nervous. As far as I >> understand the reason is too complex to be fixed promptly. Probably >> the solution I have chosen is not the best one. So I am open for >> proposals here. Should we exclude the whole test? In my opinion DRLVM >> is not just "another_VM" - it is something we should care about. IMHO. >> >> Thanks, >> >> 2006/11/8, Tim Ellison <[EMAIL PROTECTED]>: >> > Stepan Mishura wrote: >> > > Hi Alexei, >> > > >> > > Sorry, I don't understand your logic. Is the test case valid? If >> there was >> > > another bug (for example: "[another_VM][unit] half of classlib >> beans tests >> > > crashes VM"), would you agree to comment out a half of beans tests? >> > >> > Thanks Stepan, I had also intended to point out this commit. I agree >> > that it is masking a problem elsewhere which should be fixed, and I'd >> > also point out that commenting out test code is not the preferred >> way to >> > exclude a test since it will be very difficult to find the excluded >> test >> > and include it again. We have been using the build scripts to exclude >> > test classes. -- Alexei Zakharov, Intel Enterprise Solutions Software Division
Re: [classlib][testing] need to run classlib tests over DRLVM
So the best practice to run classlib tests on DRLVM is now: ant -Dhy.test.mode="perTest" [-Dbuild.module=blah-blah] test ? Regards, 2006/11/9, Alexey Petrenko <[EMAIL PROTECTED]>: I'll take a look. SY, Alexey 2006/11/9, Vladimir Ivanov <[EMAIL PROTECTED]>: > Hello committers, > > could somebody take care about > *HARMONY-2107*<http://issues.apache.org/jira/browse/HARMONY-2107>? > > It is trivial to fix issue allows easily identify tests that leads to vm > hang up/crash in the process of enabling classlib tests over VM. -- Alexei Zakharov, Intel Enterprise Solutions Software Division
Re: [classlib]Harmony classlib with J9 VM passes all the tests provided by JUnit4.1
If you're looking for another opinion, I'm not convinced. JUnit 4.x seems just as capable as TestNG. IIRC JUnit 4.x doesn't have the rich set of grouping annotations TestNG has. Moreover (again IIRC), JUnit doesn't have it at all. Only TestSuites. Thanks, 2006/11/7, Nathan Beyer <[EMAIL PROTECTED]>: On 11/6/06, Paulex Yang <[EMAIL PROTECTED]> wrote: > Geir Magnusson Jr. wrote: > > > > > > Paulex Yang wrote: > >> Geir Magnusson Jr. wrote: > >>> did we decide not to go to TestNG? > >> Sigh...I guess there must be too many ones have waited too long for > >> TestNG...(including me) > > > > I don't understand - what do you mean? > Nothing but a joke:). I mean, the TestNG depends on j.u.c, so that it > cannot be used for months, so people may think let's just use JUnit > instead... > > Ignore it, I'm all for TestNG...:) If you're looking for another opinion, I'm not convinced. JUnit 4.x seems just as capable as TestNG. -- Alexei Zakharov, Intel Enterprise Solutions Software Division
Re: svn commit: r472149 - /incubator/harmony/enhanced/classlib/trunk/modules/beans/src/test/java/org/apache/harmony/beans/tests/java/beans/PersistenceDelegateTest.java
Let me rephrase my question a little bit. What should we do in this particular case when some test passes on J9 and HDK (DRLVM with BUILD_CFG=release) and fails/crashes on DRLVM with BUILD_CFG=debug? I have two examples of such tests already. Thanks, 2006/11/9, Alexei Zakharov <[EMAIL PROTECTED]>: Stepan, Tim, Well, I am not sure here. All tests passes both on J9 and DLRVM Relase build (HDK is a RELEASE build is far as I understand). But it crashes on DRLVM DEBUG - this makes our drlvm guys a bit nervous. As far as I understand the reason is too complex to be fixed promptly. Probably the solution I have chosen is not the best one. So I am open for proposals here. Should we exclude the whole test? In my opinion DRLVM is not just "another_VM" - it is something we should care about. IMHO. Thanks, 2006/11/8, Tim Ellison <[EMAIL PROTECTED]>: > Stepan Mishura wrote: > > Hi Alexei, > > > > Sorry, I don't understand your logic. Is the test case valid? If there was > > another bug (for example: "[another_VM][unit] half of classlib beans tests > > crashes VM"), would you agree to comment out a half of beans tests? > > Thanks Stepan, I had also intended to point out this commit. I agree > that it is masking a problem elsewhere which should be fixed, and I'd > also point out that commenting out test code is not the preferred way to > exclude a test since it will be very difficult to find the excluded test > and include it again. We have been using the build scripts to exclude > test classes. -- Alexei Zakharov, Intel Enterprise Solutions Software Division
Re: svn commit: r472149 - /incubator/harmony/enhanced/classlib/trunk/modules/beans/src/test/java/org/apache/harmony/beans/tests/java/beans/PersistenceDelegateTest.java
Stepan, Tim, Well, I am not sure here. All tests passes both on J9 and DLRVM Relase build (HDK is a RELEASE build is far as I understand). But it crashes on DRLVM DEBUG - this makes our drlvm guys a bit nervous. As far as I understand the reason is too complex to be fixed promptly. Probably the solution I have chosen is not the best one. So I am open for proposals here. Should we exclude the whole test? In my opinion DRLVM is not just "another_VM" - it is something we should care about. IMHO. Thanks, 2006/11/8, Tim Ellison <[EMAIL PROTECTED]>: Stepan Mishura wrote: > Hi Alexei, > > Sorry, I don't understand your logic. Is the test case valid? If there was > another bug (for example: "[another_VM][unit] half of classlib beans tests > crashes VM"), would you agree to comment out a half of beans tests? Thanks Stepan, I had also intended to point out this commit. I agree that it is masking a problem elsewhere which should be fixed, and I'd also point out that commenting out test code is not the preferred way to exclude a test since it will be very difficult to find the excluded test and include it again. We have been using the build scripts to exclude test classes. Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. -- Alexei Zakharov, Intel Enterprise Solutions Software Division
Re: svn commit: r470310 - in /incubator/harmony/standard/site: README.txt docs/contributors.html xdocs/contributors.xml
1) **Temporarily** update the link to the CSS so you can preview the site in a local browser: -1) Go to line 266 in file xdocs/stylesheets/site.vsl +1) Go to line 250 in file xdocs/stylesheets/site.vsl 2) Edit the path to site.css. Specify an absolute path. e.g. from Shouldn't we remove point (1) at all? It seems there is no need to update css location anymore. At least it works ok for me without any updating. Regards, 2006/11/2, [EMAIL PROTECTED] <[EMAIL PROTECTED]>: Author: odeakin Date: Thu Nov 2 02:16:26 2006 New Revision: 470310 URL: http://svn.apache.org/viewvc?view=rev&rev=470310 Log: (empty) Modified: incubator/harmony/standard/site/README.txt incubator/harmony/standard/site/docs/contributors.html incubator/harmony/standard/site/xdocs/contributors.xml Modified: incubator/harmony/standard/site/README.txt URL: http://svn.apache.org/viewvc/incubator/harmony/standard/site/README.txt?view=diff&rev=470310&r1=470309&r2=470310 == --- incubator/harmony/standard/site/README.txt (original) +++ incubator/harmony/standard/site/README.txt Thu Nov 2 02:16:26 2006 @@ -5,7 +5,7 @@ 1) **Temporarily** update the link to the CSS so you can preview the site in a local browser: -1) Go to line 266 in file xdocs/stylesheets/site.vsl +1) Go to line 250 in file xdocs/stylesheets/site.vsl 2) Edit the path to site.css. Specify an absolute path. e.g. from Modified: incubator/harmony/standard/site/docs/contributors.html URL: http://svn.apache.org/viewvc/incubator/harmony/standard/site/docs/contributors.html?view=diff&rev=470310&r1=470309&r2=470310 == --- incubator/harmony/standard/site/docs/contributors.html (original) +++ incubator/harmony/standard/site/docs/contributors.html Thu Nov 2 02:16:26 2006 @@ -412,6 +412,20 @@ A + + + +Oliver Deakin + + + +IBM UK + + + +A + + Status : Modified: incubator/harmony/standard/site/xdocs/contributors.xml URL: http://svn.apache.org/viewvc/incubator/harmony/standard/site/xdocs/contributors.xml?view=diff&rev=470310&r1=470309&r2=470310 == --- incubator/harmony/standard/site/xdocs/contributors.xml (original) +++ incubator/harmony/standard/site/xdocs/contributors.xml Thu Nov 2 02:16:26 2006 @@ -34,6 +34,7 @@ (Paulex)Pu YangIBM CNA Weldon WashburnIntelA Alexey PetrenkoIntelA + Oliver DeakinIBM UKA -- Alexei Zakharov, Intel Enterprise Solutions Software Division
Re: [general] Re: svn commit: r469512 - in /incubator/harmony/standard/site: docs/contributors.html xdocs/contributors.xml
Everything works for me. Thanks. Regards, 2006/11/2, Geir Magnusson Jr. <[EMAIL PROTECTED]>: added perms for gregory, oliver, richard and alexei for svn and jira Geir Magnusson Jr. wrote: > that's because you haven't been added to the svn perms. I'll do that in > a bit... > > Gregory Shimansky wrote: >> On Tuesday 31 October 2006 18:28 Tim Ellison wrote: >>> Hurray! >>> >>> [EMAIL PROTECTED] wrote: >>>> Author: apetrenko >>>> Date: Tue Oct 31 06:57:44 2006 >>>> New Revision: 469512 >>>> >>>> URL: http://svn.apache.org/viewvc?view=rev&rev=469512 >>>> Log: >>>> I've added myself to the list of committers. >> >> Congrants to Alexey! >> >> I've tried to do the same but apparently cannot. I got my login today, >> logged on people.apache.org and changed my password for subversion. So >> far both for standard and enhanced modules I get the same message >> >> Sendingsite/docs/contributors.html >> Authentication realm: <https://svn.apache.org:443> ASF Committers >> Password for 'gshimansky': >> svn: Commit failed (details follow): >> svn: CHECKOUT of >> '/repos/asf/!svn/ver/470017/incubator/harmony/standard/site/docs/contributors.html': >> 403 Forbidden (https://svn.apache.org) >> >> I wonder if it is just a very unlucky day to try the first commit >> because of some more maintenance works done to infrastructure, or >> should I just be patient? >> >> I tried on different machines from command line svn client, eclipse >> subclipse and kdesvn with the same result. -- Alexei Zakharov, Intel Enterprise Solutions Software Division
Re: [general] Re: svn commit: r469512 - in /incubator/harmony/standard/site: docs/contributors.html xdocs/contributors.xml
Cool, congratulation! BTW, shouldn't this list be ordered somehow? Looks like it will be long enough pretty soon. Or this is a kind of historical document? ;) Just worring about where to put my name when the time (i.e. login) comes. Regards, 2006/10/31, Alexey Petrenko <[EMAIL PROTECTED]>: Yep. Hurray! It works... finally :) SY, Alexey 2006/10/31, Tim Ellison <[EMAIL PROTECTED]>: > Hurray! > > [EMAIL PROTECTED] wrote: > > Author: apetrenko > > Date: Tue Oct 31 06:57:44 2006 > > New Revision: 469512 > > > > URL: http://svn.apache.org/viewvc?view=rev&rev=469512 > > Log: > > I've added myself to the list of committers. -- Alexei Zakharov, Intel Enterprise Solutions Software Division
Re: [general] creation of "jdktools"
In other words: I just wanted to say that the big number of java projects I've been working with was using "build[.]" as a place for storing generated stuff like .class and .jar files, generated docs and etc. Regards, 2006/10/31, Geir Magnusson Jr. <[EMAIL PROTECTED]>: Alexei Zakharov wrote: > Take me for example. I will be most likely misleaded with "build" > since the majority of projects I've seen in my life were using "build" > or "build." for storing build artifacts (as Mark said). I > agree it is logically to call it "build". But "make" is logical too. > "ant" or "ant.scripts" also sound not so bad. Why not to choose the > less confusing name? (I believe you meant "make" or "make.") What projects? Java projects? > > With best regards, > > 2006/10/31, Geir Magnusson Jr. <[EMAIL PROTECTED]>: >> Why? I'm really curious about this. We "build" the project, using the >> "build.xml" file with Ant. >> >> >> Ilya Neverov wrote: >> > I would prefer to keep the current name "make" for directories related >> > to build system. For me it looks natural; at least it looks less >> > misleading than "build" :) >> > >> > -Ilya >> > >> > On 10/31/06, Mark Hindess <[EMAIL PROTECTED]> wrote: >> >> >> >> On 30 October 2006 at 18:38, "Geir Magnusson Jr." <[EMAIL PROTECTED]> >> wrote: >> >> > >> >> > Ilya Neverov wrote: >> >> > > Hello, >> >> > > >> >> > > I want to gather opinions about structure of the "jdktools" >> >> component. >> >> > > >> >> > > I'm going to create scripts for moving tools' sources from >> classlib/ >> >> > > to top-level directory jdktools/ and to prepare patches for build >> >> > > system for building tools from new place. >> >> > >> >> > Cool >> >> > >> >> > > >> >> > > I think the following structure will be appropriate for future >> >> > > evolution of the jdktools: >> >> > > >> >> > > jdktools/trunk/ >> >> > > build.xml >> >> > > make/ >> >> > >> >> > Can we stop persisting this mistake? Please call it "build" :) >> >> >> >> And call 'build' something else like 'target'? >> >> >> >> I'm not actually sure calling it build is a good idea because a number >> >> of common projects use build to contain built artifacts. What is your >> >> objection to 'make'? >> >> >> >> > > doc/ >> >> > > modules/ >> >> > > jre/ # keytool, tool launcher go >> here >> >> > > build.xml # classes go to >> >> jdk/jre/lib/tools.jar >> >> > > make/ >> >> > > src/ >> >> > > jdk/ # javac, jarsigner go here >> >> > > build.xml # classes go to >> jdk/lib/tools.jar >> >> > > make/ >> >> > > src/ >> >> > > jdwp/# separate module for large >> >> component >> >> > > build.xml >> >> > > make/ >> >> > > src/ >> >> > >> >> > Only comment is that we might want to pull the launcher out to be a >> >> > peer. Otherwise, I like it. >> >> >> >> I'd be a little tempted by that idea too. >> >> >> >> > > >> >> > > Assumptions which look reasonable for jdktool's build subsystem: >> >> > > >> >> > > 1) it works in presence of built classlib (as HDK binaries or as a >> >> > > result of classlib phase of overall build); >> >> > >> >> > yes - think of the same trick we do w/ DRLVM to "reach over" to find >> >> it. >> >> > I'd imagine the federated build to then have :
Re: [testing][support] Where to place xxxTestCase support classes
FYI in beans we have the following folders for this purpose: src/test/support/java/org/apache/harmony/beans/tests/support src/test/support/java/org/apache/harmony/beans/tests/support/mock Thanks, 2006/10/31, Ivanov, Alexey A <[EMAIL PROTECTED]>: Hi all, Both AWT and Swing modules have testing support classes. Some of them are extensions of junit.framework.TestCase which provide some utility methods for tests. To mention several: AWTTestCase, ShapeTestCase, BasicSwingTestCase, SwingTestCase. There are test cases which extend these classes. There are also several classes which provide special mock objects, fields, for example ViewTestHelpers, DefStyledDoc_Helpers. The question about support classes was discussed [1] but no decision was taken. The bad thing about these classes is that: * some are stored along with tests utilizing these classes (modules/awt/src/test/api/java/common/java/awt/), * some are stored in support folder (support/src/test/java/javax/swing/). I think we should decide where such classes are to be stored. And move them appropriately. Comments, opinions? Regards, Alexey. [1] http://thread.gmane.org/gmane.comp.java.harmony.devel/9487/focus=9561 P.S. Mikhail, did you add the text from the message above into any doc? -- Alexei Zakharov, Intel Enterprise Solutions Software Division
Re: [general] creation of "jdktools"
I mean, and do it in a way that it will be trivial to >> > add other OSs or processor architectures (IPF, for example). >> >> > This might be a good place to figure out how this should work going >> > forward for harmony, rather than experimenting in classlib. >> >> +1 >> >> > > >> > > Thank you >> > >> > No, thank you :) >> >> +1 >> >> Regards, >> Mark. >> >> > geir >> > >> > > -Ilya >> > > >> > > >> > > On 10/19/06, Ilya Neverov <[EMAIL PROTECTED]> wrote: >> > >> Hi Geir, >> > >> >> > >> Looks like that creating the "jdktools" source tree and build was >> > >> shaded by other tasks. I can help with preparing and checking >> updates >> > >> in the build system. Please let me know what needs to do in this >> area >> > >> (besides svn commits) to complete the task. >> > >> >> > >> I'm especially interested in completing the move to "jdktools" >> > >> structure since there will be a home for the JDWP code, which has >> beed >> > >> voted but still resides in JIRA. Working with SVN will be easier. >> > >> >> > >> Thanks. >> > >> -Ilya >> > >> >> > >> On 10/4/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: >> > >> > yep, that's the plan. And once we have that, we can simplify the >> > >> > launcher as well... >> > >> > >> > >> > Tim Ellison wrote: >> > >> > > +1 for creating a jdktools directory. The dependency on the >> classlib >> > >> > > launcher should be relatively light if we go with a simple tools >> > >> > > launcher that rewrites the tool invocation into a generic >> launcher >> > >> > > invocation. You may recall the idea was discussed a while ago. >> > >> > > >> > >> > > So, for example, >> > >> > > jdk/bin/javac -source 1.5 -J-Xmx200M FooBar >> > >> > > is rewritten to >> > >> > > jdk/jre/bin/java -cp jdk/lib/tools.jar;jdk/lib/ecj.jar >> -Xmx200M >> > >> > > org.apache.harmony.tools.javac.Main -source 1.5 FooBar >> > >> > > >> > >> > > and so on. >> > >> > > >> > >> > > Regards, >> > >> > > Tim >> > >> > > >> > >> > > Geir Magnusson Jr. wrote: >> > >> > >> Geir Magnusson Jr. wrote: >> > >> > >>> Now that we have javac, javah, javap (if Tim votes ;) and >> > >> keytool, I'd >> > >> > >>> like to organize these and add them to the next snapshot. >> > >> > >> My bad - the javap isn't being voted on yet. I was thinking of >> > >> the jdwp >> > >> > >> vote... sorry >> > >> > >> >> > >> > >>> So I propose adding a new top-level directory called >> "jdktools" >> > >> (and >> > >> > >>> rename "tools" to "project_tools") and create a build >> target that - >> > >> > >>> with a dependency on classlib for the launcher - creates the >> > >> 'stuff' >> > >> > >>> needed to fill into the JDK. >> > >> > >>> >> > >> > >>> Any comments? -- Alexei Zakharov, Intel Enterprise Solutions Software Division
Re: [general] creation of "jdktools"
commits) to complete the task. > > >> > > >> I'm especially interested in completing the move to "jdktools" > > >> structure since there will be a home for the JDWP code, which has beed > > >> voted but still resides in JIRA. Working with SVN will be easier. > > >> > > >> Thanks. > > >> -Ilya > > >> > > >> On 10/4/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: > > >> > yep, that's the plan. And once we have that, we can simplify the > > >> > launcher as well... > > >> > > > >> > Tim Ellison wrote: > > >> > > +1 for creating a jdktools directory. The dependency on the classlib > > >> > > launcher should be relatively light if we go with a simple tools > > >> > > launcher that rewrites the tool invocation into a generic launcher > > >> > > invocation. You may recall the idea was discussed a while ago. > > >> > > > > >> > > So, for example, > > >> > > jdk/bin/javac -source 1.5 -J-Xmx200M FooBar > > >> > > is rewritten to > > >> > > jdk/jre/bin/java -cp jdk/lib/tools.jar;jdk/lib/ecj.jar -Xmx200M > > >> > > org.apache.harmony.tools.javac.Main -source 1.5 FooBar > > >> > > > > >> > > and so on. > > >> > > > > >> > > Regards, > > >> > > Tim > > >> > > > > >> > > Geir Magnusson Jr. wrote: > > >> > >> Geir Magnusson Jr. wrote: > > >> > >>> Now that we have javac, javah, javap (if Tim votes ;) and > > >> keytool, I'd > > >> > >>> like to organize these and add them to the next snapshot. > > >> > >> My bad - the javap isn't being voted on yet. I was thinking of > > >> the jdwp > > >> > >> vote... sorry > > >> > >> > > >> > >>> So I propose adding a new top-level directory called "jdktools" > > >> (and > > >> > >>> rename "tools" to "project_tools") and create a build target that - > > >> > >>> with a dependency on classlib for the launcher - creates the > > >> 'stuff' > > >> > >>> needed to fill into the JDK. > > >> > >>> > > >> > >>> Any comments? -- Alexei Zakharov, Intel Enterprise Solutions Software Division
Re: [classlib] Preprocessor (was Re: [classlib][rmi] Code smell - Thread.sleep() in ActivationGroup method)
Hi all, Well, as an individual who has the tendency to pure Java programming I will be happier if I can control things on the source-code level. I can't say I don't like the idea about sophisticated JIT with the powerful AI inside, but if we are talking about logging then IMHO a good preprocessor is the thing that we need (but we may also continue to JIT away stuff if we like). At the same time I don't feel completely comfortable with the idea of using preprocessor to separate J2SE sources from J2ME. No clue about particular technology. It can be SableCC, something custom-made, velocity or whatever. Thanks, 2006/10/30, Fedotov, Alexei A <[EMAIL PROTECTED]>: Premature optimization is the root of all evil Donald Knuth >Just a small idea: Let teach JIT to purge this code unless special option >is ON +1 I believe a computer should adapt to my way of thinking. I prefer a simple and readable code to an efficient one since the former one saves the time of my life, why the latter one saves some electricity. With best regards, Alexei Fedotov, Intel Java & XML Engineering >-Original Message- >From: Mikhail Fursov [mailto:[EMAIL PROTECTED] >Sent: Sunday, October 29, 2006 8:56 PM >To: harmony-dev@incubator.apache.org; [EMAIL PROTECTED] >Subject: Re: [classlib] Preprocessor (was Re: [classlib][rmi] Code smell - >Thread.sleep() in ActivationGroup method) > >On 10/29/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: >> >> >> 1) The Logging Debate That Won't Die - we don't want to encumber our >> "production" code with logging or even with runtime enablement checks >> for logging i.e. >> >> if (logging.isDebugEnabled()) >> >> but it's clear that some people still want to use it for debugging. > > >Just a small idea: Let teach JIT to purge this code unless special option >is ON >? Doing this we solve performance issue at least . > >If we did this, I assume that our build becomes a two step process, >> first pre-process the code to create separate "buildable source", which >> would go into source jars and such for debugging purposes. Then our >> current javac/jar process. >> >> I'd also like to be able to work in an IDE with the pre-proc stuff >> invisible if possible... > > >This is the main problem. Backporting of your changes from the "buildable >source" to the "source with preprocessor" could have more overhead then >support of a separate branch for different Java version. -- Alexei Zakharov, Intel Enterprise Solutions Software Division
Re: [classlib][beans]got a difference with RI
Hi Tony,
I agree that the current implementation handles digits incorrectly. So
+1 for fixing decapitalize() and following RI. Thanks for finding it.
Thanks,
2006/10/30, Tony Wu <[EMAIL PROTECTED]>:
this testcase passed on RI but failed on Harmony
public class TestBeans extends TestCase {
public void test() {
String expected = "a1";
String actual = java.beans.Introspector.decapitalize("A1");
assertEquals(expected, actual);
}
}
spec does not mention the case containing a number, it says,
in the (unusual) special case when there is more than one character
and both the first and second characters are upper case, we leave it
alone.
But, IMO, we'd better follow RI here.
--
Alexei Zakharov,
Intel Enterprise Solutions Software Division
Re: [classlib][sql]Is it RI's bug about java.sql.Timestamp.compareTo
Hi all,
I agree that RI's Timestamp#compareTo() is buggy. The #toString()
method seems to be working ok but it would be nice if it can output
something like BC and AD since now the output is a bit confusing. I am
not persuading you to do so, just reflecting upon the subject.
Thanks,
2006/10/27, Leo Li <[EMAIL PROTECTED]>:
Ya, I also recognized it. Harmony's java.util.Date is not the same as that
of java.sql.Timestamp, just following RI.
I think if the toString result is reliable, the compareTo is false. I will
let the compareTo to follow toString since the latter gives detailed
information of the TimeStamp.
On 10/27/06, Andrew Zhang <[EMAIL PROTECTED]> wrote:
>
> Hi Leo,
>
> I think the problem is caused by negative value. java.util.Date and
> java.sql.Timestamp handles differently on negative value. Following code
> shows the difference:
>
> public static void main(String[] args) {
>Long l1 = Long.MIN_VALUE;
>Long l2 = Long.MIN_VALUE -1;
>
>Timestamp timestamp1 = new Timestamp(l1);
>Timestamp timestamp2 = new Timestamp(l2);
>Date date1 = new Date(l1);
>Date date2 = new Date(l2);
>System.out.println(timestamp1);
>System.out.println(timestamp2);
>System.out.println(date1);
>System.out.println(date2);
> }
> The output of RI is:
> 292278994-08-17 15:12:55.192
> 292278994-08-17 15:12:55.807
> Mon Dec 03 00:47:04 CST 292269055
> Sun Aug 17 15:12:55 CST 292278994
>
> Spec doesn't say how to handle negative value. (do i miss something here?)
>
> How would you like to fix this problem?
>
>
> On 10/27/06, Leo Li <[EMAIL PROTECTED]> wrote:
> >
> > Hi, all:
> > When fixing jira 1703, I found that at an extreme situation,
> > TimeStamp.compareTo behaves differently from its semantic: the time it
> > represents:
> > Here is the example:
> >
> > public static void main(String[] args) {
> >Long l1 = Long.MIN_VALUE;
> >Long l2 = Long.MIN_VALUE -1;
> >
> >Timestamp timestamp1 = new Timestamp(l1);
> >Timestamp timestamp2 = new Timestamp(l2);
> >System.out.println(timestamp1);
> >System.out.println(timestamp2);
> >System.out.println(timestamp1.compareTo(timestamp2));
> >}
> >
> >We get:
> >292278994-08-17 15:12:55.192
> >292278994-08-17 15:12:55.807
> >1
> >
> > From the times the timestamps represent, timestamp1 than timestamp2,
> > which indicate that timestamp1.compareTo(timestamp2) should be -1, while
> > the
> > actual result is 1, which indicate the reversed time sequence.
> >
> > Furthermore, as the spec says java.sql.Timestamp wraps the
> > java.util.Date:"A thin wrapper around java.util.Date that allows the
> JDBC
> > API to identify this as an SQL TIMESTAMP value. It adds the ability to
> > hold
> > the SQL TIMESTAMP nanos value and provides formatting and parsing
> > operations
> > to support the JDBC escape syntax for timestamp values".
> > I apply the same long value to java.util.Date:
> >Long l1 = Long.MIN_VALUE;
> >Long l2 = Long.MIN_VALUE -1;
> >
> >Date date1 = new Date(l1);
> >Date date2 = new Date(l2);
> >System.out.println(date1.compareTo(date2));
> > I got -1, which indicate that date1 is earlier than date2 as we
> expected.
> > The samething happens on java.sql.Date.
> >
> > If no one objects, I will regard it as RI's bug and go on with my
> patch.
--
Alexei Zakharov,
Intel Enterprise Solutions Software Division
Re: FW: [doc] List of current open doc issues
Well, I don't see any attachments to this message either. Seems it was lost on the way to harmony-dev. Regards, 2006/10/26, Konovalova, Svetlana <[EMAIL PROTECTED]>: Now with attachment. Sorry... Cheers, Sveta -Original Message- From: Konovalova, Svetlana [mailto:[EMAIL PROTECTED] Sent: Thursday, October 26, 2006 3:47 PM To: harmony-dev@incubator.apache.org; [EMAIL PROTECTED] Subject: RE: [doc] List of current open doc issues >I committed 3 5 and 7, but I'd like some other opinions about changing >the classlibrary section - if things need to be fixed, should we fix >them rather than remove them? I'd like the opinions of the authors of >that stuff... Geir, thanks for committing the patches 3,5,7. As for the classlibrary section, I'd like to ask its authors to check the patches 1 and 2 (unfortunately I do not them by names...). Speaking about the Building the Apache Harmony Class Library page [http://incubator.apache.org/harmony/subcomponents/classlibrary/build_cl asslib.html], which I suggest to remove because it's out-of-date, I'd like to mention that its important bits of info were removed to the patches 3 and 5. IMHO we can delete the aforementioned page without any harm... >> 2. To improve the "How to write GC" doc and update its content: >> >>http://issues.apache.org/jira/browse/HARMONY-1881 >> >> Would be great if someone can decide its fate. :) >The patch was wrong - it included the navigation. That's added in the >rendering process I'm so sorry about that. I've created another patch, hope it's the right one. But since I have a problem with logging in to JIRA that is connected with the machine died in the move, I'd like to ask someone to apply the attached patch. Thanks in advance! Cheers, Sveta -Original Message- From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 25, 2006 3:01 AM To: harmony-dev@incubator.apache.org Subject: Re: [doc] List of current open doc issues Konovalova, Svetlana wrote: > Folks, > > I do not want to be too pushy, just have a suggestion to close certain JIRAs (whenever you'll find a chance). > > 1. To reduce the number of places describing the building process, to update the content: > > http://issues.apache.org/jira/browse/HARMONY-1730 and http://issues.apache.org/jira/browse/HARMONY-1828 depended from the first JIRA. > I've integrated the patches from JIRA-1828 into the ones from JIRA-1730. So, we can close JIRA-1828 without loosing important info. > > As the result we'll get the following building instructions docs: > > "Getting Started for Contributors" describing how to get configured to build and work with the Apache Harmony source code. > Please apply quickhelp_contrib.patch (3)/JIRA-1730 > > "Getting Started for Users" providing basic instructions for users that > wish to use Apache Harmony for running their Java programs. > Please apply quickhelp_users.patch (5) /JIRA-1730 > > README providing instructions on how to point to local >versions instead of making the build download new ones from the net. > Please, apply README.patch (7) /JIRA-1730 > > I've removed the Building the Apache Harmony Class Library page [http://incubator.apache.org/harmony/subcomponents/classlibrary/build_cl asslib.html] because it's out-of-date. In this connection we need to remove the build_classlib.xml file from the repository. > I've removed all references to this page from wiki and other site pages (it increased the number of patches...sorry about that..) > Please, apply downloads.patch (1) and index.patch (2) /JIRA-1730 > I committed 3 5 and 7, but I'd like some other opinions about changing the classlibrary section - if things need to be fixed, should we fix them rather than remove them? I'd like the opinions of the authors of that stuff... > > 2. To improve the "How to write GC" doc and update its content: > > http://issues.apache.org/jira/browse/HARMONY-1881 > > Would be great if someone can decide its fate. :) The patch was wrong - it included the navigation. That's added in the rendering process > > 3. To make "DRLVM Dev Guide" more up-to-date and nice-to-read: > > http://issues.apache.org/jira/browse/HARMONY-1882 > > I'll be glad if you find a chance to look at the patches and apply them :). > Thanks in advance! -- Alexei Zakharov, Intel Enterprise Solutions Software Division
Re: [announcement] Apache Board approved Apache Harmony as a Top Level Project of the ASF
HURRAH! It's time to rest for a little while... ;-) 2006/10/26, Geir Magnusson Jr. <[EMAIL PROTECTED]>: I am happy to report that the Apache Board was willing to consider our proposal and voted to accept it at today's board meeting. As stated in the Incubation vote, this is a necessary condition for graduation from the Incubator. Therefore, upon a successful outcome of the Incubator PMC vote, we are Apache Harmony, project of the Apache Software Foundation! Congratulations to everyone! When the vote is complete, we'll get to work on the transition activities, but until then, just give yourself a well-deserved pat on the back. -- Alexei Zakharov, Intel Enterprise Solutions Software Division
Re: [classlib][tests] Junit best practice
BTW - the script does run on Windows with ActiveState's Perl runtime. > > Number of Issues by module > > 45 beans I've also checked it on WinXP + cygwin + perl v5.8.7. Also works good (HARMONY-1976). Thanks, 2006/10/26, Nathan Beyer <[EMAIL PROTECTED]>: BTW - the script does run on Windows with ActiveState's Perl runtime. -Nathatn On 10/25/06, Richard Liang <[EMAIL PROTECTED]> wrote: > Awesome. I just plan to review our junit tests, now it seems your tool > has done what I want ;-) > > I highly recommend we read this article "JUnit best practices"[1] in javaworld. > > [1] http://www.javaworld.com/javaworld/jw-12-2000/jw-1221-junit.html > > On 10/25/06, Mark Hindess <[EMAIL PROTECTED]> wrote: > > > > Earlier in the year we discussed junit best practice. For example, > > making sure assertEquals calls have the expected and actual arguments in > > the correct order to avoid getting confusing failure messages. > > > > Robert posted a script a week or so ago, to look for some of junit > > issues but it didn't handle asserts that spanned multiple lines so, > > unfortunately, it was missing the majority of them. I had a script that > > I'd thrown together one evening that would handle multi-line asserts but > > annoyingly (because it read the whole file at once) couldn't report the > > line number of the potential issue as Robert's script did. > > > > Inspired by Robert's post, I looked at my script again. I've now fixed > > it to report line numbers, added a little bit of documentation and > > attached it to a JIRA: > > > > https://issues.apache.org/jira/browse/HARMONY-1960 > > > > It finds quite a lot of potential problems (I've appended a summary of > > the findings below). (There will be a few false positives but hopefully > > not too many.) It would be nice to fix these issues - I fixed several > > hundred while testing the script - but more importantly we should make > > sure we avoid adding any new issues. > > > > Improvements to the script would be most welcome. > > > > Regards, > > Mark. > > > > Types of issue identified > > > > 4949 should possibly use assertEquals > > 815 actual may be a constant > > 437 consider using separate asserts for each '&&' component > > 330 exception may be left to junit > > 135 actual *may* be a constant > > 48 should be fail (always false) > > 40 should be fail (always true) > > 20 expected is null - should use assertNull > > 12 consider using separate asserts for each '||' component > >8 expected is false - should use assertFalse > >7 expected is true - should use assertTrue > >1 should use assertNotNull > > > > > > Number of Issues by module > > > > 1907 luni > > 1440 swing > > 699 math > > 611 security > > 335 text > > 322 awt > > 222 sound > > 186 nio > > 178 jndi > > 123 archive > > 118 auth > > 117 crypto > > 116 logging > > 91 nio_char > > 87 print > > 74 regex > > 68 concurrent > > 45 beans > > 41 x-net > > 21 sql > >1 rmi -- Alexei Zakharov, Intel Enterprise Solutions Software Division
Re: javac and hdk
Hi, You may also create a javac batch file by yourself. Something like <--- set JAVAC_CLASS=org.eclipse.jdt.internal.compiler.batch.Main \java -cp ecj_3.2.jar %JAVAC_CLASS% %* <--- on Windows. Thanks, 2006/10/26, Matthias Wessendorf <[EMAIL PROTECTED]>: thx, looks like maven2 has not an option like that http://maven.apache.org/plugins/maven-compiler-plugin/howto.html -M On 10/25/06, Gregory Shimansky <[EMAIL PROTECTED]> wrote: > On Thursday 26 October 2006 02:07 Matthias Wessendorf wrote: > > :) > > > > I wanna run the Trinidad build against javac from harmony! > > > > :) > > I think you can do it already and it should probably work. If Trinidad build > uses ant, just using JAVA_HOME to point to Harmony would make it the JRE > which ant uses. > > To use eclipse compiler (which is going to be used for Harmony javac) you can > use ecj3.2.jar from [1] (this jar file has to be placed in $ANT_HOME/lib/ > directory). To make ant use it you can specify it in > compiler="org.eclipse.jdt.core.JDTCompilerAdapter" tag of javac ant target. > > Correct my if I missed something. > > [1] > http://download.eclipse.org/eclipse/downloads/drops/R-3.2-200606291905/ecj.jar -- Alexei Zakharov, Intel Enterprise Solutions Software Division
Re: [classlib][serialization] Conditional object replacement in ObjectInputStream - bug in RI?
Hi,
I have posted the patch for HARMONY-1920. I will be glad if some
committer take a look at it. I mean the more powerfull one than me :-/
I've also tried to resolve HARMONY-1921, but it seems a good luni
expertice is required for that. So it may be the good task for local
luni exprets floating around.
With best regards,
2006/10/20, Alexei Zakharov <[EMAIL PROTECTED]>:
Hi Mikhail,
I don't see any problems with the RI behavior here. The spec says
about the ObjectInputStream#resolveClass() method:
"This method will be invoked only once for each unique class in the stream."
So your TestObjectInputStream#resolveClass() will be called only once.
And all serialized objects in the stream that have original type
a.TestClass will be deserialized to the type b.TestClass and it is the
correct behavior. This way, ClassCastException at line
>try {
>a.TestClass to4 = (a.TestClass) ois.readObject();
is expected since you are trying to cast the object of type
b.TestClass to incompatible type a.TestClass. Does it makes sense?
Thanks,
2006/10/19, Mikhail Markov <[EMAIL PROTECTED]>:
> Hi!
>
> I've recently filed 2 JIRAs (HARMONY-1920 and HARMONY 1921) related to the
> object replacement in ObjectInputStream by means of resolveObject() method
> and during experimenting with the tests, created the test which replaces the
> object according to some rule (see the code at the bottom of the message).
> Unexpectedly it fails on RI with the output:
>
> TestObjectInputStream.resolveClass() is called.
> 1-st read passed.
> 2-nd read failed with exception: java.lang.ClassCastException: b.TestClass
>
> This output indicates that RI performs caching for object replacements and
> second read just did not call resolveClass() method from
> TestObjectInputStream.
>
> I did not find any info about this case in serialization specification
> and not quite sure if this behaviour is correct. Is this a bug in RI?
> If not then this case should be also taken into account while fixing
> HARMONY-1921 JIRA.
>
> - Test.java -
> import java.io.*;
>
> public class Test {
>public static void main(String[] args) throws Exception {
>a.TestClass to1 = new a.TestClass();
>to1.i = 555;
>a.TestClass to2 = new a.TestClass();
>to2.i = 777;
>ByteArrayOutputStream baos = new ByteArrayOutputStream();
>ObjectOutputStream oos = new ObjectOutputStream(baos);
>oos.writeObject(to1);
>oos.writeObject(to2);
>oos.flush();
>byte[] bytes = baos.toByteArray();
>ByteArrayInputStream bais = new ByteArrayInputStream(bytes);
>ObjectInputStream ois = new TestObjectInputStream(bais);
>
>try {
>b.TestClass to3 = (b.TestClass) ois.readObject();
>
>if (to3.i != to1.i) {
>System.out.println("1-st read failed. Expected: " + to1.i +
> ", got: " + to3.i);
>} else {
>System.out.println("1-st read passed.");
>}
>} catch (Exception ex) {
>System.out.println("1-st read failed with exception: " + ex);
>}
>
>try {
>a.TestClass to4 = (a.TestClass) ois.readObject();
>
>if (to4.i != to2.i) {
>System.out.println("2-nd read failed. Expected: " + to2.i +
> ", got: " + to4.i);
>} else {
>System.out.println("2-nd read passed.");
>}
>} catch (Exception ex) {
>System.out.println("2-nd read failed with exception: " + ex);
>}
>}
>
>static class TestObjectInputStream extends ObjectInputStream {
>private boolean replaced = false;
>
>public TestObjectInputStream(InputStream in) throws IOException {
>super(in);
>}
>
>protected Class resolveClass(ObjectStreamClass desc)
>throws IOException, ClassNotFoundException {
>if (desc.getName().equals("a.TestClass")) {
>System.out.println("TestObjectInputStream.resolveClass() is
> called.");
>
>if (!replaced) {
>replaced = true;
>return b.TestClass.class;
>} else {
>return a.TestClass.class;
>}
>}
>return super.resolveClass(desc);
>}
>}
> }
> - a/TestClass.java -
> package a;
>
Re: [general] Announcing newest members of the Harmony PPMC
My congratulations! 2006/10/25, Geir Magnusson Jr. <[EMAIL PROTECTED]>: As progress towards our goal of having all committers on the PPMC, the Harmony PPMC is proud to announce it's newest members : Nathan Beyer Paulex Yang Weldon Washburn Please join us in congratulating them (and then tell them to get back to work...) :) The Harmony PPMC -- Alexei Zakharov, Intel Enterprise Solutions Software Division
Re: RE: Thoughtless fixes considered harmful Was: [OT] Automated fixes considered harmful
Hi all, I agree that code beautifying is a nice thing, But personally I prefer to do this kind of job manually and only in case if I have the idea what is this code about. Automated tools suit well for easy tasks like tabs to spaces replacement and may be code reformating (with caution). But if the change affects the semantics somehow I always do it by hands. Just my 0.02$ Thanks, 2006/10/23, Ivanov, Alexey A <[EMAIL PROTECTED]>: >-Original Message- >From: Alex Blewitt [mailto:[EMAIL PROTECTED] >Sent: Saturday, October 21, 2006 3:32 AM >To: harmony-dev@incubator.apache.org >Subject: Re: RE: Thoughtless fixes considered harmful Was: [OT] Automated >fixes considered harmful > >On 21/10/06, Fedotov, Alexei A <[EMAIL PROTECTED]> wrote: >> Alex, >> I see and accept your point. I believe that partial commits are a must - >> we should be a community. >> >> My point is simple - the code under active development shouldn't be a >> subject of beautification - it just should be safe for other Harmony >> modules. The first goal is to make it work. > >Completely agree. Code which is fluctuating under development >shouldn't cause a concern that it's generating warnings for this kind >of thing. > >Once the code matures, and is fully implemented and tested, *then* >that's the time to start the beautification process :-) > I agree with this too. No beautification should be performed on code which is actively being developed. I think everybody understands it clearly. But once the code is quite stable and only bug fixes are applied to it, I see no harm from deleting unused local variables and imports. Removing unreferenced private fields and methods can be dangerous. Nevertheless I'd vote for removing ones as well. It makes code more concise leaving no legacy. -- Alexei Zakharov, Intel Enterprise Solutions Software Division
Re: [vote] Graduate Apache Harmony podling from the Incubator
+1 from me. Our community seems to be very active and healthful. Best regards, 2006/10/20, Geir Magnusson Jr. <[EMAIL PROTECTED]>: We're trying something a little different. I think Roy Fielding one said something along the lines of "when a community gets organized enough to vote itself out of the Incubator, it's appropriate." So to bring the Harmony community and the Incubator community together for this important event in Harmony's life, I'm calling for a vote on graduating Harmony here on our own -dev list. The objective is for all in both the Harmony community and the Incubator community that have an opinion to vote together, in the same place, and have it "hosted" by the Harmony podling. This is an unconventional way to do this, but I think that it's valid and could provide one example to the Incubator on how it can work going forward. So, without any further ado : [ ] +1 Graduate Apache Harmony from incubation, and let it petition the board for Top Level Project status [ ] 0 No opinion [ ] -1 No, don't graduate Harmony. Here's why : This vote will end 72 hours from now + time of Apache mail outage. It will therefore end on Monday, October 23, at 3:30 PM eastern, + delta for mail outage. Thanks geir -- Alexei Zakharov, Intel Enterprise Solutions Software Division
Re: [classlib][test] Configuration dependent test of InetAddress.getHostName
I think Harmony does the right thing as spec requires, the difference is
caused by underlying system call, so it should be acceptable, i.e., the
test needs to be rewritten or excluded.
+1 from me
Thanks,
2006/10/20, Paulex Yang <[EMAIL PROTECTED]>:
Denis Kishenko wrote:
> I have researched issue H-1664 and found one more difference with RI.
> I run simple test on Windows Server 2003 SP1
>
> === Test =
> import java.net.InetAddress;
> import java.net.UnknownHostException;
>
> public class Test {
>public static void main(String[] args) throws UnknownHostException {
>System.out.println("by name (127.0.0.1) -> " +
> InetAddress.getByName("127.0.0.1").getHostName());
>System.out.println("by name (localhost) -> " +
> InetAddress.getByName("localhost").getHostName());
>System.out.println("by address -> " +
> InetAddress.getByAddress(new byte[]{127, 0, 0, 1}).getHostName());
>System.out.println("localhost -> " + InetAddress.getLocalHost());
>}
>
> }
>
> Windows Server 2003 SP1
> === RI ==
>by name (127.0.0.1) -> 127.0.0.1
>by name (localhost) -> localhost
>by address -> 127.0.0.1
>localhost -> nstdrlew21/10.125.122.60
>
> = Harmony ==
>by name (127.0.0.1) -> nstdrlew21.ins.intel.com
>by name (localhost) -> localhost
>by address -> nstdrlew21.ins.intel.com
>localhost -> nstdrlew21/10.125.122.60
>
> WinXP
> = Both ===
> by name (127.0.0.1) -> localhost
> by name (localhost) -> localhost
> by address -> localhost
> localhost -> pbwdmkishen/10.125.132.226
>
>
> Actually Harmony use native call of getnameinfo() to get host name
> (which is reasonable IMHO). MSDN says "The getnameinfo function
> provides name resolution from an address to the host name".
>
> InetAddressTest.test_getHostName (see H-1664) failed on WinServer
> because InetAddress.getByName("127.0.0.1").getHostName() returned
> "nstdrlew21.ins.intel.com" while "localhost" expected. So this test
> looks like configuration dependent.
>
> I see three possible options
> 1. Stay test as is. Just keep in mind that on specific configurations
> this one fails.
> 2. Rewrite test to be configuration dependent. Test has to do the same
> native call.
> 3. Exclude localhost checking from test_getHostName.
I think Harmony does the right thing as spec requires, the difference is
caused by underlying system call, so it should be acceptable, i.e., the
test needs to be rewritten or excluded. But this issue worth a non-bug
difference together with getHostName()'s different behavior when
SecurityManager presents[1](thanks Alexei Fedotov helped to find this
link and commented to HARMONY-1664:))
Harmony-73 is another issue, which is actually caused by HARMONY-84 and
irrelevant with getHostName() method.
[1]
http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200602.mbox/[EMAIL
PROTECTED]
>
> What do you think about this situation?
--
Alexei Zakharov,
Intel Enterprise Solutions Software Division
Re: [classlib][serialization] Conditional object replacement in ObjectInputStream - bug in RI?
Hi Mikhail,
I don't see any problems with the RI behavior here. The spec says
about the ObjectInputStream#resolveClass() method:
"This method will be invoked only once for each unique class in the stream."
So your TestObjectInputStream#resolveClass() will be called only once.
And all serialized objects in the stream that have original type
a.TestClass will be deserialized to the type b.TestClass and it is the
correct behavior. This way, ClassCastException at line
try {
a.TestClass to4 = (a.TestClass) ois.readObject();
is expected since you are trying to cast the object of type
b.TestClass to incompatible type a.TestClass. Does it makes sense?
Thanks,
2006/10/19, Mikhail Markov <[EMAIL PROTECTED]>:
Hi!
I've recently filed 2 JIRAs (HARMONY-1920 and HARMONY 1921) related to the
object replacement in ObjectInputStream by means of resolveObject() method
and during experimenting with the tests, created the test which replaces the
object according to some rule (see the code at the bottom of the message).
Unexpectedly it fails on RI with the output:
TestObjectInputStream.resolveClass() is called.
1-st read passed.
2-nd read failed with exception: java.lang.ClassCastException: b.TestClass
This output indicates that RI performs caching for object replacements and
second read just did not call resolveClass() method from
TestObjectInputStream.
I did not find any info about this case in serialization specification
and not quite sure if this behaviour is correct. Is this a bug in RI?
If not then this case should be also taken into account while fixing
HARMONY-1921 JIRA.
- Test.java -
import java.io.*;
public class Test {
public static void main(String[] args) throws Exception {
a.TestClass to1 = new a.TestClass();
to1.i = 555;
a.TestClass to2 = new a.TestClass();
to2.i = 777;
ByteArrayOutputStream baos = new ByteArrayOutputStream();
ObjectOutputStream oos = new ObjectOutputStream(baos);
oos.writeObject(to1);
oos.writeObject(to2);
oos.flush();
byte[] bytes = baos.toByteArray();
ByteArrayInputStream bais = new ByteArrayInputStream(bytes);
ObjectInputStream ois = new TestObjectInputStream(bais);
try {
b.TestClass to3 = (b.TestClass) ois.readObject();
if (to3.i != to1.i) {
System.out.println("1-st read failed. Expected: " + to1.i +
", got: " + to3.i);
} else {
System.out.println("1-st read passed.");
}
} catch (Exception ex) {
System.out.println("1-st read failed with exception: " + ex);
}
try {
a.TestClass to4 = (a.TestClass) ois.readObject();
if (to4.i != to2.i) {
System.out.println("2-nd read failed. Expected: " + to2.i +
", got: " + to4.i);
} else {
System.out.println("2-nd read passed.");
}
} catch (Exception ex) {
System.out.println("2-nd read failed with exception: " + ex);
}
}
static class TestObjectInputStream extends ObjectInputStream {
private boolean replaced = false;
public TestObjectInputStream(InputStream in) throws IOException {
super(in);
}
protected Class resolveClass(ObjectStreamClass desc)
throws IOException, ClassNotFoundException {
if (desc.getName().equals("a.TestClass")) {
System.out.println("TestObjectInputStream.resolveClass() is
called.");
if (!replaced) {
replaced = true;
return b.TestClass.class;
} else {
return a.TestClass.class;
}
}
return super.resolveClass(desc);
}
}
}
- a/TestClass.java -
package a;
import java.io.Serializable;
public class TestClass implements Serializable {
private static final long serialVersionUID = 1L;
public int i = 0;
}
- b/TestClass.java -
package b;
import java.io.Serializable;
public class TestClass implements Serializable {
private static final long serialVersionUID = 1L;
public int i = 0;
}
-
--
Alexei Zakharov,
Intel Enterprise Solutions Software Division
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [general] Incubator graduation update
The same situation with DNS provider for JNDI. The only dependence is the internationalization stuff added recently. Regards, 2006/10/20, Mikhail Loenko <[EMAIL PROTECTED]>: 2006/10/20, Geir Magnusson Jr. <[EMAIL PROTECTED]>: > For those that haven't been following along > > Graduating from the Incubator is a "dynamic" process, as there's no > really hard and fast rules to satisfy. On one hand, this is a good > thing, because determining the health and prospect of future success of > an Apache community is a difficult job, and it therefore relies on the > experience and judgment of the Incubator PMC members. (It also allows > the process to be adapted for different kinds of podlings - we're a > weird one...) On the other hand, it can result it individual Incubator > PMC members using different "filter" criterion. > > Now, I'm really proud to be a part of this community - I think we work > very well together, collaboratively, in a positive and friendly > atmosphere, and have demonstrated time and again the ability to vote, > deal with issues that arise in voting, deal with differences of opinion, > amass great hunks of software into an orderly project, etc. > > That said, I'm not very optimistic that we'll be able to bring this to a > close in time for this month's board meeting. It's a shame, but that's > ok - we're really in no rush, and if not this month, then next month. > There are no major problems - it's partially because of the rather short > timelines we tried, and partially because there are a few issues under > discussion on the general@incubator.apache.org list, a list I encourage > all of you to subscribe to and participate in. > > First, there are minor 'nits' here and there related to license and > license headers. For example, we're missing the antlr license in our > NOTICE file. Patch anyone? Also, there are other minor things here and > there which can be found with this tool : > > http://code.google.com/p/arat/ > > Anyone interested in running it ASAP and giving us a set of patches to > get a clean bill of health? > > Second, we're having a discussion on the general@ list (in which we all > can participate) regarding the necessity of a project going through a > release. This isn't actually an Incubator requirement, but the case > where information on community health and dynamics is absent or scarce, > it's a reasonable exercise. > > However... for Harmony, that isn't the case. I've been arguing that > there's plenty of information on us. All four of us mentors (Stefano, > Leo, Dims and myself) reported very positive independent assessments of > the community (go read on general@) and we have 18 months of consistent, > positive interaction with each other. My thinking was that > > 1) A release is something that we haven't wanted to do yet as a project, > as our interest is in producing a more complete and stable > implementation first. We have a roadmap, it's been published for a > while now, and at least for me, it's the goal that I'm looking towards > every day. (heck... we're still deciding what "supported" means...) > > 2) We're not stable enough to do something we want to shout out to the > world as a "developer release" or similar. We will be ready soon, but > not now. (This is just my personal opinion - others may certainly > differ...) > > Anyway, that's what I feel about it. There are Incubator PMC members > that have decided that there is ample information (Dims, Stefano and Leo > really hit it out of the park with their assessments... thanks guys!) > and have changed their minds, and I'm hoping to reach consensus with the > rest that there *is* enough information. > > However, if not, and some IPMC memebers still really want to see a > demonstration of a release process, we can certainly do that. I've > thought about what we might release. One thing that came to mind is a > Pack200 jar :) > > Any other ideas, and any other thoughts? Another option: We have three security providers that are independent pluggable modules by definition. We can release all or some of them -- Alexei Zakharov, Intel Enterprise Solutions Software Division - 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][test] Configuration dependent test of InetAddress.getHostName
Hi Denis,
InetAddressTest.test_getHostName (see H-1664) failed on WinServer
because InetAddress.getByName("127.0.0.1").getHostName() returned
"nstdrlew21.ins.intel.com" while "localhost" expected. So this test
According to the test's output you've provided:
=== RI ==
by name (127.0.0.1) -> 127.0.0.1
RI returns "127.0.0.1" rather than "localhost". Is it written
somewhere in the spec that
InetAddress.getByName("127.0.0.1").getHostName() should return
"localhost"?
Thanks,
2006/10/19, Denis Kishenko <[EMAIL PROTECTED]>:
I have researched issue H-1664 and found one more difference with RI.
I run simple test on Windows Server 2003 SP1
=== Test =
import java.net.InetAddress;
import java.net.UnknownHostException;
public class Test {
public static void main(String[] args) throws UnknownHostException {
System.out.println("by name (127.0.0.1) -> " +
InetAddress.getByName("127.0.0.1").getHostName());
System.out.println("by name (localhost) -> " +
InetAddress.getByName("localhost").getHostName());
System.out.println("by address -> " +
InetAddress.getByAddress(new byte[]{127, 0, 0, 1}).getHostName());
System.out.println("localhost -> " + InetAddress.getLocalHost());
}
}
Windows Server 2003 SP1
=== RI ==
by name (127.0.0.1) -> 127.0.0.1
by name (localhost) -> localhost
by address -> 127.0.0.1
localhost -> nstdrlew21/10.125.122.60
= Harmony ==
by name (127.0.0.1) -> nstdrlew21.ins.intel.com
by name (localhost) -> localhost
by address -> nstdrlew21.ins.intel.com
localhost -> nstdrlew21/10.125.122.60
WinXP
= Both ===
by name (127.0.0.1) -> localhost
by name (localhost) -> localhost
by address -> localhost
localhost -> pbwdmkishen/10.125.132.226
Actually Harmony use native call of getnameinfo() to get host name
(which is reasonable IMHO). MSDN says "The getnameinfo function
provides name resolution from an address to the host name".
InetAddressTest.test_getHostName (see H-1664) failed on WinServer
because InetAddress.getByName("127.0.0.1").getHostName() returned
"nstdrlew21.ins.intel.com" while "localhost" expected. So this test
looks like configuration dependent.
I see three possible options
1. Stay test as is. Just keep in mind that on specific configurations
this one fails.
2. Rewrite test to be configuration dependent. Test has to do the same
native call.
3. Exclude localhost checking from test_getHostName.
What do you think about this situation?
--
Alexei Zakharov,
Intel Enterprise Solutions Software Division
-
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][beans] Failed to build classlib
Hi Vera,
It seems you have experienced some problems with
classpath/bootclasspath. Try to do "ant clean".
Thanks,
19.10.06, Volynets, Vera<[EMAIL PROTECTED]> написал(а):
Hi,
I've tried to build classlib today.
it failed with following message:
-compile:
[javac] Since compiler setting isn't classic or modern,ignoring fork setting.
[javac] Compiling 43 source files to
C:\cygwin\work\harmony\trunk\working_classlib\build\classes
[javac] Since compiler setting isn't classic or modern,ignoring fork setting.
[javac] --
[javac] 1. ERROR in
C:\cygwin\work\harmony\trunk\working_classlib\modules\beans\src\main\java\java\beans\Encoder.java
[javac] (at line 129)
[javac] if (!Statement.isPDConstructor(oldExp)
[javac]^^^
[javac] The method isPDConstructor(Expression) is undefined for the type
Statement
[javac] --
[javac] 2. ERROR in
C:\cygwin\work\harmony\trunk\working_classlib\modules\beans\src\main\java\java\beans\Encoder.java
[javac] (at line 130)
[javac] && !Statement.isStaticMethodCall(oldExp)) {
[javac] ^^
[javac] The method isStaticMethodCall(Expression) is undefined for the type
Statement
[javac] --
[javac] --
[javac] 3. ERROR in
C:\cygwin\work\harmony\trunk\working_classlib\modules\logging\src\main\java\java\util\logging\Logger.java
[javac] (at line 431)
[javac] Handler handler =
(Handler)LogManager.getInstanceByClass(handlerName);
[javac] ^^
[javac] The method getInstanceByClass(String) is undefined for the type
LogManager
[javac] --
[javac] 3 problems (3 errors)
I think this patches could be reason of failure.
r465186 | mloenko | 2006-10-18 13:28:23 +0400 (Wed, 18 Oct 2006) | 2 lines
applied patch from HARMONY-1529
[classlib][beans] new fixes for DefaultPersistenceDelegate failures (2)
r465159 | mloenko | 2006-10-18 10:42:49 +0400 (Wed, 18 Oct 2006) | 3 lines
applied patch from HARMONY-1521
[classlib][beans] XMLEncoder.writeStatement(null) thorws NPE on Harmony and
works OK on RI
removed redundant method
r465156 | mloenko | 2006-10-18 10:23:52 +0400 (Wed, 18 Oct 2006) | 2 lines
applied patch from HARMONY-1515
[classlib][beans] EventSetDescriptor(.., Method) throws IntrospectionException
on Harmony end creates object on RI
r465154 | mloenko | 2006-10-18 10:15:34 +0400 (Wed, 18 Oct 2006) | 2 lines
applied patch from HARMONY-1504
[classlib][beans] RI throws NPE for public EventSetDescriptor(...) while
Harmony does not
r465152 | mloenko | 2006-10-18 10:00:21 +0400 (Wed, 18 Oct 2006) | 2 lines
applied patch from HARMONY-1304
[classlib][bean] compatibility: no NPE on Harmony for
Encoder().setPersistenceDelegate(Void.TYPE, null)
--
Alexei Zakharov,
Intel Enterprise Solutions Software Division, Russia
Re: [classlib][kernel]A bug or non-bug difference?
Hi,
Does it really fail? Or some not-very-important testcase fails?
Thanks,
2006/10/19, Mikhail Fursov <[EMAIL PROTECTED]>:
IMHO if Log4J fails we have no chances to keep our behavour and must follow
RI here.
On 10/19/06, Tony Wu <[EMAIL PROTECTED]> wrote:
>
> I've tried Log4j on Harmony and found there are many failures caused
> by one difference between RI and Harmony. The
> Throwable.printStackTrace(PrintWriter) calls the *println* method of
> PrinterWriter on RI whereas calls *print* twice(Obviously print
> msssage then print a line separator) on Harmony. It will cause
> different behavior when a user inherit the PrinterWriter and override
> these two methods. Shall we fix it or leave as an non-bug difference?
>
> refer to testcase below,
>
> public class TestThrow {
> public static void main(String[] args) {
> MyWriter mw = new MyWriter(System.out);
> Throwable throwable = new Exception("Just Testing");
> throwable.printStackTrace(mw);
> }
> }
> class MyWriter extends PrintWriter {
> public MyWriter(OutputStream out) {
> super(out);
> }
>
> public void print(String s) {
> System.out.println("print");
> }
>
> public void println(String s) {
> System.out.println("println");
> }
> }
> OUTPUTS:
> RI
> println
> HARMONY
> print
> print
--
Alexei Zakharov,
Intel Enterprise Solutions Software Division
-
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] build fails: build-java.xml:143: java.lang.reflect.InvocationTargetException
Which JRE are you using to run Ant? I don't know what the default -Xmx is for Sun. I was using Sun JDK 1.5.0 indeed. There is some info about memory limits in Sun VM at [1]: <-- maximum heap size: Smaller of 1/4th of the physical memory or 1GB. Before J2SE 5.0, the default maximum heap size was 64MB. You can override this default using the -Xmx command-line option. <-- However, it is only valid if the parallel gabage collector is used. [1] http://java.sun.com/j2se/1.5.0/docs/guide/vm/gc-ergonomics.html Regards, 2006/10/18, Tim Ellison <[EMAIL PROTECTED]>: Geir Magnusson Jr. wrote: > can we set this in the build somewhere ? (why is ECJ such a pig? :) Which JRE are you using to run Ant? I'm using IBM 5.0 SR2 (without ANT_OPTS) and don't have this problem. I also see OOM during gen-report with Sun code, but not with IBM's. I don't know what the default -Xmx is for Sun. Regards, Tim -- Alexei Zakharov, Intel Enterprise Solutions Software Division, Russia - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [general] POLL : supported platforms
b) platforms that we certify as being compatible, but don't make any support promises Well, I can periodically run tests on and report issues for Windows 2000. I think it fits this your (b) category. Regards, 2006/10/18, Geir Magnusson Jr. <[EMAIL PROTECTED]>: Mikhail Fursov wrote: > Mikhail, > The situation is possible with some Linux clones. > And if we have such a situation I propose to take into account if we have a > commiter/volunteer to check this platform. > If we have a volunteer - we support it. > > Another question is: what if volunteer is gone and no one supports the > platform? Will we claim that Harmony no longer supports the platform? No - to be supported, we have to agree as a community. I'm wary about there being one-person-supported platforms. We can easily have two categories - a) platforms that we certify as being compatible, and support b) platforms that we certify as being compatible, but don't make any support promises geir > > On 10/18/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote: >> >> 2006/10/17, Geir Magnusson Jr. <[EMAIL PROTECTED]>: >> > >> > >> > Mikhail Loenko wrote: >> > > 2006/10/17, Geir Magnusson Jr. <[EMAIL PROTECTED]>: >> > >> >> > >> >> > >> Mikhail Fursov wrote: >> > > I think if we decide to support a platform then we define a set of >> tests >> > > that >> > > must pass on that platform after each commit and we do roll back if >> they >> > > fail. That is how I understand "support" >> > >> > Lets define support as passing >90% of classlib unit and >> > smoke/c-unit/kernel in DRLVM >> >> It might be a criteria for addition to the set of supported, but can't >> be a definition. >> Logically there could be a platform that we don't know, but that platform >> could >> pass 99% of the tests, do you think we can support a platform we don't >> have any >> idea about? -- Alexei Zakharov, Intel Enterprise Solutions Software Division, Russia - 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] logging (was: Re: [classlib][xnet] Problem connecting using SSLSocketImpl)
If you do want to inject application-level tracing then I'd go for aspects, which are designed specifically to provide such orthogonal behavior to the classlib functionality. I suppose we still need someone to investigate this field and invent the acceptable solution. I remember Geir volunteered to do something in this direction. Regards, 2006/10/18, Tim Ellison <[EMAIL PROTECTED]>: Mikhail Loenko wrote: > 2006/10/17, Alexander Kleymenov <[EMAIL PROTECTED]>: > > Hi Tim > >> BTW, there are some logging capabilities in JSSE provider. You can >> turn them on by specifying -Djsse=record,prf,socket as an option to >> VM. Log output could be useful in problem analysis. > > You asked why we need logging. Now we have an example. I maintain that we should not be putting printf's (i.e. calls to logging) in the Java code. We are running on a virtual machine that knows everything about the executing code, what methods are being invoked, the actual arguments, the state of the stacks and the heap, etc. There is much more value in a good trace story built into the VM than having developers decide a priori where the problems are going to be. By adding logging calls you have a much more significant effect on the code base, you hit performance, modify the stack to log the messages, bloat the code for readability, and by definition introduce more bugs and maintenance overhead. If you do want to inject application-level tracing then I'd go for aspects, which are designed specifically to provide such orthogonal behavior to the classlib functionality. If you look here[1] there is a document that describes the diagnostics capabilities in the IBM VM that we use to support our customers. [1] http://www-128.ibm.com/developerworks/java/jdk/diagnosis/ Regards, Tim -- Alexei Zakharov, Intel Enterprise Solutions Software Division, Russia - 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] build fails: build-java.xml:143: java.lang.reflect.InvocationTargetException
Thanks, that helps. ant -Dhy.javac.maxmem=512M doesn't work for some reason. Regards, 2006/10/17, Andrew Zhang <[EMAIL PROTECTED]>: Please try to set ANT_OPTS = -Xms256M -Xmx512M I met the same problem 10 hours ago. :-) On 10/18/06, Alexei Zakharov <[EMAIL PROTECTED]> wrote: > > Hmm, I've got the same problem. Current workaround is to switch back > to sun javac > ant -Dhy.javac.compiler=modern -Dhy.javac.maxmem=512M > > I am still trying... > > Regards, > > 2006/10/17, Weldon Washburn <[EMAIL PROTECTED]>: > > I am at revision 464949. Does anyone else see this problem? > > > > > > > > BUILD FAILED > > C:\t_harmony\classlib\trunk\build.xml:108: The following error occurred > > while ex > > ecuting this line: > > C:\t_harmony\classlib\trunk\make\build-java.xml:143: > > java.lang.reflect.Invocatio > > nTargetException > > > > Total time: 22 seconds -- Alexei Zakharov, Intel Enterprise Solutions Software Division, Russia - 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] build fails: build-java.xml:143: java.lang.reflect.InvocationTargetException
Hmm, I've got the same problem. Current workaround is to switch back to sun javac ant -Dhy.javac.compiler=modern -Dhy.javac.maxmem=512M I am still trying... Regards, 2006/10/17, Weldon Washburn <[EMAIL PROTECTED]>: I am at revision 464949. Does anyone else see this problem? BUILD FAILED C:\t_harmony\classlib\trunk\build.xml:108: The following error occurred while ex ecuting this line: C:\t_harmony\classlib\trunk\make\build-java.xml:143: java.lang.reflect.Invocatio nTargetException Total time: 22 seconds -- Alexei Zakharov, Intel Enterprise Solutions Software Division, Russia - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ECJ set as default compiler (WAS: [general] version of gcc and other tools)
IMHO the correct ECJ jar should be located at classlib/trunk/depends/jars/ecj_3.2/ecj.jar You may also try to increase java heap size by setting ANT_OPTS variable to something like "-Xmx512M". Regards, 2006/10/17, Weldon Washburn <[EMAIL PROTECTED]>: All, I did a fresh "svn checkout" an hour ago. During build, I saw the message, "...please place ECJ.JAR in ANT_HOME/lib" and did what it said. Given a JAVA_HOME=.../jdk1.5.0_07, there may be more to it than just copying a jar file. My guess is that adding ECJ.JAR to Sun javac is now causing the following error message: [javac] -- [javac] 1. ERROR in C:\t_harmony\classlib\trunk\modules\archive\src\main\jav a\java\util\jar\Pack200.java [javac] (at line 0) [javac] /* [javac] ^ [javac] Internal compiler error [javac] java.lang.OutOfMemoryError: Java heap space I looked for a README file that says something about which Eclipse compiler to download and where to get it. Or if it is already downloaded, where to find it on my local drive. A "find" of README files on classlib/trunk turns up 2052 instances. If its in a README, its well obscured! Please tell me where the instructions are for downloading the correct version of Eclipse compiler. It might be good to add where to find Eclipse compiler to the, "...please place EJC.JAR" message. On 10/16/06, Nathan Beyer <[EMAIL PROTECTED]> wrote: > > I've set the default compiler value to use the ECJ adapter. I've also > added a check to fail the build (in build-java.xml and > build-tests.xml) if the ECJ adapter class is missing. The message says > that the ECJ JAR is missing and to copy it from the depends folder. > > If there are any changes or suggestions for a more elegant Ant > solution, just let me know and I'll add them. > > Note: The build seemingly takes a bit longer, as ECJ reports a > significant amount of warnings by default. Personally, these are > things I believe need to be cleaned up anyway (unused imports, missing > serialVersionUIDs, etc). I haven't figured out to configure the ECJ > options via the Ant task yet, so if anyone know, please let the list > know. > > Mark, Tim, IBM folks, > This may require an update to the automated builds if Ant isn't setup > like this yet, sorry. > > -Nathan > > -- Forwarded message -- > From: Geir Magnusson Jr. <[EMAIL PROTECTED]> > Date: Oct 16, 2006 12:38 PM > Subject: Re: [general] version of gcc and other tools > To: harmony-dev@incubator.apache.org > > > None from me, but please also add some useful message for people if not > found like "ECJ not found. Please copy to ..." > > > > Nathan Beyer wrote: > > On 10/15/06, Tim Ellison <[EMAIL PROTECTED]> wrote: > >> Geir Magnusson Jr. wrote: > >> > I suppose that as a temporary solution, we can just get people to > drop > >> > ECJ into ant/lib... > >> > >> Yes, that would be my preferred solution too, until Ant support comes > >> along. > >> > > > > Any objections to setting the harmony default compiler (in the build > > scripts) to Eclipse then? The 'fetch-depends' already downloads the > > necessary JAR, so copying it over should be a trivial task for now. -- Alexei Zakharov, Intel Enterprise Solutions Software Division, Russia - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [announce] New Apache Harmony Committers : Oliver Deakin, Richard Liang, Alexey Petrenko, Gregory Shimansky, Alexey Varlamov, Alexei Zakharov
Congratulations! I believe in us. :) Regards, 2006/10/17, Geir Magnusson Jr <[EMAIL PROTECTED]>: Please join the Apache Harmony PPMC in welcoming the project's newest committers, in alphabetical order : Oliver Deakin Richard Liang Alexey Petrenko Gregory Shimansky Alexey Varlamov Alexei Zakharov These six individuals have shown sustained dedication to the project, an ability to work well with others, and share the common vision we have for Harmony. We all continue to expect great things from them. Gentlemen, you don't have accounts yet. When you finally receive your new committer account information, as a first step to test your almighty powers of committitude, please update the committers page on the website. That should be a good (and harmless) exercise to test if everything is working. Things to do : 1) test ssh-ing to the server people.apache.org. 2) Change your login password on the machine 3) Add a public key to .ssh so you can stop using the password 4) Set your SVN password : just type 'svnpasswd' At this point, you should be good to go. Checkout the website from svn and update it. See if you can figure out how. Also, anything checked out of SVN, be sure that you have checked out via 'https' and not 'http' or you can't check in. You can switch using "svn switch". (See the manual) Finally, although you now have the ability to commit, please remember : 1) continue being as transparent and communicative as possible. You earned committer status in part because of your engagement with others. While it was a "have to" situation because you had to submit patches and defend them, but we believe it is a "want to". Community is the key to any Apache project. 2)We don't want anyone going off and doing lots of work locally, and then committing. Committing is like voting in Chicago - do it early and often. Of course, you don't want to break the build, but keep the "commit bombs" to an absolute minimum, and warn the community if you are going to do it - we may suggest it goes into a branch at first. Use branches if you need to. 3) Always remember that you can **never** commit code that comes from someone else, even a co-worker. All code from someone else must be submitted by the copyright holder (either the author or author's employer, depending) as a JIRA, and then follow up with the required ACQs and BCC. Again, thanks for your hard work so far, and welcome. The Apache Harmony PPMC -- Alexei Zakharov, Intel Enterprise Solutions Software Division, Russia - 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][beans] RI inconsistency in EventHandler
HARMONY-1884 was created.
Thanks,
2006/10/16, Alexei Zakharov <[EMAIL PROTECTED]>:
I am ok with this. :) Will file a JIRA soon.
Regards,
2006/10/16, Tim Ellison <[EMAIL PROTECTED]>:
> I'm fine with marking it as a non-bug difference, with the option to fix
> it if we find some compelling application that relies on this non-spec
> behavior. Is that weasely enough?
>
> Regards,
> Tim
>
> Alexei Zakharov wrote:
> > Hi Tim,
> >
> > <-- persuasion starts here
> >
> > Let me cite the spec describing design patterns for properties,
> > JavaBeans spec v1.01-A (Aug 8, 1997), page 55:
> >
> > ---
> > 8.3 Design Patterns for Properties
> >
> > 8.3.1 Simple properties
> > By default, we use design patterns to locate properties by looking for
> > methods of the form:
> >
> > public get();
> > public void set( a);
> >
> > 8.3.2 Boolean properties
> > In addition, for boolean properties, we allow a
> >
> > public boolean is();
> >
> > 8.3.3 Indexed properties
> > If we find a property whose type is an array "[]",
> > then we also look for methods of the form:
> >
> > public get(int a);
> > public void set(int a, b);
> > ---
> >
> > So we have only three design patterns specified for properties. That's
> > all. I didn't found any mentioning about any extra design patterns and
> > I've never heard anything about setDefaults() or smth. like it.
> >
> > On the other hand, if I understand things correctly the Introspector
> > class should be the decision-making center for such type of things.
> > I.e. if Introspector says there is no properties then there should be
> > no properties. RI doesn't seem to be using Introspector in the example
> > I've described ealier. Thus I still think it looks like RI bug.
> >
> > <-- end of persuasion
> >
> > Thanks and regards,
> >
> > 2006/10/14, Tim Ellison <[EMAIL PROTECTED]>:
> >> That is strange behavior, since as you point out it does not set a
> >> parametrized value, however, I wonder if there is some assumption that
> >> the setFoo() method may be a mutator anyway, e.g. setDefaults() or
> >> something like that? Just guessing.
> >>
> >> In this case it may be safer to follow the RI -- but I'm open to
> >> persuasion.
> >>
> >> Regards,
> >> Tim
> >>
> >> Alexei Zakharov wrote:
> >> > Hi all,
> >> >
> >> > Let me disturb you with another boring "RI inconsistency in beans"
> >> > –type of message. :) It seems I found a bug in RI. In
> >> > java.beans.EventHandler. I think RI incorrectly determines properties
> >> > here. According to spec, common sense and even the RI's implementation
> >> > of java.beans.Introspector the following bean should not contain any
> >> > properties:
> >> >
> >> >public static class MyBean {
> >> >public void setProp1() {}
> >> >}
> >> >
> >> > because "setProp1()" is not a valid setter method – it does not
> >> > contain a new value to set.
> >> > However, the following test fails on RI:
> >> >
> >> > <---
> >> > import java.beans.*;
> >> >
> >> > public class TestBeanInfo1 {
> >> >public static class MyBean {
> >> >public void setProp1() {}
> >> >}
> >> >
> >> >public static void main(String argv[]) throws Exception {
> >> >MyBean bean = new MyBean();
> >> >// "prop1" is neither the name of writeable property nor the
> >> > name of any public method
> >> >Object proxy = EventHandler.create(
> >> >PropertyChangeListener.class, bean, "prop1");
> >> >
> >> >// just to show that Introspector doesn't see the property
> >> > with name "prop1"
> >> >PropertyDescriptor[] pds =
> >> Introspector.getBeanInfo(MyBean.class,
> >> >Introspector.USE_ALL_BEANINFO).getPropertyDescriptors();
> >> >for (int i = 0; i < pds.length; i++) {
> >> >System.out.println("Property found: " + pds[i].getName());
> >> >}
> >> >
> >> >// should throw exception
> >> >try {
> >> >((PropertyChangeListener) proxy).propertyChange(
> >> >new PropertyChangeEvent(bean, "prop1", "1", "2"));
> >> >System.out.println("FAIL");
> >> >} catch (Throwable t) {
> >> >System.out.println("PASS");
> >> >}
> >> >}
> >> > }
> >> > <---
> >> >
> >> > So it determines "prop1" as a valid property. IMHO this behavior is
> >> > inconsistent and we should not follow RI. But I like to hear opinions
> >> > from the rest of the community.
> >> >
> >> > Thanks,
--
Alexei Zakharov,
Intel Enterprise Solutions Software Division, Russia
--
Alexei Zakharov,
Intel Enterprise Solutions Software Division, Russia
-
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][beans] RI inconsistency in EventHandler
I am ok with this. :) Will file a JIRA soon.
Regards,
2006/10/16, Tim Ellison <[EMAIL PROTECTED]>:
I'm fine with marking it as a non-bug difference, with the option to fix
it if we find some compelling application that relies on this non-spec
behavior. Is that weasely enough?
Regards,
Tim
Alexei Zakharov wrote:
> Hi Tim,
>
> <-- persuasion starts here
>
> Let me cite the spec describing design patterns for properties,
> JavaBeans spec v1.01-A (Aug 8, 1997), page 55:
>
> ---
> 8.3 Design Patterns for Properties
>
> 8.3.1 Simple properties
> By default, we use design patterns to locate properties by looking for
> methods of the form:
>
> public get();
> public void set( a);
>
> 8.3.2 Boolean properties
> In addition, for boolean properties, we allow a
>
> public boolean is();
>
> 8.3.3 Indexed properties
> If we find a property whose type is an array "[]",
> then we also look for methods of the form:
>
> public get(int a);
> public void set(int a, b);
> ---
>
> So we have only three design patterns specified for properties. That's
> all. I didn't found any mentioning about any extra design patterns and
> I've never heard anything about setDefaults() or smth. like it.
>
> On the other hand, if I understand things correctly the Introspector
> class should be the decision-making center for such type of things.
> I.e. if Introspector says there is no properties then there should be
> no properties. RI doesn't seem to be using Introspector in the example
> I've described ealier. Thus I still think it looks like RI bug.
>
> <-- end of persuasion
>
> Thanks and regards,
>
> 2006/10/14, Tim Ellison <[EMAIL PROTECTED]>:
>> That is strange behavior, since as you point out it does not set a
>> parametrized value, however, I wonder if there is some assumption that
>> the setFoo() method may be a mutator anyway, e.g. setDefaults() or
>> something like that? Just guessing.
>>
>> In this case it may be safer to follow the RI -- but I'm open to
>> persuasion.
>>
>> Regards,
>> Tim
>>
>> Alexei Zakharov wrote:
>> > Hi all,
>> >
>> > Let me disturb you with another boring "RI inconsistency in beans"
>> > –type of message. :) It seems I found a bug in RI. In
>> > java.beans.EventHandler. I think RI incorrectly determines properties
>> > here. According to spec, common sense and even the RI's implementation
>> > of java.beans.Introspector the following bean should not contain any
>> > properties:
>> >
>> >public static class MyBean {
>> >public void setProp1() {}
>> >}
>> >
>> > because "setProp1()" is not a valid setter method – it does not
>> > contain a new value to set.
>> > However, the following test fails on RI:
>> >
>> > <---
>> > import java.beans.*;
>> >
>> > public class TestBeanInfo1 {
>> >public static class MyBean {
>> >public void setProp1() {}
>> >}
>> >
>> >public static void main(String argv[]) throws Exception {
>> >MyBean bean = new MyBean();
>> >// "prop1" is neither the name of writeable property nor the
>> > name of any public method
>> >Object proxy = EventHandler.create(
>> >PropertyChangeListener.class, bean, "prop1");
>> >
>> >// just to show that Introspector doesn't see the property
>> > with name "prop1"
>> >PropertyDescriptor[] pds =
>> Introspector.getBeanInfo(MyBean.class,
>> >Introspector.USE_ALL_BEANINFO).getPropertyDescriptors();
>> >for (int i = 0; i < pds.length; i++) {
>> >System.out.println("Property found: " + pds[i].getName());
>> >}
>> >
>> >// should throw exception
>> >try {
>> >((PropertyChangeListener) proxy).propertyChange(
>> >new PropertyChangeEvent(bean, "prop1", "1", "2"));
>> >System.out.println("FAIL");
>> >} catch (Throwable t) {
>> >System.out.println("PASS");
>> >}
>> >}
>> > }
>> > <---
>> >
>> > So it determines "prop1" as a valid property. IMHO this behavior is
>> > inconsistent and we should not follow RI. But I like to hear opinions
>> > from the rest of the community.
>> >
>> > Thanks,
--
Alexei Zakharov,
Intel Enterprise Solutions Software Division, Russia
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] “java.compiler” property
I agree. Just tell me and I will commit the patch for EM(interpreter) and JIT modes. I agree it will be better if you do this since I'm not very familiar with DRLVM code yet. So +1 for you to go ahead. Regards, 2006/10/16, Mikhail Fursov <[EMAIL PROTECTED]>: On 10/16/06, Alexei Zakharov <[EMAIL PROTECTED]> wrote: > > Moreover, the spec obliges us to do so. The real question is: is it RI > bug or bug in spec? Personally I am for returning non-null values in > all cases. I agree. Just tell me and I will commit the patch for EM(interpreter) and JIT modes. BTW I think that we should create interpreter.emconf file and place all VM properties needed for interpreter into this file. So, in future, when we need to add more interpreter-mode option, we will not affect the EM C++ code. -- Alexei Zakharov, Intel Enterprise Solutions Software Division, Russia - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] “java.compiler” property
Moreover, the spec obliges us to do so. The real question is: is it RI bug or bug in spec? Personally I am for returning non-null values in all cases. Regards, 2006/10/16, Geir Magnusson Jr. <[EMAIL PROTECTED]>: since it's apparently undefined by spec, then putting something informational like "none" or "interpreter-only" would do no harm? geir Tim Ellison wrote: > FWIW in the IBM VM we set to java.compiler="" if the JIT is disabled. > > and the Sun 1.5.0_06 build doesn't set it at all! > > Regards, > Tim -- Alexei Zakharov, Intel Enterprise Solutions Software Division, Russia - 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][beans] RI inconsistency in EventHandler
Hi Tim,
<-- persuasion starts here
Let me cite the spec describing design patterns for properties,
JavaBeans spec v1.01-A (Aug 8, 1997), page 55:
---
8.3 Design Patterns for Properties
8.3.1 Simple properties
By default, we use design patterns to locate properties by looking for
methods of the form:
public get();
public void set( a);
8.3.2 Boolean properties
In addition, for boolean properties, we allow a
public boolean is();
8.3.3 Indexed properties
If we find a property whose type is an array "[]",
then we also look for methods of the form:
public get(int a);
public void set(int a, b);
---
So we have only three design patterns specified for properties. That's
all. I didn't found any mentioning about any extra design patterns and
I've never heard anything about setDefaults() or smth. like it.
On the other hand, if I understand things correctly the Introspector
class should be the decision-making center for such type of things.
I.e. if Introspector says there is no properties then there should be
no properties. RI doesn't seem to be using Introspector in the example
I've described ealier. Thus I still think it looks like RI bug.
<-- end of persuasion
Thanks and regards,
2006/10/14, Tim Ellison <[EMAIL PROTECTED]>:
That is strange behavior, since as you point out it does not set a
parametrized value, however, I wonder if there is some assumption that
the setFoo() method may be a mutator anyway, e.g. setDefaults() or
something like that? Just guessing.
In this case it may be safer to follow the RI -- but I'm open to persuasion.
Regards,
Tim
Alexei Zakharov wrote:
> Hi all,
>
> Let me disturb you with another boring "RI inconsistency in beans"
> –type of message. :) It seems I found a bug in RI. In
> java.beans.EventHandler. I think RI incorrectly determines properties
> here. According to spec, common sense and even the RI's implementation
> of java.beans.Introspector the following bean should not contain any
> properties:
>
>public static class MyBean {
>public void setProp1() {}
>}
>
> because "setProp1()" is not a valid setter method – it does not
> contain a new value to set.
> However, the following test fails on RI:
>
> <---
> import java.beans.*;
>
> public class TestBeanInfo1 {
>public static class MyBean {
>public void setProp1() {}
>}
>
>public static void main(String argv[]) throws Exception {
>MyBean bean = new MyBean();
>// "prop1" is neither the name of writeable property nor the
> name of any public method
>Object proxy = EventHandler.create(
>PropertyChangeListener.class, bean, "prop1");
>
>// just to show that Introspector doesn't see the property
> with name "prop1"
>PropertyDescriptor[] pds = Introspector.getBeanInfo(MyBean.class,
>Introspector.USE_ALL_BEANINFO).getPropertyDescriptors();
>for (int i = 0; i < pds.length; i++) {
>System.out.println("Property found: " + pds[i].getName());
>}
>
>// should throw exception
>try {
>((PropertyChangeListener) proxy).propertyChange(
>new PropertyChangeEvent(bean, "prop1", "1", "2"));
>System.out.println("FAIL");
> } catch (Throwable t) {
>System.out.println("PASS");
>}
>}
> }
> <---
>
> So it determines "prop1" as a valid property. IMHO this behavior is
> inconsistent and we should not follow RI. But I like to hear opinions
> from the rest of the community.
>
> Thanks,
--
Alexei Zakharov,
Intel Enterprise Solutions Software Division, Russia
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] “java.compiler” property
I agree. I meant the interpreter mode to be tagged with "none".
What do others think?
Regards,
2006/10/13, Mikhail Fursov <[EMAIL PROTECTED]>:
"none" is OK. But if you want a real JIT info the EM config file is the only
valid place to put it.
On 10/13/06, Alexei Zakharov <[EMAIL PROTECTED]> wrote:
>
> Mikhail,
>
> Yes, but I think we should have it by default. Another problem is that
> we should return something even if we are in the interpreter mode.
> Since this property is *mandatory* for all configs. I suggest using
> something like "none" or etc.
>
> Regards,
>
> 2006/10/13, Mikhail Fursov <[EMAIL PROTECTED]>:
> > The most simple fix: put it into all EM configuration files if you want
> it
> > to depend on JIT configuration is used.
> >
> >
> > On 10/13/06, Alexei Zakharov <[EMAIL PROTECTED]> wrote:
> > >
> > > Hi all,
> > >
> > > I found that we have some problems with system properties in DRLVM. In
> > > the javadoc for java.lang.System class the particular list of
> > > mandatory properties that should be returned by the getProperties()
> > > method is described. However, DRLVM does not provide the value for the
> > > mandatory "java.compiler" property. This leads to some problems
> > > including the test failure from the java.lang.management test suite
> > > (HY-1407). This problem was mentioned by Andrey Yakushev [1]. Below
> > > is the small test that checks all mandatory properties:
> > >
> > > <--
> > > import java.util.*;
> > >
> > > public class TestVMProps {
> > >
> > > static String[] mandatoryProps = new String[] {
> > > "java.version",
> > > "java.vendor",
> > > "java.vendor.url",
> > > "java.home",
> > > "java.vm.specification.version",
> > > "java.vm.specification.vendor",
> > > "java.vm.specification.name",
> > > "java.vm.version",
> > > "java.vm.vendor",
> > > "java.vm.name",
> > > "java.specification.version",
> > > "java.specification.vendor",
> > > "java.specification.name",
> > > "java.class.version",
> > > "java.class.path",
> > > "java.library.path",
> > > "java.io.tmpdir",
> > > "java.compiler",
> > > "java.ext.dirs",
> > > "os.name",
> > > "os.arch",
> > > "os.version",
> > > "file.separator",
> > > "path.separator",
> > > "line.separator",
> > > "user.name",
> > > "user.home",
> > > "user.dir"
> > > };
> > >
> > > public static void main(String argv[]) {
> > > Vector missed = new Vector();
> > > Properties props = System.getProperties();
> > >
> > > for (String mandProp: mandatoryProps) {
> > > boolean found = false;
> > > Enumeration propEnum = (Enumeration)
> > > props.propertyNames();
> > >
> > > while (propEnum.hasMoreElements()) {
> > > String prop = propEnum.nextElement();
> > >
> > > if (mandProp.equals(prop)) {
> > > found = true;
> > > break;
> > > }
> > > }
> > >
> > > if (!found) {
> > > missed.add(mandProp);
> > > }
> > > }
> > >
> > > System.out.println("Number of missed props: " + missed.size
> ());
> > > System.out.println("Missed props: " + missed);
> > > }
> > > }
> > > <--
> > >
> > > If invoked on DRLVM:
> > >
> C:\mydoc\projects\tests>C:\Java\harmony-hdk-r450941\jdk\jre\bin\java.exe
> > > TestVMProps
> > > Number of missed props: 1
> > > Missed props: [java.compiler]
> > >
&g
Re: [general] version of gcc and other tools
Nathan, My solution was to collect classpath in the temporary file. No external configs is needed. I'm too lazy to look into archive for the original message so I write it again here. In brief it uses the "executable" property of the ant "javac" task. The sample ant script looks like this: === === Probably it has some drawbacks but it works at least. I may provide a patch for the current build scripts if we decide to use this approach. Thanks, 2006/10/13, Nathan Beyer <[EMAIL PROTECTED]>: On 10/13/06, Alexei Zakharov <[EMAIL PROTECTED]> wrote: > > I'd prefer to be using ECJ for our compiler, but I haven't heard > > anything lately about getting that back into the build scripts. > > Do we still have a problem with it? If so - I've been using ecj for > building the classlib for quite a long time already (without any > tricks with moving ecj jar from one place to another). I believe I've > already posted my configs one or two months ago. Yes, there are certain generics syntax quirks that won't compile on Sun's 5.0_7 compiler, but are valid. I've used ECJ for the builds as well, but we need to get it integrated into build script, so that is the default and works without config. I'm not an Ant expert, so I'm not sure how to dynamically add items to Ant's classpath. I'm guessing it could be introduced in the top-level build's call to build-java.xml. -Nathan > > Regards, > > 2006/10/13, Nathan Beyer <[EMAIL PROTECTED]>: > > As Geir mentions, there a compiler difference's in Sun's JDK. The > > changes are noticeable between 5.0_7 and 5.0_8. Note: Sun as released > > 5.0_9. > > > > I'd prefer to be using ECJ for our compiler, but I haven't heard > > anything lately about getting that back into the build scripts. > > > > -Nathan > > > > On 10/12/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: > > > > > > > > > Weldon Washburn wrote: > > > > My tools are: > > > > > > > > - WindowsXP > > > >- MSVS .NET 2003 > > > >- ant-1.6.5 > > > >- Sun JDK 1.5.0_07_b03 > > > > > > > > - Linux > > > >- gcc 3.4.5 > > > >- ant-1.6.5 > > > >- IBM JDK 1.5.0_08_b03 > > > >- make 3.8.0 > > > > > > > > How about the following first stab at Geir's idea of "will work" tool > > > > chains? The idea is to quickly converge the below so that I can call a > > > > vote > > > > on it. > > > > > > I don't think we'll need a vote here - we'll be able to come to > > > agreement without that. > > > > > > > > > > > -WindowsXP on laptop, Windows Server 2003 on servers > > > > - MSVS .NET 2003 > > > >- ant-1.6.5 > > > >- Java JDK 1.5.0_ > > > > > > > > - Linux > > > >- gcc 3.4.xxx or higher > > > >- ant-1.6.5 > > > >- Java JDK 1.5.0_ > > > >- make 3.8.0 or higher > > > > > > > > > We need a strict version of Java, I think, because IIRC, there was > > > problems with a recent patch level of the compiler from Sun. I don't > > > remember how that was resolved. > > > > > > I think that we also should try to switch completely to the eclipse > > > compiler, so we can include it as a downloaded dependency, and we all > > > are building using the same thing. > > > > > > also, I'd like to define a "maximum" for the version of gcc/g++ - IOW, > > > we want to test up to 4.x.y, so when 4.x.z appears, we need to test first... > > > > > > > > > > > > > > > > > > > > > > > On 10/12/06, Pavel Ozhdikhin <[EMAIL PROTECTED]> wrote: > > > >> > > > >> To update the statistics, my tools: > > > >> > > > >> - MS Windows Server 2003 / IA32: > > > >> MSVS .NET 2003 > > > >> ant-1.6.5 > > > >> JRockit JDK 1.5.0_03 > > > >> > > > >> - Linux / IA32: > > > >> gcc 3.3.3 > > > >> GNU make 3.80 > > > >> ant-1.6.5 > > > >> JRockit JDK 1.5.0 > > > >> > > > >> Thanks, > > > >> Pavel > > > >> > > > >> On 10/10/06, Geir Ma
Re: [drlvm] “java.compiler” property
Mikhail,
Yes, but I think we should have it by default. Another problem is that
we should return something even if we are in the interpreter mode.
Since this property is *mandatory* for all configs. I suggest using
something like "none" or etc.
Regards,
2006/10/13, Mikhail Fursov <[EMAIL PROTECTED]>:
The most simple fix: put it into all EM configuration files if you want it
to depend on JIT configuration is used.
On 10/13/06, Alexei Zakharov <[EMAIL PROTECTED]> wrote:
>
> Hi all,
>
> I found that we have some problems with system properties in DRLVM. In
> the javadoc for java.lang.System class the particular list of
> mandatory properties that should be returned by the getProperties()
> method is described. However, DRLVM does not provide the value for the
> mandatory "java.compiler" property. This leads to some problems
> including the test failure from the java.lang.management test suite
> (HY-1407). This problem was mentioned by Andrey Yakushev [1]. Below
> is the small test that checks all mandatory properties:
>
> <--
> import java.util.*;
>
> public class TestVMProps {
>
> static String[] mandatoryProps = new String[] {
> "java.version",
> "java.vendor",
> "java.vendor.url",
> "java.home",
> "java.vm.specification.version",
> "java.vm.specification.vendor",
> "java.vm.specification.name",
> "java.vm.version",
> "java.vm.vendor",
> "java.vm.name",
> "java.specification.version",
> "java.specification.vendor",
> "java.specification.name",
> "java.class.version",
> "java.class.path",
> "java.library.path",
> "java.io.tmpdir",
> "java.compiler",
> "java.ext.dirs",
> "os.name",
> "os.arch",
> "os.version",
> "file.separator",
> "path.separator",
> "line.separator",
> "user.name",
> "user.home",
> "user.dir"
> };
>
> public static void main(String argv[]) {
> Vector missed = new Vector();
> Properties props = System.getProperties();
>
> for (String mandProp: mandatoryProps) {
> boolean found = false;
> Enumeration propEnum = (Enumeration)
> props.propertyNames();
>
> while (propEnum.hasMoreElements()) {
> String prop = propEnum.nextElement();
>
> if (mandProp.equals(prop)) {
> found = true;
> break;
> }
> }
>
> if (!found) {
> missed.add(mandProp);
> }
> }
>
> System.out.println("Number of missed props: " + missed.size());
> System.out.println("Missed props: " + missed);
> }
> }
> <--
>
> If invoked on DRLVM:
> C:\mydoc\projects\tests>C:\Java\harmony-hdk-r450941\jdk\jre\bin\java.exe
> TestVMProps
> Number of missed props: 1
> Missed props: [java.compiler]
>
> On IBM VME:
> C:\mydoc\projects\tests>C:\Java\harmony-bin\bin\java.exe TestVMProps
> Number of missed props: 0
> Missed props: []
>
> On RI:
> C:\mydoc\projects\tests>C:\Java\jdk1.5.0\bin\java.exe TestVMProps
> Number of missed props: 1
> Missed props: [java.compiler]
>
> You may notice that RI also does not provide the value for
> "java.compiler". BTW, we have a test in the DRLVM test suite that
> should check all mandatory properties –
> java.lang.SystemExtensionTest.test_getProperty_Str(). But it seems the
> author of the test makes a muddle of logical operators – puts OR
> instead of AND. So the test now checks if at least one of mandatory
> property is set.
>
> IMHO we should return something for the "java.compiler" property name.
> Any thoughts?
>
> [1]
>
http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200610.mbox/[EMAIL
PROTECTED]
> (problem 2)
--
Alexei Zakharov,
Intel Enterprise Solution Software Division
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[drlvm] “java.compiler” property
Hi all,
I found that we have some problems with system properties in DRLVM. In
the javadoc for java.lang.System class the particular list of
mandatory properties that should be returned by the getProperties()
method is described. However, DRLVM does not provide the value for the
mandatory "java.compiler" property. This leads to some problems
including the test failure from the java.lang.management test suite
(HY-1407). This problem was mentioned by Andrey Yakushev [1]. Below
is the small test that checks all mandatory properties:
<--
import java.util.*;
public class TestVMProps {
static String[] mandatoryProps = new String[] {
"java.version",
"java.vendor",
"java.vendor.url",
"java.home",
"java.vm.specification.version",
"java.vm.specification.vendor",
"java.vm.specification.name",
"java.vm.version",
"java.vm.vendor",
"java.vm.name",
"java.specification.version",
"java.specification.vendor",
"java.specification.name",
"java.class.version",
"java.class.path",
"java.library.path",
"java.io.tmpdir",
"java.compiler",
"java.ext.dirs",
"os.name",
"os.arch",
"os.version",
"file.separator",
"path.separator",
"line.separator",
"user.name",
"user.home",
"user.dir"
};
public static void main(String argv[]) {
Vector missed = new Vector();
Properties props = System.getProperties();
for (String mandProp: mandatoryProps) {
boolean found = false;
Enumeration propEnum = (Enumeration)
props.propertyNames();
while (propEnum.hasMoreElements()) {
String prop = propEnum.nextElement();
if (mandProp.equals(prop)) {
found = true;
break;
}
}
if (!found) {
missed.add(mandProp);
}
}
System.out.println("Number of missed props: " + missed.size());
System.out.println("Missed props: " + missed);
}
}
<--
If invoked on DRLVM:
C:\mydoc\projects\tests>C:\Java\harmony-hdk-r450941\jdk\jre\bin\java.exe
TestVMProps
Number of missed props: 1
Missed props: [java.compiler]
On IBM VME:
C:\mydoc\projects\tests>C:\Java\harmony-bin\bin\java.exe TestVMProps
Number of missed props: 0
Missed props: []
On RI:
C:\mydoc\projects\tests>C:\Java\jdk1.5.0\bin\java.exe TestVMProps
Number of missed props: 1
Missed props: [java.compiler]
You may notice that RI also does not provide the value for
"java.compiler". BTW, we have a test in the DRLVM test suite that
should check all mandatory properties –
java.lang.SystemExtensionTest.test_getProperty_Str(). But it seems the
author of the test makes a muddle of logical operators – puts OR
instead of AND. So the test now checks if at least one of mandatory
property is set.
IMHO we should return something for the "java.compiler" property name.
Any thoughts?
[1]
http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200610.mbox/[EMAIL
PROTECTED]
(problem 2)
Thanks,
--
Alexei Zakharov,
Intel Enterprise Solutions Software Division
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [general] version of gcc and other tools
I'd prefer to be using ECJ for our compiler, but I haven't heard anything lately about getting that back into the build scripts. Do we still have a problem with it? If so - I've been using ecj for building the classlib for quite a long time already (without any tricks with moving ecj jar from one place to another). I believe I've already posted my configs one or two months ago. Regards, 2006/10/13, Nathan Beyer <[EMAIL PROTECTED]>: As Geir mentions, there a compiler difference's in Sun's JDK. The changes are noticeable between 5.0_7 and 5.0_8. Note: Sun as released 5.0_9. I'd prefer to be using ECJ for our compiler, but I haven't heard anything lately about getting that back into the build scripts. -Nathan On 10/12/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: > > > Weldon Washburn wrote: > > My tools are: > > > > - WindowsXP > >- MSVS .NET 2003 > >- ant-1.6.5 > >- Sun JDK 1.5.0_07_b03 > > > > - Linux > >- gcc 3.4.5 > >- ant-1.6.5 > >- IBM JDK 1.5.0_08_b03 > >- make 3.8.0 > > > > How about the following first stab at Geir's idea of "will work" tool > > chains? The idea is to quickly converge the below so that I can call a > > vote > > on it. > > I don't think we'll need a vote here - we'll be able to come to > agreement without that. > > > > > -WindowsXP on laptop, Windows Server 2003 on servers > > - MSVS .NET 2003 > >- ant-1.6.5 > >- Java JDK 1.5.0_ > > > > - Linux > >- gcc 3.4.xxx or higher > >- ant-1.6.5 > >- Java JDK 1.5.0_ > >- make 3.8.0 or higher > > > We need a strict version of Java, I think, because IIRC, there was > problems with a recent patch level of the compiler from Sun. I don't > remember how that was resolved. > > I think that we also should try to switch completely to the eclipse > compiler, so we can include it as a downloaded dependency, and we all > are building using the same thing. > > also, I'd like to define a "maximum" for the version of gcc/g++ - IOW, > we want to test up to 4.x.y, so when 4.x.z appears, we need to test first... > > > > > > > > > > > On 10/12/06, Pavel Ozhdikhin <[EMAIL PROTECTED]> wrote: > >> > >> To update the statistics, my tools: > >> > >> - MS Windows Server 2003 / IA32: > >> MSVS .NET 2003 > >> ant-1.6.5 > >> JRockit JDK 1.5.0_03 > >> > >> - Linux / IA32: > >> gcc 3.3.3 > >> GNU make 3.80 > >> ant-1.6.5 > >> JRockit JDK 1.5.0 > >> > >> Thanks, > >> Pavel > >> > >> On 10/10/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: > >> > I'm so sick of this gcc problem. > >> > > >> > Lets decide on the versions for GCC and other tools that "will > >> work". I > >> > feel the same way that mark does re that being able to build on > >> multiple > >> > versions gives a better feeling of goodness and harmony in the universe > >> > and I encourage people to work on other versions (I will), but it's > >> > gotta be the case that we have a "reference toolchain" - that no matter > >> > what, it will work on there, and probably a list of tested versions > >> > > >> > So, what tools and what versions are people working with ? here's a > >> > partial list of mine : > >> > > >> > 1) WinXP : Visual Studio .NET 2003 > >> > > >> > 2) Linux x86 : > >> > GCC : 3.4.6 > >> > g++ : 3.4.6 > >> > make : 3.81b4 > >> > > >> > What are you using? what other tools should we list? > >> > > >> > I recently setup a new machine (linux) and now have the complete > >> list of > >> > stuff that has to be installed (starting from fresh ubuntu6) and will > >> > post that on the getting started document on teh website. > >> > > >> > > >> > geir -- Alexei Zakharov, Intel Middleware Product Division - 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] [tests] Can anyone explain what these are for?
Some tests for beans contained the code like this:
<---
public void testGetArguments() {
// Covered in the testcases for the constructor
}
public void testGetMethodName() {
// Covered in the testcases for the constructor
}
<---
I just commented it out. I could simply delete it but decided that we
may need it in the future. When we finish with 1.5 and everybody will
have a lot of free time - we can get back to it and think again: do we
need to insert an additional test case here?
Regards,
2006/10/11, Richard Liang <[EMAIL PROTECTED]>:
On 10/11/06, Nathan Beyer <[EMAIL PROTECTED]> wrote:
> Perhaps, but there are much better ways of determining that. From just
> reading the test code to code coverage tools.
>
> From my analysis, these were part of the large test contribution and
> indicated that there wasn't an explicit test for that method. In most
> cases, there were tests for these methods, either in other classes or
> in other methods of the class.
Nathan, I agree ;-)
>
> -Nathan
>
> On 10/10/06, Richard Liang <[EMAIL PROTECTED]> wrote:
> > On 10/11/06, Nathan Beyer <[EMAIL PROTECTED]> wrote:
> > > I've seen a few and I've deleted any that I've come across. I would
> > > say feel free to delete them too. I've also been deleting empty setup
> > > and teardown methods too.
> >
> > Please do not simply delete them. Maybe that means we are lack of the
> > test for some methods, for example "getInetAddress".
> >
> > >
> > > -Nathan
> > >
> > > On 10/10/06, Alexey Petrenko <[EMAIL PROTECTED]> wrote:
> > > > These could be a result of copy/paste tests creation.
> > > > And I'm curious why it was written for the first time. :)
> > > >
> > > > SY, Alexey
> > > >
> > > > 2006/10/10, Mark Hindess <[EMAIL PROTECTED]>:
> > > > >
> > > > > I've come across a couple of tests with things like:
> > > > >
> > > > > public void test_getInetAddress() {
> > > > > assertTrue("Used to test", true);
> > > > > }
> > > > >
> > > > > Can anyone explain why we have these?
--
Alexei Zakharov,
Intel Middleware Product Division
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[classlib][beans] RI inconsistency in EventHandler
Hi all,
Let me disturb you with another boring "RI inconsistency in beans"
–type of message. :) It seems I found a bug in RI. In
java.beans.EventHandler. I think RI incorrectly determines properties
here. According to spec, common sense and even the RI's implementation
of java.beans.Introspector the following bean should not contain any
properties:
public static class MyBean {
public void setProp1() {}
}
because "setProp1()" is not a valid setter method – it does not
contain a new value to set.
However, the following test fails on RI:
<---
import java.beans.*;
public class TestBeanInfo1 {
public static class MyBean {
public void setProp1() {}
}
public static void main(String argv[]) throws Exception {
MyBean bean = new MyBean();
// "prop1" is neither the name of writeable property nor the
name of any public method
Object proxy = EventHandler.create(
PropertyChangeListener.class, bean, "prop1");
// just to show that Introspector doesn't see the property
with name "prop1"
PropertyDescriptor[] pds = Introspector.getBeanInfo(MyBean.class,
Introspector.USE_ALL_BEANINFO).getPropertyDescriptors();
for (int i = 0; i < pds.length; i++) {
System.out.println("Property found: " + pds[i].getName());
}
// should throw exception
try {
((PropertyChangeListener) proxy).propertyChange(
new PropertyChangeEvent(bean, "prop1", "1", "2"));
System.out.println("FAIL");
} catch (Throwable t) {
System.out.println("PASS");
}
}
}
<---
So it determines "prop1" as a valid property. IMHO this behavior is
inconsistent and we should not follow RI. But I like to hear opinions
from the rest of the community.
Thanks,
--
Alexei Zakharov,
Intel Middleware Product Division
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [general] define pre-commit testing configs to gain the stability
> 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] > > > > > > - > 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] -- Alexei Zakharov, Intel Middleware Product Division - 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][pack200] Unpacked my first archive today!
Wow wow! My congratulations. Don't stop on this. :) 2006/10/6, Alex Blewitt <[EMAIL PROTECTED]>: I managed to unpack a Pack200 file completely today for the first time, so that by the end of it there were no bytes left in the queue. Unfortunately, it wasn't a spectacularly exciting archive -- just one interface with no methods (about as exciting as java.lang.Serializable, in fact) but I think that I've unlocked the next stage in the process for decompressing the attributes that are left (including things like bytecodes, etc.). At the moment, the data is just in an unpacked state; I've not yet looked at re-assembling the data into their constituent .class files (need to get hold of the class bytecode format for that) or even reconstituting the Jar file. I'm thinking of using ZipEntry and ZipOutputStream (or corresponding Jar variants) for building the resulting Jar file. I'm not sure whether they are implemented or not in the current trunk or not, but I might start working against the ZipOutputStream/ZipEntry APIs. Onward and upward ... Alex. -- Alexei Zakharov, Intel Middleware Product Division - 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] enabling AWT/Swing by default
No objections to this "swing-only" solution. Thanks, 2006/10/6, Oleg Khaschansky <[EMAIL PROTECTED]>: Tim, I attached a patch which doesn't have side effects to HARMONY-1723 :) -- Oleg On 10/6/06, Tim Ellison <[EMAIL PROTECTED]> wrote: > Oleg Khaschansky wrote: > >> So what happens to the patch on HARMONY-1723. > > > > My opinion is that it is OK. Consider the following: > > > > 1. Applications bounded to the RI behavior (e.g. obtaining the > > descriptors for read-only properties without construction of getter > > name) won't fail. > > 2. Construction of the default getter/setter names could be > > incapsulated in the PropertyDescriptor. For now there's no possibility > > of getting a descriptor for one read-only/write-only property without > > constructing its getter/setter name outside of the PropertyDescriptor. > > 3. Don't think that it is bad if PropertyDescriptor would lookup for > > reasonable defaults if provided names are invalid. > > > > I'd like to hear another opinion. If somebody will disagree I'll make > > another fix for the TransferHandler, whithout touching beans. > > Me too -- I was following your logic above and agreed, but I got the > impression that Alexey disagreed with that approach, so was holding off. > > I have the patch applied in my workspace but will wait before committing it. > > Regards, > Tim -- Alexei Zakharov, Intel Middleware Product Division - 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] Updated: (HARMONY-1763) [classlib][beans] method java.beans.PropertyDescriptor.equals(Object) throws ClassCastException
Oleg,
Can we write the same logic a little bit nicer?
Something like:
public boolean equals(Object object) {
-boolean result = (object != null && object instanceof
PropertyDescriptor);
-if (result) {
+boolean result = false;
+
+if (object != null && object instanceof PropertyDescriptor) {
PropertyDescriptor pd = (PropertyDescriptor) object;
Anyway +1 for the patch in general, thank you for finding this!
Regards,
2006/10/6, Oleg Khaschansky <[EMAIL PROTECTED]>:
According to the "good issue resolution guideline" I am forwarding
this to the dev. list.
-- Forwarded message --
From: Oleg Khaschansky (JIRA) <[EMAIL PROTECTED]>
Date: Oct 6, 2006 8:58 PM
Subject: [jira] Updated: (HARMONY-1763) [classlib][beans] method
java.beans.PropertyDescriptor.equals(Object) throws ClassCastException
To: [EMAIL PROTECTED]
[ http://issues.apache.org/jira/browse/HARMONY-1763?page=all ]
Oleg Khaschansky updated HARMONY-1763:
--
Attachment: harmony-1763.patch
Patch for this issue rev. 453254.
> [classlib][beans] method java.beans.PropertyDescriptor.equals(Object) throws
ClassCastException
>
---
>
> Key: HARMONY-1763
> URL: http://issues.apache.org/jira/browse/HARMONY-1763
> Project: Harmony
> Issue Type: Bug
> Components: Classlib
>Reporter: Oleg Khaschansky
>Priority: Minor
> Attachments: harmony-1763-test.patch, harmony-1763.patch
>
>
> The test below throws ClassCastException on Harmony but passes on RI.
> I will provide a patch for this issue and a unit test.
>
> import java.beans.*;
> import java.lang.reflect.*;
> public class Test {
> public static void main(String[] args) {
> PropertyDescriptor toRet = null;
> try {
> toRet = new PropertyDescriptor("p", Bean.class );
> toRet.setBound( true );
> } catch (IntrospectionException e) {
> e.printStackTrace();
> }
> Method m = null;
> try {
> m = HelpClass.class.getDeclaredMethod("f_static",
> (Class[])null);
> } catch (NoSuchMethodException e) {
> e.printStackTrace();
> }
> toRet.equals(m);
> System.out.println("PASSED");
> }
> }
> class Bean {
> public void setP(int i) {}
> public int getP() {return 0;}
> }
> class HelpClass {
> public HelpClass () {}
> public static void f_static () {}
> }
>
--
Alexei Zakharov,
Intel Middleware Product Division
-
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] enabling AWT/Swing by default (was: Re: svn commit: r452826 - in /incubator/harmony/enhanced/classlib/trunk: depends/libs/build/ depends/libs/windows.x86/ make/depends.properties make/d
Hi Oleg,
On the other hand, why don't we allow Harmony to accept invalid names
and provide a default replacements for them if there is a set/get/is
method for the specified property? It seems to me more user-friendly
then throw IntrospectionException in this situation. It looks like the
specification doesn't require PropertyDescriptor to throw an exception
in this case.
Well, the specification states here:
<==
public PropertyDescriptor(String propertyName,
Class beanClass,
String readMethodName,
String writeMethodName)
throws IntrospectionException
...
Parameters:
...
readMethodName - The name of the method used for reading the
property value. May be null if the property is write-only.
writeMethodName - The name of the method used for writing the
property value. May be null if the property is read-only.
Throws:
IntrospectionException - if an exception occurs during introspection.
<==
So we have the description of the valid parameter case, null parameter
case and the exception that can be thrown. IMHO the natural conclusion
from that is that the exception will be thrown in case of invalid
parameter. Moreover, if the implementation does not validate method
names it will never throw IntrospectionException. But it is described
by the spec.
BTW, PropertyDescriptor(String, Method, Method) validates both methods
and throws IntrospectionException if something is wrong.
This will also prevent us from breaking applications
that uses this RI behavior.
Actually I don't belive they exist in our world. :) May be we can
leave the current functionality for now and get back to this if
encounter one of such apps?
Regards,
2006/10/5, Oleg Khaschansky <[EMAIL PROTECTED]>:
Alexey,
Agree. I haven't noticed that RI doesn't accept invalid write method.
Then its behavior looks illogical. Actually, I asked about comments
especially because I expected a feedback from beans authors. Thank
you.
On the other hand, why don't we allow Harmony to accept invalid names
and provide a default replacements for them if there is a set/get/is
method for the specified property? It seems to me more user-friendly
then throw IntrospectionException in this situation. It looks like the
specification doesn't require PropertyDescriptor to throw an exception
in this case. This will also prevent us from breaking applications
that uses this RI behavior.
What is your opinion?
On 10/5/06, Alexei Zakharov <[EMAIL PROTECTED]> wrote:
> Oleg,
>
> > + we need to fix in beans the fact that the following code:
> > new PropertyDescriptor(propertyName, c.getClass(), "1", null);
> > will throw IntrospectionException on Harmony, but will return the
> > valid property descriptor with the getter method on RI.
> > Any thoughts on this? Or should I proceed with a patch for the both issues?
>
> I've already written my thoughts about this issue in [1]. In short: I
> don't think we should follow the RI behavior since it is inconsistent.
> Why it accepts invalid read method and throws exception on invalid
> write method? No logic.
>
> [1]
http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200609.mbox/[EMAIL
PROTECTED]
>
> Thanks,
>
> 2006/10/4, Oleg Khaschansky <[EMAIL PROTECTED]>:
> > I found the reason of this failure. It is an IntrospectionException
> > while executing a following method from the TransferHandler class:
> >
> >private PropertyDescriptor getPropertyDescriptor(final JComponent c) {
> >PropertyDescriptor result = null;
> >try {
> >result = new PropertyDescriptor(propertyName, c.getClass());
> >} catch (IntrospectionException e) {
> >
> >}
> >return result;
> >}
> > It tries to get the PropertyDescriptor for the class JButton and
> > property name "insets", but fails because there's no setInsets method.
> > So, flavors array stays uninitialized and getTransferDataFlavors
> > method returns null which is a cause of a NPE.
> >
> > The quick fix for this issue could be changing this method to the following:
> >
> >private PropertyDescriptor getPropertyDescriptor(final JComponent c) {
> >PropertyDescriptor result = null;
> >try {
> >return result = new PropertyDescriptor(propertyName,
c.getClass());
> >} catch (IntrospectionException e) {
> >}
> >try {
> >return result = new PropertyDescriptor(propertyName,
> > c.getClass(), "1", null);
> >} catch (IntrospectionException e) {
> >}
> >return result;
> >}
> >
> &g
Re: Re: [r451637] - Code cleanup - ... - Remove unnecessary comments
I'd say leave the TODOs alone, at least until we're in a phase where
such polishing up is desired.
Agreed. I've already posted a lot of
// XXX investigate
messages to myself to be read in the future.
Regards,
2006/10/4, Alex Blewitt <[EMAIL PROTECTED]>:
I use TODOs a lot in my code to remind me to come back to that
particular piece and do the job properly. If someone else were to
remove them then they may not do the right thing as far as the code
needs ... so I'd expect at least some kind of heads-up before this
would happen :-)
I'd say leave the TODOs alone, at least until we're in a phase where
such polishing up is desired.
Alex.
On 04/10/06, Nathan Beyer <[EMAIL PROTECTED]> wrote:
> If this is an event that should be logged, as the TODO indicated, then
> why not just print out the stack trace and be done with it? If this
> exception happens so often that you'd like it removed, then why would
> we want to log a warning message, which I would presume would print to
> the console just as frequently.
>
> As for TODOs, in general I find TODOs never get done, especially
> trivial ones like this particular case.
>
> -Nathan
>
> On 10/3/06, Alexey Varlamov <[EMAIL PROTECTED]> wrote:
> > Nathan,
> >
> > I've seen you dropped many TODOs in "- Code cleanup -" series of commits;
> > I'd like to know what reasoning was behind this? I think it's a bit
> > early to erase TODOs without appropriate consideration...
> >
> > In particular, could you please undo the following change, it produces
> > garbage messages during AUTH testing:
> >
> >
modules/auth/src/main/java/common/org/apache/harmony/auth/login/DefaultConfigurationParser.java
> > ===
> > @@ -216,12 +206,12 @@ public class DefaultConfigurationParser
> > try {
> > val = PolicyUtils.expand(st.sval, system);
> > } catch (Exception e) {
> > - //TODO: warning log
> > - }
> > + e.printStackTrace();
> > + }
> > }
> >
> > --
> > WBR,
> > Alexey
> >
> > -
> > 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]
>
>
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Alexei Zakharov,
Intel Middleware Product Division
-
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] enabling AWT/Swing by default (was: Re: svn commit: r452826 - in /incubator/harmony/enhanced/classlib/trunk: depends/libs/build/ depends/libs/windows.x86/ make/depends.properties make/d
Oleg,
+ we need to fix in beans the fact that the following code:
new PropertyDescriptor(propertyName, c.getClass(), "1", null);
will throw IntrospectionException on Harmony, but will return the
valid property descriptor with the getter method on RI.
Any thoughts on this? Or should I proceed with a patch for the both issues?
I've already written my thoughts about this issue in [1]. In short: I
don't think we should follow the RI behavior since it is inconsistent.
Why it accepts invalid read method and throws exception on invalid
write method? No logic.
[1]
http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200609.mbox/[EMAIL
PROTECTED]
Thanks,
2006/10/4, Oleg Khaschansky <[EMAIL PROTECTED]>:
I found the reason of this failure. It is an IntrospectionException
while executing a following method from the TransferHandler class:
private PropertyDescriptor getPropertyDescriptor(final JComponent c) {
PropertyDescriptor result = null;
try {
result = new PropertyDescriptor(propertyName, c.getClass());
} catch (IntrospectionException e) {
}
return result;
}
It tries to get the PropertyDescriptor for the class JButton and
property name "insets", but fails because there's no setInsets method.
So, flavors array stays uninitialized and getTransferDataFlavors
method returns null which is a cause of a NPE.
The quick fix for this issue could be changing this method to the following:
private PropertyDescriptor getPropertyDescriptor(final JComponent c) {
PropertyDescriptor result = null;
try {
return result = new PropertyDescriptor(propertyName, c.getClass());
} catch (IntrospectionException e) {
}
try {
return result = new PropertyDescriptor(propertyName,
c.getClass(), "1", null);
} catch (IntrospectionException e) {
}
return result;
}
+ we need to fix in beans the fact that the following code:
new PropertyDescriptor(propertyName, c.getClass(), "1", null);
will throw IntrospectionException on Harmony, but will return the
valid property descriptor with the getter method on RI.
Any thoughts on this? Or should I proceed with a patch for the both issues?
Thanks,
Oleg
On 10/4/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote:
> 2006/10/4, Mark Hindess <[EMAIL PROTECTED]>:
> >
> > On 4 October 2006 at 15:41, Tim Ellison <[EMAIL PROTECTED]> wrote:
> > > Excuse the change in subject line...
> >
> > No problem. I was just cursing myself for having forgotten to change
> > it.
> >
> > > Mark Hindess wrote:
> > > > With this change, the awt dependencies should now be automated for
> > > > windows and at least fairly trivial (installing a few packages on
> > > > Linux[0]). I think it is time we removed the with.awt.swing flag.
> > > > Anyone object?
> > >
> > > To the contrary, ditch it.
> > >
> > > > Please test the current setup with -Dwith.awt.swing=true and report any
> > > > problems.
> > >
> > > Problem 1: My machine is too slow running all these tests.
> >
> > Mine too. And I have wondered if the hourly builds will finish within
> > the hour now. We really should see if we can avoid the need to fork
> > for every test.
>
> I've run the tests on my XP machine, 1 failed
>
> javax.swing.TransferHandlerTest#testCreateTransferable
>
> java.lang.NullPointerException at
>
javax.swing.TransferHandlerTest.testCreateTransferable(TransferHandlerTest.java:140)
> at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:25)
> at javax.swing.BasicSwingTestCase.runBareSuper(BasicSwingTestCase.java:115)
> at javax.swing.SwingTestCase$1.run(SwingTestCase.java:44) at
> java.awt.event.InvocationEvent.runAndNotify(InvocationEvent.java:88)
> at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:77) at
> java.awt.EventQueueCore.dispatchEventImpl(EventQueueCore.java:131) at
> java.awt.EventQueue.dispatchEvent(EventQueue.java:144) at
> java.awt.EventDispatchThread.runModalLoop(EventDispatchThread.java:75)
> at java.awt.EventDispatchThread.run(EventDispatchThread.java:48)
>
--
Alexei Zakharov,
Intel Middleware Product Division
-
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] Bugs priorities
Just want to add: cosmetic changes that do not affect the functionality - trivial Regards, 2006/10/5, Anton Luht <[EMAIL PROTECTED]>: Hello, Maybe it's worth to explicitly specify priorities for various kinds of bugs? The advice that appears now near 'priority' drop-down in JIRA list is general and not Harmony-specific. Bug submitters make decision mostly by his/her intuition. An example of rule set: VM hangs & crashes - critical, Junit tests failures - major, application failures - major, exception incompatibility - minor. -- Regards, Anton Luht, Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Alexei Zakharov, Intel Middleware Product Division - 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][logging] Best practices for logging within the Class Library?
Well, I still think that logging is useful sometimes. Is it for our end-users? Do we expect them to turn on logging and look at the contents to discover problems in our code? or perhaps discover problems in their usage of the API? Both of these seem like flawed concepts. Yes, exactly. For end users. Not to discover problems in our code but to discover problems in their configurations. For example the scenario mentioned by Mikhail L. in [1]. Or with that long-suffering DNS provider. The network conditions may change as time goes by. So users may probably benefit from the knowing why they should wait so long until their request is served. And I also hold the opinion that the debug-level logging is not so bad. In case we can easily remove it from critical parts of the code of course. [1] http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200605.mbox/[EMAIL PROTECTED] Thanks, 2006/10/5, Tim Ellison <[EMAIL PROTECTED]>: We did this topic already it's even referenced from the website [1]. So at the risk of repeating my super-super-duper high level view... Why are we considering putting logging into the class library implementation? Is it for our end-users? Do we expect them to turn on logging and look at the contents to discover problems in our code? or perhaps discover problems in their usage of the API? Both of these seem like flawed concepts. Is it for us as developers? Putting printf's in the code doesn't seem like a very efficient way of figuring out how the code works, and just clutters up the codebase. I'd also object to having loads of modules depend on logging. [1] http://incubator.apache.org/harmony/subcomponents/classlibrary/agreements.html Regards, Tim Nathan Beyer wrote: > There seem to be a number of places where logging would be useful > within the class library (and Java parts of the VM), but the rules of > engagement seems to be undefined, so it's not being used. Here's my > super-duper high-level swipe at it. > > 1. Use java.util.logging for normal logging (somewhat obvious). > 2. Do not use java.util.logging within luni, security and kernel > modules; this is to prevent cyclical executions. > 3. Use the class name for the name of the Logger; this is based on the > assumption that classes will be packaged appropriately such that > logging can be enabled by packages to get sub-system information. > 4. Use the java.util.logging.Level javadoc [1] as a guide for the > appropriate logging level for a particular message. When in doubt, be > conservative and use lower levels (less than INFO). > > Thoughts, comments? The big question in my mind is what modules must > be isolated from consuming java.util.logging (regarding 2 above). The > other modules that might need isolation are archive and text, but I'm > not sure about that. Any others? -- Alexei Zakharov, Intel Middleware Product Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [general] creation of "jdktools"
Now that we have javac, javah, javap (if Tim votes ;) and keytool, I'd BTW, we have more tools indeed. I mean RMI tools: rmic <-> java org.apache.harmony.rmi.compiler.Main rmid <-> java org.apache.harmony.rmi.activation.Rmid rmiregistry <-> java org.apache.harmony.rmi.registry.RegistryImpl We can hack the launcher to enable these three tools too. Seven tools is more than just four. :) Regards, 2006/10/2, Geir Magnusson Jr. <[EMAIL PROTECTED]>: Now that we have javac, javah, javap (if Tim votes ;) and keytool, I'd like to organize these and add them to the next snapshot. So I propose adding a new top-level directory called "jdktools" (and rename "tools" to "project_tools") and create a build target that - with a dependency on classlib for the launcher - creates the 'stuff' needed to fill into the JDK. Any comments? geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Alexei Zakharov, Intel Middleware Product Division - 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] removing \t from sources
Thanks, Tim :-)
Regards,
2006/10/3, Tim Ellison <[EMAIL PROTECTED]>:
I've committed the reformatted code in r452415.
Now you can feel calm again :-)
The other modules are being cleaned-up piece by piece.
Regards,
Tim
Alexei Zakharov wrote:
> I see. This IMHO is another argument why \t is bad. My script will not
> be able to handle this, it just replaces one string pattern with
> another. So such cases should be handled manually or with the code
> formatter. However, the drawback of the code formatter is that it
> removes the "author's personality" from the code.
>
> But IMHO mixing spaces with tabs in the single unit of indentation is
> even worse than just using tabs. Normally people use either tabs or
> spaces. I suppose that mixes appear when the original source with tabs
> is being edited with IDE configured to use spaces. I haven't seen many
> of such cases in HY code, at least in the modules I worked with.
>
> With best regards,
>
> 2006/10/2, Alexey Petrenko <[EMAIL PROTECTED]>:
>> I mean that {"space", "space", "tab"} will be converted to the same
>> number of spaces as simple tab by the most of editors.
>>
>> SY, Alexey
>>
>> 2006/10/2, Alexei Zakharov <[EMAIL PROTECTED]>:
>> > What do you mean? Convert " \t" to something? If so please see the
>> > new fully customized version of my mega-script :-)
>> >
>> > The usage pattern in your case will be:
>> > ant -f tabs2spaces_v2.xml -Dsrc.dir= -Dpattern=" \t"
>> >
>> > Regards,
>> >
>> > 2006/10/2, Alexey Petrenko <[EMAIL PROTECTED]>:
>> > > Does it work with the sequences like {"space", "space", "tab"} etc?
>> > >
>> > > 2006/10/2, Alexei Zakharov <[EMAIL PROTECTED]>:
>> > > > Hi all,
>> > > >
>> > > > I noticed that the tab character (0x09) is still widely used in our
>> > > > classlib source code. At least in tests. From my recent experience
>> > > > this leads to broken indentation. I mean the situation when
>> patch with
>> > > > spaces is applied to the source there tab character is used for
>> > > > indentation. Someone knows that according to Sun code
>> conventions the
>> > > > tab should be exactly 8 spaces. The other person knows that exactly
>> > > > four spaces should be used as the unit of indentation [1]. As a
>> result
>> > > > we have all methods indented with the single tab character and the
>> > > > patched methods indented with 4 spaces. And if your IDE is
>> configured
>> > > > to display tabs as 8 spaces you will see broken indentation. Or
>> vice
>> > > > versa.
>> > > >
>> > > > I have created small ANT script - see HARMONY-1660 [2]. This script
>> > > > converts all tabs to spaces in all found sources under the given
>> > > > directory recursively. I will be grateful if someone runs this
>> script
>> > > > (tab -> 4 spaces) at least for beans tests (I currently working
>> with)
>> > > > and integrates the results. It is really painful to deal with this
>> > > > broken alignment every day. And it is too boring (and IMHO
>> silly) to
>> > > > convert it file by file and send patches for each case.
>> > > >
>> > > > [1]
>> http://java.sun.com/docs/codeconv/html/CodeConventions.doc3.html#262
>> > > > [3] http://issues.apache.org/jira/browse/HARMONY-1660
>> > > >
>> > > > Thanks,
--
Alexei Zakharov,
Intel Middleware Product Division
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [general] Using the HDK ( was Re: [general] jre and hdk snapshots posted to general snapshot site )
Egor, HARMONY-1673 is filed. I've tried both "-Xem:opt" & "-Xem:jet". Regards, 03 Oct 2006 00:06:16 +0700, Egor Pasko <[EMAIL PROTECTED]>: On the 0x1F6 day of Apache Harmony Alexei Zakharov wrote: > The same result with the "-Xem:opt". Could you file a JIRA for that, please? With steps to reproduce. Please, also check with -Xem:jet. Thanks for pointing out failures like that. > The exact command in my > environment was (WinXP SP2): > > <== > C:\mydoc\projects\tests\beans2>echo %JAVA_HOME% > C:\Java\harmony-hdk-r450941\jdk\jre > > C:\mydoc\projects\tests\beans2>%JAVA_HOME%\bin\java > -Xbootclasspath/p:.\build\classes;.\build\tests;C:\Java\harmony\enhanced\classlib\trunk\depends\jars\junit_3.8.2\junit.jar > -Xem:opt junit.textui.TestRunner > org.apache.harmony.beans.tests.java.beans.IntrospectionExceptionTest > ... > An unhandled error (4) has occurred. > HyGeneric_Signal_Number=0004 > ExceptionCode=c005 > ExceptionAddress=0052A340 > ContextFlags=0001003f > Handler1=00401010 > Handler2=11105CE0 > InaccessibleAddress= > EDI= > ESI= > EAX=0013F1AC > EBX= > ECX=007129FC > EDX= > EIP=0052A340 > ESP=0013F17C > EBP= > Module=C:\Java\harmony-hdk-r450941\jdk\jre\bin\default\harmonyvm.dll > Module_base_address=0051 > Offset_in_DLL=0001a340 > > This application has requested the Runtime to terminate it in an unusual way. > Please contact the application's support team for more information. > <== > > Regards, > > 02 Oct 2006 20:14:11 +0700, Egor Pasko <[EMAIL PROTECTED]>: > > On the 0x1F6 day of Apache Harmony Alexei Zakharov wrote: > > > Agree. In case somebody is interested: > > > org.apache.harmony.beans.tests.java.beans.IntrospectionExceptionTest > > > (from bootclasspath), harmony-hdk-r450941, WinXP. > > > > Is that reproducible on Linux? how does it run on pure OPT (-Xem:opt), > > JET? > > > > > Crash info: > > > > > > <== > > >[junit] An unhandled error (4) has occurred. > > > [junit] HyGeneric_Signal_Number=0004 > > > [junit] ExceptionCode=c005 > > > [junit] ExceptionAddress=0052A340 > > > [junit] ContextFlags=0001003f > > > [junit] Handler1=00401010 > > > [junit] Handler2=11105CE0 > > > [junit] InaccessibleAddress= > > > [junit] EDI= > > > [junit] ESI= > > > [junit] EAX=0013D69C > > > [junit] EBX= > > > [junit] ECX=007129FC > > > [junit] EDX= > > > [junit] EIP=0052A340 > > > [junit] ESP=0013D66C > > > [junit] EBP= > > > [junit] Module=C:\Java\harmony-hdk-r450941\jdk\jre\bin\default\harmonyvm.dll > > > [junit] Module_base_address=0051 > > > [junit] Offset_in_DLL=0001a340 > > > [junit] This application has requested the Runtime to terminate it > > > in an unusual way. > > > [junit] Please contact the application's support team for more information. > > > [junit] Test > > > org.apache.harmony.beans.tests.java.beans.IntrospectionExceptionTest > > > FAILED > > > <== > > > > > > Thanks, > > > > > > 2006/10/2, Vladimir Ivanov <[EMAIL PROTECTED]>: > > > > On 10/2/06, Alexei Zakharov <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > > > > > Juist my two cents. Some test even from such a high-level module as > > > > > beans fail if they run from bootclasspath (BeansTest for example). > > > > > Moreover, they crash DRLVM :) > > > > > > > > > > > > Seems, it is should be evaluated by VM peoples. The vm crash is not good > > > > reaction for test failure. > > > > thanks, Vladimir > > > > > > > > BTW, personally I use custom-made build file to develop with HDK and > > > > > single-module checkout. > > -- > Alexei Zakharov, > Intel Middleware Product Division > > - > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Egor Pasko, Intel Managed Runtime Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Alexei Zakharov, Intel Middleware Product Division - 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] removing \t from sources
I see. This IMHO is another argument why \t is bad. My script will not
be able to handle this, it just replaces one string pattern with
another. So such cases should be handled manually or with the code
formatter. However, the drawback of the code formatter is that it
removes the "author's personality" from the code.
But IMHO mixing spaces with tabs in the single unit of indentation is
even worse than just using tabs. Normally people use either tabs or
spaces. I suppose that mixes appear when the original source with tabs
is being edited with IDE configured to use spaces. I haven't seen many
of such cases in HY code, at least in the modules I worked with.
With best regards,
2006/10/2, Alexey Petrenko <[EMAIL PROTECTED]>:
I mean that {"space", "space", "tab"} will be converted to the same
number of spaces as simple tab by the most of editors.
SY, Alexey
2006/10/2, Alexei Zakharov <[EMAIL PROTECTED]>:
> What do you mean? Convert " \t" to something? If so please see the
> new fully customized version of my mega-script :-)
>
> The usage pattern in your case will be:
> ant -f tabs2spaces_v2.xml -Dsrc.dir= -Dpattern=" \t"
>
> Regards,
>
> 2006/10/2, Alexey Petrenko <[EMAIL PROTECTED]>:
> > Does it work with the sequences like {"space", "space", "tab"} etc?
> >
> > 2006/10/2, Alexei Zakharov <[EMAIL PROTECTED]>:
> > > Hi all,
> > >
> > > I noticed that the tab character (0x09) is still widely used in our
> > > classlib source code. At least in tests. From my recent experience
> > > this leads to broken indentation. I mean the situation when patch with
> > > spaces is applied to the source there tab character is used for
> > > indentation. Someone knows that according to Sun code conventions the
> > > tab should be exactly 8 spaces. The other person knows that exactly
> > > four spaces should be used as the unit of indentation [1]. As a result
> > > we have all methods indented with the single tab character and the
> > > patched methods indented with 4 spaces. And if your IDE is configured
> > > to display tabs as 8 spaces you will see broken indentation. Or vice
> > > versa.
> > >
> > > I have created small ANT script - see HARMONY-1660 [2]. This script
> > > converts all tabs to spaces in all found sources under the given
> > > directory recursively. I will be grateful if someone runs this script
> > > (tab -> 4 spaces) at least for beans tests (I currently working with)
> > > and integrates the results. It is really painful to deal with this
> > > broken alignment every day. And it is too boring (and IMHO silly) to
> > > convert it file by file and send patches for each case.
> > >
> > > [1] http://java.sun.com/docs/codeconv/html/CodeConventions.doc3.html#262
> > > [3] http://issues.apache.org/jira/browse/HARMONY-1660
> > >
> > > Thanks,
--
Alexei Zakharov,
Intel Middleware Product Division
-
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] removing \t from sources
Yes, I am really upset. Code formater is ok, any means are good. :)
Thanks.
2006/10/2, Tim Ellison <[EMAIL PROTECTED]>:
if it is upsetting you so much, I'll run the code formatter over beans
tests -- that will do the whitespace replacements. We have been
replacing them incrementally to date.
Not a slur on your script you know.
Regards
Tim
Alexey Petrenko wrote:
> I mean that {"space", "space", "tab"} will be converted to the same
> number of spaces as simple tab by the most of editors.
>
> SY, Alexey
>
> 2006/10/2, Alexei Zakharov <[EMAIL PROTECTED]>:
>> What do you mean? Convert " \t" to something? If so please see the
>> new fully customized version of my mega-script :-)
>>
>> The usage pattern in your case will be:
>> ant -f tabs2spaces_v2.xml -Dsrc.dir= -Dpattern=" \t"
>>
>> Regards,
>>
>> 2006/10/2, Alexey Petrenko <[EMAIL PROTECTED]>:
>> > Does it work with the sequences like {"space", "space", "tab"} etc?
>> >
>> > 2006/10/2, Alexei Zakharov <[EMAIL PROTECTED]>:
>> > > Hi all,
>> > >
>> > > I noticed that the tab character (0x09) is still widely used in our
>> > > classlib source code. At least in tests. From my recent experience
>> > > this leads to broken indentation. I mean the situation when patch
>> with
>> > > spaces is applied to the source there tab character is used for
>> > > indentation. Someone knows that according to Sun code conventions the
>> > > tab should be exactly 8 spaces. The other person knows that exactly
>> > > four spaces should be used as the unit of indentation [1]. As a
>> result
>> > > we have all methods indented with the single tab character and the
>> > > patched methods indented with 4 spaces. And if your IDE is configured
>> > > to display tabs as 8 spaces you will see broken indentation. Or vice
>> > > versa.
>> > >
>> > > I have created small ANT script - see HARMONY-1660 [2]. This script
>> > > converts all tabs to spaces in all found sources under the given
>> > > directory recursively. I will be grateful if someone runs this script
>> > > (tab -> 4 spaces) at least for beans tests (I currently working with)
>> > > and integrates the results. It is really painful to deal with this
>> > > broken alignment every day. And it is too boring (and IMHO silly) to
>> > > convert it file by file and send patches for each case.
>> > >
>> > > [1]
>> http://java.sun.com/docs/codeconv/html/CodeConventions.doc3.html#262
>> > > [3] http://issues.apache.org/jira/browse/HARMONY-1660
>> > >
>> > > Thanks,
>>
>> --
>> Alexei Zakharov,
>> Intel Middleware Product Division
>>
>> -
>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>
>
--
Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Alexei Zakharov,
Intel Middleware Product Division
-
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] removing \t from sources
What do you mean? Convert " \t" to something? If so please see the
new fully customized version of my mega-script :-)
The usage pattern in your case will be:
ant -f tabs2spaces_v2.xml -Dsrc.dir= -Dpattern=" \t"
Regards,
2006/10/2, Alexey Petrenko <[EMAIL PROTECTED]>:
Does it work with the sequences like {"space", "space", "tab"} etc?
2006/10/2, Alexei Zakharov <[EMAIL PROTECTED]>:
> Hi all,
>
> I noticed that the tab character (0x09) is still widely used in our
> classlib source code. At least in tests. From my recent experience
> this leads to broken indentation. I mean the situation when patch with
> spaces is applied to the source there tab character is used for
> indentation. Someone knows that according to Sun code conventions the
> tab should be exactly 8 spaces. The other person knows that exactly
> four spaces should be used as the unit of indentation [1]. As a result
> we have all methods indented with the single tab character and the
> patched methods indented with 4 spaces. And if your IDE is configured
> to display tabs as 8 spaces you will see broken indentation. Or vice
> versa.
>
> I have created small ANT script - see HARMONY-1660 [2]. This script
> converts all tabs to spaces in all found sources under the given
> directory recursively. I will be grateful if someone runs this script
> (tab -> 4 spaces) at least for beans tests (I currently working with)
> and integrates the results. It is really painful to deal with this
> broken alignment every day. And it is too boring (and IMHO silly) to
> convert it file by file and send patches for each case.
>
> [1] http://java.sun.com/docs/codeconv/html/CodeConventions.doc3.html#262
> [3] http://issues.apache.org/jira/browse/HARMONY-1660
>
> Thanks,
--
Alexei Zakharov,
Intel Middleware Product Division
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [general] Using the HDK ( was Re: [general] jre and hdk snapshots posted to general snapshot site )
Wouldn't this be something nice to show people? :) Well, it does not aligned with the current build system somehow, it was just for my personal convenience. Build sources, build tests, run all tests for the module (bootclasspath & classpath), run the single test of your choice, run tests with TestNG, convert TestNG test results with JUnitConverter and even preprocess sources with the Velocity compiler in order to remove unnecessary logging. :-) Of course I can share it, if somebody is interested. No problem. Thanks, 2006/10/2, Geir Magnusson Jr. <[EMAIL PROTECTED]>: Alexei Zakharov wrote: > Hi, > > 2006/10/2, Vladimir Ivanov <[EMAIL PROTECTED]>: >> On 10/2/06, Mark Hindess <[EMAIL PROTECTED]> wrote: > >> > I think we need more than one tests.jar. In fact, I think we need >> > more than one tests.jar per module since some tests need to be on the >> > bootclasspath while others do not (and should not). At the moment >> > it might be necessary to have more since there isn't really a way to >> > distinguish api/internal tests (this might change if/when we move to >> > testng). >> >> Almost all API tests can be run through the bootclasspath. May be we just >> waiting for something like TestNG (or other solution) and will create one >> test.jar for each module? > > Juist my two cents. Some test even from such a high-level module as > beans fail if they run from bootclasspath (BeansTest for example). > Moreover, they crash DRLVM :) > > BTW, personally I use custom-made build file to develop with HDK and > single-module checkout. Wouldn't this be something nice to show people? :) -- Alexei Zakharov, Intel Middleware Product Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [general] Using the HDK ( was Re: [general] jre and hdk snapshots posted to general snapshot site )
The same result with the "-Xem:opt". The exact command in my environment was (WinXP SP2): <== C:\mydoc\projects\tests\beans2>echo %JAVA_HOME% C:\Java\harmony-hdk-r450941\jdk\jre C:\mydoc\projects\tests\beans2>%JAVA_HOME%\bin\java -Xbootclasspath/p:.\build\classes;.\build\tests;C:\Java\harmony\enhanced\classlib\trunk\depends\jars\junit_3.8.2\junit.jar -Xem:opt junit.textui.TestRunner org.apache.harmony.beans.tests.java.beans.IntrospectionExceptionTest ... An unhandled error (4) has occurred. HyGeneric_Signal_Number=0004 ExceptionCode=c005 ExceptionAddress=0052A340 ContextFlags=0001003f Handler1=00401010 Handler2=11105CE0 InaccessibleAddress= EDI= ESI= EAX=0013F1AC EBX= ECX=007129FC EDX= EIP=0052A340 ESP=0013F17C EBP= Module=C:\Java\harmony-hdk-r450941\jdk\jre\bin\default\harmonyvm.dll Module_base_address=0051 Offset_in_DLL=0001a340 This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. <== Regards, 02 Oct 2006 20:14:11 +0700, Egor Pasko <[EMAIL PROTECTED]>: On the 0x1F6 day of Apache Harmony Alexei Zakharov wrote: > Agree. In case somebody is interested: > org.apache.harmony.beans.tests.java.beans.IntrospectionExceptionTest > (from bootclasspath), harmony-hdk-r450941, WinXP. Is that reproducible on Linux? how does it run on pure OPT (-Xem:opt), JET? > Crash info: > > <== >[junit] An unhandled error (4) has occurred. > [junit] HyGeneric_Signal_Number=0004 > [junit] ExceptionCode=c005 > [junit] ExceptionAddress=0052A340 > [junit] ContextFlags=0001003f > [junit] Handler1=00401010 > [junit] Handler2=11105CE0 > [junit] InaccessibleAddress= > [junit] EDI= > [junit] ESI= > [junit] EAX=0013D69C > [junit] EBX= > [junit] ECX=007129FC > [junit] EDX= > [junit] EIP=0052A340 > [junit] ESP=0013D66C > [junit] EBP= > [junit] Module=C:\Java\harmony-hdk-r450941\jdk\jre\bin\default\harmonyvm.dll > [junit] Module_base_address=0051 > [junit] Offset_in_DLL=0001a340 > [junit] This application has requested the Runtime to terminate it > in an unusual way. > [junit] Please contact the application's support team for more information. > [junit] Test > org.apache.harmony.beans.tests.java.beans.IntrospectionExceptionTest > FAILED > <== > > Thanks, > > 2006/10/2, Vladimir Ivanov <[EMAIL PROTECTED]>: > > On 10/2/06, Alexei Zakharov <[EMAIL PROTECTED]> wrote: > > > > > > > > > Juist my two cents. Some test even from such a high-level module as > > > beans fail if they run from bootclasspath (BeansTest for example). > > > Moreover, they crash DRLVM :) > > > > > > Seems, it is should be evaluated by VM peoples. The vm crash is not good > > reaction for test failure. > > thanks, Vladimir > > > > BTW, personally I use custom-made build file to develop with HDK and > > > single-module checkout. -- Alexei Zakharov, Intel Middleware Product Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [general] Using the HDK ( was Re: [general] jre and hdk snapshots posted to general snapshot site )
Is that reproducible on Linux? how does it run on pure OPT (-Xem:opt), JET? I will check... Regards, 02 Oct 2006 20:14:11 +0700, Egor Pasko <[EMAIL PROTECTED]>: On the 0x1F6 day of Apache Harmony Alexei Zakharov wrote: > Agree. In case somebody is interested: > org.apache.harmony.beans.tests.java.beans.IntrospectionExceptionTest > (from bootclasspath), harmony-hdk-r450941, WinXP. Is that reproducible on Linux? how does it run on pure OPT (-Xem:opt), JET? > Crash info: > > <== >[junit] An unhandled error (4) has occurred. > [junit] HyGeneric_Signal_Number=0004 > [junit] ExceptionCode=c005 > [junit] ExceptionAddress=0052A340 > [junit] ContextFlags=0001003f > [junit] Handler1=00401010 > [junit] Handler2=11105CE0 > [junit] InaccessibleAddress= > [junit] EDI= > [junit] ESI= > [junit] EAX=0013D69C > [junit] EBX= > [junit] ECX=007129FC > [junit] EDX= > [junit] EIP=0052A340 > [junit] ESP=0013D66C > [junit] EBP= > [junit] Module=C:\Java\harmony-hdk-r450941\jdk\jre\bin\default\harmonyvm.dll > [junit] Module_base_address=0051 > [junit] Offset_in_DLL=0001a340 > [junit] This application has requested the Runtime to terminate it > in an unusual way. > [junit] Please contact the application's support team for more information. > [junit] Test > org.apache.harmony.beans.tests.java.beans.IntrospectionExceptionTest > FAILED > <== > > Thanks, > > 2006/10/2, Vladimir Ivanov <[EMAIL PROTECTED]>: > > On 10/2/06, Alexei Zakharov <[EMAIL PROTECTED]> wrote: > > > > > > > > > Juist my two cents. Some test even from such a high-level module as > > > beans fail if they run from bootclasspath (BeansTest for example). > > > Moreover, they crash DRLVM :) > > > > > > Seems, it is should be evaluated by VM peoples. The vm crash is not good > > reaction for test failure. > > thanks, Vladimir > > > > BTW, personally I use custom-made build file to develop with HDK and > > > single-module checkout. -- Alexei Zakharov, Intel Middleware Product Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[classlib] removing \t from sources
Hi all, I noticed that the tab character (0x09) is still widely used in our classlib source code. At least in tests. From my recent experience this leads to broken indentation. I mean the situation when patch with spaces is applied to the source there tab character is used for indentation. Someone knows that according to Sun code conventions the tab should be exactly 8 spaces. The other person knows that exactly four spaces should be used as the unit of indentation [1]. As a result we have all methods indented with the single tab character and the patched methods indented with 4 spaces. And if your IDE is configured to display tabs as 8 spaces you will see broken indentation. Or vice versa. I have created small ANT script - see HARMONY-1660 [2]. This script converts all tabs to spaces in all found sources under the given directory recursively. I will be grateful if someone runs this script (tab -> 4 spaces) at least for beans tests (I currently working with) and integrates the results. It is really painful to deal with this broken alignment every day. And it is too boring (and IMHO silly) to convert it file by file and send patches for each case. [1] http://java.sun.com/docs/codeconv/html/CodeConventions.doc3.html#262 [3] http://issues.apache.org/jira/browse/HARMONY-1660 Thanks, -- Alexei Zakharov, Intel Middleware Product Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [general] Using the HDK ( was Re: [general] jre and hdk snapshots posted to general snapshot site )
Agree. In case somebody is interested: org.apache.harmony.beans.tests.java.beans.IntrospectionExceptionTest (from bootclasspath), harmony-hdk-r450941, WinXP. Crash info: <== [junit] An unhandled error (4) has occurred. [junit] HyGeneric_Signal_Number=0004 [junit] ExceptionCode=c005 [junit] ExceptionAddress=0052A340 [junit] ContextFlags=0001003f [junit] Handler1=00401010 [junit] Handler2=11105CE0 [junit] InaccessibleAddress= [junit] EDI= [junit] ESI= [junit] EAX=0013D69C [junit] EBX= [junit] ECX=007129FC [junit] EDX= [junit] EIP=0052A340 [junit] ESP=0013D66C [junit] EBP= [junit] Module=C:\Java\harmony-hdk-r450941\jdk\jre\bin\default\harmonyvm.dll [junit] Module_base_address=0051 [junit] Offset_in_DLL=0001a340 [junit] This application has requested the Runtime to terminate it in an unusual way. [junit] Please contact the application's support team for more information. [junit] Test org.apache.harmony.beans.tests.java.beans.IntrospectionExceptionTest FAILED <== Thanks, 2006/10/2, Vladimir Ivanov <[EMAIL PROTECTED]>: On 10/2/06, Alexei Zakharov <[EMAIL PROTECTED]> wrote: > > > Juist my two cents. Some test even from such a high-level module as > beans fail if they run from bootclasspath (BeansTest for example). > Moreover, they crash DRLVM :) Seems, it is should be evaluated by VM peoples. The vm crash is not good reaction for test failure. thanks, Vladimir BTW, personally I use custom-made build file to develop with HDK and > single-module checkout. -- Alexei Zakharov, Intel Middleware Product Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [general] Using the HDK ( was Re: [general] jre and hdk snapshots posted to general snapshot site )
Hi, 2006/10/2, Vladimir Ivanov <[EMAIL PROTECTED]>: On 10/2/06, Mark Hindess <[EMAIL PROTECTED]> wrote: > I think we need more than one tests.jar. In fact, I think we need > more than one tests.jar per module since some tests need to be on the > bootclasspath while others do not (and should not). At the moment > it might be necessary to have more since there isn't really a way to > distinguish api/internal tests (this might change if/when we move to > testng). Almost all API tests can be run through the bootclasspath. May be we just waiting for something like TestNG (or other solution) and will create one test.jar for each module? Juist my two cents. Some test even from such a high-level module as beans fail if they run from bootclasspath (BeansTest for example). Moreover, they crash DRLVM :) BTW, personally I use custom-made build file to develop with HDK and single-module checkout. Regards, -- Alexei Zakharov, Intel Middleware Product Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [build-test-infra] Build Test Infrastructure
Now everything is ok, thanks! Regards, 2006/9/29, Anton Luht <[EMAIL PROTECTED]>: Alexey, I was configuring site at that time :) I hope I've solved the problems with connection pool settings - sorry for the inconvenience. On 9/29/06, Alexei Zakharov <[EMAIL PROTECTED]> wrote: > Hi Anton, > > I hate to tell you this but it is down again (12:00 MSK). I'm not > complaining, just want to look at the site. :) > > Regards, > > 2006/9/28, Anton Luht <[EMAIL PROTECTED]>: > > Hello, > > > > The problem could be that hoster uses Mysql 4 while the app was > > configured for Mysql 5 - I've changed the settings - it's up again - > > I'll be watching it... > > > > On 9/28/06, Anton Luht <[EMAIL PROTECTED]> wrote: > > > Seems like the real-life testing broke the app :) Sorry for the > > > inconvenience - I'm going to investigate it and bring it bask asap. > > > > > > On 9/28/06, Anton Luht <[EMAIL PROTECTED]> wrote: > > > > Alexei, > > > > > > > > Thanks for the info - fixed. -- Alexei Zakharov, Intel Middleware Product Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [build-test-infra] Build Test Infrastructure
Hi Anton, I hate to tell you this but it is down again (12:00 MSK). I'm not complaining, just want to look at the site. :) Regards, 2006/9/28, Anton Luht <[EMAIL PROTECTED]>: Hello, The problem could be that hoster uses Mysql 4 while the app was configured for Mysql 5 - I've changed the settings - it's up again - I'll be watching it... On 9/28/06, Anton Luht <[EMAIL PROTECTED]> wrote: > Seems like the real-life testing broke the app :) Sorry for the > inconvenience - I'm going to investigate it and bring it bask asap. > > On 9/28/06, Anton Luht <[EMAIL PROTECTED]> wrote: > > Alexei, > > > > Thanks for the info - fixed. -- Alexei Zakharov, Intel Middleware Product Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [build-test-infra] Build Test Infrastructure
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:125) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:209) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:596) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:433) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:948) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:144) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:596) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:433) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:948) at org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2358) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:133) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:596) at org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve.java:118) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:594) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:116) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:594) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:433) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:948) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:127) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:596) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:433) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:948) at org.apache.ajp.tomcat4.Ajp13Processor.process(Ajp13Processor.java:409) at org.apache.ajp.tomcat4.Ajp13Processor.run(Ajp13Processor.java:528) at java.lang.Thread.run(Thread.java:534) <=== Some DB problems may be? Or this was my fault? Thanks, 2006/9/28, Anton Luht <[EMAIL PROTECTED]>: Alexei, VM hanged in the process of test execution - I killed it and tests proceeded - I'm not sure whether this crash is recorded as error or those tests are not included in the report. The report on site is the similar to the one I see in my local test_result/html report . On 9/28/06, Fedotov, Alexei A <[EMAIL PROTECTED]> wrote: > Anton, > > I'm looking at > http://www.harmonytest.org/testapp.do?method=showrun&id=4&name=&result=2 > &jira=0 > http://www.harmonytest.org/testapp.do?method=showrun&id=4&name=&result=3 > &jira=0 > > I see 5 errors and 14 failures. I just want to double check that we have > less than 20 problems with running unit tests on DRLVM. Is it correct > statement or some failures are missed? > > With best regards, > Alexei Fedotov, > Intel Middleware Products Division > > BTW, I have a small request for enhancement: the following request hides > search options by the right margin of my screen. I would suggest > reordering table rows in a way fixed width fields go first. > http://www.harmonytest.org/testapp.do?method=showrun&id=4&name=&result=1 > &jira=0 > > >-Original Message- > >From: Anton Luht [mailto:[EMAIL PROTECTED] > >Sent: Tuesday, September 26, 2006 7:44 PM > >To: harmony-dev@incubator.apache.org > >Subject: Re: [build-test-infra] Build Test Infrastructure > > > >> I think we'd want this to be "registered user can add user" > > > >Done. I'm still the only person with login - send me your > >login/password to register. > > > >-- > >Regards, > >Anton Luht, > >Intel Middleware Products Division > > > >- > >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] > > -- Regards, Anton Luht, Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For add
Re: [classlib][test] "fail" statements omitted in many exception catching test cases
May be you can look at my JIRA too? Thanks :)
HARMONY-1604
2006/9/28, Tim Ellison <[EMAIL PROTECTED]>:
Fixed.
Rui Hu wrote:
> Thanks Richard.
> I've looked at luni module and raised HARMONY-1618 about some bugs of those
> kind.
>
>
>
> On 9/28/06, Richard Liang <[EMAIL PROTECTED]> wrote:
>>
>> Great job, Robert. ;-)
>>
>> I will have a look at sql.
>>
>> On 9/28/06, Rui Hu <[EMAIL PROTECTED]> wrote:
>> > Great Mark!
>> > I've merged your code into my script. The script can be downloaded at
>> [1].
>> >
>> > Usage:
>> > perl failFinder.pl root_of_module
>> >
>> > e.g. Search out all related lines in luni module and redirect it to
>> > result.txt
>> >
>> > perl failFinder.pl trunk/modules/luni > result.txt
>> >
>> > e.g. Search out all related lines in all modules and redirect it to
>> > result.txt
>> >
>> > perl failFinder.pl trunk/modules/ > result.txt
>> >
>> > Anyone can find out the related lines of any modules.
>> >
>> > [1]:
>> >
>>
http://wiki.apache.org/harmony-data/attachments/failstatementsomitted/attachments/failFinder.pl
>>
>> >
>> >
>> >
>> > On 9/27/06, Mark Hindess <[EMAIL PROTECTED]> wrote:
>> > >
>> > >
>> > > This perl script does a marginally better job by being slightly
>> stricter
>> > > on matching context around 'catch'/'fail', by handling comments
>> slightly
>> > > better and by handling 'catch (...) { }' appearing on a single line.
>> > >
>> > > It also finds a few more hits such as:
>> > >
>> > > sql/src/test/java/org/apache/harmony/sql/tests/java/sql/TimeTest.java
>> +208
>> > >
>> > > which is a false positive but which uses "assertTrue(false);" which
>> > > should be fixed anyway.
>> > >
>> > > -Mark.
>> > >
>> > > #!/usr/bin/perl -w
>> > > use strict;
>> > >
>> > > my $previous_line = "";
>> > > my $possible_line_number;
>> > > while (<>) {
>> > > next if (/^\s*$/); # skip blank lines
>> > > if ($possible_line_number) {
>> > >if (m!^\s*(//|/\*|})!) {
>> > > print $ARGV, ' +', $possible_line_number, "\n";
>> > >}
>> > >undef $possible_line_number;
>> > > }
>> > > if (!m!^\s*(/?\*|//)! && /\bcatch\s*\(/ && $previous_line !~
>> > > /\bfail\s*\(/) {
>> > >$possible_line_number = $.;
>> > >if (/catch\s*\([^\)]+\)\s*{\s*}/) {
>> > > print $ARGV, ' +', $possible_line_number, "\n";
>> > > undef $possible_line_number;
>> > >}
>> > > }
>> > > $previous_line = $_;
>> > > }
--
Alexei Zakharov,
Intel Middleware Product Division
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [general] jre and hdk snapshots posted to general snapshot site
If we plan to use HDK for supporting developers who work on single module (that is a good idea IMHO) then we definitely need to supply jar with tests. We may also supply the build file with placeholders for user classes & tests dirs that will be prepended to classpath/bootclasspath. Regards, 2006/9/27, Vladimir Ivanov <[EMAIL PROTECTED]>: On 9/27/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: > > > > If I recall, the point of the test.jar was to have a pre-built jar of > tests in the HDK so that someone could setup the build-test infra > using the HDK so they could run tests on their platform w/o having to > build everything. Good idea. Yes, you are correct. This idea implemented in the jira 964. If that's so, then something would > have to be configured to have the classlib "test" target use that > jar. All I'm saying is that how we do this is important, as we don't > want to cause pain for classlib developers who use the HDK for > development support. Seems, we think about different use cases. In my case, user can download the HDK for own platform (if we have one) run tests and look on results (also, may be upload it to the harmony site). Also it can be used for application run to check 'enable' status. But if this user interested in Harmony development he should checkout ws and use built-in ant targets to build and test updated ws. How you plan to use HDK? It looks like initial miscommunication :) thanks, Vladimir > geir > > > > > Thanks, Vladimir > > > > > > > > > > > >> > Thanks, Vladimir > >> > > >> > geir > >> >> > >> >> > > >> >> > > >> >> > > >> >> > Thanks, Vladimir > >> >> > > >> >> > > >> >> > > >> >> > On 7/23/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote: > >> >> >> > >> >> >> They are at the regular place > >> >> >> > >> >> >> http://people.apache.org/dist/incubator/harmony/snapshots > >> >> >> > >> >> >> I moved all the old classlib snapshots into /old and I'll > >> >> update the > >> >> >> website accordingly. I'll be automating this. Also, lets not > >> >> >> make much > >> >> >> noise about this for a little while so we can test to make sure > >> >> >> there's > >> >> >> no major errors. Things seem good. I have a list of more > >> >> things to > >> >> >> fix, but I realized today that I was obsessing over the > >> snapshot > >> >> >> contents - it's not a release, and it's "good enough". > >> >> >> > >> >> >> I'd like to ditch both /old and the remaining classlib > >> >> snapshots, as > >> >> >> > >> >> >> 1) they are snapshots - history doesn't matter > >> >> >> > >> >> >> 2) the classlib is now in the HDK, so we just need to adjust > >> the > >> >> >> docs to > >> >> >> match. > >> >> >> > >> >> >> I'll do the latter, but wanted to see if anyone has a problem > >> >> w/ me > >> >> >> removing /old and the last classlib snapshot. I'll do this > >> if I > >> >> >> don't > >> >> >> hear any protest, so either positively acknowledge this action > >> >> if you > >> >> >> support it, dont' do a thing if you support or dont' care, > >> or say > >> >> >> why we > >> >> >> shouldn't :) > >> >> >> > >> >> >> geir > >> >> >> > >> >> >> > >> >> > >> - > >> >> >> Terms of use : http://incubator.apache.org/harmony/mailing.html > >> >> >> To unsubscribe, e-mail: harmony-dev- > >> >> [EMAIL PROTECTED] > >> >> >> For additional commands, e-mail: harmony-dev- > >> >> >> [EMAIL PROTECTED] > >> >> >> > >> >> >> > >> >> > >> >> > >> >> > >> - > >> >> Terms of use : http://incubator.apache.org/harmony/mailing.html > >> >> To unsubscribe, e-mail: harmony-dev- > >> [EMAIL PROTECTED] > >> >> For additional commands, e-mail: harmony-dev- > >> >> [EMAIL PROTECTED] > >> >> > >> >> > >> > >> > >> - > >> Terms of use : http://incubator.apache.org/harmony/mailing.html > >> To unsubscribe, e-mail: [EMAIL PROTECTED] > >> For additional commands, e-mail: harmony-dev- > >> [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] > > -- Alexei Zakharov, Intel Middleware Product Division - 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][test] "fail" statements omitted in many exception catching test cases
a.injected\java\security\UnresolvedPermissionCollection_ImplTest.java:63 .\sql\src\test\java\org\apache\harmony\sql\tests\java\sql\DateTest.java:381 .\sql\src\test\java\org\apache\harmony\sql\tests\java\sql\DriverManagerTest.java:264\315 .\swing\src\test\api\java\common\javax\swing\DefaultDesktopManagerTest.java:276\299 .\swing\src\test\api\java\common\javax\swing\GrayFilterTest.java:79 .\swing\src\test\api\java\common\javax\swing\JComponent_AddRemoveNotifyTest.java:138 .\swing\src\test\api\java\common\javax\swing\JEditorPaneRTest.java:92 .\swing\src\test\api\java\common\javax\swing\JEditorPaneTest.java:311\624 .\swing\src\test\api\java\common\javax\swing\JInternalFrameTest.java:563\846\1565\1569 .\swing\src\test\api\java\common\javax\swing\JInternalFrame_MultithreadedTest.java:122 .\swing\src\test\api\java\common\javax\swing\JTabbedPaneTest.java:521\529\531\546\554\556 .\swing\src\test\api\java\common\javax\swing\JTextAreaTest.java:618\693 .\swing\src\test\api\java\common\javax\swing\JTextPaneRTest.java:76 .\swing\src\test\api\java\common\javax\swing\plaf\basic\BasicDesktopIconUITest.java:120 .\swing\src\test\api\java\common\javax\swing\plaf\basic\BasicTextUITest.java:186\206\259\285\341\346 .\swing\src\test\api\java\common\javax\swing\RepaintManagerTest.java:631 .\swing\src\test\api\java\common\javax\swing\SwingUtilitiesTest.java:1586\1587\1588 .\swing\src\test\api\java\common\javax\swing\text\AbstractDocument_AbstractElementTest.java:183 .\swing\src\test\api\java\common\javax\swing\text\AbstractDocument_AbstractElement_MASNoLockTest.java:70\79\88\97\106\115\124 .\swing\src\test\api\java\common\javax\swing\text\AbstractDocument_BranchElementTest.java:153 .\swing\src\test\api\java\common\javax\swing\text\AbstractDocument_ContentTest.java:105 .\swing\src\test\api\java\common\javax\swing\text\AbstractDocument_FilterTest.java:195\231\238\273\280\287\294 .\swing\src\test\api\java\common\javax\swing\text\BoxView_WithChildrenTest.java:403 .\swing\src\test\api\java\common\javax\swing\text\CompositeView_NextNSVisPosTest.java:143 .\swing\src\test\api\java\common\javax\swing\text\DefaultCaretTest.java:585 .\swing\src\test\api\java\common\javax\swing\text\DefaultEditorKitRTest.java:163 .\swing\src\test\api\java\common\javax\swing\text\FlowView_FlowStrategyTest.java:330\331\345\346 .\swing\src\test\api\java\common\javax\swing\text\GapContent_GapVectorTest.java:148 .\swing\src\test\api\java\common\javax\swing\text\JTextComponentTest.java:288\463\472\922\923 .\swing\src\test\api\java\common\javax\swing\text\JTextComponent_AccessibleJTextComponentTest.java:265\274\285\297\312\320\509\510 .\swing\src\test\api\java\common\javax\swing\text\JTextComponent_AccessibleJTextComponent_variousTextTest.java:69\74 .\swing\src\test\api\java\common\javax\swing\text\JTextComponent_IMLocationTest.java:159 .\swing\src\test\api\java\common\javax\swing\text\JTextComponent_MultithreadedTest.java:160 .\swing\src\test\api\java\common\javax\swing\text\PasswordViewTest.java:161 .\swing\src\test\api\java\common\javax\swing\text\StringContentTest.java:60 .\swing\src\test\api\java\common\javax\swing\text\UtilitiesTest.java:655\721\737\773\782\863\936\951\989\1004 .\swing\src\test\api\java\common\javax\swing\text\ViewTest.java:481 .\swing\src\test\api\java\common\javax\swing\text\View_ChangesTest.java:1043 .\swing\src\test\api\java\common\javax\swing\Timer_MultithreadedTest.java:57 .\swing\src\test\api\java\common\javax\swing\UIDefaultsTest.java:215 .\swing\src\test\api\java.injected\javax\swing\text\html\parser\AttributeListTest.java:131 .\swing\src\test\api\java.injected\javax\swing\text\html\parser\ContentModelTest.java:141\148\155\162\169\176\183\189\195\201\212\217\222\228\235\241\247\254 .\swing\src\test\api\java.injected\javax\swing\text\html\parser\DTDTest.java:114\119\124 .\text\src\test\java\org\apache\harmony\text\tests\java\text\CollatorTest.java:113 .\text\src\test\java\org\apache\harmony\text\tests\java\text\DataFormatFieldTest.java:217 .\text\src\test\java\org\apache\harmony\text\tests\java\text\DecimalFormatSymbolsTest.java:421 .\text\src\test\java\org\apache\harmony\text\tests\java\text\DecimalFormatTest.java:1515 .\text\src\test\java\org\apache\harmony\text\tests\java\text\MessageFormatTest.java:147 .\text\src\test\java\org\apache\harmony\text\tests\java\text\RuleBasedCollatorTest.java:263\275 .\x-net\src\test\api\java\org\apache\harmony\xnet\tests\javax\net\ssl\SSLEngineTest.java:64 .\x-net\src\test\api\java\org\apache\harmony\xnet\tests\javax\net\ssl\SSLSocketTest.java:44\89\108 .\x-net\src\test\impl\java.injected\javax\net\ServerSocketFactoryTest.java:64\69\74 .\x-net\src\test\impl\java.injected\javax\net\SocketFactoryTest.java:64\69\74\79 .\x-net\src\test\impl\java.injected\javax\net\ssl\SSLServerSocketFactoryTest.java:50 .\x-net\src\test\impl\java.injected\javax\net\ssl\SSLSocketFactoryTest.java:50 - Terms of use : http://incubator.apache.org/harmony/mailing.
Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)
This version looks good to me. Regards, 2006/9/26, Alexey Petrenko <[EMAIL PROTECTED]>: I've combined all the comments again. And here is the last version. I hope... :) === cut === Preface This guideline covers a wide range of issues but not all of them. If you cannot do one of the steps, then write a comment to the issue. Use your common sense! Issue reporter: 1. Explicitly state the expected behavior and the actual behavior of Harmony code. Use links to specs, rfcs, etc. 2. Try to create as small a test case as possible. A patch to test will be highly appreciated. 3. Provide max. information about steps necessary to recreate the bug. If a patch for the test has not been supplied, provide as much diagnostic information about the failure as possible (stack trace, failure output, expected output etc). 4. Remember to use issue links if applicable. 5. Check the issue resolution when it is committed. Add a comment. Resolution provider :) : Depending on the type of issue, do the following: 1. Issue is probably a non-bug difference, not a bug or invalid: 1.1. Discuss on the dev list. 1.2. Add a link to the discussion thread as a comment to issue. 2. Issue is a bug: 2.1. Notify the community that you started investigation by adding a comment to the issue and send a message to dev list. If you cannot produce a patch, add another comment with the results of your investigation. 2.2. If reporter did not provide a patch to test: 2.2.1. Try to create a patch to test. 2.2.2. If you cannot produce a patch, write a comment about it. 2.3. Create a patch to fix the issue 2.3.1. Any concerns? Discuss on the dev list. Add a link to discussion as a comment. 2.4. All the pacthes (test and fix) should be relative to the directory where the main build.xml is: https://svn.apache.org/repos/asf/incubator/harmony/enhanced/classlib/trunk. Or to the module root directory. 2.5. Test and fix patches should be in different files. 2.6. If the patch requires to add, remove or move some files in the repository, add the appropriate script. 2.6. Check that all unit tests pass. 2.8. If it is an application-oriented issue, check the application. 2.9. Remember to use issue links if applicable. Committer: Depending on the issue type, do: 1. Issue is a non-bug difference, not a bug or invalid: Close the issue. 2. Issue is a bug: 2.1. If a patch to test is available, apply it. 2.2. Check that the test fails. 2.3. Apply the fix for the issue. 2.4. Check that test succeeds now. 2.5. Make sure that all unit tests pass. 2.6. For application-oriented issues, check the application. 2.7. If there are problems on previous steps, post a comment to JIRA and let "resolution provider" to resolve. 2.8. Make sure that the issue reporter is happy with the resolution. 2.9. Add revision info into JIRA issue === cut === - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Alexei Zakharov, Intel Middleware Product Division - 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] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)
How does it help to attach them separately? Just to implement the algorithm for committers described earlier by Alexey: 2. Issue is a bug: 2.1. If a patch to test is available, apply it. 2.2. Check that the test fails. 2.3. Apply the fix for the issue. 2.4. Check that test succeeds now. 2.5. Make sure that all unit tests pass. ... Regards, 2006/9/21, Tim Ellison <[EMAIL PROTECTED]>: Alexei Zakharov wrote: > Hi Alexey, > > IMHO it would be nice to explicitly state (for issue reports and/or > resolution providers) that patch to classlib code and patch to test > should be two separate patches. I personally posted several "combined" > patches in the past. :) My preference is for combined patches, if they come from the same contributor. How does it help to attach them separately? Regards, Tim > 2006/9/20, Alexey Petrenko <[EMAIL PROTECTED]>: >> 2006/9/20, Mark Hindess <[EMAIL PROTECTED]>: >> > >> > Alexey, >> > >> > What was wrong with the initial suggestion of recommending patches >> > be either relative to the classlib/trunk or >> > classlib/trunk/module/? >> Seems I was not very attentive... >> "Harmony root or module root" looks fine. >> >> Any other objections or corrections? >> >> SY, Alexey >> >> > I really don't care much *except* that there were two specific types >> > of patches I was trying to avoid as I mentioned when I first suggested >> > this guideline. So I definitely think a guideline of some form >> would be >> > constructive. >> > >> > Regards, >> > Mark. >> > >> > On 20 September 2006 at 15:48, "Alexey Petrenko" >> <[EMAIL PROTECTED]> wrote: >> > > Then we should remove this requirement at all... >> > > Since it is possible to have a patches for a few modules at once. Or >> > > for a few modules and a doc. >> > > >> > > 2006/9/20, Mark Hindess <[EMAIL PROTECTED]>: >> > > > >> > > > On 20 September 2006 at 13:56, "Alexey Petrenko" >> <[EMAIL PROTECTED] >> > > om> wrote: >> > > > > Not module build.xml but the main build.xml. >> > > > > Anyway since we got a lot of directories except of modules it is >> > > > > better to make a diff from the root. >> > > > >> > > > I anticipate that in time we will have people that only check >> out the >> > > > module they wish to work on. So I'm happy to see patches >> relative to >> > > > a module's build.xml directory. >> > > > >> > > > -Mark. >> > > > >> > > > >> > > > > 2006/9/20, Oleg Khaschansky <[EMAIL PROTECTED]>: >> > > > > > 2.4. All the pacthes (test and fix) should be relative to the >> > > > > > directory where the main build.xml is: >> > > > > > >> https://svn.apache.org/repos/asf/incubator/harmony/enhanced/classlib/tr >> > > unk >> > > > > > >> > > > > > As Mark noted, the directory where the module's build.xml is >> located >> > > > > > is also acceptable. >> > > > > > >> https://svn.apache.org/repos/asf/incubator/harmony/enhanced/classlib/tr >> > > unk/ >> > > > > modules/module_name >> > > > > > Generally, making the patch from this directory is much >> faster then >> > > > > > from the classlib/trunk :) >> > > > > > >> > > > > > >> > > > > > On 9/20/06, Alexey Petrenko <[EMAIL PROTECTED]> >> wrote: >> > > > > > > I've combined all the ideas. And here is the result. >> > > > > > > >> > > > > > > === cut === >> > > > > > > Preface >> > > > > > > This guideline covers a wide range of issues but not all >> of them. >> > > > > > > If you cannot do one of the steps, then write a comment to >> the issue. >> > > > > > > Use your common sense! >> > > > > > > >> > > > > > > Issue reporter: >> > > > > > > 1. Explicitly state the expected behavior and the >> > > > > > > actual behavior of Harmony code. Use links to specs, rfcs, >> etc. >> > > > > > > 2. Try to create as small a
Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)
t; > > > > comment with the results of your investigation. > > > > > >2.2. If reporter did not provide a patch to test: > > > > > >2.2.1. Try to create a patch to test. > > > > > >2.2.2. If you cannot produce a patch, write a comment about it > > . > > > > > >2.3. Create a patch to fix the issue > > > > > >2.3.1. Any concerns? Discuss on the dev list. Add a link to > > > > > > discussion as a comment. > > > > > >2.4. All the pacthes (test and fix) should be relative to the > > > > > > directory where the main build.xml is: > > > > > > https://svn.apache.org/repos/asf/incubator/harmony/enhanced/classlib/ > > trun > > > > k > > > > > >2.5. If the patch requires to add, remove or move some files in th > > e > > > > > > repository, add the appropriate script. > > > > > >2.6. Check that all unit tests pass. > > > > > >2.7. If it is an application-oriented issue, check the application > > . > > > > > >2.8. Remember to use issue links if applicable. > > > > > > > > > > > > Committer: > > > > > > Depending on the issue type, do: > > > > > > 1. Issue is a non-bug difference, not a bug or invalid: > > > > > > Close the issue. > > > > > > 2. Issue is a bug: > > > > > >2.1. If a patch to test is available, apply it. > > > > > >2.2. Check that the test fails. > > > > > >2.3. Apply the fix for the issue. > > > > > >2.4. Check that test succeeds now. > > > > > >2.5. Make sure that all unit tests pass. > > > > > >2.6. For application-oriented issues, check the application. > > > > > >2.7. If there are problems on previous steps, post a comment to > > > > > > JIRA and let "resolution provider" to resolve. > > > > > >2.8. Make sure that the issue reporter is happy with the resolutio > > n. > > > > > >2.9. Add revision info into JIRA issue > > > > > > -- Alexei Zakharov, Intel Middleware Product Division - 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][beans] RI violates the spec in DefaultPersistenceDelegate
Thanks for the feedback Tim. HARMONY-1503 has been rised.
Regards,
2006/9/20, Tim Ellison <[EMAIL PROTECTED]>:
I agree that it should use the BeanInfo. Leave Harmony code as-is and
file a non-bug difference JIRA.
Regards,
Tim
Alexei Zakharov wrote:
>
> Greetings to Harmony java beans experts.
>
> It seems I found another place where RI fails. The behavior of its
> java.beans.DefaultPersistenceDelegate#DefaultPersistenceDelegate(String[])
> IMHO violates at least the following part of the spec (JavaBeans spec
> v1.01 page 57):
>
> <--
> 8.7. Analyzing a Bean
>
> We allow both explicit specification of a bean's exposed
> properties/methods/events and also implicit analysis using design
> patterns.
> To simplify access to this information, and to make sure that all
> tools apply the same analysis rules, we provide a class
> java.beans.Introspector that should be used to analyze a bean class.
> It allows you to obtain a BeanInfo object that comprehensively
> describes a target bean class.
> The Introspector class walks over the class/superclass chain of the
> target class. At each level it checks if there is a matching BeanInfo
> class which provides explicit information about the bean, and if so
> uses that explicit information. Otherwise it uses the low level
> reflection APIs to study the target class and uses design patterns to
> analyze its behaviour and then proceeds to continue the introspection
> with its baseclass. (See the Introspector class definition for a full
> description of the analysis rules.)
> <--
>
> The test below illustrates that RI does not care about explicitly
> specified BeanInfo class and uses the reflection API instead. Please
> note that our implementation behaves correctly in this situation. This
> is the reason why some tests from DefaultPersistenceDelegateTest fail
> - they are "optimized" for this RI behavior.
> The test case:
> ---
> import java.beans.*;
>
> public class DefaultPDtest {
>
>public static class MyFoo {
>String ugh;
>
>public MyFoo(String str) {
>ugh = str;
>}
>
>public String myget() {
>return ugh;
>}
>
>public void myset(String val) {
>ugh = val;
>}
>}
>
>public static class MyFooBeanInfo extends SimpleBeanInfo {
>public PropertyDescriptor[] getPropertyDescriptors() {
>PropertyDescriptor pd;
>
>try {
>pd = new PropertyDescriptor("prop1",
>MyFoo.class, "myget", "myset");
>} catch (IntrospectionException e) {
>throw new RuntimeException(e);
>}
>return new PropertyDescriptor[] { pd };
>}
>}
>
>public static class MyPersistenceDelegate
>extends DefaultPersistenceDelegate {
>public MyPersistenceDelegate(String[] propNames) {
>super(propNames);
>}
>
>protected Expression instantiate(Object oldInstance, Encoder out) {
>return super.instantiate(oldInstance, out);
>}
>}
>
>public static void main(String argv[]) {
>Encoder enc = new Encoder();
>MyPersistenceDelegate pd;
>MyFoo oldBean = new MyFoo("harmony");
>Expression expr;
>
>System.out.println("Test1: arg should be \"harmony\"");
>pd = new MyPersistenceDelegate(new String[] {"prop1"});
>expr = pd.instantiate(oldBean, enc);
>System.out.println("Constructor to call: " + expr);
>
>System.out.println("Test2: arg should be null");
>pd = new MyPersistenceDelegate(new String[] {"ugh"});
>expr = pd.instantiate(oldBean, enc);
>System.out.println("Constructor to call: " + expr);
>
>}
>
> }
>
> Output on RI (Sun 1.5.0_06):
> ---
> Test1: arg should be "harmony"
> java.lang.NoSuchMethodException: DefaultPDtest$MyFoo.getProp1
> Continuing ...
> Constructor to call: DefaultPDtest$MyFoo=Class.new(null);
> Test2: arg should be null
> Constructor to call: DefaultPDtest$MyFoo=Class.new("harmony");
>
> Output on Harmony (current):
> ---
> Test1: arg should be "harmony"
> Constructor to call: DefaultPDtest$MyFoo=Class.new("harmony");
> Test2: arg should be null
> class java.lang.NoSuchMethodException: no property for name ugh is found
> Constructor to call: DefaultPDtest$MyFoo=Class.new(null);
>
> I vote for ignoring RI and following the spec here.
> Thanks for your attention,
>
>
--
Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.
--
Alexei Zakharov,
Intel Middleware Product Division
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
