Re: [classlib] Layout of tests in crypto module
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
org.apache.harmony.tests.internal.net.www.protocol.http.HttpURLConnectionTest.testGetOutputStream
can be re-write as the following. And the test should be package
org.apache.harmony.tests.java.net or tests.api.java.net.
public void testGetOutputStream() throws Exception {
// Regression for HARMONY-482
HttpURLConnection c = (HttpURLConnection) new
URL(http://127.0.0.1:;
+ port).openConnection();
c.setDoOutput(true);
//use new String(POST) instead of simple POST to obtain other
//object instances then those that are in HttpURLConnection classes
c.setRequestMethod(new String(POST));
c.getOutputStream();
//use new String(PUT) instead of simple PUT to obtain other
//object instances then those that are in HttpURLConnection classes
c.disconnect();
c.setRequestMethod(new String(PUT));
c.getOutputStream();
//use new String(GET) instead of simple GET to obtain other
//object instances then those that are in HttpURLConnection classes
c.disconnect();
c.setRequestMethod(new String(GET));
c.getOutputStream();
}
The test I was talking about was impl-independent. It obtained an
instance of
an internal class by impl-independent way and then did some
impl-independent
things over it.
I think having tests impl-independent is more preferable goal than not
having
api tests in bootclasspath
Thanks,
Mikhail
2006/5/26, Richard Liang [EMAIL PROTECTED]:
Mikhail Loenko wrote:
Hi Richard
Do you mean a mock subclass of j.n.HttpURLConnection or a mock
subclass of
o.a.h.luni.internalHttpURLConnection ?
If it is a subclass for o.a.h... then it won't pass on RI - it would
be an impl test,
Hi Mikhail,
I'm sorry if my previous description made you confused. :-)
AIUI, it IS an implementation test. Because we are testing Harmony's
detail implementation.
if it is a subclass for j.n.HUC then it won't catch a problem in
o.a.hHIC
Thanks,
Mikhail
2006/5/25, Richard Liang [EMAIL PROTECTED]:
Mikhail Loenko wrote:
Yes there is.
They can access protected fields (they are also package-visible).
Or they
can test something related to class loading.
Example. Recently I committed
modules\luni\src\test\java.injected\java\net\HttpURLConnectionAccessor.java
that is not a test though but something that is used by API test
and
that must
be in bootclasspath. (I could refactor and put the test itself
to the
bootclasspath)
Hello Mikhail,
Instead of using HttpURLConnectionAccessor, we can access protected
fields through a mock subclass of HttpURLConnection.
Thanks,
Mikhail
2006/5/25, Geir Magnusson Jr [EMAIL PROTECTED]:
Mikhail Loenko wrote:
2006/5/24, Geir Magnusson Jr [EMAIL PROTECTED]:
George Harley wrote:
Hi Mikhail,
That is a very good point and your suggestion of
supplementing the
class
or package name sounds like a very straightforward way around
the
problem. Because there will be a number of tests that must be
in an
identical package name to the type under test then it
seems that
the
differentiating mark needs to be added to the test class
name. Not
really sure what this could be. Given that we are all
settled on
the
convention that a test type has the Test suffix, how about
just add
Impl to that suffix for implementation tests giving us an
ImplTest
suffix.
e.g.
class under test : java.lang.SomeClassTest
implementation-independent test class :
o.a.h.module.tests.java.lang.SomeClassTest
Harmony-specific test class :
o.a.h.module.tests.java.lang.SomeClassImplTest
Or
o.a.h.module.apitest.java.lang.FooTest
o.a.h.module.impltest.java.lang.FooTest
Of course, the implementation test didn't need to be on the
bootclasspath, it would simply be
java.lang.FooTest
with no other garbage in the package name
Hi Geir
how to distinguish between bootclasspath implementation test
java.lang.FooTest
and bootclasspath api test
java.lang.FooTest
Is there such thing as an bootclasspath API test?
geir
-
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]
--
Richard Liang
China Software Development
Re: [classlib] Layout of tests in crypto module
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
by equals() was injecting something to the bootclasspath.
Probably it is a bad example and I had to find something else but the
idea is simple: there might be cases when we need to verify something
related either to protected stuff or to classloading so that the test is
impl-independent and requires something in bootclasspath.
BTW, another example could be: we might want to verify that the crypto framework
successfully loads a provider when provider is in bootclasspath.
Thanks,
Mikhail
2006/5/26, Richard Liang [EMAIL PROTECTED]:
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
org.apache.harmony.tests.internal.net.www.protocol.http.HttpURLConnectionTest.testGetOutputStream
can be re-write as the following. And the test should be package
org.apache.harmony.tests.java.net or tests.api.java.net.
public void testGetOutputStream() throws Exception {
// Regression for HARMONY-482
HttpURLConnection c = (HttpURLConnection) new
URL(http://127.0.0.1:;
+ port).openConnection();
c.setDoOutput(true);
//use new String(POST) instead of simple POST to obtain other
//object instances then those that are in HttpURLConnection classes
c.setRequestMethod(new String(POST));
c.getOutputStream();
//use new String(PUT) instead of simple PUT to obtain other
//object instances then those that are in HttpURLConnection classes
c.disconnect();
c.setRequestMethod(new String(PUT));
c.getOutputStream();
//use new String(GET) instead of simple GET to obtain other
//object instances then those that are in HttpURLConnection classes
c.disconnect();
c.setRequestMethod(new String(GET));
c.getOutputStream();
}
The test I was talking about was impl-independent. It obtained an
instance of
an internal class by impl-independent way and then did some
impl-independent
things over it.
I think having tests impl-independent is more preferable goal than not
having
api tests in bootclasspath
Thanks,
Mikhail
2006/5/26, Richard Liang [EMAIL PROTECTED]:
Mikhail Loenko wrote:
Hi Richard
Do you mean a mock subclass of j.n.HttpURLConnection or a mock
subclass of
o.a.h.luni.internalHttpURLConnection ?
If it is a subclass for o.a.h... then it won't pass on RI - it would
be an impl test,
Hi Mikhail,
I'm sorry if my previous description made you confused. :-)
AIUI, it IS an implementation test. Because we are testing Harmony's
detail implementation.
if it is a subclass for j.n.HUC then it won't catch a problem in
o.a.hHIC
Thanks,
Mikhail
2006/5/25, Richard Liang [EMAIL PROTECTED]:
Mikhail Loenko wrote:
Yes there is.
They can access protected fields (they are also package-visible).
Or they
can test something related to class loading.
Example. Recently I committed
modules\luni\src\test\java.injected\java\net\HttpURLConnectionAccessor.java
that is not a test though but something that is used by API test
and
that must
be in bootclasspath. (I could refactor and put the test itself
to the
bootclasspath)
Hello Mikhail,
Instead of using HttpURLConnectionAccessor, we can access protected
fields through a mock subclass of HttpURLConnection.
Thanks,
Mikhail
2006/5/25, Geir Magnusson Jr [EMAIL PROTECTED]:
Mikhail Loenko wrote:
2006/5/24, Geir Magnusson Jr [EMAIL PROTECTED]:
George Harley wrote:
Hi Mikhail,
That is a very good point and your suggestion of
supplementing the
class
or package name sounds like a very straightforward way around
the
problem. Because there will be a number of tests that must be
in an
identical package name to the type under test then it
seems that
the
differentiating mark needs to be added to the test class
name. Not
really sure what this could be. Given that we are all
settled on
the
convention that a test type has the Test suffix, how about
just add
Impl to that suffix for implementation tests giving us an
ImplTest
suffix.
e.g.
class under test : java.lang.SomeClassTest
implementation-independent test class :
o.a.h.module.tests.java.lang.SomeClassTest
Harmony-specific test class :
o.a.h.module.tests.java.lang.SomeClassImplTest
Or
o.a.h.module.apitest.java.lang.FooTest
o.a.h.module.impltest.java.lang.FooTest
Of course, the
Re: Intention to work on Pack200 uncompressor/compressor
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 with the migration of the VM to Mac OS X). You can try to build Harmony VMs which are provided with sources. DRLVM for example. It will be an interesting experience. Can I develop it against the Java 1.4 on my machine for the o.a.h module first, and then contribute it in stages? If it will work with Java on MacOS X then it should work on Harmony VM. -- Alexey A. Petrenko Intel Middleware Products Division
Re: classlib build problem?
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 ecj_3.2RC5.jar can be good substitution. I have tweaked the tools javac wrapper and managed to start ant with that compiler. There are number of errors in eclipse compiler complaining about wrong usage of @Override and @Deprecated keywords. I simply removed all of them to get through. The problem which stopped me is: [javac] 1009. ERROR in /home/ivan/experiments/harmony/trunk/modules/rmi/src/main/java/java/rmi/server/RMIClassLoader.java [javac] (at line 22) [javac] import java.util.Scanner; [javac]^ [javac] The import java.util.Scanner cannot be resolved Does there problem result from my experiments or the classlib build is broken now? -- Ivan - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Alexey A. Petrenko Intel Middleware Products Division
Re: classlib build problem?
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 by accident rather than by design. 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. Regards, Mark. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: classlib build problem?
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
Re: Multi-tree HDK config - working directory ( was Re: Supporting working on a single module?)
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 could be anywhere - the was no hard-wired spot. That allowed having multiple simultaneous HDKs (ex different snapshot version) at the same time as a full build Perhaps the HDK would have a default location which could be overridden by passing a command line option to the build scripts - possibly in a similar way to Marks suggestion for selection of the rmi module location [1]. My modifications to build an HDK from the classlib code (HARMONY-469) use an Ant property hy.hdk to specify the root directory of the HDK. With the current patch, this property doesnt quite propagate all the way down to the native makefiles, but this shouldnt be too hard to extend. Once this was done, a developer could then override the default HDK location using a command line similar to: ant -Dhy.hdk=/my/hdk/location -f make/build.xml The default HDK location would probably depend on what area you are working on - in classlib the trunk/deploy directory is the default build location at the moment, and I think it makes sense to keep this as the default HDK directory. 2) the build should ensure that the materials of the HDK never get overwritten so that we can always tell a contributor w/ a question first, before we debug this, do a ant hdk-copy.. or something to easily get them to a known good state. This to me sounds like we need some kind of working directory and a 'hdk-copy' target. The working model then allows freedom of choosing an hdk or a current full build as the 'base' to work with... I imagine that an HDK would come in a zip format, much like the current snapshots [2]. If this was the case, then once you have downloaded the HDK zip, you can unpack it into your working directory where it will be modified. Oliver, whether does it mean the HDK will contain the sources (src.zip?) as well? Otherwise I don't understand what can be modified. Could you please clarify this? Hi Vladimir, When you rebuild, the old versions of binaries (dll/so/jar etc.) would be overwritten with the new versions that are built from your altered code, and potentially altered header files will be replaced (e.g. jni.h). Hi Oliver, if I correctly understand ALL will be re-built in this case but not only the altered sources. I mean the following. Suppose, at first, I check out the Harmony sources on my machine. The next step is the downloading the HDK pre-compiled from these sources some time ago. Note the dates for both binaries sources files will be up-to-date (I mean they will differ from original ones) and therefore the 'ant -Dhy.hdk=/my/hdk/location -f make/build.xml' command will re-compile all sources from scratch (due to all dependencies were lost). IMHO the idea of HDK was different (at least I understood so). AFAIU it's supposed re-using the pre-compiled binaries for the lazy developers. Or am I wrong? Thanks, Vladimir. This is similar to the current system, where you can use a snapshot build to rebuild Java code against, and you can then drop your rebuilt jars over those of the snapshot to create an updated jre. The HDK will contain binaries to build against, and some necessary header files, but no complete src.zip. I have put up a proposed description of the HDK on the website [1], which summarises some of the ideas in this thread so far. I hope it helps clarify :) Regards, Oliver [1] http://incubator.apache.org/harmony/subcomponents/classlibrary/hdk.html Thanks, Vladimir. However, you still have the original zip to fall back on if you need to. I'm not sure that we need an extra build target for this process - to get back to a known good state, you can just unpack the zip again into your working directory. Am I missing something? Regards, Oliver [1] http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200605.mbox/[EMAIL PROTECTED] [2] http://people.apache.org/dist/incubator/harmony/snapshots/ Does this make any sense to anyone else? geir Oliver Deakin wrote: Hi all, I have opened HARMONY-485, which proposes an additional doc for the website describing the HDK and its contents. The layout of the HDK described in the doc matches that produced by the build script alterations raised in HARMONY-469. I hope that eventually (once the natives are modularised and build scripts are altered to understand/use the HDK) the doc will expand into a more full description of how developers can use the HDK to rebuild Java/native code. Regards, Oliver - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe,
Re: svn commit: r409607 - in /incubator/harmony/enhanced/classlib/trunk/modules/luni/src: main/java/java/net/ main/java/java/util/ test/java/tests/api/java/net/ test/java/tests/api/java/util/
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 the Exception-throwing
compatibility guidelines
SNIP
+public void test_decodeLjava_lang_String_Ljava_lang_String() {
+try {
+URLDecoder.decode(, );
+fail(UnsupportedEncodingException expected);
+} catch (UnsupportedEncodingException e) {
+// expected
+} catch (Exception e) {
+assertEquals(UnsupportedEncodingException.class, e.getClass());
+}
+}
SNIP
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]
Re: classlib build problem?
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 class libraries, but we should aim to fill in these gaps asap. Regards, Tim Alexey Petrenko wrote: 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. -- 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]
Re: svn commit: r409607 - in /incubator/harmony/enhanced/classlib/trunk/modules/luni/src: main/java/java/net/ main/java/java/util/ test/java/tests/api/java/net/ test/java/tests/api/java/util/
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 reason.
Actually, you are right, since Harmony does not throw
UnsupportedEncodingException at all the second catch may be removed.
What do you think, should it be removed? If yes, I am Ok with this.
+public void test_decodeLjava_lang_String_Ljava_lang_String() {
+try {
+URLDecoder.decode(, );
+fail(UnsupportedEncodingException expected);
+} catch (UnsupportedEncodingException e) {
+// expected
+} catch (Exception e) {
+assertEquals(UnsupportedEncodingException.class, e.getClass());
+}
+}
Thanks.
--
Dmitry M. Kononov
Intel Managed Runtime Division
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r409607 - in /incubator/harmony/enhanced/classlib/trunk/modules/luni/src: main/java/java/net/ main/java/java/util/ test/java/tests/api/java/net/ test/java/tests/api/java/util/
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
URL: http://svn.apache.org/viewvc?rev=409607view=rev
Log:
fixes and test for HARMONY-467
[classlib][luni] Harmony should follow the Exception-throwing
compatibility guidelines
SNIP
+public void test_decodeLjava_lang_String_Ljava_lang_String() {
+try {
+URLDecoder.decode(, );
+fail(UnsupportedEncodingException expected);
+} catch (UnsupportedEncodingException e) {
+// expected
+} catch (Exception e) {
+assertEquals(UnsupportedEncodingException.class, e.getClass());
+}
+}
SNIP
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]
Re: Intention to work on Pack200 uncompressor/compressor
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 excuteable pack200.exe in its jre). The code can be put in native-src\(win.IA32/share/Linux.IA32/Mac?) \archive, naming pack200.c or so. I'm aiming to implement it in pure Java, because one of the other goals is to allow other clients (e.g. Eclipse) to be able to bundle the pack/unpack code. BTW, I don't know if Harmony can be run on Mac currently. However, that is an aim :) Yes, it certainly is :-) You may document the interpret of the algorithm, and offer some testcases :) Actually, it would be good to have some packed Jars that I could then test my unpacking algorithm on. Does anyone know if I can run the Sun-supplied packer to compress Jar files and then use that as an input into my unpacker algorithm? I'm guessing it's OK to do that, but I need to be able to demonstrate that I've not used any internal knowledge of the implementation to achieve the goal of a clean-room implementation. The other alternative is for others to pack some simple Jars, and then verify that the unpacking algorithm works independently -- but I could use some sample 'hello world' type Jars for my own testing. As far as I understand the algorithm, it was a little complex and may take a period of time to implement. So good luck, and let's discuss on mailing-list if there's something hard. :) It's certainly fun :-) Most of the encodings are variable length, which makes it fun for trying to run through a compressed Jar (it also means that I have to complete the unpacker for the first bits before I can work on unpacking the remainder). Mind you, one neat feature (which I didn't appreciate before) is that the algorithm is designed such that you can concatenate two pack200 files together and it's still a valid file. So you can pack a bunch of Jars independently, and then concatenate them all into one big file for subsequent compression/transmission. Alex.
Re: svn commit: r409607 - in /incubator/harmony/enhanced/classlib/trunk/modules/luni/src: main/java/java/net/ main/java/java/util/ test/java/tests/api/java/net/ test/java/tests/api/java/util/
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 UnsupportedEncodingException
exception occurs for some reason.
I'd prefer to see an error's message and stack trace.
Actually, you are right, since Harmony does not throw
UnsupportedEncodingException at all the second catch may be removed.
What do you think, should it be removed? If yes, I am Ok with this.
Yes, it should be removed because it doesn't make sense -
UnsupportedEncodingException is caught by the first catch block.
Thanks,
Stepan.
+public void test_decodeLjava_lang_String_Ljava_lang_String() {
+try {
+URLDecoder.decode(, );
+fail(UnsupportedEncodingException expected);
+} catch (UnsupportedEncodingException e) {
+// expected
+} catch (Exception e) {
+assertEquals(UnsupportedEncodingException.class, e.getClass
());
+}
+}
Thanks.
--
Dmitry M. Kononov
Intel Managed Runtime Division
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
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]
Re: [tools] tools launching and javac
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 Ant scripts, on Windows and Linux and they are passing with build successful for me. I'm not claiming to be bug free, but I'm not checking in useless code either :-( It's going to be the case that people will want to go off into a 'corner' and try something. it's nice that they can do it so others can watch, help, participate, and still it is out of the mainstream codebase until that person or people want to bring it in (or propose to bring it in). The merging would be their problem, just as it would be if they were just working at home or in the office on a private copy. The benefits seem obvious. Sure, yes. I missed the point. You are absolutely right. I thought Tim was concerned because he'd already dumped junk into svn. ;-) I was pointing out that I didn't think it was a big deal - and anyway it's really cool junk that I like to see. I shall choose my words more carefully; my light-hearted use of 'junk' meant to convey work-in-progress (i.e. is unfinished / has limitations). Of course we don't expect anyone to check in real junk code. Tim -- 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]
Re: classlib build problem?
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 RI rt.jar to CLASSPATH for the ECJ-based compiler? In this case all we didn't implemented will be taken from RI. Is this a stupid idea? Thanks, Vladimir. You could pass in the -classpath to our javac to pick up the reference implementation of the class libraries, but we should aim to fill in these gaps asap. Regards, Tim Alexey Petrenko wrote: 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. -- 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]
Re: [tools] tools launching and javac
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 return code. That's a bit extreme -- I am running the tests, using our Ant scripts, on Windows and Linux and they are passing with build successful for me. Recent versions of glibc check various memory problems... free non-malloc'd memory is one of them. In this case, it's trivial but it can help catch serious problem so it is a good thing even if it is a little annoying at times. (And I don't know of a way to temporarily disable it. Does anyone else?) And I don't really expect you to test on every version of Linux. ;-) I'm not claiming to be bug free, but I'm not checking in useless code either :-( I don't think I said that. If I did, it wasn't what I meant. -Mark. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Moving forward with RMI and Math ( was Re: towards a new implementation of java.math)
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]: ant -Dhy.rmi.module=3Drmi3 -f make/build.xml works now, the next step is make ant -Dhy.rmi.module=3Drmi -f make/build.xml work as agreed. Thanks, Mikhail 2006/5/25, Geir Magnusson Jr [EMAIL PROTECTED]: Mark Hindess wrote: On 24 May 2006 at 12:50, Mikhail Loenko [EMAIL PROTECTED] wrote: As a first step I suggest taking it as a base - move rmi to rmi4 or whatever and move rmi3 to rmi. This is fine with me but, being slightly pedantic, I think that's the second step. The first step is to do the same restructure that I did with the itc 1.4 rmi when I moved it to modules/rmi. That is, make rmi3 build with: ant -Dhy.rmi.module=3Drmi3 -f make/build.xml That's not 'slightly' pedantic. :) Why not ensure that ant -Dhy.rmi.module=3Drmi -f make/build.xml works when done? geir - 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: Intention to work on Pack200 uncompressor/compressor
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 simple, but the implementation behind the unpack() and pack() methods decidedly isn't :-) My goal will be to provide the unpacking algorithm first, and then work on a packer subsequently. I'll probably try to write it in an o.a.h module first, and then hook it into the java.util.jar classes/packages later. Makes sense. The only problem is that I'm building this on a Mac (primarily) 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 with the migration of the VM to Mac OS X). Can I develop it against the Java 1.4 on my machine for the o.a.h module first, and then contribute it in stages? Yep, in fact you could develop it against a set of 1.5 libraries. If you can, keep an eye on what you are using compared to what we have already got in Harmony, but ultimately you can use any 1.5 APIs and we will be filling in behind you. The other problem is that the API is pretty sparse; the packer either unpacks, or it doesn't :-) So from a contribution point of view, there may not be much to publically show, but I'd like (if possible) to have some of the implementation work made available as I go, in case anyone else wants to help out :-) Yep, feel free to contribute the code before it is hooked in to the j.u.jar APIs and we can be merging it and compiling it as we go. I'd also like to try and design the implementation such that it could be downloaded and used by other OSGi implementations (e.g. Eclipse). That should be relatively easy, since I expect your work will primarily be in a given package or two, and we can figure out your imports when you are done. If someone can give me some advice as to a suitable package name I can make an initial start on an implementation, and then in stages can post it to Jira. If there are any internal-APIs that you expect to be useful outside the ARCHIVE module (i.e. outside j.u.jar / j.u.zip) then define them in org.apache.harmony.archive.pack200. You can go nuts with any implementation details in package (or multiple packages prefixed with) org.apache.harmony.archive.internal.pack200. Regards, Tim -- 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]
Re: Intention to work on Pack200 uncompressor/compressor
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 a warm welcome for implementation of Pach200! :) But as I know few about the legality, I wonder it is legal for us(Harmony developers) to read such algorithm directly from jcp.org? Can anyone give an answer? Let's go ahead if there's no obstacle. What? If we implement a spec from the JCP, we get the TCK and pass it. That's it. 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 discussion) with other licensees (under this or a substantially similar version of this Agreement) of the Specification. Other than this limited license, you acquire no right, title or interest in or to the Specification or any other Sun intellectual property, and the Specification may only be used in accordance with the license terms set forth herein. IANAL but that doesn't appear to give us rights to implement the spec via that source? What am I missing? Regards, Tim -- 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]
Re: Intention to work on Pack200 uncompressor/compressor
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 discussion) with other licensees (under this or a substantially similar version of this Agreement) of the Specification. Other than this limited license, you acquire no right, title or interest in or to the Specification or any other Sun intellectual property, and the Specification may only be used in accordance with the license terms set forth herein. IANAL but that doesn't appear to give us rights to implement the spec via that source? What am I missing? I wasn't sure about that either (which is why I posted the URL). However, I can't find any other specification for the pack200 other than this one -- and the JavaDoc for Pack200 pointed me in this direction in the first place: http://java.sun.com/j2se/1.5.0/docs/api/java/util/jar/Pack200.html Transforms a JAR file to or from a packed stream in Pack200 format. Please refer to Network Trasfer Format JSR 200 Specification at http://jcp.org/aboutJava/communityprocess/review/jsr200/index.html; Does this mean that we can't implement Pack200 by this specification, and if so, does that prevent a complete Java 1.5 library from being built? Or does it mean that I can't implement it from this specification, but I can discuss how to build a pack200 compliant algorithm for others to work from? Alex.
Re: classlib build problem?
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 make sense adding the RI rt.jar to CLASSPATH for the ECJ-based compiler? In this case all we didn't implemented will be taken from RI. Is this a stupid idea? Not stupid, but would mask things like this. We just need someone to write j.u.Scanner :) geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Intention to work on Pack200 uncompressor/compressor
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
Re: Intention to work on Pack200 uncompressor/compressor
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 http://www.jcp.org/aboutJava/communityprocess/first/jsr200/ I shall give you a warm welcome for implementation of Pach200! :) But as I know few about the legality, I wonder it is legal for us(Harmony developers) to read such algorithm directly from jcp.org? Can anyone give an answer? Let's go ahead if there's no obstacle. What? If we implement a spec from the JCP, we get the TCK and pass it. That's it. 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 discussion) with other licensees (under this or a substantially similar version of this Agreement) of the Specification. Other than this limited license, you acquire no right, title or interest in or to the Specification or any other Sun intellectual property, and the Specification may only be used in accordance with the license terms set forth herein. IANAL but that doesn't appear to give us rights to implement the spec via that source? What am I missing? Alex gave us the link to the Proposed Final Draft, which isn't licensed for implementation, not the final spec itself. That can be found here http://jcp.org/aboutJava/communityprocess/final/jsr200/index.html and is under the usual spec license (which I can probably repeat by heart at this point). Ah yes, that license reads much better. My question though is not about this, but if it's part of the Java SE 5 spec and therefore would be tested w/ the Java SE 5 TCK. I guess I can go dig into the documentation around JSE 5. I'm guessing not, and therefore we'll need the standalone TCK for JSR 200. It is -- there is a java.util.jar.Pack200 type in Java 5 SE, that references the JSR200 spec for details. All systems go. Tim -- 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]
Re: Intention to work on Pack200 uncompressor/compressor
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 http://www.jcp.org/aboutJava/communityprocess/first/jsr200/ I shall give you a warm welcome for implementation of Pach200! :) But as I know few about the legality, I wonder it is legal for us(Harmony developers) to read such algorithm directly from jcp.org? Can anyone give an answer? Let's go ahead if there's no obstacle. What? If we implement a spec from the JCP, we get the TCK and pass it. That's it. 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 discussion) with other licensees (under this or a substantially similar version of this Agreement) of the Specification. Other than this limited license, you acquire no right, title or interest in or to the Specification or any other Sun intellectual property, and the Specification may only be used in accordance with the license terms set forth herein. IANAL but that doesn't appear to give us rights to implement the spec via that source? What am I missing? Alex gave us the link to the Proposed Final Draft, which isn't licensed for implementation, not the final spec itself. That can be found here http://jcp.org/aboutJava/communityprocess/final/jsr200/index.html and is under the usual spec license (which I can probably repeat by heart at this point). Ah yes, that license reads much better. My question though is not about this, but if it's part of the Java SE 5 spec and therefore would be tested w/ the Java SE 5 TCK. I guess I can go dig into the documentation around JSE 5. I'm guessing not, and therefore we'll need the standalone TCK for JSR 200. It is -- there is a java.util.jar.Pack200 type in Java 5 SE, that references the JSR200 spec for details. All systems go. Indeed. And I don't have to waste time getting the TCK either since it's in SE 5. Thanks! geir Tim - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
