Re: [general] Harmony Todo list
On Thursday 16 November 2006 19:39, Stefano Mazzocchi wrote: [...] (WTF does BSD licensing for a logo mean, anyway?), It means that you don't have to distribute the source code of the logo :-), but it has to be accompanied by 200+ words of copyright notice and you can't use Sun's name to endorse your competition-winning graphic ... meaning that all 'java look-alikes' will have duke [...] Mika will never have duke, so long as I live. The coffe cup maybe, but not the pointy-headed red-nosed cretin. There are limits. :-) -- Chris Gray/k/ Embedded Java Solutions BE0503765045 Embedded Mobile Java, OSGihttp://www.k-embedded-java.com/ [EMAIL PROTECTED] +32 3 216 0369
Re: [Fwd: Re: Interesting discoveries playing around with japitools]
On Thursday 09 November 2006 11:20, David Gilbert wrote: Why don't we be honest and just admit that there is no goodwill between the projects? It was there, briefly, but now it is gone. There's no collaboration, there's no cooperation...just two separate projects implementing the same API. It is the way it is, and the world is moving on...but let's stop pretending. I thinks there's quite a bit of goodwill at the individual developer level, but this doesn't translate easily into collaboration. If a developer already contributing to one project would want to make a particular contribution available to both, she needs to not only dual-license her work but to get clearance from the other project to contribute - that's quite a lot of work already. And then she has to track acceptance or otherwise of the contribution and subsequent bug reports on both lists, which is also extra work. One could hardly blame her for sticking with the project she knows. Both FSF and ASF tend to generate strong developer loyalty (which is a Good Thing in each case), but that doesn't necessarily mean the world is divided into two opposing camps. Peace, Chris -- Chris Gray/k/ Embedded Java Solutions BE0503765045 Embedded Mobile Java, OSGihttp://www.k-embedded-java.com/ [EMAIL PROTECTED] +32 3 216 0369 Note: our official registered address has changed from Paleisstraat 119 to Koningstraat 21, 2000 Antwerpen. The operational address Bredestraat 4 remains valid, as do all telephone and fax numbers (and the VAT reg. number).
Re: [classlib] Preprocessor (was Re: [classlib][rmi] Code smell - Thread.sleep() in ActivationGroup method)
On Sunday 29 October 2006 14:04, Geir Magnusson Jr. wrote: [...] 3) Java ME - We've had some interest (Chris?) in looking at using the Harmony classlib for ME, which can also have some differences that might be most conveniently kept in place in the main codebase. Yes, I'm still here and still waiting for an answer to my last mail about bringing Mika to the incubator ... [...] First, anyone think this is a good idea and second, anyone have any experience with tools in this area? For JavaME I think it's the only way we'd be able to maintain a single source tree. We need to be able to #ifdef out references to classes we don't have, methods we don't implement, etc.. That much being said, I don't have a recommendation for a tool to use. Java syntax is sufficiently C-like that cpp is probably do-able, but we'd probably stumble over a whole series of gotcha's, and cpp isn't exactly [deity]'s gift to preprocessing anyway. Maybe one of the aspect-oriented tools (with which I am not at all familiar) could be a better bet? Cheers, Chris -- Chris Gray/k/ Embedded Java Solutions BE0503765045 Embedded Mobile Java, OSGihttp://www.k-embedded-java.com/ [EMAIL PROTECTED] +32 3 216 0369
Re: Wonka, Mika, and Apache
Geir, Tim, Noel, etc., I've had a reply from the CEO of Punch Telematix, concerning the . He asks if he really has to fill in the bulk_contribution_checklist, given that he personally has no knowledge of the process by which Wonka was developed. (In fact no one who ever worked on Wonka at Acunia is now working for Punch Telematix). He has no objection to making the donation however, and I do know all about the development process at Acunia, having been in charge of the project virtually the whole time (the missing months are covered by Gerrit, who is now working for /k/). I think there are two ways to proceed: either (i) Punch and /k/ answer the questionnaire jointly, or (ii) /k/ makes the contribution and treats Punch as an other author. Let's see how that goes: Part III : Statement of Origination a) Have you personally written all of the code or other material that you are intending to contribute to this project, and if so, are you an Authorized Contributor for all parts of the contribution? [ ] Yes [ ] No == No == continue with the rest of Part III b) Have you verified the development history of the code to identify ALL of the authors? Please list the other authors: == Acunia is listed alongside the smaller contributors c) Do you have a written agreement with all of the authors that either gives you ownership of the material or otherwise provides you sufficient rights to submit this material to the project on their behalf. Please provide the details of this agreement: == We get Punch Telematix to sign such an agreement, along with the others d) Are all of the authors Authorized Contributors for the part of the contribution written/created by each author? == No == continue with the rest of part III e) Was the code written prior to May 2005 (when the Harmony Project was initiated)? [ ] Yes [ ] No Yes, except for the code developed by /k/ after that date (i) If No, you must provide Authorized Contributor Questionnaires for the authors of the code created after May 2005 such that those authors are classified as Authorized Contributors for the portions of the contribution written by them after May 2005. == OK, /k/ needs to become an Authorized Contributor anyhow f) Did any of the authors of the code have access to third party implementations of similar technology while developing the contribution? == In a sense everyone has access to Sun's JDK, but at Acunia the Wonka developers were not allowed to look at those sources nor to have them on their machine. We asked outside contributors to do likewise. g) Was the code developed in accordance with a development process which was designed to prevent unauthorized inclusion of third party intellectual property rights into the code? (e.g., does the process require that developers not have concurrent access to third party implementations of similar technology during development?) == Yes If yes, please provide short description of the process, focusing on protections related to third party intellectual property : == Blah blah So what's the best way forward? Thanks for your time, Chris -- Chris Gray/k/ Embedded Java Solutions BE0503765045 Embedded Mobile Java, OSGihttp://www.k-embedded-java.com/ [EMAIL PROTECTED] +32 3 216 0369 - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[OT] Any JDWP/Eclipse experts out there?
Sorry for the noise, but I know there are some VM designers etc listening here. I'm trying to get JDWP working between the Wonka VM and Eclipse. I've reached the point where I can set a breakpoint and run the app until I hit it; Eclipse shows the correct stack frames and shows the correct mine in the edit window, but then throws up an error message 'An internal error occurred during Debug'. Now I'm wondering what to do next ... can anyone give me tips on how to get more debugging info out of Eclipse, documentation about how Eclipse uses JDWP, supplementary documentation on JDWP in general, etc.? Thanks for your time, Chris -- Chris Gray/k/ Embedded Java Solutions BE0503765045 Embedded Mobile Java, OSGihttp://www.k-embedded-java.com/ [EMAIL PROTECTED] +32 3 216 0369 - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wonka, Mika, and Apache
On Thursday 05 October 2006 18:38, Geir Magnusson Jr. wrote: w00t :) Don't get too excited - it wouldn't be the first time that I've got no answer to such a mail. But I'll follow up with a phone call on Monday if no reply by then. Do we need them to make a bulk contribution, or can we handle them as an other contributor? I can testify to the provenance of the code, as I was project leader at Acunia from the very beginning. -- Chris Gray/k/ Embedded Java Solutions BE0503765045 Embedded Mobile Java, OSGihttp://www.k-embedded-java.com/ [EMAIL PROTECTED] +32 3 216 0369 - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wonka, Mika, and Apache
On Thursday 05 October 2006 19:06, Tim Ellison wrote: Apologies for drifting off-topic... Is there a spec for the shape and behavior of headless SE and embeddable SE etc.? I have only seen passing references to what they are and how they act like SE. SFAIK a headless SE is simply one for which java.awt.headless has been set true; that tells the JRE to implement image operations in software instead of using the graphical capabilities of the underlying platform. Embedded SE seems to refer to a build for PowerPC that Sun demoed at ESC. If it's distributed on the same licence terms as normal JavaSE then it won't be legal to distribute stripped versions which only contain the packages needed by the application. (Presumably the same restriction will apply to certified versions of Harmony once these exist). [geir] I fully expect that over time, this project will have multiple virtual machines, as well as multiple builds for classlib to support various deployment platforms. and potentially configurations, though to tackle ME would require the ability to subset the behavior of the existing types as well. For CLDC, yes. For CDC it should be possible to just subset the classlib. -- Chris Gray/k/ Embedded Java Solutions BE0503765045 Embedded Mobile Java, OSGihttp://www.k-embedded-java.com/ [EMAIL PROTECTED] +32 3 216 0369 - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wonka, Mika, and Apache
On Friday 06 October 2006 09:29, Geir Magnusson Jr. wrote: Who owns the copyright and can therefore make the donation? Copyright in the original Wonka code belonged to Acunia, and hence now belongs to Punch Telematix; there were also a few small contributions from outsiders whom I'm fairly confident I can track down. Copyright in all changes since late 2003 belong to me or to a company called Proveo, who should also be willing to contribute their stuff (I'm writing to them now). Do you require the same docucmentation to be completed by all authors, or is there a distinction between main and subsidiary contributors? Chris -- Chris Gray/k/ Embedded Java Solutions BE0503765045 Embedded Mobile Java, OSGihttp://www.k-embedded-java.com/ [EMAIL PROTECTED] +32 3 216 0369 - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wonka, Mika, and Apache
Hi Noel, Does this still include the hardware portability layer? Any synergies with APR? Does it include the AWT code? And here is my reply to Noel's message: Hi Noel, The code runs on x86, ARM, MIPS, and PowerPC; basically it should run on any normal 32-bit processor (with or without MMU) for which a GNU toolchain exists. The OSwald internal RTOS is still there as an API, but we no longer use it to schedule Java threads within a Linux process, as recent changes to gclib mean that the __errno_location hack no longer works. On Linux we currently use o4p to map OSwald threads 1:1 onto pthreads. The OSwald API is a kind of alternative to APR. There may be synergies. The AWT code is included. It is mainly designed for LCD/touchscreen environments, either directly on a framebuffer or in a single X window (which we treat as a virtual framebuffer). Best regqrds, Chris -- Chris Gray/k/ Embedded Java Solutions BE0503765045 Embedded Mobile Java, OSGihttp://www.k-embedded-java.com/ [EMAIL PROTECTED] +32 3 216 0369 - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Wonka, Mika, and Apache
Hello guys, To introduce myself: I'm one of the original developers of the Wonka embedded VM, and my company sells both support for Wonka and our own derivative which we call Mika. Recently we made Mika available under the same BSD-style licence as Wonka. My question is whether Apache would be interested in adopting Wonka/Mika as a project, either within Harmony or as an embedded counterpart thereto. Currently ownership of the code is divided between Punch Telematix, who acquired the assets of my former employer Acunia, and my own company. Punch have no interest in the VM beyond the fact that it is an essential component of a product (the CarCube) which they inherited from Acunia. I believe they would have no objection to granting rights to the AF, beyond the sheer effort of doing so. They can probably be persuaded, but first I'd like to know if there is sufficient interest within the AF. Best regards, Chris -- Chris Gray/k/ Embedded Java Solutions BE0503765045 Embedded Mobile Java, OSGihttp://www.k-embedded-java.com/ [EMAIL PROTECTED] +32 3 216 0369 - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] invoking non-trivial jars results in IllegalAccessError
As I understand it, the classpath of the jarred application should include the jar file itself and the contents of its Class-Path attribute (if any). You probably need to create a special class loader for the application and use that whenever the application (or a library loaded by it) is the initiator. -- Chris Gray/k/ Embedded Java Solutions BE0503765045 Embedded Mobile Java, OSGihttp://www.k-embedded-java.com/ [EMAIL PROTECTED] +32 3 216 0369 - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] HARMONY-1363 - status update
On Monday 18 September 2006 18:14, Geir Magnusson Jr. wrote: Pavel Pervov wrote: Tried it on Windows and found the problem which, as it looks like, have never been caught before. As I discovered, launcher uses platform specific line separators to parse harmonyvm.properties on a specific platform. But haromynvm.properties, which is copied into deploy, has unix line endings and is skipped. As the result, EM can't initialize.' A ha! I workarounded this by running unix2dos on harmonyvm.properties. Ok - we should get that in as eol-native Wouldn't it be better (and safer) to fix the parser? Normally a properties file can contain any kind of line separators and still be parsed correctly, which is a Good Thing IMHO. E.g. according to the spec for java.util.Properties.load(), A natural line of input is terminated either by a set of line terminator characters (\n or \r or \r\n) or by the end of the file. Chris -- Chris Gray/k/ Embedded Java Solutions BE0503765045 Embedded Mobile Java, OSGihttp://www.k-embedded-java.com/ [EMAIL PROTECTED] +32 3 216 0369 - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: New IBM VME available soon
Olivier dixit: ok, I just tested myself on Windows and it seems that the RI ignores environment variable changes, so I guess it's fine if we stick with what we have in Harmony. Now that I think about it, I remember someone complaining once on a Java newsgroup that changing the CLASSPATH environment variable had no effect on a running JVM. He got an education in Java class loading. :-) Chris -- Chris Gray/k/ Embedded Java Solutions BE0503765045 Embedded Mobile Java, OSGihttp://www.k-embedded-java.com/ [EMAIL PROTECTED] +32 3 216 0369 - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Bringing License arguments to Sun
On Wednesday 23 August 2006 13:22, Leo Simons wrote: Licensing - On Sat, Aug 19, 2006 at 07:38:36PM -0700, Stefano Mazzocchi wrote: [what license should Sun use to open source java] I'll bite: the MIT license. +1, for all the reasons Stefano described. Along with the neccessary, explicit, relevant patent grants, preferably with GPL-compatible terms (eg non-reciprocical; would probably automatically meet requirements off standards bodies and open source orgs worldwide). Typically standards orgs have a patent policy already in place, see e.g. [1], [2]. These are probably the result of quite a lot of thought and discussion, so they should be read not just as something with which a proposed patent grant needs to be compatible but also as prior art in this field. [1] http://www.ecma-international.org/memento/codeofconduct.htm [2] http://www.niso.org/committees/OpenURL/PATPOL.pdf -- Chris Gray/k/ Embedded Java Solutions BE0503765045 Embedded Mobile Java, OSGihttp://www.k-embedded-java.com/ [EMAIL PROTECTED] +32 3 216 0369 - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [legal] Re: Bringing License arguments to Sun
On Tuesday 22 August 2006 23:35, Geir Magnusson Jr. wrote: How about real-time GC? Clearly an extension - the spec says nothing about doing GC in real-time - but I bet the aeronautical and military industry would pay for something like that... Indeed they do, and not infrequently they become Classpath users as a result. But perhaps we should get on with Bringing License arguments to Sun, rather than just having License arguments? Chris -- Chris Gray/k/ Embedded Java Solutions BE0503765045 Embedded Mobile Java, OSGihttp://www.k-embedded-java.com/ [EMAIL PROTECTED] +32 3 216 0369 - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Bringing License arguments to Sun
+1 to Stefano Mazzocchi: a Reference Implementation should have an MIT- or BSD-style licence. It worked for TCP/IP, it worked for X11, or JPEG and for countless other things. It's good for interoperability, becuase it encourages people to use the RI as a base and only tinker with those things that they need to. Even if a project decides to re-implement everything from scratch (e.g. lwip) it's still good do be able to grovel through the RI to see what it does, without worrying that you may be contaminating your code with the XYZL. Of course the RI is only part of Java, but it's a big part. TCKs are special in that a particular version of the code is normative, so modified versions need to be clearly marked as such (Apache licence?). And then there are the specifications - too many of these are currently marked it's OK to read this just as long as you don't intend to implement it. The specs should be licensed in a way that is compatible with the requirements of standards bodies such as ISO, ANSI, ECMA, even if Sun doesn't intend to head that way just yet. Copyright (C) Chris Gray 2006. The views expressed are not necessarily those of Harmony, Classpath, my company, or my cat. -- Chris Gray/k/ Embedded Java Solutions BE0503765045 Embedded Mobile Java, OSGihttp://www.k-embedded-java.com/ [EMAIL PROTECTED] +32 3 216 0369 - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Bringing License arguments to Sun
On Sunday 20 August 2006 12:27, Simon Phipps wrote: On Aug 20, 2006, at 09:54, Chris Gray wrote: +1 to Stefano Mazzocchi: Noted, thanks. (and edited so I am making fair use of your copyrighted material - I don't want to get sued...) My cat can be vicious. :-) The specs should be licensed in a way that is compatible with the requirements of standards bodies such as ISO, ANSI, ECMA, even if Sun doesn't intend to head that way just yet. Keep in mind that Sun doesn't get to decide this any more, it's up to the JCP, and there are plenty of voices other than Sun who would likely oppose this. While I sympathise, open sourcing Sun's Java implementations has nothing to do with the JCP and is made possible by the JCPA 2.5 and later. True, but quite often the spec lead is from Sun, e.g. for 218/219 (JavaME CDC/ FP). In such cases, if the Exec Comittee agrees Sun can set an example by licensing the specs in a way which would not preclude them being adopted as a standard by ISO co. BTW the comments made by EC members wrt JSR 218 seem to indicate that there is quite widespread support for a more open approach[1]. Best regards, Chris [1] http://jcp.org/en/jsr/results?id=1991. -- Chris Gray/k/ Embedded Java Solutions BE0503765045 Embedded Mobile Java, OSGihttp://www.k-embedded-java.com/ [EMAIL PROTECTED] +32 3 216 0369 - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [general] platform support
On Wednesday 09 August 2006 17:49, Rana Dasgupta wrote: I think Oleg has summarized and expressed better many of the things I was trying to say. A single binary on a least common denominator platform is a legacy binary. It runs unoptimized on other platforms. Though the term Win precedes these Microsoft operatig systems, that's a brand. It should really be Lose, right? -- Chris Gray/k/ Embedded Java Solutions BE0503765045 Embedded Mobile Java, OSGihttp://www.k-embedded-java.com/ [EMAIL PROTECTED] +32 3 216 0369 - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [rant] Memory options in VM -- why is the default not 'unlimited'
On Friday 04 August 2006 15:32, Guilhem Lavaux wrote: Dalibor pointed me to this thread on harmony-dev. I can answer that kaffe does not yet make a difference between weak references and soft references. They are both cleared when the GC detects that the object is not anymore strongly referenced. It generally happens when someone ask for more memory and the GC tries to first clear the existing allocated memory. As the GC is not trying to clear any weak references in the meanwhile this behaviour is justified. An improvement would be to make a quick small clean each time an allocation is requested. The problem is in the small because we do not have yet any way of parsing the heap by small pieces probably some heuristic is needed there. Wonka will sometimes make a garbage collection before memory is exhausted, and in this case strong references will survive while weak ones are collected. It is of course open to question whether these extra GC passes are a bug or a feature. Chris -- Chris Gray/k/ Embedded Java Solutions BE0503765045 Embedded Mobile Java, OSGihttp://www.k-embedded-java.com/ [EMAIL PROTECTED] +32 3 216 0369 - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [rant] Memory options in VM -- why is the default not 'unlimited'
On Tuesday 01 August 2006 18:07, will pugh wrote: How did Kaffe deal with SoftReferences? Did they ever go away when you did not have a memory limit? Why are we discussing Kaffe in the past tense? -- Chris Gray/k/ Embedded Java Solutions BE0503765045 Embedded Mobile Java, OSGihttp://www.k-embedded-java.com/ [EMAIL PROTECTED] +32 3 216 0369 - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [optimization] Algorithmic tricks
On Wednesday 26 July 2006 13:03, Anton Luht wrote:
Hello,
One of possible candidates for such optimization may be for example
String.hashCode() . Current implementation is rather common. Wikipedia
points to hash functions that look more advanced (
http://en.wikipedia.org/wiki/Hash_function ).
Seems to me that String.hashCode() has to use the algorithm described in the
spec if it's to be compliant. An application which relied on known values of
hashCode() might be stupid, but it would be according to contract.
switch(opcode.hashCode()) {
case NOP_HASH_CODE: do_nop();
case ALOAD0_HASH_CODE: do_aload0();
...
}
You could consider using a better hashcode for e.g. string interning (private
ind internalHashCode() {...}); if your internal hashcode is both faster and
better than the official one then that's a clear win. But as has been
pointed out elsewhere in this thread, in general it's a trade-off between the
effort required to calculate the hashcode and the collision rate in the
hashtable. No point in having a world-beating hash function for a table which
is s small that linear search would be fast enough ...
Chris
--
Chris Gray/k/ Embedded Java Solutions BE0503765045
Embedded Mobile Java, OSGihttp://www.k-embedded-java.com/
[EMAIL PROTECTED] +32 3 216 0369
-
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
On Thursday 06 July 2006 16:49, Geir Magnusson Jr wrote: This is a great example. The last two aren't even legal exceptions for that method. It seems like the RI is doing random crap, and it wouldn't be something that someone would depend on... can you imagine? I think we have to distinguish between exceptions like these, which normally nobody ever sees, unless they are actually writing tests for the core APIs (or unless they make a major programming blunder - and then they'll fix that and forget precisely what exception was thrown) on the one hand, and exceptions which one can reasonably expect to happen sometimes when developing code which may run in a variety of Java environments. An example of the latter would be ClassNotFoundException indicating that the runtime environment does not contain some wished-for class or package; if the application programmer builds in a throw..catch clause which implements a fallback, then you'd better theow ClassNotFoundException and not some random thing like NoClassDefFoundError or NPE. Similarly, I just heard from a customer that some application was failing because we were throwing LinkageError when a shared library could not be found, whereas the application only had a handler for UnsatisfiedLinkError. In this case both the RI and the spec were in agreement, but I would happily have made the change even if the spec had specified LinkageError and the RI was throwing the subclass UnsatisfiedLinkError. Fcourse it's not always easy to draw the line between exceptions which probably represent a programmer error and those which robust programs may need to handle, hance there will always be a need to discuss some of these cases. Chris µ -- Chris Gray/k/ Embedded Java Solutions BE0503765045 Embedded Mobile Java, OSGihttp://www.k-embedded-java.com/ [EMAIL PROTECTED] +32 3 216 0369 - 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
In 1.4.2 it was a bug, but in 1.5.0 it's a feature. :-) What a difference a doc makes ... Chris On Monday 03 July 2006 14:12, Anton Luht wrote: Hello, There's one example that shows that not only code may contain bugs, but documentation also: 1.5.0 spec [1] says about java.io.BufferedWriter.write(String, int, int) If the value of the len parameter is negative then no characters are written. This is contrary to the specification of this method in the superclass, which requires that an IndexOutOfBoundsException be thrown. 1.4.2 spec [2] doesn't say this, but 1.4.2 JRE behaves as it was written according to 1.5 doc. If it is not said, we expect that BufferedWriter should behave like Writer in this case (throw an exception) so this behaviour is formally a bug. In fact this is just a gap in documentation. [1] http://java.sun.com/j2se/1.5.0/docs/api/java/io/BufferedWriter.html#write(j ava.lang.String,%20int,%20int) [2] http://java.sun.com/j2se/1.4.2/docs/api/java/io/BufferedWriter.html#write(j ava.lang.String,%20int,%20int) On 7/3/06, Tim Ellison [EMAIL PROTECTED] wrote: Mikhail Loenko wrote: For the example I've started this thread with it seems that complying the spec is more appropriate there. But probably there are other examples that caused that the doc was worded the given way George and Tim could you please comment? What is the concrete example? e.g. are these checked exceptions, ... ? or NPE vs. IAE ... Regards, Tim 2006/6/30, Paulex Yang [EMAIL PROTECTED]: Anton Avtamonov wrote: 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. +1 from me. Wishes, -- 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] - 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] -- Chris Gray/k/ Embedded Java Solutions BE0503765045 Embedded Mobile Java, OSGihttp://www.k-embedded-java.com/ [EMAIL PROTECTED] +32 3 216 0369 - 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 Monday 03 July 2006 14:33, Andrew Zhang wrote: Maybe it's called javadoc bug or spec bug. :) Looks to me very like oops, our implementation isn't according to spec, better change the spec. To be fair to Sun, fixing the implementation could have broken existing code (maybe it did, hence the decision to fix the spec instead). Chris - 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
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. Chris -- Chris Gray/k/ Embedded Java Solutions BE0503765045 Embedded Mobile Java, OSGihttp://www.k-embedded-java.com/ [EMAIL PROTECTED] +32 3 216 0369 - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: So today Sun announced...
Open Source java wouldn't be the same if there wasn't some standard to follow and adhere to. If this standard is defined rather more by one company than the rest - what is the real problem? The real problem is that if that company also markets an implementation of the standard, there will always be forces within the company which view all other implementations as competitors. I don't believe that Fortran or C would would have been better off had IBM or ATT controlled the standardisation process the way Sun are doing with Java. -- Chris Gray/k/ Embedded Java Solutions BE0503765045 Embedded Mobile Java, OSGihttp://www.k-embedded-java.com/ [EMAIL PROTECTED] +32 3 216 0369 - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: So today Sun announced...
Geir, I'll grant you that Sun could handle the Java community much worse than they do, but I still don't agree that having such a corporation in charge is a Good Thing. Or maybe I'm just being old-fashioned, and we should get rid of all those fuddy-duddy organisations like IETF or W3C and replace them by dynamic share-holder-value-driven corporations. :-) Chris wie-so-gibts-keine-DDR-mehr Gray On Friday 19 May 2006 14:57, Geir Magnusson Jr wrote: Chris Gray wrote: Open Source java wouldn't be the same if there wasn't some standard to follow and adhere to. If this standard is defined rather more by one company than the rest - what is the real problem? The real problem is that if that company also markets an implementation of the standard, there will always be forces within the company which view all other implementations as competitors. Yes, but... :) It *is* one of the interesting things about the Java ecosystem - we are all able to all work together in creating the specifications via the JCP process, and then compete on implementation. It seems to have worked pretty well so far. geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Chris Gray/k/ Embedded Java Solutions BE0503765045 Embedded Mobile Java, OSGihttp://www.k-embedded-java.com/ [EMAIL PROTECTED] +32 3 216 0369 - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DRLVM] build process improvement
On Thursday 18 May 2006 06:11, Alexey Petrenko wrote: 2006/5/18, Chris Gray [EMAIL PROTECTED]: On Wednesday 17 May 2006 20:27, Alexey Petrenko wrote: Just FYI... We WILL have cyclic dependencies. In AWT and Swing modules for example. Sorry, you've lost me. Do you mean AWT depends on Swing? That seems odd. Not much, but... Check java.awt.im.spi.InputMethodContext interface for example. One of its methods returns JFrame. Blech. That also means Swing (or a stub) needs to be on the bootclasspath if AWT is used. (Just like java.security depends on java.awt, so even headless systems need to have java.awt.AWTPermission - but at least that's all within java.*). Now that you mention it, I think we came across another example recently where a java.* class depended on a javax.* one, just for one stupid method. Modularity is not Sun's strong suit. Thanks, Chris -- Chris Gray/k/ Embedded Java Solutions BE0503765045 Embedded Mobile Java, OSGihttp://www.k-embedded-java.com/ [EMAIL PROTECTED] +32 3 216 0369 - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DRLVM] build process improvement
Quoth Stepan Mishura: AFAIK java.security doesn't depend on java.awt. You're right, my bad. There are methods in java.lang.SecurityManager (not java.security) which look as if they should use java.awt.AWTPermission, but still no actual dependencies. That's what comes of relying on memory ... Chris -- Chris Gray/k/ Embedded Java Solutions BE0503765045 Embedded Mobile Java, OSGihttp://www.k-embedded-java.com/ [EMAIL PROTECTED] +32 3 216 0369 - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DRLVM] build process improvement
On Wednesday 17 May 2006 20:27, Alexey Petrenko wrote: Just FYI... We WILL have cyclic dependencies. In AWT and Swing modules for example. Sorry, you've lost me. Do you mean AWT depends on Swing? That seems odd. Chris -- Chris Gray/k/ Embedded Java Solutions BE0503765045 Embedded Mobile Java, OSGihttp://www.k-embedded-java.com/ [EMAIL PROTECTED] +32 3 216 0369 - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jchevm status?
You mean it's hand-me-down-ware these days, you just get a copy from someone who got it from someone else who paid 50 bucks a few years ago and wishes he didn't? Amazing how many widely-used benchmarks fall into that category ... On Monday 15 May 2006 22:51, Geir Magnusson Jr wrote: Neither, probably :) Chris Gray wrote: BTW is spec98jvm open-source these days, or is it still send 50 bucks to this address and we will send you a floppy disk which only installs on windoze? - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Chris Gray/k/ Embedded Java Solutions BE0503765045 Embedded Mobile Java, OSGihttp://www.k-embedded-java.com/ [EMAIL PROTECTED] +32 3 216 0369 - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jchevm status?
BTW is spec98jvm open-source these days, or is it still send 50 bucks to this address and we will send you a floppy disk which only installs on windoze? -- Chris Gray/k/ Embedded Java Solutions BE0503765045 Embedded Mobile Java, OSGihttp://www.k-embedded-java.com/ [EMAIL PROTECTED] +32 3 216 0369 - 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
More generally, from a performance point of view it is best not to write
if (index 0 || index = array.length || etc. etc.) {
throw new FooIndexOutOfBoundsException();
}
if there is a method call or an array access which will throw the exception
anyway. (Many null parameter checks can be omitted for the same reason).
Looks like Sun have followed this policy, and dealt with the not-quite-right
exception type by fudging the spec to throw the common supertype. :-
Chris
On Friday 12 May 2006 09:11, Mikhail Fursov wrote:
Note that this is not only beautiful but also performance oriented way -
do not create extra rethrows if it's possible
On 5/12/06, Semukhina, Elena V [EMAIL PROTECTED] wrote:
To have a beautiful fix, why don't you just write
System.arraycopy(data, start, value, 0, count);
without trying to catch any exception and rethrow another one?
ArrayIndexOutOfBoundsException, if happened, would be thrown by
System.arraycopy().
--
Chris Gray/k/ Embedded Java Solutions BE0503765045
Embedded Mobile Java, OSGihttp://www.k-embedded-java.com/
[EMAIL PROTECTED] +32 3 216 0369
-
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
On Friday 12 May 2006 11:37, George Harley wrote: Nathan Beyer wrote: Note, the RI is NOT throwing ArrayIndexOutOfBoundsExceptions, it is just letting them happen via invalid array look ups, but in these cases, the specification is marked with an IndexOutOfBoundsException. Hi Nathan, If we consider the RI as a black box whose internals should be completely hidden from us - a starting point that I think is important to all participants of this project (and their legal representatives) - then it does not matter *why* the RI is throwing the AIOOBE. It just does. Right, and in general we cannot know exactly which exception type the RI will throw in any specific case - we have to start from the assumption that it follows the spec, and take note of any deviations or more specific behaviour that turns up. It's not possible to exhaustively test every exception case. What will matter more to potential Harmony adopters ? Adherence to the spec or ease of transition of their apps from the RI to Harmony ? In this case we can satisfy the spec and enable runtime compatibility by throwing the identical concrete exception type. If the app is written to the spec there's no problem. But in real life it can happen that the developer doesn't look at the spec - during testing her code throws an AIOOBE, so she adds an exception handler for that case. In this case we make this (incorrect) app run by copying RI's behaviour (insofar as we can determine what this is). But if RI throws sun.util.FunnyIndexOutOfBoundsException and the programmer codes to this, we're hosed - the app has to fixed. Chris -- Chris Gray/k/ Embedded Java Solutions BE0503765045 Embedded Mobile Java, OSGihttp://www.k-embedded-java.com/ [EMAIL PROTECTED] +32 3 216 0369 - 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
Hi, * Dmitry (who raised the issue) believes that we should change the Harmony code to throw the type named in the Javadoc/specification (i.e. the supertype j.l.IndexOutOfBoundsException). Dmitry is wrong. * Nathan believes that the code already abides by the specification and that there is no need for any change in this area. Nathan is right. * Little old me thinks that there *is* a problem here but that the solution is to do as the RI does and throw exceptions with the very same runtime type as the RI. That's based on my interpretation of the exception-throwing compatibility guidelines [2], in particular the fragment Harmony class library code should throw exceptions of the same type as the RI. You are right too. If it were my project I would change to mimic the RI once the discrepancy were pointed out to me, but I wouldn't (and don't) go looking for such things. Chris -- Chris Gray/k/ Embedded Java Solutions BE0503765045 Embedded Mobile Java, OSGihttp://www.k-embedded-java.com/ [EMAIL PROTECTED] +32 3 216 0369 - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Supporting working on a single module?
On Tuesday 09 May 2006 22:03, Etienne Gagnon wrote: Yes. But only by checking out everything. I am developing a API stubs project, which is a full stubs implementation of the Java 1.5 API. My objective was actually to allow for not needing an API implementation to compile code against the API. I was planning to use this, among other uses, for compiling SableVM's luni-kernel implementation. For what my opinion is worth (on a good day, a cup of coffee, but not at Caffè Florian), this would be an excellent thing to have. It will never be easy to work on the core Java APIs in a totally modular way (because Sun didn't design things that way), but with such a set of stubs one could at least work on a group of classes in isolation and be able to compile them to bytecode. Furthermore the stubs can readily be used for white-box testing during development, by simply adding println()s. Go for it! Chris -- Chris Gray/k/ Embedded Java Solutions BE0503765045 Embedded Mobile Java, OSGihttp://www.k-embedded-java.com/ [EMAIL PROTECTED] +32 3 216 0369 - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Supporting working on a single module?
Geir scripsit: For what my opinion is worth (on a good day, a cup of coffee, but not at Caffè Florian), this would be an excellent thing to have. It will never be easy to work on the core Java APIs in a totally modular way (because Sun didn't design things that way), but with such a set of stubs one could at least work on a group of classes in isolation and be able to compile them to bytecode. Furthermore the stubs can readily be used for white-box testing during development, by simply adding println()s. Go for it! 1) I wonder if we could just add those println's w/ AOP since we're fundamentally lazy. I imagined that these println's would be ad-hoc and ephemeral, a step along the way to producing other deliverables (the class libraries themselves, and the various kinds of test that have already been discussed here). If you're developing method M of class C and your implementation invokes method M' of class C', you sometimes want to have a M' which just prints out hello, I've been called with inputs foo, bar and baz and/or returns some prearranged result; but I don't think you'd want the stub method to have this feature built-in for every conceivable invocation. Not unless you embark on an ambitious reflection-based framework with scripting capabilities, which of course could be huge fun in itself. :) 2) Could we mechanically create the stubs, rather than having a parallel source tree? One might argue that you could generate such a stub by transforming the spec javadoc to code no muss, no fuss, and darn quick... This is not such a daft idea. If it's not literally possible (and Etienne can mostly likely tell us why not), then it should still be possible to perform extensive automatic automatic checking of the stubs using japitools or similar. Chris -- Chris Gray/k/ Embedded Java Solutions BE0503765045 Embedded Mobile Java, OSGihttp://www.k-embedded-java.com/ [EMAIL PROTECTED] +32 3 216 0369 - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Summer Of Code 2006 - Lets get Harmony involved
On Monday 24 April 2006 23:34, Geir Magnusson Jr wrote: 1) Could we simply have a classloader that can be put in a special mode so it doesn't that unit tests for bootclasspath-resident packages are not on the boot classpath? If you mean that the custom classloader would try to load classes named (say) java.*.Test* itself instead of delegating to its parent, then you should find that the VM won't let you - I'm pretty sure that's in the spec somewhere. Chris -- Chris Gray/k/ Embedded Java Solutions BE0503765045 Embedded Mobile Java, OSGihttp://www.k-embedded-java.com/ [EMAIL PROTECTED] +32 3 216 0369 - 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 Tuesday 25 April 2006 11:23, Anton Avtamonov wrote: 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. A patchy implementation of J2SE? That would never do. (8-) -- Chris Gray/k/ Embedded Java Solutions BE0503765045 Embedded Mobile Java, OSGihttp://www.k-embedded-java.com/ [EMAIL PROTECTED] +32 3 216 0369 - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ITC's java.math package contribution
On Sunday 23 April 2006 02:07, Daniel Fridlender wrote: I also agree with [Vladimir] that it would be really nice to have a representative collection of realistic applications of the functionality of java.math. RSA key generation is definitely one of them. We should find more. That would also help us identifying methods that are critical for the performance in practice, thus methods that are worth optimizing further. For crypto, one could adopt the whole BouncyCastle test suite as a benchmark. Outside of crypto, I don't know of any practical uses for BigInteger (which doesn't mean that none exist). Chris -- Chris Gray/k/ Embedded Java Solutions BE0503765045 Embedded Mobile Java, OSGihttp://www.k-embedded-java.com/ [EMAIL PROTECTED] +32 3 216 0369 - 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 Tuesday 18 April 2006 01:34, Geir Magnusson Jr wrote: Really? Every other JRE uses the classlibrary from sun. Of the many open-source runtimes, none uses Sun's class library; almost all use Classpath. Among non-open source products, J9 has its own libraries, and I believe this is also true of many other embedded runtimes, e.g. Aonix's PERC (other companies which used to have their own class libraries are now Sun licencees, but are probably still using a lot of their own code for luni). Aicas sell a closed-source runtime which uses Classpath for its Java libraries. -- Chris Gray/k/ Embedded Java Solutions BE0503765045 Embedded Mobile Java, OSGihttp://www.k-embedded-java.com/ [EMAIL PROTECTED] +32 3 216 0369 - 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 Tuesday 18 April 2006 04:20, Geir Magnusson Jr wrote: Good question though - what does GNU Classpath do? What GNU Classpath does is the same as what the Sun class libraries do, so the former no more needs the latter than Apache needs IIS ... (Sorry to be playing the pedant but I do sometimes get the idea that Harmony is tearing ahead without ever stopping to ask about context, history, prior art ...) Chris -- Chris Gray/k/ Embedded Java Solutions BE0503765045 Embedded Mobile Java, OSGihttp://www.k-embedded-java.com/ [EMAIL PROTECTED] +32 3 216 0369 - 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 Tuesday 18 April 2006 09:37, Mark Hindess wrote: Are you saying that Classpath does match strings in exceptions? No. Ah, I see: the do in Geir's question stood for what is Classpath's policy wrt to exception messages matching those of the RI?. Then I don't speak authoritatively, but I've never noticed Classpath going out of its way to be compatible at this level. But then I would never write code which depended on the precise contents of an exception message ... Sorry for the confusion, Chris -- Chris Gray/k/ Embedded Java Solutions BE0503765045 Embedded Mobile Java, OSGihttp://www.k-embedded-java.com/ [EMAIL PROTECTED] +32 3 216 0369 - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: External libraries in the bootclasspath
On Friday 14 April 2006 10:51, Paulex Yang wrote: Soeren Strassfeld wrote: Ilya Neverov schrieb: Hi Ilya, just followed your link, as I understand it, the endorsed mechanism is only for API Classes, which are developed outside the JCP. This contains the org.w3c, org.xml and the CORBA/omg packages, but not internally used packages. I guess sun in some way trusts those library vendors to be downward compatible, and so not break the API. I guess Harmony also trusts the introduced external dependent classlib.;) And as you said, the endorsed.dir is only for newer versions of libraries (the docs explicitly points to this as well), so Applications, which depend on older versions, would still fail. Jar versioning is a difficult issue in Java world (in fact more significant on Java EE world), maybe the official solution(I mean, the standard) is JSR-277, but we probably need to wait for Java 7 to provide the spec and RI. Not sure if other component mechanism like OSGi has provided good idea on this issue? OSGi allows each bundle to specify which bundles it depends upon, optionally including a version spec which uses the _Java 2 Package Versioning Specification_, http://java.sun.com/j2se/1.4.2/docs/guide/versioning/index.html Chris -- Chris Gray/k/ Embedded Java Solutions BE0503765045 Embedded Mobile Java, OSGihttp://www.k-embedded-java.com/ [EMAIL PROTECTED] +32 3 216 0369 - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ITC: Contribution of java.math and javax.crypto
On Thursday 06 April 2006 23:59, Tim Ellison wrote: You can run the Eclipse IDE on Classpath or Harmony(*) class libraries, both are sufficiently well advanced to run it. (*) you need to use the regex code from regex-beans-math which hasn't been merged into the build process yet I knew eclipse ran on Classpath (e.g. gcj), wasn't sure about Harmony. That's good to hear. IMO Harmony developers should be encouraged to use a Sun-free workstation whenever possible, to avoid this kind of slip-up. There should also be automatic detectors for references to sun.* or com.sun.* classes. Regards, Chris -- Chris Gray/k/ Embedded Java Solutions BE0503765045 Embedded Mobile Java, OSGihttp://www.k-embedded-java.com/ [EMAIL PROTECTED] +32 3 216 0369 - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Unit testing revisited
On Monday 27 March 2006 10:14, Anton Avtamonov wrote: 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. Now let me support Geir's. 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. In a complex piece of software it is extremely valuable to have internal interfaces which are rather stable - for example the VMI or equivalent, interfaces with the thread management system, memory management/GC, JIT compiler where present, etc.. These do indeed have the nature of internal functional contracts, because each subgroup of developers trusts the other groups not to change these interfaces without warning. The contract can be changed without reference to external parties, but it is still a contract. If you change the implementation of some component and do not intend to change the contract, it is extremely useful to have tests which verify that this is so. For the Wonka VM we had such tests for the internal threading API and for the abstract data types (hashtable, fifo, etc.) which were used intensively, and they proved extremely valuable. They are especially valuable if you take the first make it correct, then make it time-/space-efficient approach, so that one group can work on tweaking a particular component without disturbing the others. We completely re-implemented Wonka's string pool a couple of times without having to rewrite the rest of the VM. 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 :-). [...] I'm not fond of initials, but I am fond of testing stuff at multiple levels - each module or component must do its thing, and together they must satisfy the requirements. If you build a complex system out of untested components and test only the final result, disaster beckons. 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'. 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. Cheers, Chris -- Chris Gray/k/ Embedded Java Solutions BE0503765045 Embedded Mobile Java, OSGihttp://www.k-embedded-java.com/ [EMAIL PROTECTED] +32 3 216 0369
Re: More helpful error messages
On Sunday 26 March 2006 20:10, Magnusson, Geir wrote: The point was to illustrate having useful information in the message. Optime any way you see fit. That said, given that you are throwing an exception... do we really care? I'm praying that we don't have apis that throw exceptions as a normal result of operation. java.lang.ClassLoader loadClass() throws a ClassNotFoundException every time a classloader delegates to its parent and the parent cannot load the class, which is pretty normal. There's probably plenty more than that - just try instrumenting a VM to print out all the exceptions thrown in java.lang.* and watch them fly by ... Chris -- Chris Gray/k/ Embedded Java Solutions BE0503765045 Embedded Mobile Java, OSGihttp://www.k-embedded-java.com/ [EMAIL PROTECTED] +32 3 216 0369
Re: More helpful error messages
On Sunday 26 March 2006 21:10, Geir Magnusson Jr wrote: I threw together a toy program when I got back to hotel. I called a method that did a minor amount of work (increment the int arg and return it). Then I created one that did the same, but then threw an exception. Then I did one that threw an exception in which string concat was used. Finally, one that thew an exception in which a StringBuffer was used. I found, for 500 iterations on a 1.86G Pentium M under WinXP using Sun's 1.4.2_10 C:\dev\eclipse\workspace\playspace\javajava -classpath . SpeedTest test1 - no exception : 16 millis test2 - exception, static string: 11859 millis test3 - exception string concat : 13516 millis test4 - exception stringbuffert : 14125 millis This simple example probably exaggerates the effect of the exception - test1 is probably so trivial that the JIT compiler probably optimises it to almost nothing, while the other tests require e.g. a stack frame in which the exception can be thrown. It would be interesting to see the results on some other VMs (including gcj). That being said, these numbers do indicate how relying on exceptions for normal flow of execution can seriously damage performance. I guess we don't get much benefit of using stringbuffer to replace only one concat (or the compiler is smart enough to do that itself anyway... String concatenations are translated to StringBuffer (or StringBuilder) operations by the compiler - there is no strcat opcode. If you're building up a string in stages, e.g. String s = foo:; if (bar) s += bar; else s += baz ...etc. ... then it's worth replacing s by a StringBuffer and doing an explicit toString() at the end: StringBuffer sb = new StringBuffer(foo); if (bar) sb.append(bar); else sb.append(baz); ...etc. ... String s = sb.toString(); because otherwise the compiler generates code to convert the String to a StringBuffer and back at every stage. But if you're just writing Hello + name + , how are you? then you save nothing by converting this to new StringBuffer(Hello ).append(name).append(, how are you?); because the generated bytecode is the same. Chris -- Chris Gray/k/ Embedded Java Solutions BE0503765045 Embedded Mobile Java, OSGihttp://www.k-embedded-java.com/ [EMAIL PROTECTED] +32 3 216 0369
Re: [result] Re: [vote] Acceptance of HARMONY-39 : Contribution of beans, regex and math class library code
On Tuesday 21 March 2006 15:53, Dalibor Topic wrote: But alas, Sun currently sees other implementations as a threat to its business model as a proprietary Java vendor, so one has to deal with such things until they stop having a business interest in being a proprietary Java vendor (yeah, right), or go bust (yeah, right), or actually makes true on the 'participation age' and 'JDK community' talk (yeah, right). Yeah, right +1 :-0 There are quite a few people within Sun who think that what we (Harmony, Kaffe, SableVM, Wonka, ...) are doing is cool - well, I've met a couple anyway. But once things start to get official, you're talking to another brick in the wall ... (mother did it need to be so high?) -- Chris Gray/k/ Embedded Java Solutions BE0503765045 Embedded Mobile Java, OSGihttp://www.k-embedded-java.com/ [EMAIL PROTECTED] +32 3 216 0369
Re: NullPointerException
On Monday 20 March 2006 09:41, Paulex Yang wrote: My opinion is: either is fine, the only principle is the exception order must be compliant with RI,[...] Good point. I agree. Chris -- Chris Gray/k/ Embedded Java Solutions BE0503765045 Embedded Mobile Java, OSGihttp://www.k-embedded-java.com/ [EMAIL PROTECTED] +32 3 216 0369
Re: NullPointerException
On Friday 17 March 2006 08:47, Anton Avtamonov wrote:
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).
+1
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.
I prefer to let these things happen automatically whenever possible.
Introducing an explicit check adds extra bytecodes and probably extra CPU
cycles in the non-null case. On some VMs null.someMethod() might be slower in
the null case, but if the RI also throws NPE then these cases should be truly
exceptional in the sense that they indicate a programming error or a missing
resource. OTOH if the RI treats a null argument as a normal case then this
should be implemented using 'if (someVar == null)', not by catching a NPE(!).
Chris
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
--
Chris Gray/k/ Embedded Java Solutions BE0503765045
Embedded Mobile Java, OSGihttp://www.k-embedded-java.com/
[EMAIL PROTECTED] +32 3 216 0369
Re: Subclipse Diff: Are there any way to ignore whitespace when creating patch using Subclipse in Eclipse
On Thursday 16 March 2006 19:09, Stefano Mazzocchi wrote: I *HATE* tabs with a passion +1 -- Chris Gray/k/ Embedded Java Solutions BE0503765045 Embedded Mobile Java, OSGihttp://www.k-embedded-java.com/ [EMAIL PROTECTED] +32 3 216 0369
Re: [Fwd: Re: [jchevm] JCHEVM discussion]
Stefano, I think we should take Geir's advice and pipe down a bit. Those whose task it is to resolve this issue are by now pretty aware of the issues involved, and our explanations to eachother serve only to increase entropy. Meanwhile we may meditate on Jorge Luís Borges' story _Pierre Menard, Author of Don Quixote_: http://charleswjohnson.name/essays/can-don-quixote-tilt-at-william-james :-) Chris -- Chris Gray/k/ Embedded Java Solutions BE0503765045 Embedded Mobile Java, OSGihttp://www.k-embedded-java.com/ [EMAIL PROTECTED] +32 3 216 0369
Re: [Fwd: Re: [jchevm] JCHEVM discussion]
Hi Etienne, A little clarification. I don't claim that you can't study another's Free/Open Source (F/OS) VM source code, or that you can't contribute to multiple VMs over time. I claim that this does not allow you to COPY one VM's source code into another one without respecting the Copyright. This is clear. I was a bit alarmed though by your reference to clean room conditions - clean room conditions are enforced in order to eliminate all possibility of taint, because there is a presumption that the owner of the copyright in A will sue the developers of B if they think they have even a chance of proving taint. In the open-source world the presumption is usually the other way around - that developer A will not sue developer B unless there is evidence of blatant plagiarism (and maybe not even then). I prefer to think that I can look at, say, Kaffe or Classpath to se how they approach certain issues without worrying that Dalibor or Mark or the FSF will use the mere fact that I have admitted to doing so in order to argue that anything I create in the way of core libraries or VM is somehow derived from their work. I would like that think that I can look at SableVM in the same way, provided I do just that: look, add the ideas to the broth already steaming in my head, and forget the details (the last bit comes very easy). That's something I don't allow myself to do with Sun's published code, because of the different presumption that applies. (For the record, up until now am untainted by SableVM, although I did pick up some interesting ideas from a talk you gave at JVM01 (and for which you won a prize, IIRC)). All the best, Chris -- Chris Gray/k/ Embedded Java Solutions BE0503765045 Embedded Mobile Java, OSGihttp://www.k-embedded-java.com/ [EMAIL PROTECTED] +32 3 216 0369
Re: [Fwd: Re: [jchevm] JCHEVM discussion]
On Monday 13 March 2006 15:22, Dalibor Topic wrote: On a Harmony-unrelated side note, if you are interested in seeing your port in the Kaffe.org CVS tree, and your contract allows for it, feel free to send me the patch. :) I'm afraid it's lost in the mists of time, Dali - last century was a long time ago. Plus the port was originally done by Transvirtual for a company which has since gone bankrupt, so there could be some difficulties in getting the necessary clearances ... Cheers, Chris -- Chris Gray/k/ Embedded Java Solutions BE0503765045 Embedded Mobile Java, OSGihttp://www.k-embedded-java.com/ [EMAIL PROTECTED] +32 3 216 0369
Re: [Fwd: Re: [jchevm] JCHEVM discussion]
Geir, Note that the last snippet that you quote has been evolved to : If you have answered yes to any question above, and that implementation is not available under a recognized Open Source license, you may not be an contributor to the related component of Apache Harmony unless the copyright owner of that implementation either: The key change is and that implementation is not available under a recognized Open Source license - because except for copying, which we don't allow, any ideas found in open-source-licensed source code are not trade secrets and therefore able to be re-implemented by others in independent, differently-licensed implementations. I do hope this is correct, because otherwise the pool of potential VM developers is even smaller than we thought it was. Heaven help me (and Wonka) if Dalibor finds out that for a few weeks at the end of the last century I worked on a port of Kaffe ... Chris -- Chris Gray/k/ Embedded Java Solutions BE0503765045 Embedded Mobile Java, OSGihttp://www.k-embedded-java.com/ [EMAIL PROTECTED] +32 3 216 0369
Re: Component status pages
On Thursday 09 March 2006 11:41, Paulex Yang wrote: But there is a very silly question, why several class names, such as FileChannel, CharBuffer, etc, are considered as hyper link automatically, while some other class name, such as Closeable are rendered as plain text? Actually there are no relevant pages available for these names, and I did nothing special to them. Help me! O:-) Probably because the wiki software considers any word with embedded capitals to be a WikiName, and hence a link to a page of that name within the wiki. You'll have to consult the documentation for the wiki software to find how to work around this feature. (A good candidate for the most annoying thing ever invented, if you ask me). Have fun, Chris -- Chris Gray/k/ Embedded Java Solutions BE0503765045 Embedded Mobile Java, OSGihttp://www.k-embedded-java.com/ [EMAIL PROTECTED] +32 3 216 0369
Re: How to deal with this kind of serialization compatibility issue?
On Tuesday 07 March 2006 14:38, Geir Magnusson Jr wrote: This is somewhat terrifying, isn't it? Are there really references to com.sun.* in serialized API objects? This *has* to be a bug in the whole spec if so... If you ask me, the serialization spec *is* a bug. There are just two many ways to break serialization compatibility while remaining binary compatible, and that ain't right. -- Chris Gray/k/ Embedded Java Solutions BE0503765045 Embedded Mobile Java, OSGihttp://www.k-embedded-java.com/ [EMAIL PROTECTED] +32 3 216 0369
Re: How to deal with this kind of serialization compatibility issue?
Hi George, I wonder what lessons other class library development teams have learned in this area ? I guess that our experience from Wonka can be summed up as serialization is a PITA. Most of the time the problem can be solved, you just never know where the next one will pop up. We advise our cutomers against using serialization as a way to exchange data between VMs - use XML, use Hessian, use anything except serialization. That goes for RMI too. I guess it's easier for us to take this line in an embedded environment than in the context of, say, J2EE. Good luck, Chris -- Chris Gray/k/ Embedded Java Solutions BE0503765045 Embedded Mobile Java, OSGihttp://www.k-embedded-java.com/ [EMAIL PROTECTED] +32 3 216 0369
