If I were in charge of re-designing SageTV.....

[m1abrams]

Originally Posted by Slipshod

I'm weak.... I can't resist the call. I know I should, but I can't...

Davephan - When Java was originally introduced it was severely slow. It's matured significantly since then, and is very competitive with other languages on speed. C# is largely a wash, and while C and C++ can be faster in certain ways the difference is not terribly significant for a large interactive application (as opposed to a small number-crunching benchmark). You could even argue that it frequently can be faster than C/C++ because you don't have to be as skilled a programmer to have fast, optimized code.

Cheers,
Slipshod

While I agree with this, the issue I have seen most with Java is the fact that many developers have seen the need to build their own custom JRE which kinda defeats the major benefit of using Java. The software written for one JRE may not work on another JRE.

[jominor]

Originally Posted by davephan

I would port parts or the entire application to a much faster Language. Java is very very slow.

Dave

No it isn't. Just give it a bit of thought for a moment. Why would people gamble their livelihoods on something that is provent to be "very, very slow." That's nonsense. I guarantee you I can expose you to all manner of Java apps and you'll never know on the basis of performance.

Vista is pretty much acknowledge as the slowest, fattest OS MS has ever released. It is mostly C++.

Where would you flee?

[stuckless]

the issue I have seen most with Java is the fact that many developers have seen the need to build their own custom JRE which kinda defeats the major benefit of using Java. The software written for one JRE may not work on another JRE.

I've been in java a long time.... (started in C btw), and I've never seen a developer start a java project where they found it necessary to build a custom JRE.... On the flip side... I've worked on many c/c++ projects where the first step in the project is to write the String Utils, List Utils, Map Utils, etc, (STL has made this a little better).

In my experience, I develop in linux/java, some of my my co workers develop in windows/java and we all deploy to solaris/java environment. The biggest challenges that I've faced have been to deal with different java versions.... but no one has decided to write their own custom JRE yet... so I count my blessings....

I wonder if you are confusing the custom JRE with the Sun/Microsoft fiasco where Microsoft decided to build their own custom JRE with the hopes of providing Java vendor lock in on the Windows platform. Those years were painful.... especially when developers would inadvertantly use the custom MS apis and then deploy to non MS platforms. The result here was that Sun flexed their muscle and forced MS to comply and the result was that MS decided to create their own virtual execution environment known as C#.... If I recall, they even provided tools to convert java to C#.... Other than that mess.... can't say that I've had an issue with people/companies writing a custom JRE....

[m1abrams]

Originally Posted by stuckless

I wonder if you are confusing the custom JRE with the Sun/Microsoft fiasco where Microsoft decided to build their own custom JRE with the hopes of providing Java vendor lock in on the Windows platform. Those years were painful.... especially when developers would inadvertantly use the custom MS apis and then deploy to non MS platforms. The result here was that Sun flexed their muscle and forced MS to comply and the result was that MS decided to create their own virtual execution environment known as C#.... If I recall, they even provided tools to convert java to C#.... Other than that mess.... can't say that I've had an issue with people/companies writing a custom JRE....

Yes that is what I am referring to. Also Oracle ships with its own jre. I do know that even if I have Sun JRE installed on the server, oracle insists on using its own.

[jominor]

Originally Posted by m1abrams

Yes that is what I am referring to. Also Oracle ships with its own jre. I do know that even if I have Sun JRE installed on the server, oracle insists on using its own.

There are, I think, two issues. Here.
1) Companies that have written their own clean room implementation so they didn't have to license java from Sun.

2) Companies that simply bundle a JRE with their product so they rest assured that the users have everything out of the box.

I think Oracle is actually item 2. I don't recall hearing that they wrote an entirely new implementation.

Furthermore, you can easily configure Oracle(or related products) to use whatever jre you wish.

[jominor]

Originally Posted by jominor

There are, I think, two issues. Here.
1) Companies that have written their own clean room implementation so they didn't have to license java from Sun.

2) Companies that simply bundle a JRE with their product so they rest assured that the users have everything out of the box.

I think Oracle is actually item 2. I don't recall hearing that they wrote an entirely new implementation.

Furthermore, you can easily configure Oracle(or related products) to use whatever jre you wish.

For one, IBM and HP both wrote their own for these reasons. BEA wrote a high-performance jvm jrockit.

[GKusnick]

The way I remember the MS case, MS wanted to use Java for writing non-portable Windows apps. Sun wouldn't allow that, taking the unreasonable position that all Java apps must be portable; no native code allowed. MS thought that was silly; if Java is such a great development tool, why shouldn't developers be allowed to use it even in cases where portability isn't a requirement? So they built their own JRE that allowed access to native APIs. Eventually Sun got the message and added JNI to the Java spec, making the MS JRE unnecessary.

[stuckless]

From the JNI documentation http://java.sun.com/docs/books/jni/html/intro.html#994

The need for Java applications to interoperate with native code has been recognized since the very early days of the Java platform. The first release of the Java platform, Java Development Kit (JDKTM) release 1.0, included a native method interface that allowed Java applications to call functions written in other languages such as C and C++. Many third-party applications, as well as the implementation of the Java class libraries (including, for example, java.lang, java.io, and java.net), relied on the native method interface to access the features in the underlying host environment.

So I'm not sure sun cared if you wrote non portable java applications so much as they cared that you didn't mess with the standard byte code. I may be wrong here, but didn't microsoft change the byte code so that applications compiled with their JDK would not run on non MS JVMs....

[jominor]

Originally Posted by GKusnick

The way I remember the MS case, MS wanted to use Java for writing non-portable Windows apps. Sun wouldn't allow that, taking the unreasonable position that all Java apps must be portable; no native code allowed. MS thought that was silly; if Java is such a great development tool, why shouldn't developers be allowed to use it even in cases where portability isn't a requirement? So they built their own JRE that allowed access to native APIs. Eventually Sun got the message and added JNI to the Java spec, making the MS JRE unnecessary.

Suns position wasn't unreasonable at all. The portability of Java is its main point. MS has a track record of coopting technology in just the manner you described and Sun was smart for stopping it.

JNI was included to allow for integration with native code, for legacy support, not, to my knowledge as a means to stop MS.

[jominor]

Originally Posted by stuckless

From the JNI documentation http://java.sun.com/docs/books/jni/html/intro.html#994


So I'm not sure sun cared if you wrote non portable java applications so much as they cared that you didn't mess with the standard byte code. I may be wrong here, but didn't microsoft change the byte code so that applications compiled with their JDK would not run on non MS JVMs....

[I think] Sun absolutely cared. The issue was that MS wanted to include Windows only keywords in their java. Even if you didn't use the native interfaces, those keywords would break on any other JVM.

[stuckless]

[I think] Sun absolutely cared. The issue was that MS wanted to include Windows only keywords in their java. Even if you didn't use the native interfaces, those keywords would break on any other JVM.

Again... not sure Sun cared about the inclusion of native code, since they supported that model, but the introduction of new "keywords" translated into changing the java language, which means a new byte code. Sun did care that the bytecode changed.

[jominor]

Originally Posted by stuckless

Again... not sure Sun cared about the inclusion of native code, since they supported that model, but the introduction of new "keywords" translated into changing the java language, which means a new byte code. Sun did care that the bytecode changed.

I actually agreed with you. I just didn't express it well. :-)

[GKusnick]

Originally Posted by jominor

Suns position wasn't unreasonable at all. The portability of Java is its main point.

Portability may have been the main point, but there was an element of religious fervor to it that took it beyond the bounds of reasonableness (in my opinion). The implication was that anyone writing non-portable apps (especially Windows apps) was somehow betraying the cause or going over to the dark side. A lot of people (not just at MS) found this with-us-or-against-us attitude overbearing and offputting, and in my estimation it was a factor in delaying the widespread adoption of Java, which is after all just a tool that developers should be free to use as they see fit, without any ideological strings attached.

MS may not have been innocent, but my point is that Sun wasn't either. They both cared more about controlling the technology than about serving the needs of real developers. Or at least that's how it seemed to me at the time.

[stuckless]

I actually agreed with you. I just didn't express it well. :-)

I realize our position is in essence the same, I just take issue with the "native" part, since I think that native code wasn't the issue as much as changing the language. The important thing is that we both disagree with Greg

They both cared more about controlling the technology than about serving the needs of real developers

On that I agree... but I think that Microsoft was getting scared that Java on the Desktop would become a reality... and they needed to ensure that if Java on the Desktop was a reality, then it was Java on the Windows Desktop. Not that they had anything to worry about.

it was a factor in delaying the widespread adoption of Java

I think that Sun needed to ensure the integrity of the Language, and I don't think that their decision slowed the adoption of Java at all. Java has been widely adopted on the server side. And, really, there is no way Java was going to become adopted on the Desktop. The primary reason I went to Java was because I knew I could write applications and deploy across windows/linux environments. The MS tactic scared me alot. Do you know frustrating it is to get a Java application, and run it, only to discover that the ONLY reason it does not run for you is that the developer made a decision to store one piece of information in the Windows Registry. That sucks and it's a waste. Portability is a big factor in the Java landscape.... Not that you need to write portable apps.... but you should

[jominor]

Originally Posted by GKusnick

Portability may have been the main point, but there was an element of religious fervor to it that took it beyond the bounds of reasonableness (in my opinion). The implication was that anyone writing non-portable apps (especially Windows apps) was somehow betraying the cause or going over to the dark side. A lot of people (not just at MS) found this with-us-or-against-us attitude overbearing and offputting, and in my estimation it was a factor in delaying the widespread adoption of Java, which is after all just a tool that developers should be free to use as they see fit, without any ideological strings attached.

MS may not have been innocent, but my point is that Sun wasn't either. They both cared more about controlling the technology than about serving the needs of real developers. Or at least that's how it seemed to me at the time.

You've got an interesting perspective, that's for sure. I've written apps for both Windows and Non-windows, but I don't agree. MS clearly was trying to break Java because cross-platform is a threat. This has nothing to do with philosophy. If you wrote in Java, you expect that your application will deploy on anywhere there is a JVM.

That's the point. Now, what happens when you can write an app that works the same on Windows and non-Windows machines.

You don't need Windows and applications are Windows main advantage. This is why MS was trying to sabotage it. No different than what they did to Netscape, but Sun wasn't a one-trick pony.

Java's initial problems, had more to do with 1)poor applets and 2)Poor initial problems than Sun trying to do anything to MS.

I've yet to meet the person who thought that what MS was doing was anything less than an obvious attempt to fragment and weaken Java. Sun successfully blocked then and Java is better for it.

I don't think your interpretation of events is accurate. Or even fair to Sun. Sun, IMO, knew that a truly cross-platform Java was and is stronger and better than a fragmented flavors which is why to are strict with everyone with respect to what can legally be called Java.

[jominor]

Originally Posted by stuckless

I realize our position is in essence the same, I just take issue with the "native" part, since I think that native code wasn't the issue as much as changing the language. The important thing is that we both disagree with Greg


On that I agree... but I think that Microsoft was getting scared that Java on the Desktop would become a reality... and they needed to ensure that if Java on the Desktop was a reality, then it was Java on the Windows Desktop. Not that they had anything to worry about.


I think that Sun needed to ensure the integrity of the Language, and I don't think that their decision slowed the adoption of Java at all. Java has been widely adopted on the server side. And, really, there is no way Java was going to become adopted on the Desktop. The primary reason I went to Java was because I knew I could write applications and deploy across windows/linux environments. The MS tactic scared me alot. Do you know frustrating it is to get a Java application, and run it, only to discover that the ONLY reason it does not run for you is that the developer made a decision to store one piece of information in the Windows Registry. That sucks and it's a waste. Portability is a big factor in the Java landscape.... Not that you need to write portable apps.... but you should

+1. Back in the day, I had to support a C/C++ library(no gui) across Win16, Win32, Unix(Clix, SunOS,HPUX), and VMS. It was a total hassle.

Java virtually eliminated that overnight on the server and headless client side. The proble with Java was on the GUI client-side. A GUI library that is both portable and fast is hard to create. Ask Sun. Ask Galaxy. No one else does this but Java.

For example, take the system tray. You have to support that on MacOS, Windows, Linux, and say Solaris. It took them until Java 6 to do this.

That is more of a challenge than just C++ in Windows.

[bastafidli]

There is library called SWT from Eclipse project which provided such support before Java 1.6

[jominor]

Originally Posted by bastafidli

There is library called SWT from Eclipse project which provided such support before Java 1.6

I know all about SWT. IBM made their own set of compromises to get this out of the door, the main one being its use of native code. Eclipse was written using SWT.

However, I think you've proven my point. IBM felt strong enough to forgo using AWT or Swing and decided to write their own.

To my knowledge, and I"m shakey on this because I hang more on the server side, the JSE 6's implementation is all native.

[bastafidli]

I am not sure what you mean by native vs. not native. What both SWT and JDK 1.6 do is to provide "native" integration between the Java and the OS they run on. So there is Java abstraction and there is native portion, which in SWT is implemented in DLL and in JDK this code is part of the JVM/accompanying libraries. So they do approximately the same thing approximately the same way, except SWT did it couple of years earlies and provides way more functionality. I implemented several applications using SWT (starting in 2003) and in most cases you cannot tell the difference between Java and non Java application. As far as performance, properly coded application is comparable to C/C++/C# for example see http://shootout.alioth.debian.org/gp...t=all&lang=all

[jominor]

Originally Posted by bastafidli

I am not sure what you mean by native vs. not native. What both SWT and JDK 1.6 do is to provide "native" integration between the Java and the OS they run on. So there is Java abstraction and there is native portion, which in SWT is implemented in DLL and in JDK this code is part of the JVM/accompanying libraries. So they do approximately the same thing approximately the same way, except SWT did it couple of years earlies and provides way more functionality. I implemented several applications using SWT (starting in 2003) and in most cases you cannot tell the difference between Java and non Java application. As far as performance, properly coded application is comparable to C/C++/C# for example see http://shootout.alioth.debian.org/gp...t=all&lang=all

SWT mostly wraps native(C/C++) API to implement its controls. Swing uses the Java 2D to draw its controls. SWT is basically a thin wrapper around OS GUI APIs.

I'm not saying one is better. Since I tend to work with java on the server side, I don't really care. I am taking a leap, and guessing that they finally got around to implementing whatever needed to be implemented to support Tray Icons in Swing.

And as you probably know, there is a bit of a schism between Swing and SWT. Again, I don't care. My only point was to address the guy who said that Java was slow, which it isn't.