Slashdot Mirror

Well, unfortunately, Java was removed from Windows. So people can't use this with an out-of-the-box Windows installation. They have to manually go and download and install the Sun JVM. Not something the average home user knows how to do.

Thus it still seems that to reach the largest market, providing streaming video in WMV and QuickTime (and possibly Real) formats would be the best solution.

This would have been a great development five years ago, though.

The Network is the Computer (R)

http://www.sun.com/

the more I use swing the more I appreciate its flexibility:
don't like hourglasses? want a wait control that superposes a transparent laptimer over the whole frame? no problem.
Don't like the default tooltips? want to roll your own that jump out like little thought bubbles? easily done.
Want to splice together a tree and a table to create a new hybrid? try
If you can imagine it, you can implement it; and that, to me, is the appeal of programming.

Moreover. Im running Java 5.0 RC and the client VM has this nice feature called Class Data Sharing and I can see how much faster the startup times are. I'd say 2 to 3 times faster.

When will we see fully improved network/remote access?

"Fully improved"? Please explain what you want in English. You appear to be using English words, but when you put them together, they make no sense.

When will we see some innovation instead of eye candy? Why does something have to be invented on OSX or Windows instead of pioneered on linux?

Since when do Microsoft invent stuff?

Why not work on something to compete against microsofts new gui/api interffaces based upon 3d rendering instead of pixel rendering?

Project Looking Glass. And, to answer your question "why not", because input and output is still 2D, so a 3D GUI is much more awkward to use than current GUIs.

We're looking into it: 5072831

don't tell http://www.sun.com/Sun (sun.com) that :-)

• J2SE 5 New Features
• JDK 5.0 Release Notes (warning: not updated for the release candidate)

• J2SE 5 New Features
• JDK 5.0 Release Notes (warning: not updated for the release candidate)

return list.toArray(new Foo[list.size()]);

return list.toArray();

for a '99 Sunfire GT in 99

Sun makes cars, too !?

[Yes, I know. It wouldn't be /. without rampant assumptions being made.]

Sun had optical mice in 1993.

The only Microsoft 3d desktop demonstration I can recall seeing was some obscure handycam video of some guy moving 2d windows around inside a WindowsXP mod called SphereXP. Not to bash the guy's efforts but by comparison it looked hacked together and confusing (especially for "Aunt Tillie"). I'm looking at research.microsoft.com right now and the video of Microsoft guys talking about a 3d desktop... Then they show their implementation of one. It. Is. A. Mess. It is beyond description. You really have to see it for yourself. Nobody would want this. If you thought people's Windows desktops now were cluttered, organizational trainwrecks, you should see this thing. It would make Aunt Tillie's head spin--if it didn't give her motion sickness first.

I'm inclined to agree with you that Microsoft may already have lost its position of leadership. Listening to the guys in the research.microsoft.com video, it sounds like MSFT is mostly populated by PHB's now.

Yes, I would pay for a free software subscription. I even occasionally click on google ads while searching to buy a particular item. But it would be a long time before I spend $299 that I might pay for a complex app that really meets my needs. Yes you can make money from side business if software itself is free, but probably not enough to cover writting software in the first place. Perhaps enough to cover distribution and minor bug fixes.

Of course support can be expensive, but that's only for corporate customers, and even then many free apps can be "supported" by googling for info. What kind of questions about Firefox are worth $100 a pop?

Let's just accept that most free software is written as a hobby, as an academic project or for personal use. Linus didn't set out to make great riches, and as far as I know he didn't. If you are trying to make money off either free or pay software that other people are willing to write and maintain as a hobby, well you should have known better.

Dude, saying "Java isn't slow" doesn't make it run any faster on the 5 different machines I have.

Well, personally I think I made more than one argument as to why I think that Java being slow is a myth. I even provided links to benchmarks and articles analysing the performance of Java.

It seems to me that you're simply biased against Java. I dunno if you really have 5 different machines running applications of poor performance, but mind you, it is possible to write slow code in just about any language - even Java!

If I got it wrong, and you're really sad about the performance of your Java applications, maybe you want to take a look as these Java performance FAQs in order to try and improve the performance of these applications.

/Spam .

If you take a look at what Sun is currently charging for the Java Desktop, it just doesn't make financial sense at the current price point. I for one don't expect to see companies switching to a subscription model that charges $100 per system per year (granted the current pricing until December 2, 2004 is $50). To be competitive and offer the business community a truly compelling reason to switch to the Java Desktop, the price is going to need to come down just a bit more.
What might be a motivating factor for a company to purchase a product using the subscription model, support perhaps? Well they do give you 60 days of support but the remaining 305 days of the year support will cost extra.

Sure you can
Oh you want one for the AMD64?
How about these?

If the OS has the concept of a superuser, then you're correct. However, that's ignoring other OSes that are built on capabilities or mandatory access controls. Those do away with "root users" altogether, and replace them with users with sufficient access to grant necessary rights to other users. These aren't hypothetical creations, but real systems in use, today, in high-security installations.

Thank you for commenting!

I agree with much of what you wrote, I realise that I in fact did overplay the significance of JIT having runtime knowledge. I wanted to stress the fact that Java isn't simply an interpreted language, not even when you use the JVM from Sun.

The most important point of my post, though, is that "Java isn't slow" anymore. When I first got to know Java, it was dreadful slow. Now, its comparable to C++, and in some cases even faster, and has the potential to be even faster. Now, all this fuss about performance has really nothing to do with the Java-language, but has to do with the Java-platform, its not unrealistic to write a compiler for C that generates Java-bytecode for the Java-platform, but the point is that the Java-platform today proves that it does in fact work, that it doesn't slow performance, as seen in early stages. It has its strengths and weaknesses. One point I must make though, is that in my opinion, JIT is not the single key that Java has reached the performance of C++. Of course, JIT _does_ help a lot, esp. in CPU intensive code, but there are other factors as well. One really important point, is that Java Bytecode applications can allocate memory very cheap, as explained in my previous post.

That being said, lets discuss JIT a little...

Now, C compilers have 20+ years of experience with things like loop unrolling, eliminating common subexpressions, yada yada. C++ compilers have a somewhat harder job because the language is more complicated, but are rapidly catching up. Java's been way behind the pace for years, and JIT allows it to level the playing field somewhat, since it's finally running as a compiled rather than an interpreted language.

(Just for the record):

Its naive to assume that the cost of JIT is free, but its also naive to assume that Java compilers would not benefit from the last 20 years of experience on C compilers. The Java compiler from SUN is able to optimise the bytecode as well AOT as well as optimise the bytecode with JIT.

Your analysis on when JIT is beneficial, is very good, I do have a few notes though:

Now, if you're talking about an application that runs the same few subroutines thousands of times on similar data, it might be worth the overhead, but for most code, that simply isn't the case.

I don't think that this pose a real problem. The point is that "Most code", doesn't need much CPU, and thus the overhead of the JIT profiling, won't matter much, whereas the bonus from JIT-compiling critical code in CPU-intensive code will be a great gain for the JVM.

In C, when you write CPU-intensive code, you usually hint the compiler about optimising, in one way or another, since you know which code you want to be optimised. You may "inline" some code, ask to get an index variable kept in a register, and compile with flags / options like "-funroll-all-loops", "-funsafe-math-optimizations" and others. Usually, these hints will make the compiler able to make as good decisions as any JIT would be able to.

On the other hand, if you write CPU-intensive code, without paying attention to micro-optimising, chances are that the JIT-enabled code will run slightly faster (given the same algorithm, of course). With todays speed of CPU's, Code that is not CPU-intensive, will often seem to run at equal speed, from the users perspective, whether its interpreted or (JIT)compiled. (Even though they might actually be faster in the AOT code).

Here is an example where the JIT compiler seems to slow down the code, and how to mend that. Note that this type of code is very rarely seen in actual real life programs.

If we talk about really micro optimising code, I guess you would want to either write the code in assembler, or be really creative about how you optimise your code. As I mentioned in my first post on this subject, Java can also be compiled with AOT compiles! Another possibility, if you know that C is faster (or already have the optimised code in C source), is to use JNI (Java Native Interface), that lets you call native code. Note that this will of course invalidate any claim as to be "Pure Java" code.

The X developers should rewrite the server from scratch using the Aspect Oriented methodology and for example the AspectJ programming language. Many of the X extensions really touch all parts of the server which is exactly the kind of problem aspect oriented programming was designed to solve.

Using AspectJ, an extension such as the Damage extension could be written in a weekend.

Also rewriting the server in AspectJ would allow the developers to leverage the full power of the Java language. With Java reflection the core dispatch code in the server could be replaced by just a few lines of code. The RENDER extension could be completely removed from the server and replaced by using the delegate design pattern to forward X requests to Java2D

The Fresco project had huge potential, but never managed to escape the legacy language C++. It seems everybody working on window system is stuck in the software engineering practices of the seventies.

What's your favorite help sites?

Computer Hope's Unix
Tech-recipes's Unix
Tek-tips forums
Sun's BigAdmin

Help me add to my favorites...

Davak

"don't hold on to the reference" is equivalent to saying "free it." [...] anywho, these hash tables are kept around forever, so all objects need to be "freed" from the hash table. this isn't such an uncommon occurrence, so saying "don't hold on to it" is silly.

As far as distributing your apps, you can use a self-contained jar file that has everything it needs and execute that. I have ran plenty of Java apps that were just a single jar with all needed class libraries and the manifest file.

One of the reasons that some consider Java uncool, is because of the myth that Java is slow. I call it a myth, and I will try to explain why it is a myth. (Actually, in theory, Java will outperform C++ soon).

Just to take a swing at another myth, while we're at it: When it comes to size of the stack, how you want the garbage collector to use memory etc., you CAN in fact give the JVM parameters to control this stuff.

Java isn't slow anymore. It may be true, that (small) Java applications generally takes a little longer to start up, if you didn't use an AOT compiler (like for instance the "free as in freedom" compiler GCJ or the more mature but proprietary Excelsior JET). Its true that early versions of Java were slow, but 1.4.x isn't generally slower than C++, in fact, I wouldn't be surprised if it outperformed C++ on general terms one of these days.

One of the things that makes Java "not slow", is actually the way memory is allocated. Its rather cheap to allocate memory in Java, compared to other languages, and its even cheaper to "free" memory, since you don't do it, you have the cost of the garbage collector instead. The garbage collector in Java is very fast, compared to older garbage collectors.

(For the interested, IBM has an article on "garbage collection in the HotSpot JVM", and another article that explains various garbage collection techniques, and finally they have an article that covers performance concerning garbage collection. They have a lot of other interesting articles, but I don't want to list all I know, if you like to check it out, here is the search I used to "refind" these articles.)

I make the claim that Java isn't slow, but don't just take my worth for it. (Not that I think you would). Go search on google or whatever. A word of warning though .. since older Java's were indeed slow, do note the version of the Java tested. It should be (at least) 1.4.x. I don't think 1.5.x is stable yet and I dunno if its faster or slower, but 1.4.x have a real nice enhanced garbage collecting subsystem. (Esp. 1.4.2 and above).

(On purpose, I didn't go for SUN benchmarks, as they might be (considered) biased, but sun does have a word to say about "Java Performance".)

Here is a couple of quotes from an article that considers performance of Java vs. C++, analysing some benchmarks of Java, C++ and other languages. While the article was updated this year, I was still unable to find a link to a benchmark diagram of the current 1.4.x JVM. It seems though, that the 1.3.x wasn't too slow, even without latest optimised GC-subsystem, which is one of the key factors that makes 1.4.2 faster.

Here are the quotes:

"Five composite benchmarks listed below show that modern Java has acceptable performance, being nearly equal to (and in many cases faster than) C/C++ across a number of benchmarks."

"Java is now nearly equal to (or faster than) C++ on low-level and numeric benchmarks. This should not be surprising: Java is a compiled language (albeit JIT compiled)."

And C/C++ doesn't? What language has only one GUI API??

Most languages have multiple GUI API's, but that isn't necessarily a strength. Java was aiming for true write once, run anywhere. But by coming out with multiple GUI API's, Sun has only managed to further fragment it's own platform.

Okay, so it might be a little hard to just start a project from scratch and design all these models and such, but start off by extending or implementing one of the many models Java provides.

After you test and fully develop your models, you can drop them into Swing components (view), use one-liner anonymous subclasses to tie GUI events to model method calls (controller) and then profit! Then when you get bored, mix it up by reusing your models by putting them to work with JSPs (view) and Servlets (controller). If you have a good design, you won't need to touch a line of model code. I just finished a project that had both a web and Swing interface, but share the exact same model code -- any feature I add to a model can be reflected in the view by tieing a button or hyperlink to the model method.

Have fun!

Okay, so it might be a little hard to just start a project from scratch and design all these models and such, but start off by extending or implementing one of the many models Java provides.

After you test and fully develop your models, you can drop them into Swing components (view), use one-liner anonymous subclasses to tie GUI events to model method calls (controller) and then profit! Then when you get bored, mix it up by reusing your models by putting them to work with JSPs (view) and Servlets (controller). If you have a good design, you won't need to touch a line of model code. I just finished a project that had both a web and Swing interface, but share the exact same model code -- any feature I add to a model can be reflected in the view by tieing a button or hyperlink to the model method.

Have fun!

Okay, so it might be a little hard to just start a project from scratch and design all these models and such, but start off by extending or implementing one of the many models Java provides.

After you test and fully develop your models, you can drop them into Swing components (view), use one-liner anonymous subclasses to tie GUI events to model method calls (controller) and then profit! Then when you get bored, mix it up by reusing your models by putting them to work with JSPs (view) and Servlets (controller). If you have a good design, you won't need to touch a line of model code. I just finished a project that had both a web and Swing interface, but share the exact same model code -- any feature I add to a model can be reflected in the view by tieing a button or hyperlink to the model method.

Have fun!

Okay, so it might be a little hard to just start a project from scratch and design all these models and such, but start off by extending or implementing one of the many models Java provides.

After you test and fully develop your models, you can drop them into Swing components (view), use one-liner anonymous subclasses to tie GUI events to model method calls (controller) and then profit! Then when you get bored, mix it up by reusing your models by putting them to work with JSPs (view) and Servlets (controller). If you have a good design, you won't need to touch a line of model code. I just finished a project that had both a web and Swing interface, but share the exact same model code -- any feature I add to a model can be reflected in the view by tieing a button or hyperlink to the model method.

Have fun!

Okay, so it might be a little hard to just start a project from scratch and design all these models and such, but start off by extending or implementing one of the many models Java provides.

After you test and fully develop your models, you can drop them into Swing components (view), use one-liner anonymous subclasses to tie GUI events to model method calls (controller) and then profit! Then when you get bored, mix it up by reusing your models by putting them to work with JSPs (view) and Servlets (controller). If you have a good design, you won't need to touch a line of model code. I just finished a project that had both a web and Swing interface, but share the exact same model code -- any feature I add to a model can be reflected in the view by tieing a button or hyperlink to the model method.

Have fun!

Depending on your definition of 'open source' then Java is or is not open source. If your definition of open source is that of the source being available, then the source for the J2SE (Java 2 Platform, Standard Edition) source code is available under the Sun Community Source License.

Depending on your definition of 'open source' then Java is or is not open source. If your definition of open source is that of the source being available, then the source for the J2SE (Java 2 Platform, Standard Edition) source code is available under the Sun Community Source License.

Here I am with some code written in Java, and I want to call it from Tcl. Write a quick C wrapper, link the .o in, and package require... no...? How do I do that, then?
The first google hit - http://www.javaworld.com/javaworld/jw-05-2001/jw-0 511-legacy.html

Here I am with a library written in C, or Fortran, and I want to call it from Java... well, how badly do I want it?
http://java.sun.com/docs/books/tutorial/native1.1/ It is really easy.

You cannot force garbage collection. From the API:

Calling the gc method suggests that the Java Virtual Machine expend effort toward recycling unused objects in order to make the memory they currently occupy available for quick reuse.

[Emphasis added.]

I don't think there is an equivalent with Java... but there should be.

I don't think there is an equivalent with Java... but there should be.

http://java.sun.com/j2se/1.4.2/docs/api/java/lang/ System.html#gc()

That was a deliberate decision in order to avoid the monster mistake Bjarne made with C++ templates.

Java 1.5 introduces generics: the ability to define type-able collections and does them in a much, much more elegant way than C++'s abomination.

That was a deliberate decision in order to avoid the monster mistake Bjarne made with C++ templates.

Java 1.5 introduces generics: the ability to define type-able collections and does them in a much, much more elegant way than C++'s abomination.

Not to pick nits, but a class with only public data members is essentially a struct, and J2SE 1.5 will have enums.

Linus doesn't seem to publish much like this annually, but the other ones are easy:

Microsoft Annual Report
Apple Annual Report (2003 doesn't seem to be available yet)
Sun annual report

FYI - they typically come out in the spring for the previous years. The SEC "encourages" that.

I think this is what it will boil down to:
Rehat vs. IBM + Novell/Suse + Sun

1) Sun's JavaDesktop is based on Suse Linux, and provides a very good mechanism for updates, for just one time cost of $50 (includes Star Office).
2) Sun and Novell(parent company of Suse) are the 2 top contributors to Star Office / Open Office.
3) IBM and Suse have been working with each other for a while. Especially in the Lotus Notes area.
4) Novell's new directory services can be used on Suse Linux.
5) Suse can be a cluster resource in the Novell Clustered environment.

Where does RedHat fit in this picture????

specially if it is as sexy as his last window toolkit

...if it's anything like his language design, I'll pass.

No such thing as a free lunch, baby.

If all software was free, why would anyone bother developing it?

Gee, I can't think of anyone who would develop software without getting paid for it...

But seriously, there are several reasons people would write software whose price is 0:

• People want better software to do $WHATEVER (for values of $WHATEVER that make money, which is most of them), so they write it
• People want to get a job as a programmer so they write a software package to prove they aren't total code monkeys
• People like fame; they like being admired and appreciated
• An industry consortium decides they need an open, standard, free way to do $WHATEVER
• Some people have a political motivation to undermine proprietary software (we may not have that same motivation; but it is a real driving force for some people)
• Some people like to help others (ditto)
• Your company might want to make your product universally (or nearly so) used in order to be able to charge money for training, certification, etc.
• I mentioned 15 high-profile products that are competitive with best-of-breed and are available for $0 (and not all of it is Free as in speech). All of them were written because one of the above bullet points (or one I forgot) applied.

There are lots of motivations for people's actions besides money.

I'm sure the commons-collection is a nice implementation, but for those who haven't heard, Java 1.5 (currently in beta) contains most of the features you've named. Some are simply new classes in the collections framework, others are language extensions (i.e. generics for type-safe collections).

Also, some of the features you named are already in java 1.4, such as identity maps, reference maps that allow garbage collection, adapters for converting collections to/from enumerations and arrays.

I'm sure the commons-collection is a nice implementation, but for those who haven't heard, Java 1.5 (currently in beta) contains most of the features you've named. Some are simply new classes in the collections framework, others are language extensions (i.e. generics for type-safe collections).

Also, some of the features you named are already in java 1.4, such as identity maps, reference maps that allow garbage collection, adapters for converting collections to/from enumerations and arrays.

I'm sure the commons-collection is a nice implementation, but for those who haven't heard, Java 1.5 (currently in beta) contains most of the features you've named. Some are simply new classes in the collections framework, others are language extensions (i.e. generics for type-safe collections).

Also, some of the features you named are already in java 1.4, such as identity maps, reference maps that allow garbage collection, adapters for converting collections to/from enumerations and arrays.