Hopefully Chernobyl style meltdowns are a thing of the past.
But accidents happen, as occurred this week in Tricastin, France. Burning coal mightn't be greenhouse friendly but don't kid yourself nuclear power is ecologically safe.
Then there's the sensitive issue of selling uranium to countries like Iran.
For some, the risks are too great and would wish others would just leave the stuff in the ground.
Agreed, a photo taken with a typical low-end VGA camera *is* a gimmick. (Others may point out one can buy a higher end phone with a 10 mega-pixel camera but I suspect that's not the end of the market you're referencing.)
However, such a 'mugshot mode' does at least allow the possibility of face-to-face chat over wifi/3G. VGA exceeds the resolution of most standard handsets, so may be adequate for this. Again you may consider this fetishism but the market in this context isn't to replace the standalone digital camera.
This announcement means OpenJDK passes all the tests. That doesn't mean the GPL replacements for the Sun proprietary code are yet mature enough to be considered 'production ready'; Sun may continue to link the encumbered bits in their release versions.
e.g. As someone else mentioned, things like font rendering still aren't quite there yet in terms of quality. They 'do the job' enough to pass the test suite but adequacy doesn't imply polish.
Another factor is not everything included in a JRE has been released into OpenJDK. Examples are a browser plugin for applets and Java Web Start for JNLP. These are undergoing a rewrite as Sun tries rediscovers the client through their JavaFX initiative. Perhaps these will be freed into the OpenJDK7 source tree over time. Meanwhile, IcedTea have provided substitutes for these two technologies.
Classpath's methodology has been to progressively increase coverage of the Java class libraries based on running real-world applications, such as tomcat, eclipse and jboss which redhat wanted to bundle but couldn't rely on Sun's JRE because it did ship on all their supported architectures.
For a number of years software was stuck using Java SE 1.4.2 - Large scale software projects tended to be fairly conservative when jumping to new 1.5 features such as generics and hence held back on using newer 1.5 and beyond APIs.
So don't be surprised if coverage is best for 1.4.2. Classpath has been somewhat dormant for a year or so - many of the chief developers have been working on IcedTea.
I wouldn't be expecting Classpath to be passing the TCK any time soon, if ever. BrandWeg may help in substituting missing classes but for implementing specific methods like your missing constructor, probably not.
But then classpath's goal of "escaping the Java trap" by having a complete Java platform under the GPL has now been realised, so the need for anyone to 'finish' it is reduced.
Gary Benson has been steadily implementing a processor-independent version of HotSpot.
The shipping HotSpot is available only for a limited number of platforms such as Sparc, x86 and x86_64 because it uses intricate assembly language specific to those CPUs. Benson's work uses a purely C++ version of the bytecode interpreter for which he is JIT-ifying using LLVM.
Though sponsored by RedHat for their Linux platforms, the resultant PPC JVM will hopefully one day integrate nicely with Soylatte.
Whoa, Java applets are largely dead. But the idea you're proposing is very similar. You're talking about replacing a specialist interpreter for javascript (spidermonkey/tamarin), with a managed execution environment (parrot) for languages compiled down to a common intermediate bytecode. That's exactly what.Net does (CLR) and what Java has done (JVM), as I said, for 13 years.
Ultimately applets never really caught on for a several of reasons, including
machines back in the 90s weren't powerful enough to run an interpreted execution layer with ease. Try running any modern environment like Java,.Net or parrot within a web browser with less than a 1ghz machine with 1/2 a gig of RAM - it won't be pretty.
Microsoft sabotaged Java. Sun successfully sued them for releasing an incompatible version.
Sun's implementation required a ~ 10MB download and then took several seconds to load each time.
As for applets being ugly, that's largely due to the developer! Flash has had specialist media APIs which Sun are belatedly trying to address with JavaFX.
As far as accessing the browser DOM, Java applets can via LiveConnect.
As for speed and size, Sun have been addressing this in their consumer JRE. Further, the LiveConnect Javascript bridge has been rewritten for FireFox 3.
BTW, I've never seen anything run in an applet beside Java.
How would you know? It's all compiled down and distributed as the same bytecode - the source language code be java, python, groovy or ruby. Just as would be supplied to parrot - the difference being that javascript is generally distributed in source form rather than bytecode. And by the way, the UI toolkit (AWT/Swing) != Java the platform. It supplements HTML with a cross-platform toolkit, something parrot won't support[1]. But no one's forcing developers to use it; as I've mentioned, Java can directly manipulate the DOM.
[1] Ok, there's XUL but that will only work in firefox and related browsers.
Sun Microsystems launched this idea around 13 years ago... Java applets.
Though Java-centric in nature, the JVM provides a secure sandboxed environment to host numerous languages including Ruby, Python, Lisp and even JavaScript. Throw in Groovy and Scala for home-grown alternatives.
Thanks to the efforts of IcedTea (principally funded by RedHat) and others, Java 6 will be fully GPL by the end of the year.
Rhino and SquirrelFish have totally different codebases, are written in different languages and may be under different licenses.
So, no. Unless someone takes the time to apply similar optimisations to Rhino.
But as far as a Java embedded scripting engine go, the comments for this blog about Java's new embeddable web component indicate that they are using the native webkit library (and JavaScript interpreter) underneath.
So, in theory, they could expose SquirrelFish to Java clients as a JSR 223 scripting engine. Would the performance benefits be as spectacular as claimed in this context? SquirrelFish has one set of JIT optimisations, hotspot another; the two must interact via JNI. (Significant overhead???)
On licensing, the BSD port licensed its code from Sun under a different license before Java went GPL.
At the moment, legal eagles are working through some paperwork regarding acceptance of this code into the GPL source tree. But in coming months we'll hopefully see the BSD and, by extension, Landon Fuller's OS X work hosted in the main openjdk codebase. Patience...
Now on the other matter, the OS X Java, there have been pleadings from Java developers in the past for Sun to take the reins and do an official port. Particularly a few months ago when Leopard shipped without Java 6.
What makes the port to OS X harder than, say, Linux? Among other things:
* A Cocoa implementation of AWT * Porting the hotspot virtual machine to PPC * native libraries, e.g. the Java-Cocoa bridge
These are not trivial tasks they require some expertise of OS X and PowerPC internals. If they were simple to implement, Apple wouldn't be 2 years late. For Sun to replicate these existing features from scratch would take many man years. And for 10%, or thereabouts, of the desktop market they obviously don't see a cost benefit. Would Sun be willing to 'buy back' Apple's source tree and GPL it? Some OS X internals Apple may not wish to expose (IP issues) and like Sun's codebase be encumbered by code they don't own.
Ultimately some of the ball is in Apple's court. They have sought to maintain their own Java port for competitive reasons such as low level OS integration. But what competitive advantage they deem to have when their releases are a full version behind Linux, Solaris and Windows is debatable.
Would Apple publish changes back to openjdk? They seem reluctant to. One benefit:
* PowerPC hotspot - someone else can maintain legacy architecture support for the G4. Who else have a vested interest in openjdk? Redhat, who have signalled intentions to support multiple architectures besides x86. Do Apple and Redhat really compete for the same markets, aside from a few Xserves???
Hence my comment about workaholics.:) I can't imagine typing would be much fun either.
Purely a subjective opinion but I find it difficult enough reading a paperback at times with people crowding me with newspapers, body odor, excessively loud music and personal phone conversations broadcast the length of the carriage.
IMHO Trackpads and 'nipples' suffice for an emergency when one leave one's USB mouse at home but...
For me the interaction just plain sucks, particularly when selecting text or drag and drop.
Workaholics on public transport trying to cram an extra 20 minutes into their day, and I see them plugging numbers into excel, may see some benefit in such input mechanisms.
If I had to pick an ultra-portable, I'd ditch the conventional hinged keyboard altogether. 1 docking station keyboard and mouse for work, 1 for home. Something like this. Perfect for reading PDFs on the train or on the couch.
Slashdot Mirror
Cute!
*In theory* a binary format such as Mach-O favoured by Apple could be used, booting from an architecture-neutral bootloader.
I'm not a low-level ones and zeros programmer so I'm not sure how much effort would be required to release such a dream.
Of course the limited capacity of the flash storage device would probably then be the deal breaker.
But accidents happen, as occurred this week in Tricastin, France. Burning coal mightn't be greenhouse friendly but don't kid yourself nuclear power is ecologically safe.
Then there's the sensitive issue of selling uranium to countries like Iran.
For some, the risks are too great and would wish others would just leave the stuff in the ground.
Agreed, a photo taken with a typical low-end VGA camera *is* a gimmick. (Others may point out one can buy a higher end phone with a 10 mega-pixel camera but I suspect that's not the end of the market you're referencing.)
However, such a 'mugshot mode' does at least allow the possibility of face-to-face chat over wifi/3G. VGA exceeds the resolution of most standard handsets, so may be adequate for this. Again you may consider this fetishism but the market in this context isn't to replace the standalone digital camera.
Sure, but non-free is not going to increase mindshare.
The goal is for Java to be a 1st class citizen. That means getting in the main repository so it'll be included on the default ISO.
Get it right, Sun own MySQL.
Java, Apache, MySQL, Solaris.
Ideally, couldn't there be some fusion where mono provides the CLR infrastructure and wine provides the Win32 plumbing?
This announcement means OpenJDK passes all the tests. That doesn't mean the GPL replacements for the Sun proprietary code are yet mature enough to be considered 'production ready'; Sun may continue to link the encumbered bits in their release versions.
e.g. As someone else mentioned, things like font rendering still aren't quite there yet in terms of quality. They 'do the job' enough to pass the test suite but adequacy doesn't imply polish.
Another factor is not everything included in a JRE has been released into OpenJDK. Examples are a browser plugin for applets and Java Web Start for JNLP. These are undergoing a rewrite as Sun tries rediscovers the client through their JavaFX initiative. Perhaps these will be freed into the OpenJDK7 source tree over time. Meanwhile, IcedTea have provided substitutes for these two technologies.
For a number of years software was stuck using Java SE 1.4.2 - Large scale software projects tended to be fairly conservative when jumping to new 1.5 features such as generics and hence held back on using newer 1.5 and beyond APIs.
You can check the completeness here
So don't be surprised if coverage is best for 1.4.2. Classpath has been somewhat dormant for a year or so - many of the chief developers have been working on IcedTea.
I wouldn't be expecting Classpath to be passing the TCK any time soon, if ever. BrandWeg may help in substituting missing classes but for implementing specific methods like your missing constructor, probably not.
But then classpath's goal of "escaping the Java trap" by having a complete Java platform under the GPL has now been realised, so the need for anyone to 'finish' it is reduced.
Gary Benson has been steadily implementing a processor-independent version of HotSpot.
The shipping HotSpot is available only for a limited number of platforms such as Sparc, x86 and x86_64 because it uses intricate assembly language specific to those CPUs. Benson's work uses a purely C++ version of the bytecode interpreter for which he is JIT-ifying using LLVM.
Though sponsored by RedHat for their Linux platforms, the resultant PPC JVM will hopefully one day integrate nicely with Soylatte.
'Buzzwordy' maybe. But does it run on toasters? :)
Ultimately applets never really caught on for a several of reasons, including
- machines back in the 90s weren't powerful enough to run an interpreted execution layer with ease. Try running any modern environment like Java,
.Net or parrot within a web browser with less than a 1ghz machine with 1/2 a gig of RAM - it won't be pretty.
- Microsoft sabotaged Java. Sun successfully sued them for releasing an incompatible version.
- Sun's implementation required a ~ 10MB download and then took several seconds to load each time.
As for applets being ugly, that's largely due to the developer! Flash has had specialist media APIs which Sun are belatedly trying to address with JavaFX.As far as accessing the browser DOM, Java applets can via LiveConnect.
As for speed and size, Sun have been addressing this in their consumer JRE. Further, the LiveConnect Javascript bridge has been rewritten for FireFox 3.
BTW, I've never seen anything run in an applet beside Java.
How would you know? It's all compiled down and distributed as the same bytecode - the source language code be java, python, groovy or ruby. Just as would be supplied to parrot - the difference being that javascript is generally distributed in source form rather than bytecode. And by the way, the UI toolkit (AWT/Swing) != Java the platform. It supplements HTML with a cross-platform toolkit, something parrot won't support[1]. But no one's forcing developers to use it; as I've mentioned, Java can directly manipulate the DOM.
[1] Ok, there's XUL but that will only work in firefox and related browsers.
A maxed-out 12 inch iBook G4 would suffice.
Pros:
- roughly the same price and performance as an EEE pc or Aspire One
- an adult-size keyboard
- last I checked the Aspire didn't have bluetooth.
:(
- well-known hardware for servicing
- Linux should hopefully have open source drivers for most of the hardware (radeon 9550/airport extreme) by now.
Cons:Though Java-centric in nature, the JVM provides a secure sandboxed environment to host numerous languages including Ruby, Python, Lisp and even JavaScript. Throw in Groovy and Scala for home-grown alternatives.
Thanks to the efforts of IcedTea (principally funded by RedHat) and others, Java 6 will be fully GPL by the end of the year.
So, no. Unless someone takes the time to apply similar optimisations to Rhino.
But as far as a Java embedded scripting engine go, the comments for this blog about Java's new embeddable web component indicate that they are using the native webkit library (and JavaScript interpreter) underneath.
So, in theory, they could expose SquirrelFish to Java clients as a JSR 223 scripting engine. Would the performance benefits be as spectacular as claimed in this context? SquirrelFish has one set of JIT optimisations, hotspot another; the two must interact via JNI. (Significant overhead???)
In Tasmania? You gotta be kidding me!
:)
It's bloody cold down there!
...IPS were better than apt?
It's designed by (deb)Ian Murdock, with 15 years of hindsight.
On licensing, the BSD port licensed its code from Sun under a different license before Java went GPL.
At the moment, legal eagles are working through some paperwork regarding acceptance of this code into the GPL source tree. But in coming months we'll hopefully see the BSD and, by extension, Landon Fuller's OS X work hosted in the main openjdk codebase. Patience...
Now on the other matter, the OS X Java, there have been pleadings from Java developers in the past for Sun to take the reins and do an official port. Particularly a few months ago when Leopard shipped without Java 6.
What makes the port to OS X harder than, say, Linux? Among other things:
* A Cocoa implementation of AWT
* Porting the hotspot virtual machine to PPC
* native libraries, e.g. the Java-Cocoa bridge
These are not trivial tasks they require some expertise of OS X and PowerPC internals. If they were simple to implement, Apple wouldn't be 2 years late. For Sun to replicate these existing features from scratch would take many man years. And for 10%, or thereabouts, of the desktop market they obviously don't see a cost benefit. Would Sun be willing to 'buy back' Apple's source tree and GPL it? Some OS X internals Apple may not wish to expose (IP issues) and like Sun's codebase be encumbered by code they don't own.
Ultimately some of the ball is in Apple's court. They have sought to maintain their own Java port for competitive reasons such as low level OS integration. But what competitive advantage they deem to have when their releases are a full version behind Linux, Solaris and Windows is debatable.
Would Apple publish changes back to openjdk? They seem reluctant to. One benefit:
* PowerPC hotspot - someone else can maintain legacy architecture support for the G4. Who else have a vested interest in openjdk? Redhat, who have signalled intentions to support multiple architectures besides x86. Do Apple and Redhat really compete for the same markets, aside from a few Xserves???
Hence my comment about workaholics. :) I can't imagine typing would be much fun either.
Purely a subjective opinion but I find it difficult enough reading a paperback at times with people crowding me with newspapers, body odor, excessively loud music and personal phone conversations broadcast the length of the carriage.
For me the interaction just plain sucks, particularly when selecting text or drag and drop.
Workaholics on public transport trying to cram an extra 20 minutes into their day, and I see them plugging numbers into excel, may see some benefit in such input mechanisms.
If I had to pick an ultra-portable, I'd ditch the conventional hinged keyboard altogether. 1 docking station keyboard and mouse for work, 1 for home. Something like this. Perfect for reading PDFs on the train or on the couch.
Probably because they see JavaScript, bytecode and virtual machine all in the same sentence. Put two and two together and you end up with five.
I was going to suggest this. Some enterprising opportunist could open a book store just over the state line to avoid the sales tax.
They could call it Borders.
Ironically he performs exclusively masked so no one knows his real identity.
Indeed, had the original poster done some research, Atari employed Jobs who in turn outsourced work to Woz.
It wouldn't surprise me, either as head of IT: Stallman Convinces Cuba to Switch to Open Source or, perhaps, musician: Guantanamero.