Showing messages 1 through 19 of 19.

• That is key feature to promote desktop usage
  2007-05-09 06:56:27 gniliak [Reply | View]
  
  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
  2006-09-14 07:47:56 fuerte [Reply | View]
  
  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
  2007-07-17 02:01:17 vr9_desu [Reply | View]
  
  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...
  <br/>
  
  I have one solution to make java faster:::
• Perhaps it would be better to add features, not remove them
  2007-07-17 01:56:17 vr9_desu [Reply | View]
  
  Is it possible to have a jam(which is new format for jar) that support the stream based java class loading.
  For this I give an example If I have an Applet(1.class) in package(app) deal with 2 classes(2.class, 3.class) in package (app2)
  Then JVM should first be able to load the 1.class from the jam file and then start render it ,
  in the rendering point if it requires to call a method on 2.class and it is not loaded at that
  time then JVM should load the 2.class and show a golden progress line in TOP CORNER of applet and
  temperarily stop rendering, after it loads the 2.class it should just start working normally,
  after sometime if the 2.class need to call a method in the 3.class and it also not available
  at that time then once more we should show a loading bar and wait until the 3.class loads.
  This is the way we can have the good user experience.
  If this is not possible with jam then why not you introduce a filetype called jab(JavaArchive for Browser). The jab works like below As said above app(Folder) contains 1.class and app2(Folder). app2(Folder) contains 2.class and 3.class. Then the jab format should be like <FOLDER name="app"> <FILE name="1.class">Content of 1.class in zipped format to reduce the size</FILE> <FOLDER name="app2"> <FILE name="2.class">Content of 2.class in zipped format to reduce the size</FILE> <FILE name="3.class">Content of 3.class in zipped format to reduce the size</FILE> </FOLDER> </FOLDER> Here the jab packer should be smart enougth to place the class files according to usage tree. In this format in the first you will encounter the main class in the start if archive , so you can start rendering the applet. This is the way we can avoid the time waited by the user until all the jar files needed are loaderd into JVM. If any one wants to have brought round the view pleae feel free to mail me <br/> iamdvr@yahoo.com <br/> OR desu.venkateswara@yahoo.co.in <br/> :::::::::::::::::::::::::::::::::::: <br/> <br/> :::::::::::::::::::::::::::::::::::::::::::::::::
  
  
  
  
  
  
  
  
  

• Java Installer internal engine!
  2006-09-09 20:15:21 ivano [Reply | View]
  
  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!
  2006-09-12 04:10:29 jwenting [Reply | View]
  
  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.

  <Remote installation? Hell no, no different from local except you may well be restricted in your network access, causing that remote installer to fail because it lacks the privileges to connect to the internet.</p>

  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.
  2006-09-09 20:11:37 ivano [Reply | View]
  
  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
  2006-09-08 21:01:41 jamesstaylor [Reply | View]
  
  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
  2006-09-10 20:34:13 hontvari [Reply | View]
  
  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...
  2006-09-08 15:17:16 prime21 [Reply | View]
  
  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
  2006-09-08 10:34:21 jwenting [Reply | View]
  
  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
  2006-09-08 14:40:38 prime21 [Reply | View]
  
  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
• reduce the size some other way
  2006-09-09 00:53:52 jwenting [Reply | View]
  
  Won't work for the reasons I mentioned. It will be very slow while loading classes remotely (if it weren't the original specification would have included that mechanism).
  Remember that applets will require at the very least the complete AWT (and today Swing as well, when was the last time you got away with using raw AWT?).
  That's several more megabytes that need to be loaded remotely.
  Storing it on the client computer would inevitably break the applet sandbox model, thus only be allowed for signed applets (I wonder if they even considered that...), so most applets that people on slow connections use will need to load those megabytes on every invocation of the applet. Not only will their connections not like that, the load on the hosting servers where they'd pull it from would be high as well. And of course the applet model doesn't allow non-trusted applets to load anything from servers other than the server the applet itself is loaded from, so everyone would have to host a JVM and download mechanism on his own server (which is only proper as it reduces the burden and reliance on Sun to host it all).
  It just won't work like that, so either the applet security model which doesn't allow remote loading of data and storing it on the client computer needs to go out the window (which is not something I'd want to see, I think you'll agree, as it will also mean that someone can sneak a library requirement into his applet that would be unsafe and download from http://www.cracks4u.com) or it is only useful on gigabit local networks (on which having to download and install the JVM one time is no problem for anyone and the sysadmins will just deliver it preinstalled anyway).
• reduce the size some other way
  2006-09-09 03:42:57 mthornton [Reply | View]
  
  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
  2006-09-09 07:46:46 jwenting [Reply | View]
  
  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 xyz.com telling that an activeX control is trying to contact sun.com (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?
  2006-09-11 07:38:03 mthornton [Reply | View]
  
  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
  2006-09-11 07:33:10 mthornton [Reply | View]
  
  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.

• Can I get a link...
  2006-09-08 07:50:02 ctreber [Reply | View]
  
  ...to some Java Kernel information?
  
  Cheers,
  
  Chris
• Can I get a link...
  2006-09-08 08:31:04 hayden [Reply | View]
  
  http://weblogs.java.net/blog/enicholas/archive/2006/09/java_browser_ed.html