Thank you for the link! that fact alone -easy tz database update independent of the jre/jdk release- makes Joda-time very valuable. I always wondered why there isn't such a mechanism for Java.
If your app in java 1.4 uses swings it may hit some bumps in the migration to java 5 to java 6 to java 7. I have a real case of that. Mostly is a case of loose programming for swing in 1.4 that got stricter in later versions. Surprisingly going directly from 1.4 to 7 seems to work fine. Only god knows why. I can't find anything on the release notes that explains it.
I'm aware of that. My question pointed specifically to the timezone implementation. If the relevant parts are open source it should be not hard to write an alternative utility.
"Linux Mint 15 is the most ambitious release since the start of the project. MATE 1.6 is greatly improved and Cinnamon 1.8 offers a ton of new features, including a screensaver and a unified control center."
Really, linux mint, a screensaver, really?
Well, the last time I tried Ubuntu 3d screensavers wouldn't work properly, meaning the screen went black and I had to enter my password with no visual feedback to unlock. Also the screensavers weren't configurable and were generally an example of all that was wrong with ubuntu, linux and everything.
This solution is a compromise to create predictable release numbers for future Java releases, leave version numbers available for unplanned releases needed to address security alerts, and maintain backward compatibility with systems that expect the version number to have only a family number plus a single “update” number. It will be the new standard for the affected version.
A more elegant solution requires changing the version format of the JDK to accommodate multiple types of releases. To avoid incompatibilities with existing code however, a change in the version string format needs to be implemented on a future major Java release and will have to be documented and communicated with adequate time to allow software developers to prepare for the change. Is this the long-term solution?
This is a workaround. Oracle is being plain about this and at least making an effort not to break applications.
From Wikipedia: In 1982, the Internet Protocol Suite (TCP/IP) was standardized and the concept of a world-wide network of fully interconnected TCP/IP networks called the Internet was introduced.
You know, Philip K. Dick invented a similar game using computers in he's book Galactic Pot-Healer in 1969, well before the Internet, Google or TCP existed. Probably before computer assisted translation was practical.
When Sun announced that they were going to open source Java they got a lot of bashing of people here because they didn't want to believe it or because Sun was slow in its process. Some things are not instantaneous (code reviews, packaging, third party licenced components, etc) and people should not have unrealistic expectations on this. But they Sun was true and open sourced the main components of Java. I don't know if Oracle plans to continue on this path with the remaining components but they are not the most important ones IMHO.
Sorry, you are saying that there are security bugs in older versions of the JRE that allow drive-in attacks when Java is used only in the server-side? Please provide some examples because I'm interested. Of course, if companies that spend millions in applications can't update the old versions it can't be blamed all on Java, could it? And yes, I know very well how companies work.
Sun open sourced the main components of Java 6 as OpenJDK. Notably exceptions are the Java browser plugin and web start. IcedTea was a fork by Redhat but now they are OpenJDK contributors. What people refer simply as Java covers a lot of different things (compiler, library, plugin, hotspot jvm, etc). Read the article on wikipedia for more details: http://en.wikipedia.org/wiki/OpenJDK.
from the Wayland faq it seems that the X developers have a different perception of the X protocol:
What is wrong with X?
The problem with X is that... it's X. When you're an X server there's a tremendous amount of functionality that you must support to claim to speak the X protocol, yet nobody will ever use this. For example, core fonts; this is the original font model that was how your got text on the screen for the many first years of X11. This includes code tables, glyph rasterization and caching, XLFDs (seriously, XLFDs!). Also, the entire core rendering API that lets you draw stippled lines, polygons, wide arcs and many more state-of-the-1980s style graphics primitives. For many things we've been able to keep the X.org server modern by adding extensions such as XRandR, XRender and COMPOSITE and to some extent phase out less useful extensions. But we can't ever get rid of the core rendering API and much other complexity that is rarely used in a modern desktop. With Wayland we can move the X server and all its legacy technology to an optional code path. Getting to a point where the X server is a compatibility option instead of the core rendering system will take a while, but we'll never get there if don't plan for it.
If X developers don't want to keep it going and prefer to develop Wayland then feel free to fork X and carry it from there. I understand that open source works that way.
The thing i like most about Slashdot, is the easy access to totally unqualified opinions, whose distribution around the correct answer is an inverted bell curve.
You are wrong, like most people in Slashdot... mmh, wait a second...
Slashdot Mirror
Joda actually provides their own TZ update mechanism: http://joda-time.sourceforge.net/tz_update.html
Thank you for the link! that fact alone -easy tz database update independent of the jre/jdk release- makes Joda-time very valuable.
I always wondered why there isn't such a mechanism for Java.
If your app in java 1.4 uses swings it may hit some bumps in the migration to java 5 to java 6 to java 7. I have a real case of that. Mostly is a case of loose programming for swing in 1.4 that got stricter in later versions.
Surprisingly going directly from 1.4 to 7 seems to work fine. Only god knows why. I can't find anything on the release notes that explains it.
I'm aware of that. My question pointed specifically to the timezone implementation. If the relevant parts are open source it should be not hard to write an alternative utility.
Bytecode is but a concept and there are many different, incompatible implementations. Like programming languages and compilers.
it's Time to switch to python
Sorry, no. Perhaps it was time 10 years ago if ever. Now is too late. Even Google is using less Python these days.
How this impacts openjdk? does it uses the same Olsen timezone data or has another tool for updating it?
I don't know but I suppose it was for portability across different operating system.
Horse-pulled carridges just work, and don't need to be replaced.
Indeed. Finally someone talking sense at Slashdot.
Frankly, the threat to free speech and stifling of technology is orders of magnitude more important, even from a purely financial perspective.
Free speech? Mmmh if someone could monetize on that... Just saying...
"Linux Mint 15 is the most ambitious release since the start of the project. MATE 1.6 is greatly improved and Cinnamon 1.8 offers a ton of new features, including a screensaver and a unified control center."
Really, linux mint, a screensaver, really?
Well, the last time I tried Ubuntu 3d screensavers wouldn't work properly, meaning the screen went black and I had to enter my password with no visual feedback to unlock. Also the screensavers weren't configurable and were generally an example of all that was wrong with ubuntu, linux and everything.
From TFA:
Is this the long-term solution?
This solution is a compromise to create predictable release numbers for future Java releases, leave version numbers available for unplanned releases needed to address security alerts, and maintain backward compatibility with systems that expect the version number to have only a family number plus a single “update” number. It will be the new standard for the affected version.
A more elegant solution requires changing the version format of the JDK to accommodate multiple types of releases. To avoid incompatibilities with existing code however, a change in the version string format needs to be implemented on a future major Java release and will have to be documented and communicated with adequate time to allow software developers to prepare for the change.
Is this the long-term solution?
This is a workaround. Oracle is being plain about this and at least making an effort not to break applications.
From Wikipedia: In 1982, the Internet Protocol Suite (TCP/IP) was standardized and the concept of a world-wide network of fully interconnected TCP/IP networks called the Internet was introduced.
Check mate!
If you use the offline installer option from http://www.oracle.com/technetwork/java/javase/downloads/index.html it doesn't try to install the Ask Toolbar or any other software. I just tried.
You know, Philip K. Dick invented a similar game using computers in he's book Galactic Pot-Healer in 1969, well before the Internet, Google or TCP existed. Probably before computer assisted translation was practical.
java does auto update for years now on Windows. what is your point?
When Sun announced that they were going to open source Java they got a lot of bashing of people here because they didn't want to believe it or because Sun was slow in its process. Some things are not instantaneous (code reviews, packaging, third party licenced components, etc) and people should not have unrealistic expectations on this. But they Sun was true and open sourced the main components of Java. I don't know if Oracle plans to continue on this path with the remaining components but they are not the most important ones IMHO.
surely complex javascript implementations deeply integrated in browsers will have no security problems at all...
Sorry, you are saying that there are security bugs in older versions of the JRE that allow drive-in attacks when Java is used only in the server-side? Please provide some examples because I'm interested.
Of course, if companies that spend millions in applications can't update the old versions it can't be blamed all on Java, could it? And yes, I know very well how companies work.
It was not a fork, rather Java was open sourced as OpenJDK.
Sun open sourced the main components of Java 6 as OpenJDK. Notably exceptions are the Java browser plugin and web start. IcedTea was a fork by Redhat but now they are OpenJDK contributors. What people refer simply as Java covers a lot of different things (compiler, library, plugin, hotspot jvm, etc).
Read the article on wikipedia for more details: http://en.wikipedia.org/wiki/OpenJDK.
you mean in your country it is?
from the Wayland faq it seems that the X developers have a different perception of the X protocol:
What is wrong with X?
The problem with X is that... it's X. When you're an X server there's a tremendous amount of functionality that you must support to claim to speak the X protocol, yet nobody will ever use this. For example, core fonts; this is the original font model that was how your got text on the screen for the many first years of X11. This includes code tables, glyph rasterization and caching, XLFDs (seriously, XLFDs!). Also, the entire core rendering API that lets you draw stippled lines, polygons, wide arcs and many more state-of-the-1980s style graphics primitives. For many things we've been able to keep the X.org server modern by adding extensions such as XRandR, XRender and COMPOSITE and to some extent phase out less useful extensions. But we can't ever get rid of the core rendering API and much other complexity that is rarely used in a modern desktop. With Wayland we can move the X server and all its legacy technology to an optional code path. Getting to a point where the X server is a compatibility option instead of the core rendering system will take a while, but we'll never get there if don't plan for it.
If X developers don't want to keep it going and prefer to develop Wayland then feel free to fork X and carry it from there. I understand that open source works that way.
The thing i like most about Slashdot, is the easy access to totally unqualified opinions, whose distribution around the correct answer is an inverted bell curve.
You are wrong, like most people in Slashdot... mmh, wait a second...
Gravity doesn't get anywhere. The black hole bend space towards itself, like any body.
I think that the black hole mass bends spaces.