Embedded machines are not the only domain for this chip. It's scalability should make it the ideal choice for a server with hundreds of thousands of threads. So it not a bad thing at all to produce something like this.
Also Java has been rather unsuccesfull on the desktop but is quite succesfull on the server and is also gaining momentum in the embedded machines world. JIT is not the same as interpreted (which you are suggesting). JIT stands for just in time compilation. Another thing sun is working on is dynamic compilation which JIT taking advantage of profiling information collected during execution. One major advantage of dynamic compilation over static compilation is that you can use information that is only available during runtime for optimizations. One of those optimizations could be discovering paralellism. And its exactly this type of optimizations that is beneficial on a MAJC architecture.
Also the ability to combine a MAJC core with a DSP on one die seems like a killer feature to me for embedded machines where every extra chip increases the price of the product.
You seem to be under the impression that its not going well with SUN at this moment. Truth is that SUN one of the more succesful companies of the last few years, especially in the server market.
SGI on the other hand has had quite some reorganizations over the past time.
Linux doesn't have to be a threat to companies like SUN. SUN gets its most revenue from hardware, not from software.
"Just about as likely as me going to my boss and suggesting building a system around a mutant CPU from this drowning company."
Probably your boss won't consult you for this. In case you haven't noticed, I responded to each argument in your post, if you think I forgot one or don't agree: do reply.
It shouldn't be too difficult for SUN to port the JVM since its code was designed to be ported to more than one platform.
They will probably won't deliver a 1.3 JDK since that jdk is still several months away from final release and they probably don't want to add another platform for it right now.
So it makes an excellent platform for running Java.
"It's slow, ugly, and a real hog of cpu and memory."
On the other hand, you can develop software really fast with it, its language is much more elegant than C/C++ and performance is good enough on the server side.
"Can't we move on? There are _hundreds_ of better alternatives."
"On my mac, Swing simply doesn't look (even with their Mac PLAF) nor feel like a mac application."
The explanation for this is quite simple: the apple implementation of Java sucks.
"You cannot have a cross-platform GUI when you create the widgets in your code"
I'm a bit confused about this statement. I hope you don't mean that its impossible to recreate the same GUI on different platforms because that is exactly what swing does.
Later on you mention that it is impossible to entirely incorporate the look and feel of one platform without violating the look and feel on other platforms. You're right, so what? The goal of pluggable look and feel is not to copy into every detail the look and feel of a specific platform but to be able to customize the applications look and feel without touching the application. A nice application of this is to immitate the look and feel of different platforms to provide users with a familiar looking GUI. A more interesting advantage is that it enables application developers to give a unique look to their applications.
"cross platform" for Java programs simply means that a program works on every platform that implements the VM. Of course you can't make all platform specifics crossplatform (that's a contradiction). It's silly to claim that and nobody is doing that.
"NeXTstep and MacOS X Server provide an at least as powerful framework as Swing, but is much faster and doesn't have those inconsistencies."
Irrelevant because you need apple hardware to run it. Nice design but not crossplatform (in both our interpretations of this term).
Sigh, once more: the only, repeat only area where java performance is less than desirable is in the GUI/graphics area. In other areas, ranging from palm top applications to servlets developers are quite happy.
The customers of your java applications probably won't care for your graphical applications. What they do care for is the speed with which you develop applications (about twice as fast as in similar OO languages).
well I still think you are the one doing something wrong. I mean, I have seen several swing apps and have programmed quite a few myself. I found that swing's powerfull features generally are an open invitation to use them which leads to sluggish performance if you don't know what you are doing.
I'm not claiming swing is well implemented at this moment. But if you know how to use it it is usable.
"One could say that that's what they did with AWT - they got the low level done and then the moved on to a more complicated, complete GUI framework. I would argue that they never got AWT right; instead they threw up their hands and said, "oh well", and then proceeded to build a huge monsterous framework on top of the weak foundation that they had built with AWT."
Ok, how would you solve the problem of designing a cross platform GUI framework? AWT wasn't really cross platform since it used native GUI components. Yet it did provide a nice abstraction from the graphical subsystem. What they did with swing is kick out the native components and provide cross platform replacements.
If you really dive into the framework, you must admire its design. Like you said it solves a lot of problems. And it does so in a rather elegant way.
Swing is a large complex framework that was developed in a short timespan (the final version is only a year old). The sun developers added a lot of functionality. What they will probably do the coming time is optimize the framework. I expect that JDK 1.3 will be mainly bugfixes and optimizations.
"Ibm make a wonderful compiler (jikes), and a pretty good jvm but i don't understand why sun doesn't do that job."
SUN can't do all at once. The past few years they have been working really hard designing APIs and implementing them. They don't have time to support every platform. IBM has a nice VM but so far they have failed to implement a good java 2 platform which is annoying. Both SUN and IBM are working on linux versions of a java 2 vm so something should come out of that. Until that linux is probably not a suitable development platform for Java (unless you like waiting tools to become available that are already available on other platforms). I have full confidence that they will support linux eventually because Linux is becoming increasingly important as a server platform.
Gee, I don't know. I've developed several Swing applications (on computers much slower than your 200 Mhz machine) and I can't say I share your experiences. Sure there are certain things like the slow loading and high memory usage of applications that are annoying but generally you can create a decent application if you know what you are doing.
"depending on some data being entered my app"
Read the javaworld main article of this month. It deals with performance problems due to excessive object creation (which probably explains your problem).
netbeans (www.netbeans.com) is a swing app. Actually most java development is either serverside or stand alone client development. If you are doing serverside development you generally don't need a GUI and if you need one swing covers most of your needs. If you are doing client side development, AWT is not good enough because it doesn't provide much functionality and because it relies on native GUI components (leading to all sorts of incompatibilities between platforms). So for both types of applications swing is used often to provide the GUI.
Yes, swing is slow. Yes, it is complex (if you're a pearl/vb/fill in your favorite scripting language -hacker, it's probably too complex for you). But it is also a very well designed framework. For many developers the advantages of the good design outweigh the disadvantages of bad performance.
I heard some people complain it provided too much functionality and that SUN should have focussed on a less ambitious framework. I'm glad they didn't and decided that the design was important. It may take a bit longer for swing to become usable that way but at least it will be really usable when the performance problems are solved.
I get really tired of those folks who stopped reading in 1995 (that's the only excuse for not knowing that java is (successfully) used for other stuff than applets mostly).
True, swing is slow ate the moment. But it has been steadily improving. One of the main reasons for its perceived slowness is that it takes a long time to load the classes. Swing is a very complex framework and thus even simple swing programs load a lot of classes. As an illustration. Back in the days when swing was still beta, you were better of running swing programs with the interpreter than than with the JIT. The simple reason for this was that a JIT compiler compiles all classes that are loaded, including those that are rarely executed. BTW. I was working on a pentium 133 with 64 Mb in those days. Even though the loading time was very high, the performance after loading was quite OK (again on a pentium 133).
What this anecdote proves is that it's not so much the raw peformance of the interpreter that is causing the bad performance but the dynamic class loading. JIT compilers generally only make dynamic class loading an even more expensive operation.
If I remember correctly it is exactly this problem (slow loading of swing classes) that is being targeted by jdk 1.3 beta. I'm really looking forward to improvements in this area.
If you are interested in how to make your Java programs faster, you should check out this article. It provides an excellent background on how Java manages its objects.
If there's one thing you can do with Swing it is building advanced tools to create GUIs (needless to say that such tools exist). Unlike MFC (which is the underlying architecture for VB), JFC has a very well designed architecture.
Because of this you can do really cool stuff like embedding GUI components in other GUI components. Try building a 'tree-table', that is a tree structure with tables as its nodes, in VB. It's almost trivial to do such things in swing. Needless to say that it is equally trivial to use whatever component you want for the table cells. The only problem I have with this particular example is that it is difficult to find useful applications for it (somebody help me out).
The swing tutorial is part of the Java tutorial and has been available from www.javasoft.com/tutorial for years now. During this period the tutorial was expanded to cover new API's. It's an excellent resource for Java programmers. Together with the API documentation it is all the documentation you will ever need. The only thing that puzzles me is why somebody would want to use a printed version of these documents. The online version is so much more convenient.
As the reviewer noted, you typically don't read the tutorial from cover to cover. What you do is find some topic you're interested in, read it. Then you click links to related topics, examples or the API documentation. The latter is very hard to do in a paper version.
that implies that there is an accused and defending party. This is a simple statement "linux has more marketshare on the desktop then NT". I find it a little hard to believe just like that.
Lynx is no alternative for IE. Its only useful if your blind in which case you would want to put a braille machine on it or an enormous nerd with very thick glasses and skull. In all other cases people also want to view the graphical information. Netscape 4 is now at least two years old and we haven't seen it progressing. Netscape 5 is a promissing product but it will take several months to become final. When it will become final it is an unproven but still promising product. In other words it will take at least half a year for mozilla to catch on. That's a lot of time for a browser.
Open cd, insert freshly burnt cd, don't wait for the cdrom to spinup but access the cd straight away with explorer. Enjoy the view (BSOD). Works consistently on my dell optiplex gx1 and nt workstation 4.0, service pack 5.
Otherwise I have not much trouble running NT. I've learned to work around this by waiting a few seconds before attempting to access the cd but it sure is annoying to have to hard reset your workstation while all you wanted is access some files on a stupid cdr.
Making a webpage accessible for blind people is not a big effort in most cases. Because of this I think that companies like AOL should make their websites accessible to the blind. Just like you make buidings accessible to people in wheelchairs you should make websites accessible to the blind.
If AOL were a smart company they would not await a lawsuit but just make the minor investment to adapt their sites. Who knows, maybe a few blind people would become AOL members if they did so. If they don't, all that awaits them is bad publicity.
Forking is a symptom that Linux is reaching a stage where its own weight prevents it from moving further. Basically there are two thing that can happen: - a fork, from then there are two incompatible versions of linux that will grow further apart in the future since they are maintained by people with different interests - no fork, this means accepting that linux is unfeasible in certain domains
Probably a fork will happen. Why? because linux is not flexible enough to efficiently provide a solution for both domains (without forking). A few years ago the linux kernel was a big fat monolith with everything compiled into it. The situation has improved over the years but not enough. It's still a monolithical system. An even more modular system would perhaps have prevented a fork since the embedded version of linux could then choose to leave out a few modules or choose to provide custom implementations of a few modules.
What we really need is standardization. Standard APIs and custom implementations. If there's one thing you can learn from the Java platform it is that standard APIs are very convenient.
It's much easier to standardize APIs then component implementations. The reason for this is that there is never a single best implementation for all circumstances. With standard APIs forking of projects is no longer a problem as long as the API is preserved.
BTW. what exactly is meant by a component here. Corba? A C library?
Interesting idea. An enhancement would be to have applications present different views at different distances. Another idea would be to take a user on a tour along different windows to let him/her perform a task (also great for training since people are good at remembering routes).
Interesting idea that you can control a single molecule. But can it be done fast? is it expensive? If not it won't be any good for hardrives or internal memory. The article doesn't go into detail on these issues.
Will it beat holographic storage and other interesting techniques?
Interesting times are ahead of us. I could have said that anytime during the last 100 years or so and I hope I can keep saying it for quite some time.
Slashdot Mirror
Embedded machines are not the only domain for this chip. It's scalability should make it the ideal choice for a server with hundreds of thousands of threads. So it not a bad thing at all to produce something like this.
Also Java has been rather unsuccesfull on the desktop but is quite succesfull on the server and is also gaining momentum in the embedded machines world. JIT is not the same as interpreted (which you are suggesting). JIT stands for just in time compilation. Another thing sun is working on is dynamic compilation which JIT taking advantage of profiling information collected during execution. One major advantage of dynamic compilation over static compilation is that you can use information that is only available during runtime for optimizations. One of those optimizations could be discovering paralellism. And its exactly this type of optimizations that is beneficial on a MAJC architecture.
Also the ability to combine a MAJC core with a DSP on one die seems like a killer feature to me for embedded machines where every extra chip increases the price of the product.
You seem to be under the impression that its not going well with SUN at this moment. Truth is that SUN one of the more succesful companies of the last few years, especially in the server market.
SGI on the other hand has had quite some reorganizations over the past time.
Linux doesn't have to be a threat to companies like SUN. SUN gets its most revenue from hardware, not from software.
"Just about as likely as me going to my boss and suggesting building a system around a mutant CPU from this drowning company."
Probably your boss won't consult you for this. In case you haven't noticed, I responded to each argument in your post, if you think I forgot one or don't agree: do reply.
It shouldn't be too difficult for SUN to port the JVM since its code was designed to be ported to more than one platform.
They will probably won't deliver a 1.3 JDK since that jdk is still several months away from final release and they probably don't want to add another platform for it right now.
"major selling points for Be is the speed."
So it makes an excellent platform for running Java.
"It's slow, ugly, and a real hog of cpu and memory."
On the other hand, you can develop software really fast with it, its language is much more elegant than C/C++ and performance is good enough on the server side.
"Can't we move on? There are _hundreds_ of better alternatives."
Name them, I hope perl isn't on your list.
"On my mac, Swing simply doesn't look (even with their Mac PLAF) nor feel like a mac application."
The explanation for this is quite simple: the apple implementation of Java sucks.
"You cannot have a cross-platform GUI when you create the widgets in your code"
I'm a bit confused about this statement. I hope you don't mean that its impossible to recreate the same GUI on different platforms because that is exactly what swing does.
Later on you mention that it is impossible to entirely incorporate the look and feel of one platform without violating the look and feel on other platforms. You're right, so what? The goal of pluggable look and feel is not to copy into every detail the look and feel of a specific platform but to be able to customize the applications look and feel without touching the application. A nice application of this is to immitate the look and feel of different platforms to provide users with a familiar looking GUI. A more interesting advantage is that it enables application developers to give a unique look to their applications.
"cross platform" for Java programs simply means that a program works on every platform that implements the VM. Of course you can't make all platform specifics crossplatform (that's a contradiction). It's silly to claim that and nobody is doing that.
"NeXTstep and MacOS X Server provide an at least as powerful framework as Swing, but is much faster and doesn't have those inconsistencies."
Irrelevant because you need apple hardware to run it. Nice design but not crossplatform (in both our interpretations of this term).
whine, whine,
Sigh, once more: the only, repeat only area where java performance is less than desirable is in the GUI/graphics area. In other areas, ranging from palm top applications to servlets developers are quite happy.
The customers of your java applications probably won't care for your graphical applications. What they do care for is the speed with which you develop applications (about twice as fast as in similar OO languages).
well I still think you are the one doing something wrong. I mean, I have seen several swing apps and have programmed quite a few myself. I found that swing's powerfull features generally are an open invitation to use them which leads to sluggish performance if you don't know what you are doing.
I'm not claiming swing is well implemented at this moment. But if you know how to use it it is usable.
"One could say that that's what they did with AWT - they got the low level done and then the moved on to a more complicated, complete GUI framework. I would argue that they never got AWT right; instead they threw up their hands and said, "oh well", and then proceeded to build a huge monsterous framework on top of the weak foundation that they had built with AWT."
Ok, how would you solve the problem of designing a cross platform GUI framework? AWT wasn't really cross platform since it used native GUI components. Yet it did provide a nice abstraction from the graphical subsystem. What they did with swing is kick out the native components and provide cross platform replacements.
If you really dive into the framework, you must admire its design. Like you said it solves a lot of problems. And it does so in a rather elegant way.
Swing is a large complex framework that was developed in a short timespan (the final version is only a year old). The sun developers added a lot of functionality. What they will probably do the coming time is optimize the framework. I expect that JDK 1.3 will be mainly bugfixes and optimizations.
"Ibm make a wonderful compiler (jikes), and a pretty good jvm but i don't understand why sun doesn't do that job."
SUN can't do all at once. The past few years they have been working really hard designing APIs and implementing them. They don't have time to support every platform. IBM has a nice VM but so far they have failed to implement a good java 2 platform which is annoying.
Both SUN and IBM are working on linux versions of a java 2 vm so something should come out of that. Until that linux is probably not a suitable development platform for Java (unless you like waiting tools to become available that are already available on other platforms). I have full confidence that they will support linux eventually because Linux is becoming increasingly important as a server platform.
Gee, I don't know. I've developed several Swing applications (on computers much slower than your 200 Mhz machine) and I can't say I share your experiences. Sure there are certain things like the slow loading and high memory usage of applications that are annoying but generally you can create a decent application if you know what you are doing.
"depending on some data being entered my app"
Read the javaworld main article of this month. It deals with performance problems due to excessive object creation (which probably explains your problem).
netbeans (www.netbeans.com) is a swing app. Actually most java development is either serverside or stand alone client development. If you are doing serverside development you generally don't need a GUI and if you need one swing covers most of your needs. If you are doing client side development, AWT is not good enough because it doesn't provide much functionality and because it relies on native GUI components (leading to all sorts of incompatibilities between platforms). So for both types of applications swing is used often to provide the GUI.
Yes, swing is slow. Yes, it is complex (if you're a pearl/vb/fill in your favorite scripting language -hacker, it's probably too complex for you). But it is also a very well designed framework. For many developers the advantages of the good design outweigh the disadvantages of bad performance.
I heard some people complain it provided too much functionality and that SUN should have focussed on a less ambitious framework. I'm glad they didn't and decided that the design was important. It may take a bit longer for swing to become usable that way but at least it will be really usable when the performance problems are solved.
I get really tired of those folks who stopped reading in 1995 (that's the only excuse for not knowing that java is (successfully) used for other stuff than applets mostly).
True, swing is slow ate the moment. But it has been steadily improving. One of the main reasons for its perceived slowness is that it takes a long time to load the classes. Swing is a very complex framework and thus even simple swing programs load a lot of classes.
As an illustration. Back in the days when swing was still beta, you were better of running swing programs with the interpreter than than with the JIT. The simple reason for this was that a JIT compiler compiles all classes that are loaded, including those that are rarely executed. BTW. I was working on a pentium 133 with 64 Mb in those days. Even though the loading time was very high, the performance after loading was quite OK (again on a pentium 133).
What this anecdote proves is that it's not so much the raw peformance of the interpreter that is causing the bad performance but the dynamic class loading. JIT compilers generally only make dynamic class loading an even more expensive operation.
If I remember correctly it is exactly this problem (slow loading of swing classes) that is being targeted by jdk 1.3 beta. I'm really looking forward to improvements in this area.
If you are interested in how to make your Java programs faster, you should check out this article. It provides an excellent background on how Java manages its objects.
If there's one thing you can do with Swing it is building advanced tools to create GUIs (needless to say that such tools exist). Unlike MFC (which is the underlying architecture for VB), JFC has a very well designed architecture.
Because of this you can do really cool stuff like embedding GUI components in other GUI components. Try building a 'tree-table', that is a tree structure with tables as its nodes, in VB. It's almost trivial to do such things in swing. Needless to say that it is equally trivial to use whatever component you want for the table cells. The only problem I have with this particular example is that it is difficult to find useful applications for it (somebody help me out).
The swing tutorial is part of the Java tutorial and has been available from www.javasoft.com/tutorial for years now. During this period the tutorial was expanded to cover new API's. It's an excellent resource for Java programmers. Together with the API documentation it is all the documentation you will ever need. The only thing that puzzles me is why somebody would want to use a printed version of these documents. The online version is so much more convenient.
As the reviewer noted, you typically don't read the tutorial from cover to cover. What you do is find some topic you're interested in, read it. Then you click links to related topics, examples or the API documentation. The latter is very hard to do in a paper version.
I think linux is the OS that needs to prove itself now.
that implies that there is an accused and defending party. This is a simple statement "linux has more marketshare on the desktop then NT". I find it a little hard to believe just like that.
Lynx is no alternative for IE. Its only useful if your blind in which case you would want to put a braille machine on it or an enormous nerd with very thick glasses and skull. In all other cases people also want to view the graphical information. Netscape 4 is now at least two years old and we haven't seen it progressing. Netscape 5 is a promissing product but it will take several months to become final. When it will become final it is an unproven but still promising product. In other words it will take at least half a year for mozilla to catch on. That's a lot of time for a browser.
Can you back that claim up please. I find it a little hard to believe that linux outnumbers NT on the desktop.
can you say NT workstation?
Open cd, insert freshly burnt cd, don't wait for the cdrom to spinup but access the cd straight away with explorer. Enjoy the view (BSOD). Works consistently on my dell optiplex gx1 and nt workstation 4.0, service pack 5.
Otherwise I have not much trouble running NT. I've learned to work around this by waiting a few seconds before attempting to access the cd but it sure is annoying to have to hard reset your workstation while all you wanted is access some files on a stupid cdr.
that says more about you then the browser you are using.
Making a webpage accessible for blind people is not a big effort in most cases. Because of this I think that companies like AOL should make their websites accessible to the blind. Just like you make buidings accessible to people in wheelchairs you should make websites accessible to the blind.
If AOL were a smart company they would not await a lawsuit but just make the minor investment to adapt their sites. Who knows, maybe a few blind people would become AOL members if they did so. If they don't, all that awaits them is bad publicity.
Forking is a symptom that Linux is reaching a stage where its own weight prevents it from moving further. Basically there are two thing that can happen:
- a fork, from then there are two incompatible versions of linux that will grow further apart in the future since they are maintained by people with different interests
- no fork, this means accepting that linux is unfeasible in certain domains
Probably a fork will happen. Why? because linux is not flexible enough to efficiently provide a solution for both domains (without forking). A few years ago the linux kernel was a big fat monolith with everything compiled into it. The situation has improved over the years but not enough. It's still a monolithical system. An even more modular system would perhaps have prevented a fork since the embedded version of linux could then choose to leave out a few modules or choose to provide custom implementations of a few modules.
What we really need is standardization. Standard APIs and custom implementations. If there's one thing you can learn from the Java platform it is that standard APIs are very convenient.
It's much easier to standardize APIs then component implementations. The reason for this is that there is never a single best implementation for all circumstances. With standard APIs forking of projects is no longer a problem as long as the API is preserved.
BTW. what exactly is meant by a component here. Corba? A C library?
Interesting idea. An enhancement would be to have applications present different views at different distances. Another idea would be to take a user on a tour along different windows to let him/her perform a task (also great for training since people are good at remembering routes).
It just won't be cool anymore by then.
Interesting idea that you can control a single molecule. But can it be done fast? is it expensive? If not it won't be any good for hardrives or internal memory. The article doesn't go into detail on these issues.
Will it beat holographic storage and other interesting techniques?
Interesting times are ahead of us. I could have said that anytime during the last 100 years or so and I hope I can keep saying it for quite some time.