Re: [classlib] Exception throwing compatibility: java.util.Scanner
On 7/7/06, Richard Liang <[EMAIL PROTECTED]> wrote: We may frequently encounter this confused situation, and I suggest we discuss the problems case by case if someone is not sure how to do. ;-) For this case, I decide to follow "useRadix(int radix)". Please correct me if I'm wrong. Thanks a lot. +1. -- Anton Avtamonov, 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]
Re: [classlib] Exception throwing compatibility: java.util.Scanner
Hi Richard,
Very good example.
You are right, spec says nothing about invalid radix processing for
nextInt(). RI behavior just proves they have no guard check. However
useRadix() produces IAE for the invalid radix and the sound of logic
says that IAE is a proper reaction for wrong radix in any method with
radix. Looks like a bug in RI for me...
Don't beat me please :-), but I would suggest two approaches:
- either no checks for radix, so that underlying algorithm does or
doesn't produce some exceptions
- implement guard check and produce IAE.
I believe that right solution is the second one - produce IAE -
however it potentailly results in less compatibility with RI.
--
Anton Avtamonov,
Intel Middleware Products Division
On 7/6/06, Richard Liang <[EMAIL PROTECTED]> wrote:
Hello All,
When I'm trying to implement Scanner.nextInt(int radix), I met a problem.
As we all know, Character.MIN_RADIX equals 2 and Character.MAX_RADIX
equals 36, so the parameter radix can not less than 2 or greater than
36, Otherwise that parameter is illegal.
But on RI, when the parameter radix is illegal, there are different
kinds of Exception thrown.
* If the parameter is less than 0 or greater than 36, RI throws a
StringIndexOutOfBoundsException. Obviously this exception depends
an RI's implementation.
* If the parameter equals 1, RI throws an InputMismatchException
with an additional information "The radix 1 is less than the
Character.MIN_RADIX".
* If the parameter equals 0, RI throws a
java.util.regex.PatternSyntaxException whose constructor has three
parameters. And the parameters depends on RI's implementation,
that makes me can not follow RI.
And nothing is documented in the spec. Shall I follow RI's behavior?
Thanks a lot.
Here is the test case to demo this issue.
public void test_nextIntI(){
Scanner s = new Scanner("123 456");
try {
s.nextInt(-1);
fail("Should throw StringIndexOutOfBoundsException");
} catch (StringIndexOutOfBoundsException e) {
// Expected
}
try {
s.nextInt(0);
fail("Should throw PatternSyntaxException");
} catch (PatternSyntaxException e) {
// Expected
}
try {
s.nextInt(1);
fail("Should throw InputMismatchException");
} catch (InputMismatchException e) {
// Expected
}
try {
s.nextInt(40);
fail("Should throw StringIndexOutOfBoundsException");
} catch (StringIndexOutOfBoundsException e) {
// Expected
}
}
--
Richard Liang
China Software Development Lab, IBM
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] Exception-throwing compatibility question
On 6/30/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote: But section "Exception-throwing compatibility" says that exceptions are different and we aim "to be fully compartible with the RI" "by matching the exception characteristics of each method". I believe that it is for "However, in most cases the specification does not describe all possible exceptions that may be thrown" case only. In case the spec is complete and not looks like a bug I would vote to follow the spec. Wishes, -- Anton Avtamonov, 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]
Re: [apps] freemind
I failed to reproduce on Windows machine, so minimal test case/scenario would be fantastic. Btw, FreeMind looks differently on RI and Harmony on Windows since application is based on Windows L&F which is not supported by Harmony. Metal L&F (default) is used instead. -- Anton Avtamonov, Intel Middleware Products Division On 6/15/06, Alexey Petrenko <[EMAIL PROTECTED]> wrote: 2006/6/15, Anton Luht <[EMAIL PROTECTED]>: > I've built Harmony with AWT + Swing and tried to run Freemind > (http://freemind.sourceforge.net/) on it. It is Swing application. It > worked fine in general - I've created a simple 'map' (sort of scheme) > in it and saved the file. Great! :) > The only problem I've noticed is that the > upper menu (File, Edit, ...) sometimes disappeared after redraws. > After resizing the window menu became visible again. Can you try to minimize the testcase and file it in JIRA? -- Alexey A. Petrenko 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]
Re: [apps] freemind
Which platform? Wishes, -- Anton Avtamonov, Intel Middleware Products Division On 6/15/06, Anton Luht <[EMAIL PROTECTED]> wrote: Good day, I've built Harmony with AWT + Swing and tried to run Freemind (http://freemind.sourceforge.net/) on it. It is Swing application. It worked fine in general - I've created a simple 'map' (sort of scheme) in it and saved the file. The only problem I've noticed is that the upper menu (File, Edit, ...) sometimes disappeared after redraws. After resizing the window menu became visible again. -- 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]
Re: [apps] welkin (was Re: [VOTE] Acceptance of Harmony-528: ...)
On 6/6/06, Stefano Mazzocchi <[EMAIL PROTECTED]> wrote: That's interesting I suspect that BasicHTML and LineListener are dependencies of JApplet because I don't use sound nor HTML rendering in there... but I do extend JApplet. Yes, unfortunately JApplet is not there yet :-( Some assumptions regarding BasicHTML and sound (I can't promise I'm 100% correct): All Swing components support HTML-formatted text (not done in Harmony yet). BasicHTML is the entry point for that. I suppose that RI implementation performs check BasicHTML.isHTMLString() for all text lines of swing components. Therefore BasicHTML is triggered even application has no HTML formatting. So, we can forget about this class for now - Harmony doesn't need it for the time being and should perfectly work for plain text. About sound... Just an assumption that it was requested from L&F for some component (L&F should provide audio action maps). It is also not currently implemented for Harmony and should not prevent applications from being run sucessfully. Hmmm... BTW, is Harmony's Java2D hardware accelerated or software drawn? Our 2D implementation is based on GDI/GDI+ technologies. Therefore it is as accelerated as those technologies are :-). Regards, -- Anton Avtamonov, 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]
Re: [testing] Re: AWT, Java2D and SWING contribution
On 6/2/06, Anton Avtamonov <[EMAIL PROTECTED]> wrote:
On 6/2/06, Erik Axel Nielsen <[EMAIL PROTECTED]> wrote:
> >
> > Actually my English is not good :-). Will work on improvement.
> >
> > What I tried to say is that we really don't need to use third-party
> > L&Fs for visual testing. It doesn't mean we should not try them. We
> > should! Just because L&F implementation is one of the most significant
> > customization in Swing and may be based on the very internal things
> > (like the order of components in some specific container, etc). So,
> > running third-party applications which provide their own L&Fs will
> > allow to determine many inconsistencies. Obviously, the more
> > applications we probe during testing the better fucntional coverage
> > we achieve (and the more problems get identified).
> >
> > Talking about scenario automation: if I got your idea right, you
> > proposed to use some third-party L&F. Just because this approach would
> > allow unified look for both RI and Harmony.
> > This is excellent idea, but third-party L&F could also provide not
> > just own colors, but customized behavior as well, replacing our
> > classes. That's why I think we should not used them.
> > Your idea can be easily implemented by overriding color-related
> > constants in L&F.
> > What we need is just call:
> > UIManager.put("someColorConstant", new ColorUIResource
> > (PREDEFINED_COLOR))
> > for all the color-related constants.
> > This allows to test the standard set of L&F classes.
>
> Thanks a lot clearing this up for me Anton. I agree with most of your
> views. However I think that using third party L&F in our testing
> could help us isolate problems that are not in our own L&Fs but
> rather in our implementation of the other parts of Swing/Awt/Java2D.
> But as you say, we will have to find a L&F that overrides most if not
> all of BasicLF and that could be a bigger problem than I though
> originally.
Yes, agree.
If we want to test the underlying fucntionality completely isolated
L&F would be nice. For instance, the fact that button changes its
state to pressed/released is UI responsibility, however the fact that
listeners are notified is the reposnsibility of ButtonModel. And the
fact that mouse events are propoerly delivered is responsibility of
event queue and dispatching machinery. So, replacing UI part we can
test all event-processing layer for instance.
Anyway I'll try third-party L&Fs you are pointed out just to look how
it works with Harmony.
As I expected custom L&Fs are the most complecated tests for the Swing
fucntionality. I tried L&Fs you advised and even was able to run a
simple application with one of them with minor changes in Swing :-).
I'll continue my investigations. I hope I'll be able to provide some
patches when the original contribution appears in SVN.
Thank you,
--
Anton Avtamonov,
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]
Re: [testing] Re: AWT, Java2D and SWING contribution
On 6/2/06, Erik Axel Nielsen <[EMAIL PROTECTED]> wrote:
>
> Actually my English is not good :-). Will work on improvement.
>
> What I tried to say is that we really don't need to use third-party
> L&Fs for visual testing. It doesn't mean we should not try them. We
> should! Just because L&F implementation is one of the most significant
> customization in Swing and may be based on the very internal things
> (like the order of components in some specific container, etc). So,
> running third-party applications which provide their own L&Fs will
> allow to determine many inconsistencies. Obviously, the more
> applications we probe during testing the better fucntional coverage
> we achieve (and the more problems get identified).
>
> Talking about scenario automation: if I got your idea right, you
> proposed to use some third-party L&F. Just because this approach would
> allow unified look for both RI and Harmony.
> This is excellent idea, but third-party L&F could also provide not
> just own colors, but customized behavior as well, replacing our
> classes. That's why I think we should not used them.
> Your idea can be easily implemented by overriding color-related
> constants in L&F.
> What we need is just call:
> UIManager.put("someColorConstant", new ColorUIResource
> (PREDEFINED_COLOR))
> for all the color-related constants.
> This allows to test the standard set of L&F classes.
Thanks a lot clearing this up for me Anton. I agree with most of your
views. However I think that using third party L&F in our testing
could help us isolate problems that are not in our own L&Fs but
rather in our implementation of the other parts of Swing/Awt/Java2D.
But as you say, we will have to find a L&F that overrides most if not
all of BasicLF and that could be a bigger problem than I though
originally.
Yes, agree.
If we want to test the underlying fucntionality completely isolated
L&F would be nice. For instance, the fact that button changes its
state to pressed/released is UI responsibility, however the fact that
listeners are notified is the reposnsibility of ButtonModel. And the
fact that mouse events are propoerly delivered is responsibility of
event queue and dispatching machinery. So, replacing UI part we can
test all event-processing layer for instance.
Anyway I'll try third-party L&Fs you are pointed out just to look how
it works with Harmony.
--
Anton Avtamonov,
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]
Re: [testing] Re: AWT, Java2D and SWING contribution
On 6/2/06, Erik Axel Nielsen <[EMAIL PROTECTED]> wrote:
Hi Anton
>
> However if some third-party L&F provides "full" decoration, i.e.
> provide its own look for all components overriding every setting from
> BasicLookAndFeel then it can perfectly satisfy our needs:
How about this one: http://napkinlaf.sourceforge.net/ ?
I haven't looked at the code, but if they reuse a substantial part of
basic LF I will be surprised. :)
Just for the record, this is partly meant as a joke, but who knows?
Perhaps it is worth checking out.
> Looking at this idea deeply I would ever suggest not to use any
> third-party L&Fs (since they can override some behavior anyway), but
> just override all color L&F keys which is very simple.
I'm sorry, but my english is not that good. What exactly are you
suggesting here? If I read it correctly, you mean we should never do
checks with a third party LF? If that is correct, why?
Actually my English is not good :-). Will work on improvement.
What I tried to say is that we really don't need to use third-party
L&Fs for visual testing. It doesn't mean we should not try them. We
should! Just because L&F implementation is one of the most significant
customization in Swing and may be based on the very internal things
(like the order of components in some specific container, etc). So,
running third-party applications which provide their own L&Fs will
allow to determine many inconsistencies. Obviously, the more
applications we probe during testing the better fucntional coverage
we achieve (and the more problems get identified).
Talking about scenario automation: if I got your idea right, you
proposed to use some third-party L&F. Just because this approach would
allow unified look for both RI and Harmony.
This is excellent idea, but third-party L&F could also provide not
just own colors, but customized behavior as well, replacing our
classes. That's why I think we should not used them.
Your idea can be easily implemented by overriding color-related
constants in L&F.
What we need is just call:
UIManager.put("someColorConstant", new ColorUIResource(PREDEFINED_COLOR))
for all the color-related constants.
This allows to test the standard set of L&F classes.
--
Anton Avtamonov,
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]
Re: [testing] Re: AWT, Java2D and SWING contribution
On 6/2/06, Erik Axel Nielsen <[EMAIL PROTECTED]> wrote: Hi, >> Very hard part. Colors used in Harmony are not equivalent to RI. >> Therefore I expect that "as is" comparison will show that everything >> is different :-). The entire component Look is not 100% copied, i.e. >> position of the focus frame, look of the borders, etc. differ. >> Besides, colors are theme-dependent and may differ for MetalTheme and >> OceanTheme, for instance. I think a possible way to partly test the wanted behaviour of our Swing/AWT component will be to do a pixel compare using a third party Look and Feel. A good one for this purpose could be jgoodies [1]. It has several different L&Fs and they are all pretty complete. I know this wouldn't test the L&Fs that Harmony are supposed to ship (like Metal and Ocean?) but at least its a way to test the underlying engine. All third party L&Fs should be identical on both Harmony and RI, shouldn't they? Hi Erik. That you for the interesting idea! The quick answer to your question is - not necessary. All third-party L&Fs I've ever seen were based on BasicLookAndFeel. BasicLookAndFeel is not used independently, however provides 95% of the components behavior. All other L&Fs just add some "decoration", but don't provide all the fucntionality from scratch (just because that is the major part of Swing :-) ). However if some third-party L&F provides "full" decoration, i.e. provide its own look for all components overriding every setting from BasicLookAndFeel then it can perfectly satisfy our needs: we would have same colors on both Harmony and RI, however will be able to test the behavioral part since only colors were changed. Looking at this idea deeply I would ever suggest not to use any third-party L&Fs (since they can override some behavior anyway), but just override all color L&F keys which is very simple. -- Anton Avtamonov, 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]
Re: [testing] Re: AWT, Java2D and SWING contribution
On 6/1/06, Mark Hindess <[EMAIL PROTECTED]> wrote: On 1 June 2006 at 17:36, "Alexey Petrenko" <[EMAIL PROTECTED]> wrote: > > Which thing will this tool compare? Created windows or displays pixel > by pixel? The syntax I listed for xwd dumps the whole virtual display. You can also instruct it to dump single windows. But either way, it's a pixel by pixel dump which is why I said that doing something meaningful in step 4 - the comparison - would be the hard part. Very hard part. Colors used in Harmony are not equivalent to RI. Therefore I expect that "as is" comparison will show that everything is different :-). The entire component Look is not 100% copied, i.e. position of the focus frame, look of the borders, etc. differ. Besides, colors are theme-dependent and may differ for MetalTheme and OceanTheme, for instance. That's why I suppose that using of some heuristical rules will be required. Like "button is in pressed state if its color became darker". Wishes, -- Anton Avtamonov, 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]
Re: [testing] Re: AWT, Java2D and SWING contribution
On 6/1/06, Chris Gray <[EMAIL PROTECTED]> wrote: I believe that Classpath uses the VisualTestEngine we developed at Acunia. Requires manual operation, but it has facilities for explanatory texts, pass/ fail indications, etc.. It will even run applets if you ask it nicely. You can find it in the SVN repository at www.wonka-vm.org (which is down at the moment I write this, I'll ping Luminis to ask why). I don't think it's that difficult to hack X to write to normal RAM instead of a framebuffer, but the real problem is that there's no hard spec of which pixels should change to what colour when you create e.g. a button. You could instrument an X server in other ways though, for example to see that [J]Frame actually opens a new window and sets its title. Well, IMHO it is not reuiqred to test every pixel. What is important for visual testing of JButton say it to check that it change its color being pressed, for instance. Or that focus is displayed. I believe we could figure out not very complicated heuristics to identify different states for each component. I expect Swing testing is based on real applications and use some tool to automate scenarious and automatically check the results (compoennt states) basing on the choosen heuristics. Wishes, -- Anton Avtamonov, 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]
Re: [classlib] internationalization
On 5/31/06, Tim Ellison <[EMAIL PROTECTED]> wrote:
Yep, we discussed that a while ago.
IIRC there was some debate about how the message keys should look.
Today we have short strings (e.g. "K1234") and there was a proposal to
make that . (e.g. "beans.42"). I recall some objections to
that proposal but cannot recreate them right now.
Yes. I proposed to have self-documenting key names.
Because when code produces some exception, for instance, I would
prefer to see something like
throw new IOException(I18N.getMessage("wrongFileFormatMsg"))
rahter than
throw new IOException(I18N.getMessage("K1234")):-).
With my proposal it is very easy to understand the idea of the coded
message and its intention.
Wishes,
--
Anton Avtamonov,
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]
Re: [classlib] java.io.File doesn't work with non-latin names
On 5/30/06, Tim Ellison <[EMAIL PROTECTED]> wrote: Hi Anton (not seen you for a while!) Yeah, I was busy with Swing contribution preparation :-) Probably best to raise it in JIRA anyway, and we can close it as a duplicate if it is already covered. Otherwise it may get lost on the list. (just cut-n-paste your note into JIRA) Done. Tracked as https://issues.apache.org/jira/browse/HARMONY-535 Thank you for the response! -- Anton Avtamonov, 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]
[classlib] java.io.File doesn't work with non-latin names
Hi,
I just faced the problem that java.io.File doesn't properly work with
the file names which has non-latin chars (I tried Russian, of course
:-) ) on Windows.
The minimal code to reproduce is:
File russianDir = new File("c:\\temp\\\u0440\u0443\u0441_dir");
russianDir.mkdirs();
System.out.println("isCreated = " + russianDir.isDirectory());
which prints out "false".
The very important thing here is that Control Panel > Regional And
Language Options > Regional Options tab > "Standards and formats"
setting is set to "English US". All other regional settings (location,
language for non-unicode programs) are set to Russian. If I switch
"Standards and formats" to Russian everything works fine.
Similar problem with other extended unicode chars.
I looked through both mailing list and JIRA and found lots
encoding-related issues, but not sure if my case is covered or not.
Could the experts please look and decide should I submit new JIRA
issue or not? If it is already tracked could you please point out its
JIRA index?
Wishes,
--
Anton Avtamonov,
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]
Re: AWT, Java2D and SWING contribution
As part of Swing module the implementation of javax.accessibility is also contributed. Wishes, -- Anton Avtamonov, Intel Middleware Products Division On 5/30/06, Alexey Petrenko <[EMAIL PROTECTED]> wrote: Dear all, I am glad to announce next contribution to Harmony classlib on behalf of Intel. The archive with the contribution is uploaded to the following location: http://issues.apache.org/jira/browse/HARMONY-528 The contribution consists of the following modules: awt – AWT and Java2D packages swing – SWING package misc – utility classes that do not belong to AWT or SWING but are used by both modules. We have tested these modules with ClassEditor, JUnit and JEdit. Geir has used these modules for demo on JavaOne. The Java2D implementation uses GDI+ library on Windows and Xlib on Linux. For more information on AWT and Java2D implementation internals, you can read documentation inside the awt module. The building system included with the contribution is entirely written on ANT. Eclipse 3.1.1 compiler is used for compile the Java code. The native code can be built with MSVC or Intel C compiler on Windows and GCC or Intel C compiler on Linux IA32. The build uses header files and libraries from current Harmony workspace. All the resulting jars and dynamic libraries are placed in corresponding subdirectories of Harmony/deploy directory. You can find systematic building instructions in the README.txt file in the archive. However, there are many things to do in these modules such as Java 1.5 support, bidirectional text handling, complete implementation of drag and drop, HTML and RTF formats support, Multi and Synth look-and-feels and others. The java.awt.PrintJob class and image data flavors have been removed or commented out because they depend on the packages javax.print and javax.imageio respectively, which are not available in Harmony yet. Please refer to the README.txt file for bigger list of To-Dos and known issues. You are welcome to try the contribution and share your opinion! SY, Alexey -- Alexey A. Petrenko 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]
Re: [classlib] HARMONY vs. J2SE API source, binary compatibility: JAPI for 1.5 required
Vladimir,
- Am I right that source/binary compatibility implies that
package-private implementation also matches? If it does then how does
it fit to clean-room?
- Do we really need to be source/binary compatible? Do you think that
existing compatibility guideline
http://incubator.apache.org/harmony/subcomponents/classlibrary/compat.html
is not enough?
Sorry if it was discussed before and I missed it.
--
Anton Avtamonov,
Intel Middleware Products Division
On 5/6/06, Vladimir Ivanov <[EMAIL PROTECTED]> wrote:
Recently I thought about guaranteeing binary and source compatibility
between HARMONY API and other compatible J2SE API implementations, what is
our goal and how to check it, automation. Let me share my thoughts - for us
to understand clearly what we want and how to test it.
Here is the summary:
· For 1.4 J2SE API implementation - JAPI tool, being applied in both
ways (RI vs. HARMONY and HARMONY vs. RI), tests 2-way binary compatibility
between two J2SE API implementations and only one small update to check the
inheritance class hierarchy should be added to tests 2-way source
compatibility.
· For 1.5 – JAPI tests 2-way binary compatibility. For checking 2-way
source compatibility JAPI lacks some 1.5 language specific checks in
addition to checking inheritance class hierarchy. We need some add-ons for
JAPI.
Details:
First, definitions…
Binary compatibility – if class A can be linked with a set of classes B and
a set of classes C than sets B and C are binary compatible (from the A's
point of view). For Java it is defined in the JLS chapter 13.
Source compatibility – if a source of class A can be compiled with a set of
classes B and a set of classes C (by conformant compiler) than sets B and C
are source compatible.
1-way binary/source compatibility – any arbitrary class A, linked/compiled
with a set of classes B, can be linked/compiled with a set of classes C.
2-way binary/source compatibility – any arbitrary class A, linked/compiled
with a set of classes B, can be linked/compiled with a set of classes C AND
vice versa – any arbitrary class A, linked/compiled with a set of classes C,
can be linked/compiled with a set of classes B.
Some observations
Observation #1: I think, in general, binary compatibility is a weaker
requirement then source compatibility and is completely covered by source
compatibility.
Observation #2: I think, talking about 1.4, checking of 2-way binary
compatibility + throws clause + inheritance hierarchy will guarantee 2-way
source compatibility. I did not find any contra examples.
Observation #3: In 1.5, however, checking of 2-way binary compatibility+
throws clause + inheritance hierarchy does not guarantee 2-way source
compatibility. Why? - generics, enums, annotations.
Example for generics:
class A {
public void m(T p) {
}
}
class A {
public void m(Object p) {
}
}
class MyClass {
public static void main() {
new A().m("abc");
}
}
Both "A"s are 2-way binary compatible, but, MyClass can not be compiled with
non-parameterized A.
What is our (Harmony) goal?
In terms of these definitions, ideally, I suppose we want that Harmony is
2-way source compatible with the conformant J2SE API implementation (RI API)
to make sure that any application compiled with RI API can be compiled with
Harmony and vice versa (as well as linked, that is guaranteed by the
"Observation #1").
* Automation: what does JAPI check? (http://www.kaffe.org/~stuart/japi/)
Being run in two ways (for example, RI vs Harmony and Harmony vs RI) JAPI
checks 2-way binary compatibility for both 1.4 and 1.5 language-written
APIs.
It compares method, class signatures in two sets of API binaries and, being
run in two ways, checks the following:
---
Checks | JAPI
---
Classes: modifiers (access+abstract) | +
Classes: add/remove super classes| +/+
Classes: add/remove super interfaces | +/+
Classes: order of super class hierarchy | -
Fields: modifiers (access+final) | +
Fields: change value for constant| +
Fields: change static/transient | +/-
Fields: add/remove | +/+
Methods: modifiers(access+abstract+final)| +
Methods: change static/throws clause | +/+
Methods: add/remove | +/+
Constructors: modifiers(access) | +
Constructors: add/remove | +/+
Interfaces: modifiers| +
Interfaces: add fields/methods | +/+
Interfaces: remove fields/methods| +/+
---
So, talking about 1.4, two runs of JAPI - Harmony vs RI and RI vs Harmony
and small JAPI update (check that it is illegal to re-order class
inheritance, actually, it is checked
Re: [classlib] How to test serialization? (was: [classlib] Tests for serialization – which package, name?)
Stepan.
Let me answer you shortly: yes, my main concern is about an assetion step.
Just because I saw too many classes without specified serialization
form, without equals() and so on. Actually, I suppose that is the
entire graphical framework (awt + Swing) which is definitely more then
5% :-). I didn't deep investigations of course, but suppose that the
simple assertion approach would not work there. Just because it will
require to compare specific fields rather than call assertEquals().
About third scenario with IOException.
If IOException is the only possible reaction for incorrect form then
you are right: we don't need any specific checks.
--
Anton Avtamonov,
Intel Middleware Products Division
On 5/2/06, Stepan Mishura <[EMAIL PROTECTED]> wrote:
On 5/2/06, Anton Avtamonov wrote:
>
> On 5/2/06, Stepan Mishura wrote:
> > Mikhail,
> >
> > You are right - I think I asked not proper question. The base issue is:
> how
> > we are going to test serialization and what support from testing
> framework
> > is required? So far we have two serialization frameworks. Roughly, the
> first
> > framework provides utility class with set of static methods and the
> second
> > one provides super class to be extended.
> >
> > Let's understand what kind of serialization tests are required.
> > 1) Compatibility: testing scenario - serialize a number of a class'
> objects
> > on RI to get a set of golden files, create test to verify that
> > deserialization of golden files produces expected objects on Harmony
> > implementation. I think that everybody agree that this scenario is
> required
> > for every serializable class.
>
> Agree. The only exception is those cases when serialization form is
> not documented and cannot be implemented as in RI.
>
> >
> > 2) Self testing: testing scenario is to verify that an object can be
> > serialized/deserialized smoothly on Harmony implementation. Again this
> > scenario is also required for every serializable class.
>
> Agree.
>
> >
> > 3) Error: testing scenario is to check that deserialization of corrupted
> > serial form results in IOException, for example, if a class has fields
> > startDate and endDate then class implementation should verify that
> startDate
> > < endDate after deserialization. This scenario is not required for every
> > class.
>
> Yes. This requires both corrupted ser forms and assertion customization.
Sorry, I didn't catch - what assertion customization is required in case of
IOException?
>
> > Are there any others testing scenarios?
> >
> > I think that this is obvious that 1 and 2 scenarios need support from
> > testing framework. Let's review what support we currently have:
> > --- compatibility testing scenario:
> > If you use the first framework then you have explicitly add to each test
> for
> > serializable class a separate method and use utility methods to perform
> > testing, for example,
> > public void serializationCompatibility() {
> >SerializationTester.assertCompabilityEquals(new MyClass(), "
> > MyClassFile.ser");
> > }
> >
> > In case of the second framework a test inherits method testGolden() that
> > does standart testing routine: for each object returned by getData()
> method
> > it finds corresponding golden file, deserializes it and compares with
> the
> > object.
>
> You forgot to mention the comparison method which may have to be
> overriden as well in case:
> - RI serialzaition differ
How many such cases? I expect that there should be no more then 3-5% of
overall amount of serializable classes. Should we base serialization
testing framework design on such rare cases? I think no. Also IMHO that such
cases may be resolved by overriding testGolden() method and putting all
specific to this method.
- you need to check the state of transient fields
Most of them are private, right? So you will check them via public API?
- equals() method is not defined for the type or not covers all the
> fields. In this case you have to provide 'manual' comparison (very
> often case, IMHO)
IMHO this is the right approach to have separate comparision method that is
differ from other assert methods to compare object in case of
serialization/deserialization testing. So if you have to perform 'manual'
comparison in any case then it would be better to do it in separate
and standartized assert method. IMHO, assertDeserialized is a proper name
for such method. Also this is very often case for Exception classes so we
can generalize this case in super class too.
> >
> > --- self testing scenario:
> > Similar to compatibility scenario
Re: [classlib] How to test serialization? (was: [classlib] Tests for serialization – which package, name?)
On 5/2/06, Stepan Mishura <[EMAIL PROTECTED]> wrote:
Mikhail,
You are right - I think I asked not proper question. The base issue is: how
we are going to test serialization and what support from testing framework
is required? So far we have two serialization frameworks. Roughly, the first
framework provides utility class with set of static methods and the second
one provides super class to be extended.
Let's understand what kind of serialization tests are required.
1) Compatibility: testing scenario - serialize a number of a class' objects
on RI to get a set of golden files, create test to verify that
deserialization of golden files produces expected objects on Harmony
implementation. I think that everybody agree that this scenario is required
for every serializable class.
Agree. The only exception is those cases when serialization form is
not documented and cannot be implemented as in RI.
2) Self testing: testing scenario is to verify that an object can be
serialized/deserialized smoothly on Harmony implementation. Again this
scenario is also required for every serializable class.
Agree.
3) Error: testing scenario is to check that deserialization of corrupted
serial form results in IOException, for example, if a class has fields
startDate and endDate then class implementation should verify that startDate
< endDate after deserialization. This scenario is not required for every
class.
Yes. This requires both corrupted ser forms and assertion customization.
Are there any others testing scenarios?
I think that this is obvious that 1 and 2 scenarios need support from
testing framework. Let's review what support we currently have:
--- compatibility testing scenario:
If you use the first framework then you have explicitly add to each test for
serializable class a separate method and use utility methods to perform
testing, for example,
public void serializationCompatibility() {
SerializationTester.assertCompabilityEquals(new MyClass(), "
MyClassFile.ser");
}
In case of the second framework a test inherits method testGolden() that
does standart testing routine: for each object returned by getData() method
it finds corresponding golden file, deserializes it and compares with the
object.
You forgot to mention the comparison method which may have to be
overriden as well in case:
- RI serialzaition differ
- you need to check the state of transient fields
- equals() method is not defined for the type or not covers all the
fields. In this case you have to provide 'manual' comparison (very
often case, IMHO)
--- self testing scenario:
Similar to compatibility scenario: using the first framework you have
explicitly add a separate testing method:
public void testSerialization() {
assertTrue(SerializationTester.assertEquals(new SomeSerializable()));
}
In case of the second framework a test inherits testSelf() does the
following testing routine: for each object returned by getData() method it
serializes/deserializes the object and compares with the initial object.
Again, you have to provide comparison customization. Besides, it may
differ from comparison for the golden form. So, to cover everything
you have to define two comparison methods in your framework: for
golden comparison and for self-comparison.
To summarize: for the first framework it is required to add explicitly at
least two testing methods to each test.
Yes. And allows to do all the particular asserions (fields comparison)
right in the test. At the other hand, if the comparison is 'default',
you just need assertEquals().
The second framework uses
inheritance mechanism so two standart testing methods are inherited from
super class and you only have to implement getData() abstract method.
This is really convenient for the simple cases when you don't have to
customize the assertion step.
IMHO, as far as it is possible to unify serialization testing I think that
inheritance appoach makes sense - two standart testing methods, less
copied/pasted code that leads to more maintainable tests.
As I said before, second approach can result in less code since some
TestCases will just override one-two methods. However I disagree about
maintanability - the inheritance approach is much less flexible (see
above).
--
Anton Avtamonov,
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]
Re: [classlib] Tests for serialization – which package, name?
Stepan, I see everyone agree that we have to use the same approach accross the modules, but have no agreement on the particular test layout approach. May be you should initiate voting to choose the layout approach? Just to decide either to have tests in separate packages, separate TestCases or together with tests for other methods? Wishes, -- Anton Avtamonov, Intel Middleware Products Division On 4/28/06, Richard Liang <[EMAIL PROTECTED]> wrote: > Stepan Mishura wrote: > > On 4/28/06, Anton Avtamonov wrote: > > > >> On 4/28/06, Stepan Mishura wrote: > >> > >>> On 4/28/06, Anton Avtamonov wrote: > >>> > >>>> On 4/28/06, Stepan Mishura wrote: > >>>> > >>>>> On 4/27/06, Anton Avtamonov wrote: > >>>>> > >>>> > >>>> > >>>> Which approach is better is very personal :-). I would ay that the > >>>> second one. It is more intention-revealing. Really, when you override > >>>> testDeserialized() you don't see how and where it is used. With > >>>> properly used delegation pattern the tests would be: > >>>> > >>> Anton, when you override setUp() and tearDown() methods you also don't > >>> > >> see > >> > >>> how and where they are used. Do you use them or copy/paste > >>> > >> setUp/tearDown > >> > >>> code to every testing method? > >>> > >> That's why setUp() should do something very common for all the tests > >> in the TestCase. All "test specific" customizations go to test > >> methods. > >> > >> Actually, no reasons to argue about minor design specifics: all of > >> them work. What to prefer is very individual as I said. I don't expect > >> consensus here :-). > >> > > > > > > A lot of copy/pased tests. > > > > I use delegation when possible just because of better flexibility. If > > > >> we want to discuss design and Design Patterns aspects (especially how > >> and where inheritance or delegation should be used) we can create a > >> separate thread :-). > >> > >> The idea is that both separating and mixing of the serialization tests > >> can be done. The original question is: what do we want. Definitely, > >> both approaches can be implemented. > >> > > > > > > Yes, it is possible to implement any number of approaches - luni module will > > use one approach, security module will use another approach, beans will use > > the third one. But it would be better to select one approache and follow it > > to make development/support easier and simple. > > > > > I strongly recommend that all modules use the same approach. ;-) > > Thanks, > > Stepan Mishura > > > > -- > > Terms of use : http://incubator.apache.org/harmony/mailing.html > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > -- > Richard Liang > China Software Development Lab, IBM > > > > - > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - 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 for serialization – which package, name?
On 4/28/06, Stepan Mishura <[EMAIL PROTECTED]> wrote: > On 4/28/06, Anton Avtamonov wrote: > > > > On 4/28/06, Stepan Mishura wrote: > > > On 4/28/06, Anton Avtamonov wrote: > > > > > > > > On 4/28/06, Stepan Mishura wrote: > > > > > On 4/27/06, Anton Avtamonov wrote: > > > > > > > > > > > > Which approach is better is very personal :-). I would ay that the > > > > second one. It is more intention-revealing. Really, when you override > > > > testDeserialized() you don't see how and where it is used. With > > > > properly used delegation pattern the tests would be: > > > > > > > > > Anton, when you override setUp() and tearDown() methods you also don't > > see > > > how and where they are used. Do you use them or copy/paste > > setUp/tearDown > > > code to every testing method? > > > > That's why setUp() should do something very common for all the tests > > in the TestCase. All "test specific" customizations go to test > > methods. > > > > Actually, no reasons to argue about minor design specifics: all of > > them work. What to prefer is very individual as I said. I don't expect > > consensus here :-). > > > A lot of copy/pased tests. > > I use delegation when possible just because of better flexibility. If > > we want to discuss design and Design Patterns aspects (especially how > > and where inheritance or delegation should be used) we can create a > > separate thread :-). > > > > The idea is that both separating and mixing of the serialization tests > > can be done. The original question is: what do we want. Definitely, > > both approaches can be implemented. > > > Yes, it is possible to implement any number of approaches - luni module will > use one approach, security module will use another approach, beans will use > the third one. But it would be better to select one approache and follow it > to make development/support easier and simple. Absolutely agree. That's why I said that the core question is to decide what we want: to mix or separate (as you posted initially). Basing on the taken approach we can figure out the best design. -- Anton Avtamonov, 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]
Re: [classlib] Tests for serialization – which package, name?
On 4/28/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote: > 2006/4/28, Anton Avtamonov <[EMAIL PROTECTED]>: > > On 4/28/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote: > > > 2006/4/27, Anton Avtamonov <[EMAIL PROTECTED]>: > > > > On 4/27/06, Tim Ellison <[EMAIL PROTECTED]> wrote: > > > > > I say leave them mixed. We are no more likely to want to run > > > > > serialization tests separately than we are locking tests etc. and > > > > > trying > > > > > to layout the tests on disk to represent all the different metadata > > > > > about each test case is not going to work. > > > > > > > > +1. usually we have test layout like: one class - one TestCase. I > > > > > > Sometimes we need different setUp and tearDown operations > > > for different tests against the same class. This is best to be handled as > > > multiple TestCases (or test classes in other words as TestCase can be > > > ambiguous) > > > > That's true. It happens quite often and has no correlation with some > > particular type of tests (like serialization testing). When you need > > to cover 50 methods of some class for instance, you can hardly expect > > that all the preparation required for one of them is really needed for > > others. I don't think that is a good reason to create separated test > > cases. I'd prefer to use the most essential and common instantiations > > in setUp() and provide further customization in each particular test. > > Some days ago I posted statistics about ~1% of tests that run 80% of time. > Most of these tests do exactly what you describe here - in the test > methods they do what is supposed to be done in setUp Sorry Mikhail. I didn't catch. setUp() is called before each test call. Therefore setUp() which performs some "universal" initialization definitely takes much time than setUp() doing very essential things and allowing each test method to perform specific settings if it is required. Could you explain please how more time-consuming approach (IMHO) can be quicker? -- Anton Avtamonov, 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]
Re: [classlib] Tests for serialization – which package, name?
On 4/28/06, Stepan Mishura <[EMAIL PROTECTED]> wrote: > On 4/28/06, Anton Avtamonov wrote: > > > > On 4/28/06, Stepan Mishura wrote: > > > On 4/27/06, Anton Avtamonov wrote: > > > > > > Which approach is better is very personal :-). I would ay that the > > second one. It is more intention-revealing. Really, when you override > > testDeserialized() you don't see how and where it is used. With > > properly used delegation pattern the tests would be: > > > Anton, when you override setUp() and tearDown() methods you also don't see > how and where they are used. Do you use them or copy/paste setUp/tearDown > code to every testing method? That's why setUp() should do something very common for all the tests in the TestCase. All "test specific" customizations go to test methods. Actually, no reasons to argue about minor design specifics: all of them work. What to prefer is very individual as I said. I don't expect consensus here :-). I use delegation when possible just because of better flexibility. If we want to discuss design and Design Patterns aspects (especially how and where inheritance or delegation should be used) we can create a separate thread :-). The idea is that both separating and mixing of the serialization tests can be done. The original question is: what do we want. Definitely, both approaches can be implemented. -- Anton Avtamonov, 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]
Re: [classlib] Tests for serialization – which package, name?
On 4/28/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote: > 2006/4/27, Anton Avtamonov <[EMAIL PROTECTED]>: > > On 4/27/06, Tim Ellison <[EMAIL PROTECTED]> wrote: > > > I say leave them mixed. We are no more likely to want to run > > > serialization tests separately than we are locking tests etc. and trying > > > to layout the tests on disk to represent all the different metadata > > > about each test case is not going to work. > > > > +1. usually we have test layout like: one class - one TestCase. I > > Sometimes we need different setUp and tearDown operations > for different tests against the same class. This is best to be handled as > multiple TestCases (or test classes in other words as TestCase can be > ambiguous) That's true. It happens quite often and has no correlation with some particular type of tests (like serialization testing). When you need to cover 50 methods of some class for instance, you can hardly expect that all the preparation required for one of them is really needed for others. I don't think that is a good reason to create separated test cases. I'd prefer to use the most essential and common instantiations in setUp() and provide further customization in each particular test. I expected that is common approach... IMHO the reason to introduce additinal TestCases can be when one need to test something really 'separated'. Something, which requires absolutely different setUp() and may even override runBare() (to run tests in the another thread, etc). For instance, it may be nesessary for multi-threading testing. Wishes, -- Anton Avtamonov, 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]
Re: [classlib] Tests for serialization – which package, name?
On 4/28/06, Stepan Mishura <[EMAIL PROTECTED]> wrote:
> On 4/27/06, Anton Avtamonov wrote:
>
> > On 4/27/06, Tim Ellison wrote:
> > > I say leave them mixed. We are no more likely to want to run
> > > serialization tests separately than we are locking tests etc. and trying
> > > to layout the tests on disk to represent all the different metadata
> > > about each test case is not going to work.
> >
> > +1. usually we have test layout like: one class - one TestCase. I
> > don't see big reason to support several layouts simultaneously
> > (class-based, serialization-based, etc.)
>
>
> Agree, "one class - one TestCase" it's a good formula in general.
> But I'd prefer separate tests to verify standalone functionality (BTW, there
> a separate spec. for serialization!).
Well, the spec describes how and which private fields/methods can be
defined to handle serialization, right? So, to test serialization spec
we should use special tests which cover serialization engine itself.
As I told already that is not a case for object serialization testing
which just ensure that object is properly restored.
> Separating makes possible to unify
> testing approach that in turn leads to more simple and effective tests, for
> example, which tests looks better?
>
> public class SerMyTest extends SerializationTest {
>protected Object[] getData() {
>return new Object[]{
>new My(param1, param2, param3),
> new My(param4, param5, param6),
>new My(param7, param8, param9),
>};
>}
>
>protected void assertDeserialized(Object oref, Object otest) {
>//override to provide specific comparison
>}
> }
>
> public class MyTest extends TestCase {
>
>public void setUp() throws Exception {
>// sophisticated set up that unrelated to serialization at all !!!
>}
> public void tearDown() throws Exception {
>// sophisticated tear down that unrelated to serialization at all
> !!!
>}
>
> public void testSerialization1(){
>ObjectInputStream in = new
> ObjectInputStream(getClass().getResourceAsStream(
>"test1.ser"));
>My my = (My) in.readObject();
>assertEquals(new My(param1, param2, param3), my);
> }
>
> public void testSomethingUnrelatedToSerialization() {
> }
>
> public void testSerialization2(){
>ObjectInputStream in = new
> ObjectInputStream(getClass().getResourceAsStream(
>"test2.ser"));
>My my = (My) in.readObject();
>assertEquals(new My(param4, param5, param6), my);
> }
>
> public void testCtor() {
> }
>
> public void testSerialization3(){
>ObjectInputStream in = new
> ObjectInputStream(getClass().getResourceAsStream(
>"test3.ser"));
>My my = (My) in.readObject();
>assertEquals(new My(param7, param8, param9), my);
> }
> }
Which approach is better is very personal :-). I would ay that the
second one. It is more intention-revealing. Really, when you override
testDeserialized() you don't see how and where it is used. With
properly used delegation pattern the tests would be:
testSelfSerialization() {
Object deserialized = SerializationTest.serializeDeserialize(original);
assertEquals(original, deserialized);
}
In case deserialization assertion for the particular object is not
just assertEquals() it will be well-shown.
Similarly to test against stored serialization form (golden file).
Wishes,
--
Anton Avtamonov,
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]
Re: [classlib] Tests for serialization – which package, name?
On 4/28/06, Stepan Mishura <[EMAIL PROTECTED]> wrote: > So if you fix bug in java.io.ObjectInputStream then you have to run all > tests for all modules because tests for serialization mixed with other > tests. Are you OK with this? Why? I hope tests for ObjectInputStream provide enough coverage to check its own functionality. Serialization tests IMHO cover not ObjectInputStream behavior, but serialization of those particular classes. Of course it is posiible to break serialization by changing ObjectInputStream, however that is of low correlation (we have discussed the concept of dependency matrix already). With your approach each change in String requires almost all tests to re-launch (since almost all classes use Strings). Do you think we have to separate all the tests which use Strings? :-) -- Anton Avtamonov, 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]
Re: [classlib] Tests for serialization – which package, name?
On 4/27/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote: > As I understand most of them now separated. > > We may either 'leave them' or 'mixed' , not both :) Yeah, quick search gave 93 files for "extends SerializationTest" search mask :-) -- Anton Avtamonov, 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]
Re: [classlib] Tests for serialization – which package, name?
On 4/27/06, Anton Avtamonov <[EMAIL PROTECTED]> wrote: > On 4/27/06, Tim Ellison <[EMAIL PROTECTED]> wrote: > > I say leave them mixed. We are no more likely to want to run > > serialization tests separately than we are locking tests etc. and trying > > to layout the tests on disk to represent all the different metadata > > about each test case is not going to work. > > +1. usually we have test layout like: one class - one TestCase. I > don't see big reason to support several layouts simultaneously > (class-based, serialization-based, etc.) Just to be clear: I would prefer "option 3" from the original Stepan's post: to have serialization test methods inside TestCase for the class. -- Anton Avtamonov, 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]
Re: [classlib] Tests for serialization – which package, name?
On 4/27/06, Tim Ellison <[EMAIL PROTECTED]> wrote: > I say leave them mixed. We are no more likely to want to run > serialization tests separately than we are locking tests etc. and trying > to layout the tests on disk to represent all the different metadata > about each test case is not going to work. +1. usually we have test layout like: one class - one TestCase. I don't see big reason to support several layouts simultaneously (class-based, serialization-based, etc.) -- Anton Avtamonov, 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]
Re: [classlib] Tests for serialization – which package, name?
On 4/27/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote: > As far as most of serialization tests extend SerializationTest then > having serialization test cases included into a regular unit tests > would cause that ALL the tests will extend SerializationTest that is > not very good. Well, it is easy to allow serialization tests to be in the same TestCase with others. We just need to convert the existing schema with inheritance to the delegation pattern. Or combine both approaches by adding public static method to the SerializationTest which gets an Object and returns an Object which were serialized and deserialized (similar to testSelf() but without assertion). And public static accessor to golden files of course. May be it even make the tests more obvious: Object deserialized = SerializationTest.serializeAndDeserialize(original); assertEquals(original, deserialzied); I don't think that having ser tests separated is a bad idea, however having an additinal test file with one-two methods only for each api class looks like a bit 'expensive' approach. > > Thanks, > Mikhail > > 2006/4/27, Stepan Mishura <[EMAIL PROTECTED]>: > > Hi, > > > > I'd like to discuss naming conventions for serialization tests - does it > > make sense to separate serialization tests from unit tests? > > > > For example, in module security tests for serialization were placed into > > separate packages: > > java.security.serialization > > java.security.cert.serialization > > java.security.spec.serialization > > > > Also it is possible to put tests in the same package but name them in > > different ways, for example, > > SomeClassTest.java – unit test for SomeClass > > SerSomeClassTest.java – serialization test for SomeClass > > > > Or we won't separate serialization tests from unit tests and will test > > serialization by adding corresponding methods to unit test, for example, > > public void testSerialization1() > > public void testSerialization2() > > public void testSerialization3() > > public void testSerializationCorrupted() > > public void testSerializationIllegalValues() > > > > Thoughts? > > > > Thanks, > > Stepan Mishura > > 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] > > -- Anton Avtamonov, 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]
Re: [classlib] Testing
On 4/26/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote: > Seems like implemantation-specific tests for java.security package do not > fit well into the proposed solution > > I think we do not have to stick to requirement about > organization name in the tests: we already have tests in package java.* > why don't have package tests.*? +1. The smaller and obvious package names we have the easier to navigate. "tests.*" looks very obvious and small. Wishes, -- Anton Avtamonov, 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]
Re: [doc] Compatibility guidelines
Hi Tim, May I ask for minor clarification just to make sure (looks like it is not fully covered here). In case the spec definitely says something which is not true for RI we should: - base on spec - base on RI - discuss in the mailing list I think that is the very core question which we cannot agree on. On 4/26/06, Tim Ellison <[EMAIL PROTECTED]> wrote: > What I'm trying to convey is: > > 1) We should be doing spec-driven development, not development based on > probing the behavior of any particular implementation of the spec (even > the RI). > > I believe this is in best keeping with the spirit of Sun's intent for > independent implementations of Java. > > 2) Since we know from experience that the spec leaves many questions > unanswered, we should use the RI of the spec to resolve those questions > using the public published interfaces to the RI. Typically this will > mean running a test, written to public APIs, and observing the result. > > 3) Compatibility with existing implementations is very important to us, > therefore we will run our tests written based on the spec against both > our implementation and the RI (and possibly other implementations) to > ensure we behave in the established way. > > Where there are anomalies or inconsistencies in the way the spec > describes how things should work, how they work in the RI, or how they > work in accepted implementations, then we discuss, decide, and document > the chosen solution for Harmony. > > Regards, > Tim > > > Anton Avtamonov wrote: > > On 4/25/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote: > >> > >> Anton Avtamonov wrote: > >>> On 4/25/06, Tim Ellison <[EMAIL PROTECTED]> wrote: > >>>> Anton Avtamonov wrote: > >>>>> Tim, that is excellent! Thank you. > >>>>> > >>>>> I have couple of minor questions: > >>>>> > >>>>> Am I right with interpretation that the primary "source" is the spec > >>>>> rather than RI behavior? If the spec is consistent and logical, but > >>>>> contradicts to the RI behavior we are basing on spec? I'm asking just > >>>>> because that caused lots of debates last time and I want to make sure > >>>>> everyone agreed with this statement now. > >>>> That's what I thought we agreed. If the guide does not make that clear > >>>> then I am happy to clarify. > >>> Guidelines clearly mentioned that. I could not recall if everyone was > >>> agree or not :-). > >>> As I remember there were lots of people who proposed to base on RI > >>> behavior only (to be as much comatible as possible). > >>> > >>> Personally I'm completely agree with guidelines approach. > >> The problem is that in the real world, we're going to have trouble > >> defending why everyone else is wrong, and we are correct. > >> > >> This is why I'd like to discuss and be able to go w/ RI behavior, and in > >> either case, WRITE EVERYTHING DOWN so that for diversions from the RI we > >> can make it easy for users to see why their code breaks on Harmony when > >> it runs everywhere else and for diversions from spec, we can eventually > >> come back after some time when we have achieved World Dominance(tm) and > >> fix them... > > > > I see I was right that we didn't have an agreement :-) > > > > Geir, I completely understood you point and even agree with you. My > > idea (and I believe Tim's guidelines support it) was to avoid copying > > of definite RI bugs. Just because I believe that there are no (or > > almost no) applications which are based on something which is > > definitely bug, not feature. > > > > However your proposal just to be as good as RI does for now, 'mark' > > all problems and revise them later definitely makes sense. > > > > Let's say I'm neutral and wait for others opinions. > > > > I'm sure that this is very key question and we have to achieve an > > agreement here. > > > > Wishes, > > -- > > Anton Avtamonov, > > 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] > > > > > > -- > > 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] > > -- Anton Avtamonov, 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]
Re: [doc] Compatibility guidelines
On 4/25/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote: > Anton, > > look at "Do we want to be bug compatible?" thread > > everybody agreed to the scheme: > > 1. we should comply with spec > 2. if RI is contradict with spec, and RI is not logical(sometimes it is > very obvious, you know what I mean), we comply with spec; else, we > discuss it case by case. > 3. if spec is not so clear, we should comply with RI > 4. if some application failing on that different behavior, we > discuss it case by case > 5. Log every difference from either the spec or the RI in JIRA. Mikhail, I suppose that Tim's guidelines are generally about the same. Am I wrong? And as you can see it is not something which everyone agreed on: at least Geir's position is different. Or I got him wrong? -- Anton Avtamonov, 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]
Re: [doc] Compatibility guidelines
On 4/25/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote: > > > Anton Avtamonov wrote: > > On 4/25/06, Tim Ellison <[EMAIL PROTECTED]> wrote: > >> Anton Avtamonov wrote: > >>> Tim, that is excellent! Thank you. > >>> > >>> I have couple of minor questions: > >>> > >>> Am I right with interpretation that the primary "source" is the spec > >>> rather than RI behavior? If the spec is consistent and logical, but > >>> contradicts to the RI behavior we are basing on spec? I'm asking just > >>> because that caused lots of debates last time and I want to make sure > >>> everyone agreed with this statement now. > >> That's what I thought we agreed. If the guide does not make that clear > >> then I am happy to clarify. > > > > Guidelines clearly mentioned that. I could not recall if everyone was > > agree or not :-). > > As I remember there were lots of people who proposed to base on RI > > behavior only (to be as much comatible as possible). > > > > Personally I'm completely agree with guidelines approach. > > The problem is that in the real world, we're going to have trouble > defending why everyone else is wrong, and we are correct. > > This is why I'd like to discuss and be able to go w/ RI behavior, and in > either case, WRITE EVERYTHING DOWN so that for diversions from the RI we > can make it easy for users to see why their code breaks on Harmony when > it runs everywhere else and for diversions from spec, we can eventually > come back after some time when we have achieved World Dominance(tm) and > fix them... I see I was right that we didn't have an agreement :-) Geir, I completely understood you point and even agree with you. My idea (and I believe Tim's guidelines support it) was to avoid copying of definite RI bugs. Just because I believe that there are no (or almost no) applications which are based on something which is definitely bug, not feature. However your proposal just to be as good as RI does for now, 'mark' all problems and revise them later definitely makes sense. Let's say I'm neutral and wait for others opinions. I'm sure that this is very key question and we have to achieve an agreement here. Wishes, -- Anton Avtamonov, 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]
Re: [classlib] matching RI exceptions -- are we required to have this type of compatibility?
On 4/25/06, Jimmy, Jing Lv <[EMAIL PROTECTED]> wrote: > For the example 1) I mean the spec usually merge several exceptions into > one parent exception. In this situation, commonly RI throws child > exception itself, although it is hard to tell what RI exactly throw in > some special situation. > And I think we are not "improving" the spec if we throw child > exceptions, it is just convention or something writing "throws > IOException" instead of writing "throws connectionException, > UnknownHostException". We do follow spec if we throw child exception. > > > The idea behind the question is: why not just copy RI in this case > > (conforming Tim's guidelines)? > > > > Yes,I firmly agree with Tim's guidelines. We should first follow spec > and then RI. In this case, we still follow the spec, right? :) Absolutely! The question was: why we decided to throw sub-classing exceptions. If the answer is: "because RI does" I completely support such decision (which completely complies Tim's guidelines). -- Anton Avtamonov, 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]
Re: [classlib] resource files for testing serialization - .dat or .ser?
On 4/25/06, Richard Liang <[EMAIL PROTECTED]> wrote: > Tim Ellison wrote: > > ".ser" is commonly used for Java serialized form > > > > http://filext.com/detaillist.php?extdetail=SER > > > > > So we will rename the 296 files? wow ;-) If we will be affraid to beautify different contributions to be in the single style we will have something very ugly and "consisting of different patches" rather than a product. IMHO, it is fine to rename :-) Wishes, -- Anton Avtamonov, 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]
Re: [classlib] matching RI exceptions -- are we required to have this type of compatibility?
On 4/25/06, Dmitry M. Kononov <[EMAIL PROTECTED]> wrote:
> On 4/25/06, Tim Ellison <[EMAIL PROTECTED]> wrote:
> > Jimmy, Jing Lv wrote:
> > > I agree.
> > > But there are at least two exceptional situation:
> > > 1) several exceptions throws from one method, which extend one parent
> > > class, e.g. ConnectionException and UnknownHostException, javadoc writes
> > > "throws IOException" rather than "throws
> > > ConnectionException,UnknownHostException". And in implementation, we
> > > shall throw them out directly instead of
> > > try{...
> > > }catch(UnknownHostException e){
> > > throw new IOException();
> > > }
> > > catch(ConnectionException e){
> > > throw new IOException();
> > > }
> > > right? :)
> >
> > +1, and other instances where super-types or super-interfaces declare
> > compatible throws clauses that are implemented in subclasses that throw
> > more specific subtypes. I do not agree that we should be bound to throw
> > and exception of the identical type as the declaration.
>
> If we want to follow the spec and if we want to restrain ourself from
> "improving" the spec, I think we really need to throw IOException. If
> this exception can be caused by different ways we apparently have to
> throw IOException with an appropriate cause.
>From the general perspective, in the example above re-throwing
IOException looks quite ugly. Besides, it hides some important
information (since Java uses exception sub-classing to represent the
particular type of problem). However we are not free with design, I
think. Could someone please remind me an idea: for the example above
do we mean that the spec states IOException and RI throws exactly
IOException (I traversed the thread, but still not sure what was
meant)?
The idea behind the question is: why not just copy RI in this case
(conforming Tim's guidelines)?
--
Anton Avtamonov,
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]
Re: [doc] Compatibility guidelines
On 4/25/06, Tim Ellison <[EMAIL PROTECTED]> wrote: > Anton Avtamonov wrote: > > Tim, that is excellent! Thank you. > > > > I have couple of minor questions: > > > > Am I right with interpretation that the primary "source" is the spec > > rather than RI behavior? If the spec is consistent and logical, but > > contradicts to the RI behavior we are basing on spec? I'm asking just > > because that caused lots of debates last time and I want to make sure > > everyone agreed with this statement now. > > That's what I thought we agreed. If the guide does not make that clear > then I am happy to clarify. Guidelines clearly mentioned that. I could not recall if everyone was agree or not :-). As I remember there were lots of people who proposed to base on RI behavior only (to be as much comatible as possible). Personally I'm completely agree with guidelines approach. > > > Another minor comment regarding to the serialization compatibility: > > What if serialization form is not specified and the spec states that > > serialization form will not be compatible with future releases? Does > > it mean we want to copy the existing serialization form? Or we are > > going to define our own? Should it be reflected in the guidelines? > > I suggest that we copy the current RI form (if we can deduce it > honestly) to get better interoperability. +1. -- Anton Avtamonov, 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]
Re: [doc] Compatibility guidelines
Tim, that is excellent! Thank you. I have couple of minor questions: Am I right with interpretation that the primary "source" is the spec rather than RI behavior? If the spec is consistent and logical, but contradicts to the RI behavior we are basing on spec? I'm asking just because that caused lots of debates last time and I want to make sure everyone agreed with this statement now. Another minor comment regarding to the serialization compatibility: What if serialization form is not specified and the spec states that serialization form will not be compatible with future releases? Does it mean we want to copy the existing serialization form? Or we are going to define our own? Should it be reflected in the guidelines? Wishes, -- Anton Avtamonov, Intel Middleware Products Division On 4/24/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote: > nice. thanks. > > Tim Ellison wrote: > > I've tried to capture in a webpage the compatibility guidelines that we > > have agreed over the last few weeks. > > > > The page is here: > > http://incubator.apache.org/harmony/subcomponents/classlibrary/compat.html > > > > I'm sure I'll have forgotten something, so additions / corrections / > > etc. are welcome. > > > > Regards, > > Tim > > > > - > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r396013 - in /incubator/harmony/enhanced/classlib/trunk/modules/luni/src: main/java/java/net/Inet6Address.java main/java/java/net/InetAddress.java test/java/tests/api/java/net/Inet6Add
On 4/24/06, Andrew Zhang <[EMAIL PROTECTED]> wrote:
> Stepan Mishura wrote:
> > Hi,
> >
> > I thought that we agreed on utilizing JUnit's exception handling (see [1]).
> > So the next code from added unit test doesn't follow this convention. Also
> > why it checks the same code twice?
> >
> > try {
> > Inet6Address.getByAddress("123", addr2, 3);
> > } catch (UnknownHostException e) {
> > fail("no exception should be thrown");
> > }
> > try {
> > Inet6Address.getByAddress("123", addr2, 3);
> > } catch (UnknownHostException e) {
> > fail("no exception should be thrown");
> > }
>
> Sorry, it's a mistake. It's assumed use "-1" in the second case.
> I'll upload a patch right away.
And as we discussed try/catch is not required here, right?
--
Anton Avtamonov,
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]
Re: [classlib] matching RI exceptions -- are we required to have this type of compatibility?
On 4/24/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote: > > Yeah, in case RI operates with classes not from public API I would > > propose to base on spec. Or use the nearest class from public API if > > spec doesn't work for some reasons. > > Actually, spec even contains sometimes references to the classes from > > not public API... > > Really? You mean that the spec is not transitively close? > Can you give an example? Of course. I saw that many times. Just the first I can recall: MetalScrollBarUI.bumps Field bumps is of type which is not public api: the reference is not hyperlinked. If you want I can find some other cases: I definitely saw more than one :-) Wishes -- Anton Avtamonov, 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]
Re: [classlib] matching RI exceptions -- are we required to have this type of compatibility?
On 4/24/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote: > Look at HARMONY-387. > > Example: > 1) java.io.ByteArrayOutputStream.write(byte[] b , int off, int len): > Harmony throws ArrayIndexOutOfBoundsException when off<0 or/and len > <0, while RI throws IndexOutOfBoundsException. > Specification mentions neither ArrayIndexOutOfBoundsException nor > IndexOutOfBoundsException. > > > Actually ArrayIndexOutOfBoundsException is a sub class of > IndexOutOfBoundsException. > > So the statement "both Harmony and RI throw IndexOutOfBoundsException" is > true. > > But do we have to throw exactly those exceptions that are thrown by RI? I think so. If RI behavior is reasonable and doesn't contradict to the spec (as above) we should unconditionally copy RI behavior. Really, why do we need additional differences even though we absolutely sure that particular minor deviation would have no impact on client apps? > Can we throw > o.a.h.VMRisenNPE that extends NullPointerException? > > What if they throw kind of > sun.internal.SunFavoriteSubClassOfNullPointerException ? Yeah, in case RI operates with classes not from public API I would propose to base on spec. Or use the nearest class from public API if spec doesn't work for some reasons. Actually, spec even contains sometimes references to the classes from not public API... Wishes, -- Anton Avtamonov, 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]
Re: Internationalized messages
On 4/21/06, Tim Ellison <[EMAIL PROTECTED]> wrote: > Anton Avtamonov wrote: > > On 4/21/06, Tim Ellison <[EMAIL PROTECTED]> wrote: > > >> I'd prefer the module name '.', i.e. beans.1, beans.2, and so on. > > > > I'm not sure. Module name IMHO doesn't make too much sense since it is > > already 'coded' into accessor location and class location. I would > > prefer . like > > RandomAccessFile.file_is_closed > > or something similar which keeps the idea of what the message is about. > > > > That requires a bit more efforts but makes the code understandable. > > I'd be inclined to agree, but using long key String turned out to be one > of the top Eclipse performance bloopers [1] so we actually need to keep > them short. Ok, I cautch it. But I didn't propose long keys, just intention-revealing. They should be definitely no longer then usual fields/methods names. Besides, I suppose classlib is ususally quite silent :-). The majority of messages we need are exceptions, right? I remember our investigation - exception itself (trace calculation) takes too much; String impact will be eliminated :-) Wishes, -- Anton Avtamonov, 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]
Re: Internationalized messages
On 4/21/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote: > > I'm not sure. Module name IMHO doesn't make too much sense since it is > > already 'coded' into accessor location and class location. I would > > prefer . like > > RandomAccessFile.file_is_closed > > or something similar which keeps the idea of what the message is about. > > That would create more duplication like > > File.file_is_closed > RandomAccessFile.file_is_closed Agree. That's why I said 'something similar' :-) For this particular case I would keep just File.file_is_closed and used it everywhere. Prefix, IMHO is required just to split functional areas within a module. It can be class name, but can also be some generalized 'functionality' name like Dialogs.ok_button The main idea I'm trying to express is that: - when looking into properties file it should be clear how (where) each key is used just from its name - when looking into the code should be clear the idea of the message behind the key. Wishes, -- Anton Avtamonov, 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]
Re: Internationalized messages
On 4/21/06, Stepan Mishura <[EMAIL PROTECTED]> wrote: > > > Creating and maintaining these (accessor/strings) is trivial in the > > > Eclipse string externalization tool. > > > > Right. > > > And what about developers that don't use Eclipse? They can create an accessor manually. Eclipse just helps to generate it, no more. Do you mean "how too keep them in the same format"? -- Anton Avtamonov, 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]
Re: Internationalized messages
On 4/21/06, Tim Ellison <[EMAIL PROTECTED]> wrote: > > Mikhail Loenko wrote: > > 2006/4/21, Tim Ellison <[EMAIL PROTECTED]>: > >> Mikhail Loenko wrote: > >>> Well, the reason is we did not discuss the topic here > >> Sure. What would you like to discuss? > > > > 1. Do we put all the messages into one file or per-module? > > I'd prefer one catalog per module now that we have the code split up. > The risk is that there will be large duplication of common messages, but > let's see, they should stand alone. Definitely. I think that keeping them serarately increases modularization. > If we do split them up then I guess it makes sense to put the accessor > class and properties files into org.apache.harmony..internal? +1 > Creating and maintaining these (accessor/strings) is trivial in the > Eclipse string externalization tool. Right. > > > 2. When I tried to internationalize it with Eclipse it suggested me > > keys looking > > different way (something like "RandomAccessFile.1"). So what are the keys > > that > > are liked by most of the people? > > I'd prefer the module name '.', i.e. beans.1, beans.2, and so on. I'm not sure. Module name IMHO doesn't make too much sense since it is already 'coded' into accessor location and class location. I would prefer . like RandomAccessFile.file_is_closed or something similar which keeps the idea of what the message is about. That requires a bit more efforts but makes the code understandable. Wishes, -- Anton Avtamonov, 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]
Re: Long,long testcase name...
On 4/19/06, Thorbjørn Ravn Andersen <[EMAIL PROTECTED]> wrote: > Anton Avtamonov skrev den 12-04-2006 15:44: > > > > However such approach doesn't work when you really have several > > same-named methods with different params. You have to test similar > > scenarios, but with different methods... > > > > In such a case, w0uld it be reasonable to append a > "_ScenarioServerIsOnFire" or similar to the testcase name? Why not? The only I would say "_ServerIsOnFire" :-) -- Anton Avtamonov, 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]
Re: svn commit: r394890 - in /incubator/harmony/enhanced/classlib/trunk/modules: applet/make/common/ archive/make/common/ auth/make/common/ awt/make/common/ beans/make/common/ crypto/make/common/ jndi
On 4/18/06, Stepan Mishura <[EMAIL PROTECTED]> wrote: > Mark, > > The update only adjusts build files to *initial* style (that is tabs-style). > > IMHO really doesn't matter how many spaces in one tab if you follow one > style in a file and don't mix tabs with spaces. Also I like > tab-style because I have opportunity to choose a number of spaces that more > suitable for my eyes. If everybody will agree to use only space-style then > OK - I'll fix tabs. Stepan, If it was a question I also vote for space-style. It guarantees same look in all editors. I used to 4-spaces indentation. -- Anton Avtamonov, 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]
Re: should strings in exceptions match the reference implementation?
On 4/18/06, Mark Hindess <[EMAIL PROTECTED]> wrote: > I thought my first message in this thread made this clear but obviously not. > > I'm not suggesting that code would care if the exception messages are > identical. I was suggesting that it is probably now quite common for > users to type error messages straight in to google. Therefore having > messages match those of existing implementations would help our users > find the cause of an exception. Yes, right. I saw several times like people did that and even did by myself for javac. If I remember we decided not to copy the mesages because it is *possibly* a legal isssue and maybe copyrightable. Is it possible to ask apache legal? Probably the answer will solve our problems :-). Wishes, -- Anton Avtamonov, 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]
Re: should strings in exceptions match the reference implementation?
I also agree. The only 'requirement' I would add is that it should be possible to do such mark-up on per-check basis rather than per-test_method or even per-test_class basic. Because each testMehtod() may have several checks only few of them will be harmony-dependent. -- Anton Avtamonov, Intel Middleware Products Division On 4/17/06, Andrew Zhang <[EMAIL PROTECTED]> wrote: > +1. Annotation is a good way to deliver such information. > > > > On 4/17/06, Paulex Yang <[EMAIL PROTECTED]> wrote: > > > > I consider the isHarmony() should be metadata, I have concerns to hard > > code in test cases. How about mark these test cases as "non-compatible" > > by annotation, by naming convention or more directly by some list, and > > use test script to handle them? > > > -- > > > Anton Avtamonov, > > > 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] > > > > > > > > > > > > > > > -- > > Paulex Yang > > China Software Development Lab > > IBM > > > > > > > > - > > Terms of use : http://incubator.apache.org/harmony/mailing.html > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > -- > Andrew Zhang > China Software Development Lab, IBM > > - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: should strings in exceptions match the reference implementation?
> Yes, and another problem is that it is hard to tell if the tests are
> currently running on Harmony or RI, even harder than to tell the platforms.
Well, actually it is quite simple :-). It is enough just to check
presence of some class which is specific for Harmony (something from
org.apache.harmony...)
> However I think Avtamonov's idea is professional, although a bit complex. :)
> After all, the tests, currently in Harmony, put all tests for one class in
> one testcase file and all tests for one method in one test method, that's why
> it seems write try{fail()}catch{//correct} is rather easy, right? :)
--
Anton Avtamonov,
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]
Re: should strings in exceptions match the reference implementation?
On 4/17/06, Andrew Zhang <[EMAIL PROTECTED]> wrote: > On 4/17/06, Anton Avtamonov <[EMAIL PROTECTED]> wrote: > > > > Well, not completely agree. I RI has BUG, I agree to have > > corresponding Harmony test failing. However do you think that > > different exception messges say is a good reason to have failures? I > > don't think so. Just a minor differemce which can be 'formally > > documented' by using isHarmony() is tests. > > > I agree with you that different exception messages are not failures. So in > my opnion, we'd better avoid such test cases. > If some exception messages are really very important to developers ( I don't > have any idea about such Exception classes), > I think RI should contain similiar information so that we can write some > test cases, which both RI and Harmony could pass, by verifying keywords > instead. > If "isHarmony()" is used, then what's the expected message? I don't think > there's a "Harmony exception message spec" :-) > People may argue which message is best or more meanfuling :) As I said already I also not sure if we really need those test cases. And I also would like to avoid them when possible. What I vote for is that if we still have to test such things (not only messages, maybe something else) we should not have failing tests on this. Besides, we decided to document "desired" deviations via JIRA. My point here is that all such deviations also should not fail on RI. Just because failure should indicate something was broken. No need to indicate this on 'known' places. For 'known' deviations we may also use isHarmony() add reference (in comment) to the corresponding JIRA issue. I proposed isHarmony() just because I don't know the better way to avoid failures and 'formally' document deviations. -- Anton Avtamonov, 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]
Re: should strings in exceptions match the reference implementation?
On 4/17/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote:
> Why it is that complicated?
>
> Why one have jump over utility methods in different classes or even folders to
> understand what a 5-line test does?
>
> testSomething() throw OtherException {
>try {
>ec.do_something_exceptional();
>fail("NullPointerException was not thrown!");
>} catch (NullPointerException e) {
>//expected
>}
> }
>
> Let's keep simple things simple
Actually, it is not complicated. Because in the 'client' code you will
have only small and intention-revealing checkes like:
testExceptionalCase(new NullPointerCase() {
public void exceptionalAction() throws Exception {
}
});
As I told that is well fits into OO conept and garantee you from not
loosing any checks. Besides, it avoid duplication since you write only
absolutely necessary code, not repeating
try {
...
fail(blah-blah-blah)
}
each time...
If you need to check a message you have just to mention it is the constructor...
It doesn't pretend to be the best choice. As I mantioned it was just
how I do that. If you don't find this approach convenient and
duplication-free don't use it :-).
Wishes,
--
Anton Avtamonov,
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]
Re: should strings in exceptions match the reference implementation?
On 4/17/06, Andrew Zhang <[EMAIL PROTECTED]> wrote: > Very sorry, there're some typing mistakes in last letter. Please ignore it. Exctually, I haven't noticed any :-). May be because I also do lots of them. I hope native-speakers will excuse us :-). Wishes, -- Anton Avtamonov, 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]
Re: should strings in exceptions match the reference implementation?
On 4/17/06, Andrew Zhang <[EMAIL PROTECTED]> wrote: > Hello, Anton, > > On 4/17/06, Anton Avtamonov <[EMAIL PROTECTED]> wrote: > > > > No, we don't need all those branches. Only the branch for Harmony. > > Only for those cases when we DO know that we have a deviation. > > IMHO, I prefer to have all tests passing on RI (which verify tests > > itself) and on Harmony (which verifies Harmony). > > > > > But there ARE some different behaviours between Harmony and RI. > How could our test case show or these differences if all are passed both on > RI and Harmony? > I think our test cases should show these differences instead of hiding them. > > Failures should > > indicate something wrong with tests or with Harmony code. There should > > be no other failures, I think. > > > Yes. So I think all test cases could pass on Harmony, but on RI :-) > Failures on RI mean RI has different understanding or behaviours compared to > Harmony criteria, or in other words, they're wrong behaviour according to > Harmony criteria. Well, not completely agree. I RI has BUG, I agree to have corresponding Harmony test failing. However do you think that different exception messges say is a good reason to have failures? I don't think so. Just a minor differemce which can be 'formally documented' by using isHarmony() is tests. Wishes, -- Anton Avtamonov, 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]
Re: should strings in exceptions match the reference implementation?
On 4/17/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote: > Sorry, Anton, I did not catch. > > Only one branch means "no branches, just one way" or does it mean > "two different ways (one normal way and one branch)"? > > If we have just one way, why isHarmony() method necessary? Mikhail, Formally two branches :-). One to test Harmony and another to skip the check. isHarmony() is needed to: - perform check when it is required, i.e. on Harmony - avoid test failure on other implementations. -- Anton Avtamonov, 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]
Re: should strings in exceptions match the reference implementation?
On 4/17/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote:
> Why we should test something other than Harmony?
>
> We might run our tests on different implemetations to
> see whether/how they differ from Harmony, but we do not need
> special branches in our tests like
>
> if( isHarmony() ) {
> assert(harmony behavior)
> } else if( is BEA ) {
> assert(BEA behav) {
> } else if( Classpath ) {
Hi Mikhail.
No, we don't need all those branches. Only the branch for Harmony.
Only for those cases when we DO know that we have a deviation.
IMHO, I prefer to have all tests passing on RI (which verify tests
itself) and on Harmony (which verifies Harmony). Failures should
indicate something wrong with tests or with Harmony code. There should
be no other failures, I think.
That is a bit similar to 'exclude list' we introduced: we don't want
to have failures when they are expected and predictable.
--
Anton Avtamonov,
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]
Re: should strings in exceptions match the reference implementation?
In addition, I want to share what I do when testing exceptions.
I created the following basic abstract class:
protected abstract class ExceptionalCase {
private Class clazz;
private String msg;
public abstract void exceptionalAction() throws Exception;
public ExceptionalCase() {
}
public ExceptionalCase(String msg, Class clazz) {
this.msg = msg;
this.clazz = clazz;
}
public Class expectedExceptionClass() {
return clazz;
}
public String expectedExceptionMessage() {
return msg;
}
}
and the following utility test method:
protected void testExceptionalCase(final ExceptionalCase ec) {
try {
ec.exceptionalAction();
fail("Exceptional case was not detected!");
} catch (final Exception e) {
if (ec.expectedExceptionClass() != null) {
if
(!ec.expectedExceptionClass().isAssignableFrom(e.getClass())) {
fail("Exception of wrong type " + e.getClass() + "
is produced!");
}
}
if (ec.expectedExceptionMessage() != null) {
assertEquals("Wrong exception message",
ec.expectedExceptionMessage(),
e.getMessage());
}
}
}
Besides, I created several 'concrete' ExceptionalCases like:
protected abstract class NullPointerCase extends ExceptionalCase {
public Class expectedExceptionClass() {
return NullPointerException.class;
}
}
So, every time when I want to test that "NPE and only NPE" is produced
I do the following:
testExceptionalCase(new NullPointerCase() {
public void exceptionalAction() throws Exception {
//some action which should produce NPE
}
});
It doesn't care about the message.
If I need to test some particular message as well as type of exception
I should either override expectedExceptionMessage() or use an
appropriate constructor to create ExceptionalCase like:
testExceptionalCase(new ExceptionalCase("expected message",
NullPointerException.class) {
public void exceptionalAction() throws Exception {
//some action which should produce NPE
}
});
I believe that is convenient and Object-Oriented approach.
Wishes,
--
Anton Avtamonov,
Intel Middleware Products Division
On 4/17/06, Anton Avtamonov <[EMAIL PROTECTED]> wrote:
> On 4/17/06, Mark Hindess <[EMAIL PROTECTED]> wrote:
> > So, the second issue, should we be checking for messages/descriptions
> > in exception
> > tests, even to match what Harmony throws? If we do then our api tests
> > wont pass on other implementations.
>
> Hi Mark,
> As I said already I don't see any huge reasons to check the messages
> (probably for not being empty only). However I suppose sometimes it
> could be necessary. I'm pretty sure we will face many cases when we
> need to deviate from RI (it was discussed already in other threads).
>
> What I propose is to use for tests some utility method like
> isHarmony(). It will act as a 'formal' indicator of all our
> deviations.
>
> For this particular situation is should be something like:
> if (TestUtilities.isHarmony()) {
>assertEquals("some message", e.getMessage())
> }
>
> What do you think?
>
> --
> Anton Avtamonov,
> 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]
Re: should strings in exceptions match the reference implementation?
On 4/17/06, Mark Hindess <[EMAIL PROTECTED]> wrote:
> So, the second issue, should we be checking for messages/descriptions
> in exception
> tests, even to match what Harmony throws? If we do then our api tests
> wont pass on other implementations.
Hi Mark,
As I said already I don't see any huge reasons to check the messages
(probably for not being empty only). However I suppose sometimes it
could be necessary. I'm pretty sure we will face many cases when we
need to deviate from RI (it was discussed already in other threads).
What I propose is to use for tests some utility method like
isHarmony(). It will act as a 'formal' indicator of all our
deviations.
For this particular situation is should be something like:
if (TestUtilities.isHarmony()) {
assertEquals("some message", e.getMessage())
}
What do you think?
--
Anton Avtamonov,
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]
Re: should strings in exceptions match the reference implementation?
On 4/17/06, LvJimmy，Jing <[EMAIL PROTECTED]> wrote:
> Agreed. Try some other words may be better. The only possible un-compatible
> with RI is that some rookie may write codes like:
> try{
>...
> }catch(Except e){
>if (e.getMessage().equals(RI_String)){
>dosomething;
>}
> }
> But this kind of code is properly unstable and unacceptable,right?
Agree. I expect there is no or almost no client applications doing
that. I think we shouldn't be message-compatible. Otherwise we would
have to be compatible with localized messages as well in assumption
someone checks for e.getLocalizedMessage() :-).
--
Anton Avtamonov,
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]
Re: assertEquals in tests with incorrect argument order
Completely agree about using proper 'asserts' :-).
Just want to remind about one more useful pair of methods -
assertSame()/assertNotSame() which are useful when comparing
instances. I saw many times in my practice that assertTrue(instance1
== instance2) was used intead. Besides, assertEquals() is also used
for that purpose sometimes which is definitely wrong...
Sometimes assertTrue(false) used instead of fail().
Actually, it is not too many 'assert' methods in
junit.framework.Assert class. May be it is a good idea for those who
never did it before to look at. Having all of them in mind will help
to use the most applicable when necessary.
--
Anton Avtamonov,
Intel Middleware Products Division
On 4/17/06, LvJimmy，Jing <[EMAIL PROTECTED]> wrote:
> 2006/4/17, Mark Hindess <[EMAIL PROTECTED]>:
> >
> > Another type of test that could be improved are those using
> > assertTrue to compare two objects for equality. Most of them should
> > be using assertEquals, assertNull or assertNotNull.
> >
> > Using assertEquals automatically gives more meaningful error messages.
> > It saves people writing asserts like:
> >
> > assertTrue("Size should return 100, returned: " + map.size(),
> > map.size() == 100);
> >
> > when this would do just as well:
> >
> > assertEquals("Incorrect size", 100, map.size());
>
>
> Good idea. :)
>
> I'm going to submit a few (big) patches to fix some of these.
>
>
> I think there's a lot of them, even, few of our testcases is written in this
> style, so, good luck :)
> Anyway, we can discuss about this, and see if we can agree on some
> convention.
>
> Regards,
> > Mark.
> >
> > On 4/15/06, Mark Hindess <[EMAIL PROTECTED]> wrote:
> > > Trying to fix/enable the PatternSyntaxExceptionTest (HARMONY-352) was
> > > quite confusing. If you get the arguments to assertEquals the wrong
> > > way around you get errors like:
> > >
> > > error expected but got
> > >
> > > rather than:
> > >
> > > error expected but got
> > >
> > > The correct way around is to have the expected value before the actual
> > value.
> > > We should all try make sure we get the arguments to assertEquals in the
> > > correct order. And fix any we spot that are the wrong way around. ;-)
> > >
> > > I've fixed a few of the more obviously incorrect method calls in
> > > HARMONY-353.
> > >
> > > Regards,
> > > Mark.
> > >
> > > --
> > > Mark Hindess <[EMAIL PROTECTED]>
> > > IBM Java Technology Centre, UK.
> > >
> >
> >
> > --
> > Mark Hindess <[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]
> >
> >
>
>
> --
>
> Best Regards!
>
> Jimmy, Jing Lv
> China Software Development Lab, IBM
>
>
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Long,long testcase name...
On 4/12/06, Leo Simons <[EMAIL PROTECTED]> wrote: > On Wed, Apr 12, 2006 at 08:09:41PM +0700, Mikhail Loenko wrote: > > 2006/4/12, Andrew Zhang <[EMAIL PROTECTED]>: > > > Hello, geir, > > > Let's consider the case you mentioned. > > > I totally agree that "testRequestPasswordAuthentication1" is a BAD name, > > > > Why? [SNIP] > > So you end up with names such as > > testRequestPasswordAuthenticationThrowsAnExceptionOnNullArguments > > or > > testRequestPasswordAuthenticationAcceptsSimpleJohnDoeParameters > > they are painful to type, but less painful than typing javadocs, and more > likely to get read than javadocs, and likely to get read a lot more than > written. Furthermore, if you have camel case searching, you can search for > tRPA and get all the relevant bits. Hi Leo, What are you talking about is excellent when you have one method to test, but need to cover several scenarios. You don't want to have them together in one test to keep all scenarios clear, right? I also do in the similar way with minor deviation: I would prefer testRequestPasswordAuthentication_ThrowsAnExceptionOnNullArguments - underscore between method name and test intention. However such approach doesn't work when you really have several same-named methods with different params. You have to test similar scenarios, but with different methods... Please correct me if I got it wrong. Wishes, -- Anton Avtamonov, 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]
Re: classlib test suite status emails?
Well, you will need to build-up dependency info anyway, right? Therefore probably that would be a good chance to revise and update manifests :-)? -- Anton Avtamonov, Intel Middleware Products Division On 4/12/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote: > BTW AFAIK we do not test whether manifests list all imports/exports > > So if we create data from manifests then it could be insufficient and > we might have the same failures we had yesterday. > > Thanks, > Mikhail > > 2006/4/12, Anton Avtamonov <[EMAIL PROTECTED]>: > > On 4/12/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote: > > > Why have a static file? Why not just generate from the modules > > > manifests? Then the error can only be in one place - the dependent > > > module... right? > > > > If they have enough info - of course! That would be excellent. > > I suppose it is a bit not trivial since the required information is > > not the modules the particular module is depended on, but all the > > modules which depend on the particular module. However it should be > > not hard to revert. > > Did I catch your idea right? > > > > -- > > Anton Avtamonov, > > 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] > > - 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 suite status emails?
On 4/12/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote: > Why have a static file? Why not just generate from the modules > manifests? Then the error can only be in one place - the dependent > module... right? If they have enough info - of course! That would be excellent. I suppose it is a bit not trivial since the required information is not the modules the particular module is depended on, but all the modules which depend on the particular module. However it should be not hard to revert. Did I catch your idea right? -- Anton Avtamonov, 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]
Re: classlib test suite status emails?
On 4/12/06, George Harley <[EMAIL PROTECTED]> wrote: > Hi, > > Thanks for your comments. > > Working on the "walk first then try to run" principle, I will try to > start adding in "run.dependants.tests" targets to individual modules' > build.xml scripts over the next few days. Text seems like a good > candidate to start. George, Just a raw idea: it is possible to have description of all dependencies located in a single place out of individual modules? As XML file for instance? As I understoond you are going to list all the dependencies right in the build.xml of each module. IMHO, such approach makes not too easy to understand the dependencies. I would suppose to have some XML file representing kind of dependency table which is accessed by the build.xml of each module (by some specific target. run.dependants.tests is fine) to retreive the particular list of dependencies for the particular module. Having all the dependencies in the single place would simplify their support. Besides, I expect it would be not too difficult to create XSLT to generate HTML table in the perfect human-readable form... As I said that is just an idea. I'm not experienced in ant-scripting, not sure if that is good idea and how it difficult to implement. Wishes, -- Anton Avtamonov, 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]
Re: classlib test suite status emails?
On 4/12/06, Stepan Mishura <[EMAIL PROTECTED]> wrote: > Hi George, > > Your example looks good for me and I think everybody agreed that we should > organize testing to avoid running all tests for each update: if you fix bug > in 'net' module you don't have to run tests say for 'awt' module but if you > update 'luni' then you have to run tests for all modules. Absolutely agree. Looks like a concept of so-called 'dependency matrix'. Its rows and columns represents functional areas. Each cell contains a number from 0 to 1 which represents the correlation between those functionalilies, diagonal cells (representing self-impact of each functional area) obviously contain 1. QE usually used that approach to decide which tests needs to be re-executed. Simplifiing this approach to use only binary dependency (0 or 1) I beleive it can be automated so that commiter will just need to call some ant target to run all dependent tests. Of course, it needs to be kept up to date, however I expect such dependencies are not dynamically changed, i.e. it is well-known that almost everything depends from luni and almost nothing from net, etc. -- Anton Avtamonov, 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]
Re: Long,long testcase name...
> > Geir Magnusson Jr wrote: > > > testRequestPasswordAuthentication1() > > > > > > I mean, why do we want to embed all that crap in the testcase name? > > > Who cares? The only person that will care is someone fixing when a > > > testcase breaks, and they'll read the code... I agree with Geir. May be just "1" is not briliant one, however much better than too long names. It really gives nothing for human understanding. Btw, as I remember Eclipse does auto-test generation in the similar manner. Wishes, -- Anton Avtamonov, 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]
Problems with accessing JIRA
Hi, I cannot access JIRA with "Service Temporarily Unavailable" message. Could someone please investigate? Thank you in advance, -- Anton Avtamonov, 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]
Re: [classlib] Switching to a 5.0 compiler
On 4/5/06, Etienne Gagnon <[EMAIL PROTECTED]> wrote: > I think that using Sun's javac and Eclipse with their undocumented and > unsupported options during the "transition period" seems the cleanest > strategy for both class library and VM maintenance. I see no trouble > having such a dependency for a limited period of time (a few months). +1. Anyway we will have VM with 1.5 support. We just need to wait for a while, right? If we have simple workarround which solves the problem for the moment why we should invent something else? Wishes, -- Anton Avtamonov, 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]
Re: matching reference implementation exception behaviour
On 4/3/06, Tim Ellison <[EMAIL PROTECTED]> wrote:
> Anton Avtamonov wrote:
> > On 4/3/06, Mark Hindess <[EMAIL PROTECTED]> wrote:
> > [SNIP]
> >> Personally, I'd raise JIRA's one at a time when you have fixes
> >> prepared. That way they can be discussed and we can firm up our
> >> policy on matching behaviour.
> >>
> >
> > Not completely agree. I believe bug report should be done immediately
> > when the problem is discovered. That is the only garantee it is never
> > lost. Besides, sometimes a person who found a problem and a person who
> > makes a patch are
> > not the same :-).
>
> You are right, I should not assume that Alex is in a position to submit
> patches/tests (we would not expect that of our 'end users').
>
> If Alex cannot provide patches then I'd vote for submitting the script
> itself so that Harmony developers can run it and fix the problems.
>
> > Talking about the original Alex's question I think we should have
> > separate JIRA issues for each diffirence. As I remember we decided to
> > document all the deviations and discuss them if they are not trivial.
>
> I thought the conclusion was to document agreed departures in this way
> -- simple bugs that show we don't behave the same as the RI should just
> be fixed.
>
> > The way how we document them is a special JIRA category, right? So,
> > tracking each deviation independent allows us to discuss them and
> > change the category in case we would like to preserve the deviation.
> > Makes sense?
>
> Is anyone suggesting that these should not be fixed?
Well, probably I expressed my idea not clearly enough, sorry for that.
What I tried to say is that if we have separate jira issue for each
deviation and then will be decided that the deviation should not be
fixed we can easily change the category ('Component/s' field) of this
issue to be 'Non-bug differences from RI'.
At the other hand, if we have several differences in the single jira
issue and then decide that one of the differences should not be fixed
we will have to create a separate jira record to document this
deviation.
--
Anton Avtamonov,
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]
Re: [classlib] Der Plan
On 4/4/06, Paulex Yang <[EMAIL PROTECTED]> wrote: > Tim, > > I've rolled back the page, and I'm sorry if it made someone > uncomfortable. I thought Wiki should not be something final, or > official, and it just used as record for sth. in progress, say, > discussion, code status, or volunteer, so that everyone can see and > involve if interest, and IMHO Wiki is easier to summary and read > (otherwise the new comers may need to search in mailing list archive, or > just ask questions have been discussed before), especially considering > Wiki modification can be subscribed. Hi Paulex, I agree with you: we definitely need some sort of summaries on Wiki. Harmony mailing has lots of threads which one can hardly track not being full time there. However information published on Wiki should be "agreed" with others who affected. Otherwise it can even mislead someone, right? Therefore we need mailing notifications/discussions before publishing I think. Wishes, -- Anton Avtamonov, 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]
Re: matching reference implementation exception behaviour
On 4/3/06, Mark Hindess <[EMAIL PROTECTED]> wrote: [SNIP] > > Personally, I'd raise JIRA's one at a time when you have fixes > prepared. That way they can be discussed and we can firm up our > policy on matching behaviour. > Not completely agree. I believe bug report should be done immediately when the problem is discovered. That is the only garantee it is never lost. Besides, sometimes a person who found a problem and a person who makes a patch are not the same :-). Talking about the original Alex's question I think we should have separate JIRA issues for each diffirence. As I remember we decided to document all the deviations and discuss them if they are not trivial. The way how we document them is a special JIRA category, right? So, tracking each deviation independent allows us to discuss them and change the category in case we would like to preserve the deviation. Makes sense? -- Anton Avtamonov, 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]
Re: bug-to-bug compatiblity case: Proxy handling
On 3/30/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote: > I think this is the case when me might choose "follow the spec" > > Most likely we will not break existing applications if we weaken > requirements for method arguments. But advanced users would be able > to use our benefits. +1 -- Anton Avtamonov, Intel Middleware Products Division
Re: More helpful error messages
On 3/27/06, Thorbjørn Ravn Andersen <[EMAIL PROTECTED]> wrote: > I believe to have read that some of the optimizations that went into > Java 5 was the construction of the stacktrace in an exception. > > So I think it is not as much the object but more all the track keeping > that is expensive. Of course. Object itself (new String() for instance) takes almost nothing. -- Anton Avtamonov, Intel Middleware Products Division
Re: Unit testing revisited
On 3/27/06, Chris Gray <[EMAIL PROTECTED]> wrote: [SNIP] > > It may not be general, but there are enough specific instances to make it > worthwhile having a systematic way to do such tests. > > Note that I am not advocating full white-box testing, in which you check the > state of every internal variable after every stimulus - that really is a > waste of time. I'm advocating black-box testing of internal interfaces which > are important enough to be worth documenting. > Geir, Chris, You convinced me (with regard to the last paragraph above: not white-box testing, but 'gray-box' testing of the important internal interfaces). -- Anton Avtamonov, Intel Middleware Products Division
Re: More helpful error messages
I was so impressed by the results that decided to reproduce them.
No wonder I got very similar timing :-)
I slightly modified test to be able to see how much time Exception
object creation takes itself:
public class Test {
private static long exceptionCreationTime;
private static long exceptionThrowMoment;
private static long exceptionThrowTime;
public static void main(final String[] args) {
long startTime = System.currentTimeMillis();
for( int i = 0; i < 50; i++ ) {
try {
exceptionalMethod();
} catch (Exception e) {
exceptionThrowTime += System.currentTimeMillis() -
exceptionThrowMoment;
}
}
long totalTime = System.currentTimeMillis() - startTime;
System.out.println("total time = " + totalTime);
System.out.println("exception creation time = " + exceptionCreationTime);
System.out.println("exception throwing time = " + exceptionThrowTime);
System.out.println("rest time = " + (totalTime -
exceptionCreationTime - exceptionThrowTime));
}
static void exceptionalMethod() {
long startTime = System.currentTimeMillis();
RuntimeException e = new RuntimeException();
exceptionCreationTime += (System.currentTimeMillis() - startTime);
exceptionThrowMoment = System.currentTimeMillis();
throw e;
}
}
I got the following (in average):
total time = 2743
exception creation time = 2252
exception throwing time = 341
rest time = 150
Really, Exceptions creation tales too much and (suprising for me) not
too much when throwing. Probably that is because in this sample stack
frame is not huge and if we have bigger method call stack exception
throwing will take more?
I tried to increase stack (I'm not sure how adequate this test is):
public class Test2 {
private static long exceptionCreationTime;
private static long exceptionThrowMoment;
private static long exceptionThrowTime;
public static void main(final String[] args) {
long startTime = System.currentTimeMillis();
for( int i = 0; i < 50; i++ ) {
try {
exceptionalMethod(100);
} catch (Exception e) {
exceptionThrowTime += System.currentTimeMillis() -
exceptionThrowMoment;
}
}
long totalTime = System.currentTimeMillis() - startTime;
System.err.println("total time = " + totalTime);
System.err.println("exception creation time = " + exceptionCreationTime);
System.err.println("exception throwing time = " + exceptionThrowTime);
System.err.println("rest time = " + (totalTime -
exceptionCreationTime - exceptionThrowTime));
}
static void exceptionalMethod(final int counter) {
if (counter > 0) {
exceptionalMethod(counter - 1);
} else {
exceptionalMethodInner();
}
}
static void exceptionalMethodInner() {
long startTime = System.currentTimeMillis();
RuntimeException e = new RuntimeException();
exceptionCreationTime += (System.currentTimeMillis() - startTime);
exceptionThrowMoment = System.currentTimeMillis();
throw e;
}
}
The results are:
total time = 20400
exception creation time = 16805
exception throwing time = 2623
rest time = 972
So even in such conditions Exception object creation is dominating.
Anyway, absolutely agree with Geir: exceptions should not be used for
'normal' operation results where possible (i.e. where not defined by
spec or RI).
--
Anton Avtamonov,
Intel Middleware Products Division
Re: Unit testing revisited
On 3/27/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote: [SNIP] > > I don't think it's easier to write test cases for internals though a > public API, because you can call the internal methods directly to see if > they do as they promise, where it's not so easy to always have the same > thing happen through an indirect public API. > > Also, wrt things breaking. yes, tests that ensure that something > works as expected will need to change if the expectation changes. > > That also is exactly what you want, right? To know if you broke a > 'internal contract' in a class? Hmmm... Lemme support Richard's point. At the first, internals not just specify 'internal functional contracts', but design decisions. Making redesign you will probably have some (design-dependent) unit tests failing, despite functionality is not changed. If so we will have to change the tests, right? If we changing the tests we cannot be sure they still tests the original behavior. IMHO, tests are the formal and executable way to represent requirements (XP approach) so they should reflect the 'requirements level'. In our case that is public API. At the second, what we really need to satisfy is API behavior only. Internal implementation is not significantly important if public part works fine. I fond of XP and test-driven development and don't feel that we need to test something which is not part of requirements :-). If something is not accessible from the usage scenarios of public API level, it is not important how it works (I believe this idea appeared several times already in this thread). I completely understand the issue of complexity if we test big amout of code referenced by public API, however I believe that in the majority of cases the behavior of each API method is not very complicated and can be tested by few scenarios. At least I haven't seen spec for some method of several pages long :-) Usually the behavior is comparative simple. At the end (but not least important) you have to 'verify' your tests somehow. You prepare them basing on specification, however you should check them on RI. Just to make sure test is correct, spec corresponds to RI, etc. I cannot understand how it could be done for 'internals'... I even know the objections, that only 'public API tests' (in .tests.) should be run on RI. And I even probably agree... Sometimes, it is really desire to write an 'internal' test. For instance, if you use some sorting algoritms, or algoritms which find next match, etc. In this case such 'utility' stuff might be tested independently from the points of usage. However I believe that is not 'general case'. -- Anton Avtamonov, Intel Middleware Products Division
Re: [result] Re: [vote] Acceptance of HARMONY-39 : Contribution of beans, regex and math class library code
On 3/22/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote: > As I understood the main Tim's concern with running tests in bootclasspath is > that real apps wont run that way. > > If we test in special VM mode then we go far away from how real apps > are running. Agree. Besides, VM will have to be even more complicated and (most likely) a bit slowly. -- Anton Avtamonov, Intel Middleware Products Division
Re: NullPointerException -- This info should be in wiki
On 3/20/06, karan malhi <[EMAIL PROTECTED]> wrote: > Hi, > > This information should be put in the wiki under "Coding Guidelines" or > "How do I " kind of a section. I think that a lot of discussion gets > buried in the mailing list and then the same issue crops up again. I am > willing to undertake updating the wiki with this information if you all > agree. > Absolutely agree. I believe all the valuable decisions made here in Harmony during discussions must be put on wiki. For this particular issue "Coding Guidelines" is fine, I think. -- Anton Avtamonov, Intel Middleware Products Division
Re: [vote] Require compiler options that allow partial 5.0 language features
+1 -- Anton Avtamonov, Intel Middleware Products Division On 3/17/06, Tim Ellison <[EMAIL PROTECTED]> wrote: > As discussed on the list, there is a compiler option in the 5.0 > compilers we use that allows source code containing a subset of Java 5.0 > language features to be compiled into 1.4 compatible class files. > > Since this is quite a significant change I'd like to get a vote on > whether the project should make this compiler option a necessity for our > code. > > The positive outcome of this is that we can develop APIs that rely on > those 5.0 language features, and run the resulting code on existing > 1.4-compatible VMs. > > The downside is that we are using an undocumented compiler feature on > the reference implementation (it is supported on the Eclipse compiler). > > [ ] +1 - Yes, change the build scripts to compile 5.0 code to 1.4 target > [ ] 0 - I don't care > [ ] -1 - No, don't change the compiler options (please state why)
Re: NullPointerException
On 3/17/06, Karan Malhi <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Some of the methods/constructors in the API throw a NullPointerException
> when a null is passed in as an argument. The spec doesnt say anything that
> the method/constructor should throw a NullPointerException, neither does it
> say anything about how the method/constructor should behave when a null is
> passed in.
> What should be the approach in that case?
> 1. Could we check for null within a method and handle it so that the method
> does not unneccessarily throw an NPE (this would differ from how the spec
> would behave) or
> 2. should we allow the method to throw an NPE if the spec method also throws
> it?
Hi,
Actually null-processing and corresponding NPEs are very very often
omitted from the spec.
I would say that according to the guidelines Paulex proposed (and as I
understood we agreed on) we should be RI-compatible in this case.
Really, spec doesn't say anything regarding null-processing and
therefore throwing NPE in this case does *not* contradict to the spec.
Having NPE we will be better RI-compatible and stay on the same
position in the spec-compatibility (since it is silent).
Therefore I suggest to be RI-compatible by default in all cases when
spec keep silence. I believe it well suites Paulex guidelines (please
correct me if I wrong).
Talking about how particulary we should throw NPE I'm not sure what to
advise: in many cases RI just produces them automatically when actual
call like null.someMehtod() occurs. To provide better notation we can
do that directly, i.e.
if (someVar == null) {
throw NullPointerException("some valuable message")
}
I'm not really sure what is better and would like to know what others
think about.
Btw, when we will work on documentation (javadoc) I think we should
append references to the standard Sun API in the methods javadoc with
the direct info about null-processing and NPE if a method can produce
it (when it is missing from the original spec of course).
--
Anton Avtamonov,
Intel Middleware Products Division
Re: [classlib] bug-to-bug compatibility: SecureRandom
On 3/13/06, Paulex Yang <[EMAIL PROTECTED]> wrote: > Mikhail > > I think current Harmony code is fine in this case. Because it is > reasonable to consider null as another exceptional case and to > differentiate it with the case of non-existing algorithm. +1 -- Anton Avtamonov, Intel Middleware Products Division
Re: Do we want to be bug compatible? (was: Re: newbie to project-where to start from)
On 2/27/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote: > > Lemme remember Paulex's rules: > > > >> 1. we should comply with spec > >> 2. if RI is contradict with spec, and RI is not logical(sometimes it is > >> very obvious, you know what I mean), we comply with RI; else, we discuss > >> it case by case. > >> 3. if spec is not so clear, we should comply with RI > >> 4. if some application failing on that different behavior, we discuss it > >> case by case > > > > 5. Log every difference from either the spec or the RI in JIRA. Absolutely agree. [snip] > > Actually, I think that Sun does have an internal group which does > exactly that. I've heard some great stories about the raging fights > that have erupted internally due to this process... > > We'll get to have our great fights here :) :-) -- Anton Avtamonov, Intel Middleware Products Division
Re: Do we want to be bug compatible? (was: Re: newbie to project-where to start from)
On 2/27/06, Paulex Yang <[EMAIL PROTECTED]> wrote: > The second line, I meant to be: > 2. if RI is contradict with spec, and RI is not logical(sometimes it is > very obvious, you know what I mean), we comply with _*SPEC*_; else, we > discuss it case by case. I also missed that! The idea was absolutely clear, particular words are not important :-) -- Anton Avtamonov, Intel Middleware Products Division
Re: Do we want to be bug compatible? (was: Re: newbie to project-where to start from)
On 2/27/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote: > As I understood people in this and similar threads tend to be compatible > with the Spec rather then with RI (unless we prove that being incompatible > with RI breaks some existing implementation) > > I'm trying to oppose that, I'd to be compatible with RI when in doubt. Well, actually you are right. I disagree just to simply copy all the existing bugs... And as I rememeber I'm not along :-). The main idea is to follow the guidelines Paulex proposed, i.e. to be reasonable. Lemme remember Paulex's rules: >1. we should comply with spec >2. if RI is contradict with spec, and RI is not logical(sometimes it is >very obvious, you know what I mean), we comply with RI; else, we discuss >it case by case. >3. if spec is not so clear, we should comply with RI >4. if some application failing on that different behavior, we discuss it >case by case I believe this approach will give better results: keepping us compatible with the existing applications and provide more consistent implementation where possible. Note that according to the rules above we are not mandatory follow to the spec. Btw, releasing new JDK SUN updates some existing methods, sometimes changing not only internal implementation, but even some behavior. I suppose they don't run all existing applications to make sure nothing is broken :-). I don't know how this process is organized, however I would expect some kind of CCB (Change Control Board) which decide if it's safe change or not. I suppose our mailing list can act in a very similar manner. -- Anton Avtamonov, Intel Middleware Products Division
Re: bug-to-bug compatibility - another issue
On 2/22/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote: > Definitely not only. But when one place in the spec contradicts to another > one (like in your first example) we should follow RI. Actually, I don't see real contradiction... In the class description (you posted) the idea is that flush() should be called at the end to allow decoder to flush its internal info. The provided steps is a description of the overall decoder usage, further detalization is in the methods spec... The idea of that description is to show that the flush is required at the end, no more... That is my interpretation, at least. -- Anton Avtamonov, Intel Middleware Products Division
Re: bug-to-bug compatibility - another issue
On 2/22/06, Paulex Yang <[EMAIL PROTECTED]> wrote: > This paragraph is just what I want to say about the bug compatibility, > my idea is: > 1. we should comply with spec > 2. if RI is contradict with spec, and RI is not logical(sometimes it is > very obvious, you know what I mean), we comply with RI; else, we discuss > it case by case. > 3. if spec is not so clear, we should comply with RI > 4. if some application failing on that different behavior, we discuss it > case by case and +1 from me :-). IMHO, excellent guideline. Bugs can be both in the spec and in the RI impl. For all non-trivial cases logic and discussion here in mailing list should help us to decide what to comply. -- Anton Avtamonov, Intel Middleware Products Division
Re: bug-to-bug compatibility - another issue
Well, I briefly looked through the spec...
I agree, it is quite confusing... If decode() with true is not called
flush() cannot decide what to do with the remaining data... From the
other side, flush() is intended to store everything from its internal
cashes, however reset() clears it. So, flush() definitely should do
nothing after reset(). It has no any problems deciding what to do with
its internal state. Why to throw exception is this case?
--
Anton Avtamonov,
Intel Middleware Products Division
On 2/22/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote:
> Paulex,
>
> look at the class description in the spec:
>
> "A decoder should always be used by making the following sequence of
> method invocations, hereinafter referred to as a decoding operation:
>
> Reset the decoder via the reset method, unless it has not been used before;
>
> Invoke the decode method zero or more times, as long as additional
> input may be available, passing false for the endOfInput argument and
> filling the input buffer and flushing the output buffer between
> invocations;
>
> Invoke the decode method one final time, passing true for the
> endOfInput argument; and then
>
> Invoke the flush method so that the decoder can flush any internal
> state to the output buffer. "
>
> So RI works according to class description. It might be a misprint in the
> method description you have cited. I'd rather be compatible with RI
>
> Thanks,
> Mikhail
>
>
> On 2/22/06, Paulex Yang <[EMAIL PROTECTED]> wrote:
> > Following the discussion before, I have another issue about RI's "bug",
> >
> > try this little test below:
> >
> > import java.nio.charset.*;
> > public class DecoderTest{
> >public static void main(String[] args){
> >CharsetDecoder decoder = Charset.forName("utf-8").newDecoder();
> >decoder.reset();
> >decoder.flush(CharBuffer.allocate(10));
> >}
> > }
> >
> > It quits quietly on Harmony, while on RI(JDK 5.0/1.4.2), it throws
> > exception like below:
> > java.lang.IllegalStateException: Current state = RESET, new state = FLUSHED
> >at
> > java.nio.charset.CharsetDecoder.throwIllegalStateException(Unknown Source)
> >at java.nio.charset.CharsetDecoder.flush(Unknown Source)
> >
> >
> > But the spec of CharsetDecoder.flush() says:
> >
> > Throws:
> >IllegalStateException - If the previous step of the current decoding
> > operation was an invocation neither of the reset method nor of the
> > three-argument decode method with a value of true for the endOfInput
> > parameter
> >
> > It's so interesting that the spec emphasizes it SHOULD NOT throw
> > IllegalStateException when flush() just after reset().
> >
> > In fact, this is just one example of contradiction between spec and RI's
> > CharsetDecoder/Encoder internal status implementation. These *bugs* are
> > serious so that the RI's Decoder/Encoder must be used by experiment.
> > Should Harmony be compatible with RI?
> >
> >
> >
> > --
> > Paulex Yang
> > China Software Development Lab
> > IBM
> >
> >
> >
>
Re: bug-to-bug compatibility - another issue
On 2/22/06, Paulex Yang <[EMAIL PROTECTED]> wrote: [snip] > > But the spec of CharsetDecoder.flush() says: > > Throws: >IllegalStateException - If the previous step of the current decoding > operation was an invocation neither of the reset method nor of the > three-argument decode method with a value of true for the endOfInput > parameter > > It's so interesting that the spec emphasizes it SHOULD NOT throw > IllegalStateException when flush() just after reset(). > > In fact, this is just one example of contradiction between spec and RI's > CharsetDecoder/Encoder internal status implementation. These *bugs* are > serious so that the RI's Decoder/Encoder must be used by experiment. > Should Harmony be compatible with RI? Hi Paulex, I have no deep knowledge in this area and therefore cannot really judge the possible impact. My opinion is from common sense only: - spec DEFINITELY states exception should not be thrown and people DEFINITELY take this into account - I cannot believe applications really EXPECT this exception to detect this particular scenario and do something specific for the case flush() is called after reset(). Most likely application just stop processing if exception occur. Exception is terated as a 'signal that something is wrong'. - I cannot find what is wrong in calling flush() after reset(). Looks like quite normal operation. Spec proves that. My opinion here - to follow the spec. At least unless we really have an application failing on that (what I personally hardly believe to happen). -- Anton Avtamonov, Intel Middleware Products Division
Re: Do we want to be bug compatible? (was: Re: newbie to project-where to start from)
On 2/20/06, Gerry Steele <[EMAIL PROTECTED]> wrote: > It might also be worth nothing that if you are licensed to use the > tck, there is an appeal process, so it may be possible to make sun > accept deviation from the spec or unreasonable claims in the spec, on > their part, on a case by case basis. > > But i suppose the real test is how well it runs existing applications. > If a user finds it more difficult to run their app than with the Sun > JVM, then they simply wont use it. In general, of course. If I ran my application and found all the buttons are in the mess on the wrong places, scrollers don't scroll, etc... Yeah, most likely I just stop trying. In the other hand, if I have one exception with adequate message which I recognize as a problem in my code... I just say 'great thanks' to those who helped me to find it :-) Again, it should not be hundreds of exceptions! It may be 1 exception per 100 applications... Something like that... Otherwise we will identify the problem when testing and decide what to do. Sorry if I very optimistic :-) Probably we can have some place where everyone will be able to record identified deviations? I'm not sure that is really makes sense 'cause I can't imagine how to handle such list for the practical value. Obviously all serious deviations have to be discussed here. -- Anton Avtamonov, Intel Middleware Products Division
Re: Do we want to be bug compatible? (was: Re: newbie to project-where to start from)
On 2/20/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote: > Well seems like we all agree with the general approach. Yes. Agree. > > But... > > :) > > I do not agree with the specific case you describe: NPE vs. IAE. > > I can imagine a programmer who does not read the spec, who > does not want to check for null, who just makes 'catch NPE' somewhere Mikhail, I definitely can imagine the same story. I only want to have such application first. Then we will be able to judge and decide what to do. Before that no need to deviate from spec (of cource, excepting the cases when spec itself contains bugs as in my example with GrayFilter when required exception is missed from spec). In your example, such 'professional' developer most likely catches just Exception rather then the particular one :-) > > And his app would work well on RI and fail with uncaught IAE on Harmony > if we follow the spec. So, what is the reason in this very specific case > to firmly follow the spec? Because NPE (IMHO) is not well-defined way to inform the developer something is wrong with his/her code. It just shows 'something inside implementation' fails (excluding cases when NPE contains proper message and is thrown intentively). In opposite, IAE always shows programmer called the method with wrong input values. All is about better notation only. In case existing program specified percentage outside the reasonable range, for instance, and worked anyway it may be even better to clearly inform the developer something is wrong with the program. Because in reality there were no garantee that such incorrect code worked properly on Sun's impl: just a play of chance. Of course we should not add more exceptions than exist in code/spec (at least for now), but try to use 'proper' exceptions with better notation clear for the developers. I propose to continue this discussion when we have real examples, i.e. real applications failed because of such differences or particular methods which can potentially fail applications... Otherwise the discussion is quite abstract... Just IMHO. -- Anton Avtamonov, Intel Middleware Products Division
Re: Do we want to be bug compatible? (was: Re: newbie to project-where to start from)
On 2/20/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote: > Anton > > still no answer to: What is the goal of that firm spec compatibility? > > Are you sure that if some usage scenario does not make sense for you > and for all progressive people in the world then there no application working > this way? > > Think of the following: we release Harmony, people will try their apps > and find out > that they do not work. What will the people do? Absolutely agree with the concern above. I mean that some of ther potential users just stop using Harmony and get something which 'properly' works. However I believe: 1. We will test Harmony on many applications and will be able to identify the major part of the potential problems 2. People will send us bug report in the same manner they do for Sun's implementation. I completely agree that we must be very careful decising what is bug and what is not (actually, it was my original post :-) ). I just added that we should try to be spec-compatible when possible. Particulary talking about exceptions: I hope that there should not be too many applications which are relevant to what kind of RuntimeException JRE produces (NPE or IllegalArgumentException) in those cases when Sun's impl doesn't satisfy its spec. Therefore to be spec-compatible here should not cause a problem. [snip] > Sure, we do not have to copy obvious bugs like SIGSEGVs, but we still have to > carefully work with all the cases when we can potentially break existing > applications. +2 (with both hands :-) ) -- Anton Avtamonov, Intel Middleware Products Division
Re: Do we want to be bug compatible? (was: Re: newbie to project-where to start from)
On 2/19/06, karan malhi <[EMAIL PROTECTED]> wrote: > > > Geir Magnusson Jr wrote: > > > Well, I don't really know if Sun would do that. There is an expert > > group that Sun has to deal with... > > > > But if it did happen, yes, we'd have to fix our code. > > > I agree. Whatever experience I've had with java till now, I have found > that Sun mainly deprecates a method and provides a replacement, instead > of changing the spec for that method after the spec has been released. > So, if Sun decides to deprecate a method, it will still not break > harmony. I still feel our code should be spec compatible and not bug > compatible with Sun's impl. As a developer, I would look at the API docs > and then write the code. So, if our impl is compatible with the API > docs, won't that make a case for using harmony instead of a buggy impl :) Yeah! Very optimistic! I agree :-) In practical terms developers hate when spec contradicts to the real behavior so for the developers of the new applications it would be fantastic to have such implementation. However we have to run all existing applications first, and, therefore, have to be as closer to Sun's impl as possible... If I got it right we decided to discuss all not-trivial cases and I believe that is right approach. -- Anton Avtamonov, Intel Middleware Products Division
Re: Do we want to be bug compatible? (was: Re: newbie to project-where to start from)
On 2/19/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote: > > > Mikhail Loenko wrote: > > What is the goal of spec-compatibility for exceptions? > > > > 1. Existing applications that work well on Sun's Java might fail on Harmony. > > Right - this is a problem. People will say that we're broken. It's not > a easy conversation to have with users who don't care about license, > just want a good JRE to work with, so then delete our implementation. Sounds reasonable. However I hope the expected deviations for Sun's impl (if we talk about exceptions) should not be so dramatic... I hope we will be basing on both spec, impl behavior and common sense. For instance, there is javax.swing.GrayFilter class which constructor takes 'percentage of gray' parameter (a value in a [0-100] range). Spec doesn't state there should be IllegalArgumentException if the value is out of range, but both Sun's impl and common sense tell us it should be. Another case is if spec states IllegalArgumentException, but impl produces NPE... I don't believe there are applications which are really care about the particular kind of RuntimeException :-). So in this case I would follow the spec. Really, IllegalArgumentException is always a guard statement for definitely wrong usage of API (like setting percentage out of [0-100] range). Not too many people should break such 'common sense' idea. Besides, I hope we will have not too many places when Sun's impl and spec differ. > > > 2. Sun, once it discovers the bug, will most likely change the spec > > rather then impl, > > and we will have to return and fix our code > > Well, I don't really know if Sun would do that. There is an expert > group that Sun has to deal with... I think we should try to be spec-compatible when possible. If the spec is changed - we will change the implementation. Actually, for the time being I don't know any applications which are broken because of using IllegalArgumentException instead of NPE or vise versa. Let's see if we have such and then decide. Before that, spec-compatibility looks more preferrable for me... -- Anton Avtamonov, Intel Middleware Products Division
Re: newbie to project-where to start from
On 2/17/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote: > I agree with Tim that we should discuss on the dev list +1 > > Later we might want to have some roadmap once we find a number > of similar issues > > At this point I think we might be compatible when RI throws > wrong exceptions - for example it often mixes NPE and > IllegalArgumentException Sometimes spec states IllegalArgumentException should be thrown, but implementation produces NPE. I think that is because IllegalArgumentException is missed in impl and algorithm just failed somewhere... IMHO, when spec states some exception we should be spec-compatible. -- Anton Avtamonov, Intel Middleware Products Division
Re: newbie to project-where to start from
Just minor comment: Many times I saw very strange behavior in jdk which I was absolutely sure about: definitely a bug. But then... I found applications which used those strange things! I hust want to say that it is important to be very careful when deciding what is bug: it is very probable to find an application basing on it (java world is very very huge :) ). -- Anton Avtamonov, Intel Middleware Products Division On 2/17/06, Tim Ellison <[EMAIL PROTECTED]> wrote: > Mikhail Loenko wrote: > > depending on the bug... > > actually, this is the answer I would give too (which I know is not very > helpful). > > Some apparent 'bugs' are ambiguities in the spec, or a different choice > of under-specified behavior that we likely want to match to ensure > compatibility; others may be deemed implementation bugs that we should > not recreate. > > Sometimes it's a tough call, we should seek consensus on the dev list. > > > I would not like to be compatible with SIGSEGVs :) > > We'll have our own versions ;-) > > Regards, > Tim > > > Thanks, > > Mikhail > > > > On 2/16/06, Alexey Petrenko <[EMAIL PROTECTED]> wrote: > >> 2006/2/16, Tim Ellison <[EMAIL PROTECTED]>: > >>> Tests should be written to the javadoc spec, rather than deducing > >>> behavior from any particular implementation. > >> By the way... > >> Do we want to be bug compatible with reference implementation? > >> > >> -- > >> Alexey A. Petrenko > >> Intel Middleware Products Division > >> > > > > -- > > Tim Ellison ([EMAIL PROTECTED]) > IBM Java technology centre, UK. > >
Re: Mission impossible: new APIs without spec in Java 5.0
On 2/16/06, Tim Ellison <[EMAIL PROTECTED]> wrote:
> Hmm, they look to me like they could be impl methods that were
> inadvertently exposed. They don't seem to fit in to the BreakIterator bag.
>
> If I were you I'd implement them to throw a NotYetImplementedException.
>
> Regards,
> Tim
>
I agree that those methods are a bit strange... Does the proposed
exception well fit to the compatibility strategy? As I know once the
method was exposed it will never be removed from spec and therefore
everyone can use it...
I did 5 min research and found that their implementation should be
very simple (sorry I provide the test not in JUnit format):
Method getInt = BreakIterator.class.getDeclaredMethod("getInt", new
Class[] {new byte[0].getClass(), Integer.TYPE});
getInt.setAccessible(true);
Object result = getInt.invoke(null, new Object[] {new byte[] {0, 0, 0,
1, 1, 0}, new Integer(0)});
System.err.println("expected 1 = " + (new Integer(1).equals(result)));
result = getInt.invoke(null, new Object[] {new byte[] {0, 0, 0, 1, 1,
0}, new Integer(1)});
System.err.println("expected 257 = " + (new Integer(257).equals(result)));
result = getInt.invoke(null, new Object[] {new byte[] {0, 0, 0, 1, 10,
0}, new Integer(1)});
System.err.println("expected 266 = " + (new Integer(266).equals(result)));
IMHO, it is not very difficult to implement.
--
Anton Avtamonov,
Intel Middleware Products Division
Re: Mission impossible: new APIs without spec in Java 5.0
Hi, What is wrong if you prepare unit tests and investigate how it works? I think that is valid approach for such cases. Am I wrong? -- Anton Avtamonov, Intel Middleware Products Division On 2/16/06, Richard Liang <[EMAIL PROTECTED]> wrote: > Dears, > > There are three protected methods added in java.text.BreakIterator, but > I cannot find their specification. What shall we do? > > protected static long getLong(byte[] buf, int offset) > protected static int getInt(byte[] buf, int offset) > protected static short getShort(byte[] buf, int offset) > > -- > Richard Liang > China Software Development Lab, IBM > > >
Re: I welcome J2SE 6's faster-splash.... re: Java speed-up
On 2/16/06, Fernando Cassia <[EMAIL PROTECTED]> wrote: [snip] > You try to sound clever by making that statement, but imho, despite any > other speed-up work who might be implemented, Sun's solution > is very important, and something that should have been implemented a long, > long time ago. I welcome their implementation, even if late. > > Get this: Splash screens sever an important purpose: they're a visual cue to > tell the user that the program is loading (even if it takes a long time). Yes, splash screen feature is very important from usability point of you. However the problem itself is not completely clear for me: even early I was able to show splash screen if I wanted. Obviously, Swing stuff takes to much time to be initialized, but it start initialization only when the first reference to Swing is processed, i.e. direct or indirect call requires UIManager to be loaded. Therefore you can easily show splash screen at the begging of the program and continue with loading all other 'heavy-weight' stuff then. Does it make sense? For instance, I used SWT just to show splash screen quickly and then continue with Swing-based UI. Of course, such approach requires VM to be completely initialized anyway (in contrast to Mustang's splashes). I welcome any approaches which makes JVM start up faster :-) -- Anton Avtamonov, Intel Middleware Products Division
Re: Using Cairo for Harmony graphic stuff?
Yeah, thank you Tim. I also thought about SwingWT when saw Stefano's letter. Unfortunately such approach have serious problem with supporting PLAF concept, as I know :-(, but really very fast (thanks to swt :-)) -- Anton Avtamonov, Intel Middleware Products Division On 2/13/06, Tim Ellison <[EMAIL PROTECTED]> wrote: > http://swingwt.sourceforge.net/ > > (I merely mention it, not recommending it) > > Regards, > Tim > > Stefano Mazzocchi wrote: > > Anton Avtamonov wrote: > >> On 2/13/06, Stefano Mazzocchi <[EMAIL PROTECTED]> wrote: > >> [snip] > >>> The other thing to consider is to follow apple's advice and implement > >>> Swing using native widgets. I don't know what this entails in terms of > >>> complexity but I always found stupid that swing is barely scratching the > >>> surface of what my GPU accelerator could do for me. > >>> > >> [snip] > >>> -- > >>> Stefano. > >>> > >> > >> Hi Stefano, > >> > >> Am I right you propose to implement Swing on native widgets? I mean > >> using real native push buttons, etc. and get rid of 'standard' Swing > >> approach to have lightweight platform-independent stuff? Sorry if I > >> caught you wrong... > > > > I don't even know what I'm saying myself :-) > > > > All I know is that I want something fast that feels as solid as SWT on > > windows or swing/java2d on macosx. > > > > Unfortunately, I don't think I know enough how to figure out how to get > > there though, but I suspect you guys do ;-) > > > > -- > > Tim Ellison ([EMAIL PROTECTED]) > IBM Java technology centre, UK. >
