Skip to main content

What do you think of the proposed Java Kernel project?

It's very important
37% (316 votes)
It's somewhat important
13% (111 votes)
It's not very important
5% (40 votes)
It's not at all important
3% (29 votes)
Java Ker-what?
43% (367 votes)
Total votes: 863


reduce the size some other way

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.

reduce the size some other way

So you'd have something that's both signed and unsigned... That's not supported, and would lead to major security problems. People replacing some Sun classes with their own for example that have a nasty payload would be an immediate possibility. Anything that's not part of the JVM installation is part of the applet, therefore not only would the now-non-core classes be part of your applet and not the JVM, they'd be part of each applet separately and thus require downloading every time an applet is run. That's no different from loading optional packages today, those too are loaded individually for each applet. And of course it means as I said they can only be loaded from the site hosting the applet. Don't trust Sun? Most people don't know who Sun are, they just run applets without ever installing anything, they get a JVM preinstalled on their PCs. If they'd get a message from their firewall when visiting telling that an activeX control is trying to contact (which would be a result of your system where the removed classes are hosted by Sun) they'll click "deny" (or more likely it will be automatically denied as a possible trojan attack) and than face a failing applet.

Why preinstall just the kernel?

Surely any preinstalled JVM would be the complete Java SE. The kernel would only apply to new installations or updates where the difference from an existing installation is not small.

reduce the size some other way

WebStart already supports a mix of signed and unsigned components. An unsigned WebStart application can already use components which are signed. It works just fine. WebStart already caches these components. There is a check for a newer version, but if the version is still current it uses the cached code (if still present). Perhaps we should allow the user more control over the version checking in the case of applications which allow offline use.

That is key feature to promote desktop usage

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

Perhaps it would be better to add features, not remove them

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.

Perhaps it would be better to add features, not remove them

Yes I accepted you.. To compete java people with flash, need to be rich API that make things made easier to develop rich internet applications...
I have one solution to make java faster:::

Java Installer internal engine!

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.

Java Installer internal engine!

why the heck would a database server profit from an on the fly downloaded modular JVM? It's installed once and will be a lot larger than that JVM anyway (for real database servers, not small embedded ones which will thanks to the Sun marketing department ship with the JVM anyway). Same for application servers.

Internal engines of installers? Adding 3MB for a core JVM and having it connect to the internet to download the rest as needed when installing a non-Java application seems rather silly. Much rather write the installer in some other language. And if you're installing a JVM anyway you don't want to have an internal JVM to the installer and have to download everything twice.

People on pay per second dialup don't want an application that needs permanent internet connectivity just because it might need a class it doesn't have and wants to download it from somewhere. They want it all installed once and disconnect, preferably installed from a CD or floppy (in which case a 3MB total JVM installer would be too large as it doesn't fit on a floppy, not even an IBM 2.88MB floppy).

We need small JRE for alot of things.

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 ?

Delivery is the key

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)

Delivery is the key

Looking at actual beginner users I found that they much easily installed an exe then an ActiveX. Currently Sun uses an ActiveX control by default, unfortunately 7 out of 7 users were not able to install Java on their machines using IE, they didn't even notice the bar IE displayed to request permission for installing an ActiveX control (i.e. Java JRE). On the other hand they are used to install exe-s regularly.

Java Kernel will rule the known universe...

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

reduce the size some other way

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.).

reduce the size some other way

Removing deprecated functionality is great, but that's not going to buy us the small size that we need to compete with Flash. Java needs to be SMALL for the impatient web page visitor. The full JSE download will always exist (15 - 20MB), but you'll have a much smaller Java Kernel as an active X plugin or stand alone installer (~3MB) for the sake of applets. -Bryan

Can I get a link... some Java Kernel information? Cheers, Chris