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

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

        Markus,

> > > 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?
> 
> IF RedHat's GCJ/Classpath project really fixes bugs faster, sure it is an
> argument. But I did not consider GCJ/Classpath to be a professional
> alternative, since it does not cover a complete J2SE or J2EE platform yet.
> So before I can judge RedHat's beeing faster in fixing bugs, I need to
> wait for a complete release to test for bugs first.
> 
        I used GCJ just as an example. I wanted to mention a VM with a
static compiler here, but some of them are long gone (TowerJ, JOVE) and
others target J2ME. I am not sure what is the current status of BulletTrain
- at least the NaturalBridge's Web site is still live and has some
information about the product. I would have used our product (which covers
J2SE) as an example, but thought that could make the readers think I am
continuing this discussion to promote it. 

> > > 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.
> 
> Dmitry, you know I thought of Java components since this is a Java related
> discussion.
> 
        Well, our experience shows that it is possible to find good
components for Delphi and C++. What is so special about Java that makes the
creation of good Java components impossible? :)

> > > 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.
> 
> We gave up after trying to fix a bug in a professional, closed party
> product that came with source code. The code was worst I have ever seen.
> Parts of the variable and method names, also many comments, had been in
> serbocroatic language! :-(
> 
        That's why I suggested the 15 minutes time frame. You can of course
adjust it according to your deadlines, time zone, past vendor
responsiveness, and so on.

        We avoid writing comments in Russian even in our internal-use
sources, because there exist so many completely different encodings that
Russian comments are not portable at all (DOS, Windows, Unix, and Mac are
all different, plus there is also ISO...)

> > 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...
> 
> One would wish that vendor to be removed from the Java Map. ;-) Maybe it
> would help if there would be something like a "Approved Quality" label
> that we could stick on our products to declare our software beeing more
> bug free than others...
> 
        Things like Readers' Choice Award reflect product quality to some
extent. I can suggest no other means to create a trusted label of this kind
but through end-user experience.

> >     Maybe that's only Russian programmers who are solving problems in
> > such a way? :)
> 
> I don't know, maybe it is. ;-))
> 
> You're from russia? Moved to the states or working remote?
> 
        He-he, you've got into this trap too. The domain name
excelsior-usa.com is reserved for future extension. Right now, we are 100%
Russian company located in Novosibirsk (GMT+6, circa 3,000 km to the east
from Moscow). The only asset of our company that resides in the US is the
corporate Web site. :)

> > > > 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?
> 
> So with your sound analysis you have a problem here: You wrote below that
> you don't have the knowledge of that business, so how can you fix a bug
> then?
> 
        Well, that particular case is related to incompatibility between JRE
1.3 and 1.4 APIs, so if the library was not obfuscated, or the source was
available, it should have been possible to track down the problem.

>  I Germany this is solved that way often: A company needs to provide a
> proof of how potent they are. This means, we do not buy third party from
> everyone but only from partners that can proof they will still exist and
> maintain their software in two years.
> 
        This raises an interesting question: When it comes to open source,
how can you be sure that a particular piece of OSS will still be maintained
in two years? I do not mean first-grade projects like Linux or Apache
(though the former is experiencing legal attacks from SCO.)

> > > 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.
> 
> Ususally yes, but I hope that IBM, Novell and others speed up a bit.
> Novell is a good candidate. They have moved from 1.4.1 to 1.4.2 now, while
> Sun released 1.4.2 in Summer. So they have a delay of a quarter of a year
> only. They had a delay of two years with 1.3 AFAIK. So if they keep this
> evolvement, they maybe could become the first releasing 1.6? Why ever,
> Novell seems to have faster Java implementors than Sun has... ;-)
> 
        Sounds great. Should not we consider a Novell port after we are done
with Linux?

> For IBM, it is not true that they don't have 1.4 for Windows. I asked IBM
> for that half a year ago. Actually they had 1.4 for Windows already, but
> unfortunately they stopped marketing for a standalone, free SDK. This
> means, if you want to get a Windows 1.4 JRE from IBM, you need to buy the
> next release of WebSphere for Windows. Unfortunately there are other
> components in that sampler which need more maturity so it is not on the
> shelf yet. I asked them if there is any way to get the Windows 1.4 JRE
> without waiting for that. He told me that this is not planned by IBM.
> 
        I was not aware of that. Thank you for the information.

> Seems IBM recognized that there is no need to compete with Sun on the
> field of free software when they can just profit from selling their
> product. They know their VM is better so why giving it away for nothing?
> 
        So do we. :)

> Actually, we do not consider AOT since we experiened that there is much
> more potential in improving the Java source. We had such a project years
> ago in JOnAS where a programmer just removed BAD code in JOnAS by GOOD
> code and JOnAS was improved (on my system, with my app running on top) by
> 50%. I am sure we can repeat this. Same though Mr. Bulka (?) when writing
> his book on server side performance tuning. AOT is the last step one
> should do. Writing good code should be the first.
> 
        Could not have said this better ourselves, after dealing with tons
of third-party code. AOT surely won't make bubblesort work at the speed of
quicksort on large datasets.

        A VM switch still looks more appealing than the
profiling/analysis/refactoring cycle under certain circumstances, e.g if you
need that 15-20% speed increase ASAP or face contract termination.

        With best regards,

        Dmitry

>  << File: message.footer >>