Re-2: [ObjectWeb architecture] just an idea for (Java) native comp ilation

[<markus.karg@xxxxxxxxx>]

Dmitry,

> > 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.

> > 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 ;-) ). :)

Damned tower of babylon. ;-))

> > 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.

> > 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! :-(

>       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.

Sometimes I wish it would be possible to kick-ass some developers. But as an 
alternative, luckily there are third-party drivers for most databases. But I 
know what you mean. But actually I don't want to be the bug fix guy for every 
third-party software any user has. This is a problem for many companies, I 
know, but actually it is not a Java-only problem. We had the same with bugs 
in the Windows OS also... One time I asked for help at Redmond and they told 
me they know the bug for years but don't intend to fix it!?

> 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...

>       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?

> > > 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? 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.

> > > 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.

Maybe it would make a good open source project if there really is only one 
vendor and the business is that complex. Maybe some university is interested 
in something like that...?

> > 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... ;-)

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.

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?

> > 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?

Actually I don't have the URL here since I was not interested in that topic 
when I read that news. Maybe I was wrong totally, but I thought to have read 
this some months ago.

> > 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.

Hm... I think the real cause for the changes was that the old API was miles 
away from beeing mature. ;-)

> > >   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. 

Sure, yes, we think twice. Actually we read specs until we really understand 
it, and begin programming THEN. I know many companies do it the other way. 
Hack some stuff, try out on the own machine ("it runs for me"), fall on the 
nose on another machine, fool around with senseless workarounds, THEN read 
specs MAYBE... ;-)

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.

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

;-))

We did for some extend. There is special hardware connected to our app, by 
means of RS-232. Fortunately there is JavaCommAPI, so we just had to 
implement the higher level protocol on top of it... :-)

> > 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. :)

Sometimes I think Sun's marketing isn't aware of Java at all... ;-)

Have Fun
Markus