RE: [ObjectWeb architecture] just an idea for (Java) native comp ilation

["Leskov, Dmitry" <dleskov@xxxxxxxxxxxxxxxxx>]

        Markus,

> > > 1) Bugs
> > > 
> > > Every VM has bugs. I am assuming that you will not tell us that your
> VM is
> > > bug free. What sense does it make to switch from one VM to another and
> > > give up the bugs of one to get the bugs of the next? Also, I would
> prefer
> > > telling the vendor of a bug to receive a patch instead of just
> switching
> > > the VM.
> > > 
> >     Sure, I am not going to pretend that our software is bug-free or was
> > designed using fail-safe methodologies. Then, with Sun you have the
> option
> > to tell them about the bug, but see how many bugs have been open in
> their
> > bug parade for years... Maybe they would fix the bug you submitted if
> you
> > subscribe for some paid support service, I do not know. 
> 
> That's true but still it is an argument for not switching the VM.
> 
        Why? If RedHat fixes the bugs you report in GCJ/Classpath faster
than Sun in HotSpot, does not it create an argument for at least considering
switching to their implementation?

> > > 2) Incompatibilities
> > > 
> > > RTFM. ;-))
> > > 
> >     *I* did. Moreover, the article from which I borrowed the sample
> > includes all this information. I have included its URL in my message 
> > instead
> > of pasting full explanation and workaround, just to save space. So
> please 
> > do
> > not make assumptions about my knowledge of the platform and tools. :)
> 
> As you can see by the ;-)) it was just a joke. I really appreciate your
> knowledge and enjoy this discussion with you. I do not make assumptions
> about your knowledge, it was just the answer on the more or less false
> example you posted. I will do no more jokes in future. Sorry.
> 
        As you can see by the :), I recognized it as a joke. I will
recognize more in the future :) , though I cannot guarantee I will always be
able to do that (after all, we both are using a non-native language to
communicate), so please continue marking them with ;-) ). :)

> > > Java is UPWARDs compatible, not DOWNWARDs. That means, sure if you
> compile
> > > it without target and bootclasspath switches, what you get is expected
> to
> > > run on JRE 1.4 and sure will not work on 1.3. But hey, Sun can expect
> one
> > > to read the docs when using their free JDK...
> > > 
> >     Well, suppose you have read the docs, but the author of some
> > third-party component that you want to use have not.
> 
> Did you find any GOOD third party components actually? No joke: We didn't.
> 
        We do not do much Java programming ourselves, but mostly help our
clients optimize their Java software, when the choice of components has
already been done. Our own product is written mostly in Oberon-2 and
Modula-2 and for custom application development we primarily use C++ and
Object Pascal (Delphi). So, to your question: yes, we did find good
components, although not Java components.

> > You can guess the
> > reason of the problem, decompile the offending classes and recompile
> with
> > proper switches or try complaining to the author.
> 
> Are you really doing that? We don't. Instead we post bugs and try to get
> vendor support. It's not my job to seek other's failures (as long as it is
> no open source, where I don't need to decompile).
> 
        Our experience shows that it is often the fastest route to a fix. At
least it makes sense to try and if you can find the reason and suggest a fix
in 15 minutes, you can have your product working and send the bug report to
the vendor together with the solution, though it does not always help.

        For instance, we had been fighting a memory leak in our client's
product a few months ago, which appeared to be in a third-party JDBC driver.
We had found the place in its code where the leak occurs and suggested a
workaround. Our client had communicated that information to the driver
vendor, but the workaround is still there...

        Maybe that's only Russian programmers who are solving problems in
such a way? :)

> > The
> > library is obfuscated so they cannot patch it and the vendor refuses to
> fix
> > the problem since 1.4 release.
> 
> What about looking for another vendor? If a vendor is dull enough not to
> move on to a new java generation eighteen months past its first release,
> he has to encounter some loss of customers.
> 
        What if the vendor (has been taken over by a company that) is no
longer interested in the product?

> > The problem is that there is no other Java
> > library on the market that does the same thing (as far as I can recall,
> it
> > has to do with audio stream encoding/decoding and analysis), so they
> still
> > live on 1.3 and the management thinks about moving to .NET...
> 
> Hm... Can't believe that there is really only one company that provides
> this. There is are good APIs (media API, sound API) already in the
> platform kernel, so there should be librarys which are using these. IBM
> and Sun would not invent APIs without any use. 
> 
        As I said, that library implements audio stream _analysis_, namely
it can recognize and decode DTMF tones, facsimile transmissions, modem
traffic, and so on, so it goes a little bit beyond the APIs you mentioned. 

> Other idea: Seems to be a golden field. Why not getting up and writing one
> and lateron selling it?
> 
        I believe component development is not their business. Also, it
would take a lot of time to gather information about all existing fax/modem
protocols and stuff like that.

> >     Then, Windows is not a perfect analogy, because it is only available
> > for one hardware platform (well, now also for IA64) and comes from one
> > company, whereas there are many Java vendors that have their own release
> > schedules. 
> 
> This is not true. Windows exists for IA64 as you wrote, and months ago it
> existed for Alpha.
> Also, the version numbers are not vendor specific as one might think. The
> numbers are given by the JCP and designate the standard not the product. A
> product that implements the "Tiger" standard might be called "MyVM 36.7",
> but actually it implements "J2EE 1.5". This is a difference.
> 
        Whatever the name, vendors are usually months behind Sun. Correct me
if I am wrong, but it took Apple about a year to catch up with 1.4 on MacOS
X, and IBM still does not have 1.4 available for Windows.

> >     The Windows 95 to 3.11 example is even more incorrect, because there
> > was also a big change in  hardware. Or am I so ignorant and Java 1.4
> uses a
> > different set of bytecode instructions? :)
> 
> In part it does. AFAIK there is a difference in the JAR format (what is
> EXE in the Windows analogy). Also AFAIK in Tiger there really is changed
> bytecode. 
> 
        I have heard of JSR 175 "A Metadata Facility for the JavaTM
Programming Language" but it is not about changing the bytecode section of
class files. The JSRs that describe language extensions used to emphasis on
the fact that no JVM instruction set changes are required. So would you
please point me to a JSR that proposes bytecode changes and will be part of
1.5?

> In addition the main difference in the APIs of Win95 and Win311 was not
> the hardware change 16 to 32 bit, but a lot of new APIs and changed API
> models (driver model).
> 
        One can say that the hardware change was used as an excuse for
massive changes in the API.

> > > Maybe what many people are upset is that WORA. Actually WORA works if
> the
> > > ISV knows what he does. 
> > > 
> >     This is exactly my point. Should not it be rephrased "Think Twice,
> > Write Once, Test, Uh-Oh, Think Again,..." then? :) Or would that
> resemble
> > the C++ development cycle too much? :)
> 
> Well, this is no joke, but we do not have that problems that you talk
> about. :-)
> 
        I think this is exactly because you think twice, or think well, or
both. As we are a JVM vendor, our support deals with lots of third-party
Java software, the authors of some of which did not do that. For instance,
we had several support cases where compiled applications hang on startup
because the authors relied on sleep() for synchronization. 

> Maybe you are writing device drivers in Java? ;-))
> 
        Thanks God, the answer is "no, we are not writing device drivers,
period.". :)

> > > WORA works inside of a generation. WORA works UPWARDs for the most
> extend
> > > (not for point 3) even with increasing platform numbers. But WORA is
> not
> > > meant to work DOWNWARDs. The idea that WORA would work DOWNWARDs is
> not
> > > promised.
> > > 
> >     Now, why I think that downwards compatibility *is* an issue? Because
> > it takes vendors time to update their JDKs after Sun releases a new
> major
> > version.
> 
> Again, we do not act when Sun acts. We act when the JCP acts. This is a
> difference. Actually the JCP publishes a new J2SE platform standard only
> every eighteen to twenty four months. Is this too fast? I don't think so.
> It was easy for us switching from 1.3 to 1.4, took us just one month.
> Actually it was not necessary but we liked the new features.
> 
        An approach well thought.

> >     Well, I just wanted to provide some samples you asked for and to my
> > surprise it turned into an argument. I agree with you on most points
> > actually. The problem is that there was too much hype about WORA and it
> > disappoints people a lot when they hit one of such problems.
> 
> Actually in 75% we have the same opinion. For the WORA hype: I am not fond
> of hyping anything. That hypers should first read a spec and think over
> the real idea behind it. ;-)
> 
        It looks as if Sun's management/marketing guys had not read the
specs. :)

        With best regards,

        Dmitry