Storing the downloaded extra classes doesn't break the applet sandbox model because these classes (and supporting binaries where necessary) will be signed (by Sun). If the user didn't trust Sun they wouldn't download or permit installation of the kernel in the first place. In any case the existing JVM (and browser) will cache unsigned applets and thus avoid repeated downloads.

As MS did not boundle Java with windows, it is the most important features for Java to take control of user's desktop.

If Java is to compete with Flash, then perhaps it would be better to add features to Java, so that these simple animations/games/whatever would be easier to implement. Perhaps create Flash-compatible toolkit even. And make Java loading (starting) faster, if possible. And make sure that Java is pre-installed with every Windows/Linux, so that there is no download problem.

Good for :- 1 ) Installer internal engine 2 ) db server 3 ) application server 4 ) Remote side installation 5 ) For those countries with less or equal 1MB internet line area.

Small size are good as an installer internal engine, java database server, java application server, remote side installation. Please, not all contries got 1MB internet line! Look at this world, how many countries are consider developed countries ? How many ?

A lot of emphasis has been put on size. In my opinion the size is not all that important, delivery is the key. The trick is going to be to have the install as smooth and seamless as the Flash Player (ActiveX, XPI, etc). If applets are going to have any chance of survival, the "Java Kernel" needs to have a slick method of installing (i.e. NO downloading an exe and then installing)

Was that over the top? Never! The "Java Kernel" will own, and here's why: 1) The initial download of Java will be small. All other points are predicated on this. 2) Your custom Java application can be bundled with a 3MB JVM plus all the classes that YOUR application needs (and nothing more), yet the user isn't stuck with a non JSE complaint JRE. The JRE will download all the missing stuff on demand for other Java applications that may require more of the standard rt.jar classes. 3) Versioning and updates will be much faster/easier. If some new JCP API comes online, then Sun can throw it out there. If your uses don't need that API then they'll never have to download those classes. But if they use an app that does need those API (or a newer version of the API), it will be downloaded without any fuss. 4) The name "Java Kernel" sounds cool. 5) Did I mention that you could bundle your app without the ubber dependency that is the full JSE download and install? 6) People will actually write applets and the web will be rescued from the tragedy that is AJAX. Don't get me wrong. AJAX is swell, but it's an inferior, poor man's attempt at getting the features of an applet. Appet use would be HUGE if everyone had the JSE pre-installed (many do) AND if you don't, the download is 3MB and a double-click away. Make the download easy and the install require nothing more than a double-click, and you'll have an applet revolution. 7) The Java Kernel will work well with the future open source model that Java will take. I have no doubt that Sun will continue to institute a high quality process and Java's development model will be consistent and high quality. BUT, when the open source faucet gets warmed up, we're going to see a lot of new feature and classes coming down the pike. That's great news. But all these new classes and features will just continue to bloat the JRE... Well, actually it WON'T. Not with the Java Kernel model that is. You will only download the classes and features that you actually use. Do you only ever do server side stuff? Great! You'll never download Swing. Desktop only? Great! You'll never download CORBA (we'll nobody will ever download this), or naming, or ServerSocket or a million other things. Get it? This is cool stuff. 8) I like it. And everything that *I* like rules. 9) We will have something like CPAN, but EVEN BETTER. That way, we can scoff our perl friends to scorn. We have a faster runtime, better development tools, bigger salaries, AND now we'll have a better feature download model. I wonder if this might even make some of my perl friends cry? That would rule. -Bryan

by getting rid of the tons of deprecated functionality, the webservers and database servers stupidly put in in 6.0, and things like that.Having the JVM installer install nothing more than a download manager which downloads the rest at runtime will only make more people complain that Java is slow and cause masses of complaints about Java being spyware (after all, it's constantly connecting to the internet when it's running...) and of course that "Java doesn't work" when the download servers are unreachable (overload, network trouble, etc.).

...to some Java Kernel information? Cheers, Chris