Sun said Tuesday it had struck distribution deals with Acer, Gateway, Samsung, Toshiba, and Tsinghua Tongfang; the five firms will bundle Java on their desktops and laptops. In June, Sun made similar arrangements with Dell and HP. With this deal, Sun now claims that over half of desktops sold will contain a JRE.

Read Sun's press release.

Now, if only they had done this 5 years ago.

Great. Now maybe Sun will finally be convinced that suing Microsoft for $1 billion over its refusal to bundle a JRE that few experts like anyway is a waste of time.

Innovation by Monopoly is bad, but so is Innovation by Litigation (which is unfortunately starting to become the hot new IT trend :-)

Now over half of all new PC owners will be able to open a command shell, type 'java', hit enter and see what all the fuss is about.

Whee!

Now lets just hope the PC manufacturers put it in the path.

That was funny.

Putting java in the path would be a novel idea.

I never thought Tsinghua Tongfang would bite. What a huge win for Sun!!

These sort of press releases always surprise me to some extent. I have never had a problem downloading and installing the JVM, was this really such a big problem?

The catch is that even though you can download and install a JRE, few non-techies can. With the JRE already installed, you don't need to bundle a JRE with your application or teach the user to download one from java.sun.com.

I am aware of both of those "issues" but niether of them seems like such a big deal. If you can't install the JRE then chances are you can't install any software at all, so why do you need a JRE? If you need help to install the JRE you need help to install the software that uses the JRE, so we are back where we started and must ask whether this matters at all? When there is a new version of the JRE do you go out and buy a new PC?

I am sure there is a lot of people who still use Win95 because they do not know how to upgrade. On the other side, there are a lot of people who prefer to buy the whole new system each 2-3 years just to make hardware a software upgrade with no hassle.

No, not at all. The problem is that non-techies understand what their software is, but don't uinderstand what Java is or why they have to install it separately. They shouldn't have to know this either. By having Java pre-installed, Java becomes a service of the machine that is expected to be there. The user never has to worry about it.

This is very important when it comes to Java Applets and browser applications. A user should be able to browse to a Web page with an Applet on it, and get a great experience. It is great for the developers and the users. Also, since the version being shipped will be at least 1.3 or 1.4, the developers can take advantage of the latest featuress in Java.

I couldn't agree more. It's not the bundling of a JRE that is the reason of low java usage on the desktop. The reasons are purely 'technical', give us a faster swing and faster start up times and people will go there.

Comparison:

Pros
- Platform independent (there are some issues but generally this is ~99%)
- Decent language with GC support
- Tools, tools and tools (Java's greatest strength IMHO)
- Good performance on server apps, one must be a lousy coder if it's not the
  IO that is the bottleneck.

Cons
- Uses 25...100% more memory than no VM languages (C, C++, Pascal, etc..)
  (not necessarily so in 'server' apps, but in desktop this really is the case)
- Swing apps start up time is slow
- No VM sharing between applications, so running many Java apps -> BMM
  (Buy More Memory syndrome). Presumably not an issue in OS X though.
- No collection classes for primitive data types. Sheesh. I have to work with
  huge amounts of data so I have to find alternatives. Luckily there are
  (fastutil) but without templating support the package is huge!
- GC (this is a double edged sword)
- No preinstalled JRE..

Now - does that last 'con' part seem so important?!

Better late than never. It'll be nice to get a new machine and have webstart applications just work quickly w/o having to wait for a JVM to download the 1st time.

Cool!

Rob
http://www.robsite.org

First thing I do to desktop that comes with windoze XP from vendors
is reformat the drive and install Redhat 9.0 then download JDK from
java.net site and walla I ready.

If that was all you had to do to have a working Linux installation no one would use Windows. Unfortunately that is not the case... :)

Redhat 9 installing is pretty easy infact it is easier than windows XP
and more robust, secure. Linux beats windows and we all know that

"Washington, DC - Some of the nation’s leading computer science and network security experts today issued a report warning that the computers and critical technological infrastructure worldwide are increasingly vulnerable to attack because of the security practices and dominance of Microsoft software in desktop computing. As a result of Microsoft’s concerted effort to fortify and expand its monopolies by tightly integrating applications with its operating system, and its success in achieving near ubiquity in personal computing, our computer networks are now susceptible to massive, cascading failures."

http://www.ccianet.org/
http://www.ccianet.org/papers/cyberinsecurity.pdf

be careful now...TSS does not like this kind of irresponsible messages that make MS look bad

>

TX-REQUIRED is used in the exact same context as the 'transient' keyword. transient deals with serializations, tx-required deals with transactionality. Developers write serializable objects because they know the object will be serialized. They will do the same with transactionality.

The same analogy can be applied to synchronized. Think of Hashtable and HashMap. One can be concurrently accessed because it uses synchronized methods, the other cannot. You could apply the same pattern to transactionality. This class is transactional and cannot be access outside of a transaction. See what I'm getting at here? Where synchronized/transient are either on or off, transactions have different degrees of on/off.

So, I'm saying I don't agree that it is a bad idea for your code to have knowledge that it's being used as a part of a wider AOP system. I think it is situational. Some code needs to know exactly what is happening in order to be maintainable and readable. Other code needs the flexibility of not being tagged as it may be used in a variety of situations. TX-REQUIRED can fall into both catagories.

This brings me to my long standing point that metatags should be able to be applied to a class both explicitly in the code and implicitly via some other mechanism. Just as AOP can provide poitncuts to apply advices to a given Java class, it should also be able to do the same with metadata. Separation of concerns should not solely apply to functionality. It should be allowed for metadata as well.

This brings me back to some of my problems with JSR-175. It defines no way of applying metadata implicitly, nor does it allow for dynamic insertion of metadata at runtime so that a proprietary framework could take over this function. Instead we are forced to preprocess a Java file, bytecode manipulate pre-runtime, or at runtime when a class is loaded.


> This sort of approach can sharply limit reusability, and in the end looks an awful lot like EJBs with fewer configuration files.

The key word is "can" here. It can limit reusability.

It looks alot like EJB config via XDoclet, the key difference being that EJB is a finite set.

>What I'd call "real" AOP can operate on business domain objects directly, without their knowledge (if desired, it's not an absolute), and the same domain objects can be altered differently in different environments by varying AOP aspect code.
>
> It sounds rather silly to some, but if you try a meta-tag approach for awhile it feels amazingly like EJBs sans deployment XML files, and you find that to achieve reusabilty you have to do the same sorts of tricks here as you do in EJB, with various facade and proxy objects artificially introduced.
>
> -Mike

Allthough reusablity is a usual end goal for for frameworks and libraries, it does not hold true for most end-user applications where maintainability and readability are more desirable.

Great news for all Java lovers. go Sun !