Re: Harmony Meetup at JavaOne (Was Re: JavaONE - anyone going? Last day for early bird reg.)
Geir Magnusson Jr. wrote: On May 27, 2005, at 6:52 PM, Dmitry Serebrennikov wrote: Daytime on Sunday before the conference works for me, but I'm open otherwise. I don't understand.. Does this mean Sun day is best, but you are open? geir exactly dmitry
Re: [arch] VM/Classlibrary interface
Rodrigo Kumpera wrote: Last time I checked, no one, nether me or you, is developing code agains the TCK, but to a real JVM. And as hard as we may try, sometimes we end with software that depends on unspecified behavior. So it's better try to be bug compatible too. If you end up with software that depends on unspecified behaviour, then it is either a) your deliberate decision, then you probably have a very, very good reason to tie yourself to the particular revision of the particular platform, or b) an accidental mistake, then you fix the small bug in your code, feel better about the quality of your code, and move on. Neither a nor b requires anyone to be bug compatible as a) is not a bug in anyone's code, and b) is something you'll want to fix in your code, if you care about the quality of your code, rather then working around your bugs in everyone's class library code, and breaking other people's applications. Regarding usage of implementation specific classes, I believe that most developers using the Java programming language are familar with the warnings not to use implementation-specific classes or to rely on their behaviour, names, presence or anything esle. cheers, dalibor topic
Re: [arch] VM/Classlibrary interface
Rodrigo Kumpera wrote: Last time I checked, no one, nether me or you, is developing code agains the TCK, but to a real JVM. And as hard as we may try, sometimes we end with software that depends on unspecified behavior. So it's better try to be bug compatible too. No, I don't agree on this either. Dalibor already mentioned several good reasons why Harmony should not try to be implementation compatible with any other VM and another good reason is that the usage of com.sun-classes is also version or release dependent of Sun's VM. If Sun decides to rename, repackage or somehow change the internal classes in a new VM release, e.g. 1.5.0_04, code relying on these classes will break as well. The implementors of such code should fix their part and no other VM vendor seem to find a reason to implement their VMs in such a fashion that broken code will run on them. Tor
Re: Tutorials
Added to Wiki. I wish I could do wiki changes offline... On May 28, 2005, at 2:01 AM, Steve Blackburn wrote: I was reminded of the existence of the following tutorials. There is an treasure trove of really valuable information here. I invite people to take a look. There is also an MMTk tutorial there, but it is out of date and frankly (as an author ;-) not as good as the ones listed below. The first of the tutorials listed below is the most recent, is not Jikes RVM specific, and is perhaps the place to start. --Steve Dynamic Compilation and Adaptive Optimization in Virtual Machines http://jikesrvm.sourceforge.net/info/presentations.shtml#pldi04 The Design and Implementation of the Jikes RVM Optmizing Compiler http://jikesrvm.sourceforge.net/info/presentations.shtml#oopsla02 The Design and Implementation of the Jalapeño Research VM for Java http://jikesrvm.sourceforge.net/info/presentations.shtml#pact01 -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: Tutorials
On May 28, 2005, at 7:33 AM, Raffaele Castagno wrote: 2005/5/28, Geir Magnusson Jr. [EMAIL PROTECTED]: Added to Wiki. I wish I could do wiki changes offline... It's quite simple: 1: open the page 2: copy the wiki source in your favourite text editor, and annotate the date of last update 3: go offline 4: modify it 5: go online, and check if the page has been bodified in the meanwhile 6: eventually apply modification to your modified source 7: paste the modified source, and save. :) No, I was thinking more along the lines of just having the wiki content in SVN or such, and let me do updates to that. Maybe a thin client on my machine to do the creation of new pages and such... geir My 2 (euro)cents Raffaele -- If you want a GMail account, send me an E-Mail. -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: [arch] VM/Classlibrary interface
Tor-Einar Jarnbjo wrote: Rodrigo Kumpera wrote: Last time I checked, no one, nether me or you, is developing code agains the TCK, but to a real JVM. And as hard as we may try, sometimes we end with software that depends on unspecified behavior. So it's better try to be bug compatible too. No, I don't agree on this either. Dalibor already mentioned several good reasons why Harmony should not try to be implementation compatible with any other VM and another good reason is that the usage of com.sun-classes is also version or release dependent of Sun's VM. Well, it needs to be compatible and pass the official test suites. That's possible and will happen. Being compatible with something for which no specification or documentation exists is impossible, though, so it can't happen. And in practice, it is not necessary, either. Evolution sorts out portable from unportable code over time. I have not seen an actively maintained application using the com.sun.java.swing or java.awt.swing migrational, runtime-specific API[1] in the last 3 years at least. ;) cheers, dalibor topic [1] http://java.sun.com/products/jfc/package.html
Re: Tutorials
Geir Magnusson Jr. wrote: On May 28, 2005, at 7:33 AM, Raffaele Castagno wrote: 7: paste the modified source, and save. :) No, I was thinking more along the lines of just having the wiki content in SVN or such, and let me do updates to that. Maybe a thin client on my machine to do the creation of new pages and such... Dokuwiki? []s André AE
Re: Threading
A long, long time ago... Craig Blake wrote: Seems to me that you might want to be open to either using the platform's threading when a platform has good scalability, and punt and do it in VM when the platform doesn't offer it. If it can be done then I am all for it. Once the Harmony VM becomes modular it is something that can probably be investigated further, anyways. http://www.mail-archive.com/mono-devel-list@lists.ximian.com/msg00846.html until the end of thread. mainly http://www.mail-archive.com/mono-devel-list@lists.ximian.com/msg00885.html []s André AE
Re: [arch] VM/Classlibrary interface
Ulrich Kunitz wrote: On Fri, 27 May 2005, Geir Magnusson Jr. wrote: (Tomcat : I'd bet they fixed that (or will fix...)) Well, can't the VM just prevent non-kernel code from using them? Maybe overhead too high? You could play class loader games, however those could be circumvented by just another customized class loader. Doug Lea discussed the general issue in a message to this mailing list already. IMHO the problem is, that you can make a class only public, package-private or visible for a single class (e.g. private static). Some finer grained controls might be usefil like exporting a class to a particular package. Doug referenced the paper http://www.research.ibm.com/people/d/dgrove/papers/oopsla03.html that discuesses a number of the issues involved and proposes a solution based on a module concept. He referenced this page http://www.cs.utah.edu/flux too. You can definitely get these types of features from class loader games, but somehow that sounds like a pejorative description. I don't see why using class loaders for this purpose is not a good idea, it is possible to create a pretty decent module system just using class loaders and JAR files. I have just made available an alpha release of Oscar 2.0, my OSGi framework implementation, with some extensions to the R3 version of the specification: http://oscar.objectweb.org/oscar-alpha.html There are basic capabilities, like a having a JAR declare what it allows to be exported (and imported), but there are also more advanced capabilities, like being able to include/exclude certain classes from specific exported package. This latter capability makes it possible to get around some of the limitations of Java's access modifiers as they pertain to packages. In these situations, the classes in the JAR file itself have complete access to their contents, but external classes do not. This is all fairly easy and just requires that the classes be packaged into JAR files with some metadata. As far as circumventing these capabilities using another customized class loader, yes, they could create a URLClassLoader directly to a module JAR file, which would ignore the metadata completely and then they might be able to load classes directly from it. However, this is going to a bit of effort to get at implementation details... - richard
Re: [arch] VM/Classlibrary interface
On 5/28/05, Dalibor Topic [EMAIL PROTECTED] wrote: Rodrigo Kumpera wrote: Last time I checked, no one, nether me or you, is developing code agains the TCK, but to a real JVM. And as hard as we may try, sometimes we end with software that depends on unspecified behavior. So it's better try to be bug compatible too. If you end up with software that depends on unspecified behaviour, then it is either a) your deliberate decision, then you probably have a very, very good reason to tie yourself to the particular revision of the particular platform, or b) an accidental mistake, then you fix the small bug in your code, feel better about the quality of your code, and move on. I agree with you about the first one, but the second is where the fine line between pragmatic and retoric solutions line. It's easy to say 'just fix it then', but I hope that Harmony gets more users that a few hackers. The TCK is not the silver bullet for compatibility, A software I wrote for 1.4.0 suddenly got broken on 1.4.1 because of, I don't know, bug fixes or subtle changes on behavior of java.nio. My point is, testing against just the TCK is just not enouth. Testing against real applications is where the real value of Harmony can be asserted. Most free JVMs already do that and nobody seens to be complaining. Rodrigo
