Date: Wed, 31 Oct 2001 09:49:16 -0700 From: Nate Williams <nate@yogotech.com> To: tlambert2@mindspring.com Cc: Nate Williams <nate@yogotech.com>, John Baldwin <jhb@FreeBSD.org>, chat@FreeBSD.org Subject: Re: time_t not to change size on x86 Message-ID: <15328.11148.994822.484027@caddis.yogotech.com> In-Reply-To: <3BDFB624.D85F5352@mindspring.com> References: <XFMail.011029134349.jhb@FreeBSD.org> <3BDE6ED3.64DC027E@mindspring.com> <15326.50508.909158.688936@caddis.yogotech.com> <3BDED2DC.A04B6822@mindspring.com> <15326.55082.743110.502241@caddis.yogotech.com> <3BDFB624.D85F5352@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > > I've run into several instances where I needed to marshall > > > objects from a local node to a remote node, and then reinstance > > > them, without explicitly knowing anything other than that they > > > inherit from a particular class, and then later marshall them > > > again (either back or elsewhere). > > > > Using interfaces + Serialization, this is trivial, as well as much > > cleaner than in C++, IMO. I did this all the time in my last Java > > application. > > It doesn't work if the object whose interface you are exporting > is opaque to where you are exporting it... it's very hard to > reinstance an object for which you don't know the class. Well, duh? > In C++, I can actually pass such an object through a third party, > but with Java, it's practically impossible, without the third > party knowing the object layout. Not true. You can still do a pass thru using reflection/serialization. > See the Sun draft RFC on the > serialization of Java objects into LDAP directories: the objects > can't be active in the directories (e.g. for adding new attribute > types) because of this. If they're active, then the complete knowledge needs to be known. So, either the object is know, or it's not. (C++ has this problem as well, so things are the same for both languages.) > > > Instance but unconstructed objects are inherently bad. > > > > Because? Static classes are a necessary evil (IMO), and is what makes > > the Java language useful, vs. a nice CS solution. (In theory, one never > > needs unconstructed objects, but in practice things are very different.) > > > > The use of static classes are what makes the language able to handle > > most of design patterns in a simple manner. > > Ugh. There are better ways; Java just doesn't support them. Subjective/elitist attitude. > > > I've implemented the majority of the Java 1.2 and JavaX 1.2 > > > classes, as well as the JavaMail API in C++. > > > > I actually re-implemented parts of the JavaMail API in Perl once, and it > > was pretty trivial. I wouldn't call it a 'significant' programming > > challenge to re-implement the classes. > > > > What I find interesting is that you didn't choose a C++ class as the > > basic for implementing the API. Also, what JavaX extensions did you > > implement? There are about a zillion of them. > > Yeah, I know. I ended up with over 22,000 lines of code, with > the Sun ones necessary for the support of the JavaMail API (I > already said it was 1.2). Wow, that's alot of codes for such a simple API (IMO). > I did start with a C++ class as the basis for the API; it just > happened to follow the pattern of a Java class. If Sun spent > millions upon millions of dollars doing the research, I might > as well use their published information (which I'm allowed to > do, without a license problem ...8-)). > > In the process, I found that unconstructed classes were essentially > impossible to duplicate in C++, and that they were a "necessary > evil" which wasn't really necessary, if you had explicit scoping > available, instead of having to rely on implicit scoping instead. They are trivial to implement in *any*1 language as a non-class. Consider them C classes, which is how Sun describes them. They bundle them into a class only to keep them together. > > > The inability to apply a decent optimizer to JIT'ed code is > > > just the icing on the cake. > > > > Actually, you haven't done much lately, since the new JIT's are quite > > usable. (However, I've found that I can get close to native speed by > > optimizing my Java code, which is *infinitely* easier to do in Java than > > in any other language since the tools have access to a much larger > > THis is about the same state of the art as C in the early 1990's, > where the source code you wrote had a big effect on how fast the > resulting code would run. Modern optimizers have laid some, but > not all, of that to rest, these days. I disagree completely, as you can well imagine. You still must optimize the code to get decent speeds (of course, using Knuth's ideas, code first, optimize later). > I was thinking specifically about peephole optimization and long > loop unrolling, which are pretty easy without a JIT. The code > for predictive branching (e.g. on Alpha and Itanium) is also not > somethin that is commonly done for JIT'ed code, Java or otherwise. Not true. The Compaq JVM did alot of optimization, as well as the optimization on the HP platform are completely state of the art, better than most compilers. > > > FWIW: dynamic scoping is cool; but garbage collection is not > > > something one can afford, when designing an embedded system. > > > > Blanket statements like that prove that you are being elitist. You > > really should get out more often Terry. > > The problem with GC's is that they always run at the most > inopportune time (not elitism: just bowing to Murphey), and > your memory profile is not precommited or deterministic, > unless all your inputs are deterministic. So for some subset > of problems you can use it, but it really limits the utility > of the language. Not necessarily. Many of the new JVM's (as well as older ones) allow you to tune the GC setup to be 'more' deterministic, but not completely deterministic. We took advantage of this fact to help out our application not use as much memory. > Needing to pay Sun half a million and per unit royalties isn't > helping the language out any, either... That's changing (or so I've heard). > > We attempted to use Kaffe for our Java product, and kept giving up in > > disgust. The final straw was when M$ bought the primary Kaffe > > developers off which effectively killed the product. The basic Sun JVM > > w/out a JIT out-performed Kaffe with a JIT, because of bugs and > > non-support for many of the Java 1.1 features, and some bugs in the Java > > 1.0 support. Don't compare Java using Kaffe with Java performance. > > (And, I understand that cost was the primary reason that Whistle chose > > Kaffe vs. Sun's JVM, but it's still unfair to imply that using Kaffe for > > your JVM is a fair comparison to how Java performs.) > > Not really; the primary reason was that the memory footprint > was much, much smaller. If you want a smaller memory footprint, then you the original JDK1.0 code. It's at least an order of magnitude less (which is why Kaffe was using a smaller footprint, since it didn't support the 1.1 features). > That's also why the Almaden researchers > chose to use Kaffe for their project, even though they had ready > access to IBM's JVM, and Sun's JVM, through IBM's licensing of it. That happened later, as I understand things. The researchers didn't have access to the code at the time, so momentum kept them using Kaffe, despite all it's shortcomings. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?15328.11148.994822.484027>