Date: Wed, 31 Oct 2001 00:28:20 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Nate Williams <nate@yogotech.com> Cc: John Baldwin <jhb@FreeBSD.org>, chat@FreeBSD.org Subject: Re: time_t not to change size on x86 Message-ID: <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>
next in thread | previous in thread | raw e-mail | index | archive | help
Nate Williams wrote: > > 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. 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. 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. > > Java is really "dumbed down" in order to make it safe for people who > > aren't very meticulous about their coding. > > Yeah right. I've been doing C/C++ coding for 16 years, and *EVERY* > single person I've spoken with that has done significant coding in both > C++ and Java would choose the latter in a heartbeat, since it allows > them to focus on the problem at hand, rather than the language. > > Again, you're being elitist, especially considering you've never coded > up anything significant in Java. Well, that's an invalid assumption; but in any case, as far as your anecdotal experience, different strokes for different folks... > > 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. > > 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). 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. > > I've also done not an inconsiderable amount of work in Rational Rose > > with "plain old Java". > > RR is not a Java product, IMO. Claiming to be a Java programmer because > you used RR is like saying you're a Basic programmer because you made a > nice QUI in V-Basic. I said *with*, not *generationg*; code generators are pretty much fun for rapid prototyping, but not useful for real code. > > I think that historically, we will find that Java will end up > > being a compiled language, and will serve predominantly as a > > cross platform API. > > That's your call to make. I don't see it happening, as there still > isn't a single usable compiler for Java. (The closest one to being > usable is TowerJ, but it leaves out all of the AWT/Swing/GUI classes, > making it less than useful.) Yeah; that's really annoying, since one of the most useful things you can do with Java is UI work, since it's not really performance sensitive, since it hooks humans to computers, and humans aren't well known for running at high clock rates. 8-). The reason I say that it's probably going to fall into the cross-platform API crack is that it has so far failed pretty badly to deliver the "write once, run everywhere" promise. > > This is, I think, the reason that Microsoft targeted it for > > the "embrace and extend" treatment. > > Java on M$ is a dead product. It is now. At one time, Microsoft intended to tie it to a lot of JNI code that was written for Windows, but not for other platforms. IE's Java GIF renderer (for example) was via a JNI, rather than interpreted, like the one in Netscape (this is why, unless you serialize image loads, mvong the mouse in a Java UI on FreeBSD Netscape prior to a complete download will crash the browser). Like it or not, most useful platforms for Java code are Microsoft platforms, even if Microsoft itself isn't doing the JVM support themselves any more. > > 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 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. > > 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. Needing to pay Sun half a million and per unit royalties isn't helping the language out any, either... > 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. 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 said, the overhead of using Java was _significant_, and > > one of the things we had to do (add a more powerful CPU and > > more RAM) pushed in a number of undesirable attributes, as > > wll, including, but not limited to, the addition of moving > > parts to the product (fans) to dissipate the increased heat > > from the increased hardware bulk required. > > *laugh* You are entertaining, if nothing else Terry. I can give you > counter-proposals about how a Java implemented solution used *LESS* CPU > and RAM than a functionally equal C++ application. Must be really badly written C++ code... 8-). -- Terry 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?3BDFB624.D85F5352>