Mikhail Loenko wrote:
It is more preferable to have tests implementation-independent:
we can validate them on RI, the tests will not have to be modified if we
modify our implementation.
Hello Mikhail,
Agree. :-)
But I think the test
the previous message returned, so resending...
-- Forwarded message --
Now when you pointed to internization of String literals it would definitely
work. I was talking about original problem. The only way to check
that Harmony implementation of HttpURLConnection compares strings
2006/5/26, Alex Blewitt [EMAIL PROTECTED]:
The only problem is that I'm building this on a Mac (primarily)
That's not a problem. Probably you are lucky guy :)
and so I don't have the ability to download the IBM VM for bootstrapping the
VM process (though a later task is to see if I can help
I've just built fresh Harmony sources without any problems.
2006/5/26, Ivan Volosyuk [EMAIL PROTECTED]:
I am experimenting with eclipse compiler from
org/apache/harmony/tools/javac/Main. The point is that I don't have
java5 at home computer, but I figured out that eclipse compiler in
On 26 May 2006 at 12:18, Alexey Petrenko [EMAIL PROTECTED] wrote:
2006/5/26, Ivan Volosyuk [EMAIL PROTECTED]:
I am experimenting with eclipse compiler ...
I've just built fresh Harmony sources without any problems.
But not with the Eclipse compiler... which I think means it is working
2006/5/26, Mark Hindess [EMAIL PROTECTED]:
We don't have java.util.Scanner and
so the only reason it is compiling is because the RI compiler assumes
its own bootstrap classes so finds its java.util.Scanner.
Yes, this can be a reason.
--
Alexey A. Petrenko
Intel Middleware Products Division
On 5/25/06, Oliver Deakin [EMAIL PROTECTED] wrote:
Vladimir Gorr wrote:
On 5/25/06, Oliver Deakin [EMAIL PROTECTED] wrote:
Geir Magnusson Jr wrote:
Some stuff that got lost (because I got consumed by J1 and I was the
only one pushing on it) was the idea of ensuring that
1) the HDK
Sorry, I didn't catch - what for the second catch block was inserted:
-Original Message-
Author: mloenko
Date: Fri May 26 02:25:03 2006
New Revision: 409607
URL: http://svn.apache.org/viewvc?rev=409607view=rev
Log:
fixes and test for HARMONY-467
[classlib][luni] Harmony should follow
That's right. When we compile with Sun's compiler it compiles against
the Sun class libraries, and when we compile with the Harmony
(ECJ-based) javac it compiles against the Harmony class libraries.
You could pass in the -classpath to our javac to pick up the reference
implementation of the
Stepan,
On 5/26/06, Stepan Mishura [EMAIL PROTECTED] wrote:
Sorry, I didn't catch - what for the second catch block was inserted:
The second catch allows us to see the human-readable message of the
JUnit output, if the other than the UnsupportedEncodingException
exception occurs for some
I've already removed it :)
It was on the original patch and I've overlooked it
2006/5/26, Stepan Mishura [EMAIL PROTECTED]:
Sorry, I didn't catch - what for the second catch block was inserted:
-Original Message-
Author: mloenko
Date: Fri May 26 02:25:03 2006
New Revision: 409607
On 26/05/06, Jimmy, Jing Lv [EMAIL PROTECTED] wrote:
I know little about Mac, though I love its appearance :) I wonder if you
would write the implementation by pure java or native code. IMHO, write
them in native may be a help in performance, and maybe easy to merge
(And we see, RI create a
On 5/26/06, Dmitry M. Kononov wrote:
Stepan,
On 5/26/06, Stepan Mishura [EMAIL PROTECTED] wrote:
Sorry, I didn't catch - what for the second catch block was inserted:
The second catch allows us to see the human-readable message of the
JUnit output, if the other than the
Mark Hindess wrote:
snip
HARMONY-510 is causing every java invocation to exit with a glibc memory
corruption crash. Which causes all the IBM vme/harmony hosted bits of
our builds to break - they work but ant sees the bad return code.
That's a bit extreme -- I am running the tests, using our
On 5/26/06, Tim Ellison [EMAIL PROTECTED] wrote:
That's right. When we compile with Sun's compiler it compiles against
the Sun class libraries, and when we compile with the Harmony
(ECJ-based) javac it compiles against the Harmony class libraries.
Tim,
maybe does it make sense adding the
On 26 May 2006 at 11:07, Tim Ellison [EMAIL PROTECTED] wrote:
Mark Hindess wrote:
snip
HARMONY-510 is causing every java invocation to exit with a glibc memory
corruption crash. Which causes all the IBM vme/harmony hosted bits of
our builds to break - they work but ant sees the bad
On 26 May 2006 at 17:32, Mikhail Loenko [EMAIL PROTECTED] wrote:
P.S. Thanks to Mark!
I was feeling guilty for being pedantic!
I agree we should switch these... especially in light of the Eclipse
compile problem with the current default.
-Mark.
2006/5/26, Mikhail Loenko [EMAIL PROTECTED]:
Alex Blewitt wrote:
Hi everyone,
Hi Alex
I'd like to start work on an implementation of the pack200
decompression algorithm, from the specification which is available at
http://www.jcp.org/aboutJava/communityprocess/first/jsr200/
Great!
The actual java class/interface is relatively
Geir Magnusson Jr wrote:
Jimmy, Jing Lv wrote:
Alex Blewitt wrote:
Hi everyone,
I'd like to start work on an implementation of the pack200
decompression algorithm, from the specification which is available at
http://www.jcp.org/aboutJava/communityprocess/first/jsr200/
I shall give you
On 26/05/06, Tim Ellison [EMAIL PROTECTED] wrote:
The license I get to by following the URL above states (amongst other
things):
This license includes the right to discuss the Specification (including
the right to provide limited excerpts of text to the extent relevant to
the point[s] under
Vladimir Gorr wrote:
On 5/26/06, Tim Ellison [EMAIL PROTECTED] wrote:
That's right. When we compile with Sun's compiler it compiles against
the Sun class libraries, and when we compile with the Harmony
(ECJ-based) javac it compiles against the Harmony class libraries.
Tim,
maybe does it
Excellente :-) I shall get started on it straight away ...
On 26/05/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote:
See my other note. It's fine - we can build an implementation.
geir
Geir Magnusson Jr wrote:
Tim Ellison wrote:
Geir Magnusson Jr wrote:
Jimmy, Jing Lv wrote:
Alex Blewitt wrote:
Hi everyone,
I'd like to start work on an implementation of the pack200
decompression algorithm, from the specification which is available at
Tim Ellison wrote:
Geir Magnusson Jr wrote:
Tim Ellison wrote:
Geir Magnusson Jr wrote:
Jimmy, Jing Lv wrote:
Alex Blewitt wrote:
Hi everyone,
I'd like to start work on an implementation of the pack200
decompression algorithm, from the specification which is available at
24 matches
Mail list logo
