News and commentary from the cross-platform scripting community.
|
||
|
Mail Starting 4/9/98 | |
Someone wondered why MS isn't going to use VJ6 for the next version of Java.
From: michaelw@microsoft.com (Michael Winser);
Sent at Thu, 9 Apr 1998 17:34:15 -0400;
Why the next version of Excel won't be written in JavaWould you port millions of lines of C++ and C code to a new language just for the sake of it? No.
Would you take the entire Excel development team and make them learn Java just for the sake of it? No.
Would you even start writing new Excel code in Java and inter-mixing it with the existing C and C++? No.
Would you trash a huge investment in code and developer experience in one big hyper java jump? No way.
You should attend the Java SIG of the Software Entrepreneurs Forum to see what the Java development community is up to. A year ago about 50 people showed - less than 10 said they were employed to write Java. This week's meeting had about 125 people - 3/4 of them said they were employed and there were lots of announcements of Java developers wanted.
From: fcohen@inclusion.net (Frank Cohen);
Sent at Thu, 9 Apr 1998 09:55:52 -0700;
Re:The Java BalloonMicrosoft presented Visual J++ 6.0 beta. I am at a loss to figure out their product strategy. VJ6 is a hybrid: some written in Java some in C++. The IDE runs very fast since it includes all the native optimizations. Good for them. Will Microsoft use VJ6 to write the next Excel? "No," said their product manager. If VJ6 builds Windows-native applications that run quick and offer the benefits of Java - easy code maintenence, solid object technology that would let developers inherit and override the application's published classes - then why not move Microsoft's applications to VJ6?
The down side to VJ6 is that they introduced yet another component model and event model. Their models compete with Java Beans - they are incompatible. While you can quickly write Java classes, you can't turn those classes in Java Beans and let others benefit from your work. And when it comes to scripting... well.
Generating native code from Java classes does not mean the end of "write-once-run-anywhere". In fact, it's likely to make it a reality sooner. You see, the problem is that most of what people call Java is today actually implemented in native C code, and can be changed by each vendor or reimplemented on their platform. Thus, even when they aren't adding or changing any Java classes their implementation is still subtly different from everyone else's.
From: jyl@tcl-tk.com (Jacob Levy);
Sent at Thu, 09 Apr 1998 07:57:28 -0700;
The Java BalloonWhen you generate efficient native compiled code from Java classes, it opens up the opportunity to rewrite in Java a lot of the code that's now written in C and that is now part of the Java VM. A lot of this code is in C for efficiency reasons only, and could equally well have been written in Java, if the performance was bearable. Now it's going to be, so to guarantee portability it makes sense to rewrite it in Java. Only the parts dealing with really system specific stuff like threads and memory allocation have to be in C.
Compiling to native code also does not mean that people give up on the run-anywhere part. Most compilers that you mention take as input bytecodes or Java, so they preserve the idea of bytecodes as the transportable code format. Compilation on the fly for downloaded code is a well understood idea and surely will be incorporated into every respectable compiler and runtime environment.
Finally, the issue that people had with ActiveX was not about being impure or some abstract concept like that. The issue was that ActiveX code is written in C and thus opens you up to all the security issues associated with C code. In contrast, native code generated from the bytecodes is guaranteed (if the compiler is correct) to be as safe as the bytecodes. Another issue was that ActiveX enabled code only works on Windows. The bytecodes, in contrast, can be compiled and linked on any platform on which there is a native compiler and runtime.
No portability is lost.
I don't look at the Java issue as a Sun or Microsoft issue but rather a customer and ISV issue. I still think ISVs and customers find a very compelling value proposition in being able to deploy an application or a piece of middleware across a heterogeneous environment.
From: tschlein@kpcb.com (Ted Schlein);
Sent at Thu, 9 Apr 1998 09:55:34 -0700;
Re:The Java BalloonPicture the ISV that comes into a corporate customer and answers yes to whether they can be deployed on Unix, Windows, or some other variant or all of the above. Not necessarily on the client but on the server whether that server is a typical NT or Solaris box or a 390 or AS/400. Integrating these systems is a very powerful feature and benefit.
As for clientside deployment, you can either go through and debug for each VM, which have numerous ISV's that have done it quite successfully or you can pick a VM and debug for it. In many caes you might pick the MSFT VM since it resides on most clients. As long as it works well, customers are not going to care.
So I think Sun can still win, not with total dominance of the server market but by supplying high performance servers that run Java services and applications extremely quickly and reliably. This does not mean that Microsoft loses but it does mean that customers win. I think the next big hurdle will be how good HotSpot really is.
