True I download here in Tokyo at 300 kbytes / sek in my browser in my 12 Mbit down / 1 mbit up connection.
Speeds are depending on the distance to the hub.
All the new flats here has 100 mbit per default glass fiber. That is 100 mbit both ways.
If you want to have fun you can also download by data using your FOMA 3G phone everywhere. Is fatser than the most DSL connection outside of Japan.
That also have a lot of hot spots for your laptom ready.
Regards,
Lars
Please thing of that you will become lonely and strange if you do that for longer time.
Move to the city or find a job close to home.
I am currently living in Tokyo a city that is 3 times bigger than London so I know what I am talking about for NOT commuting. It is "normal" for Japanese to commute 1 1/2 hours each way after working 12 hours here.
Even Sun admits that Java has a problem using to many resources for small tasks.
I don't know if that is better than.NET;)
The Java Problem
Author: Julian S. Taylor
Reviewed by: Steve Talley, Mark Carlson, Henry Knapp, Willy (Waikwan) Hui, Eugene Krivopaltsev, Peter Madany, Michael Boucher
Executive Summary
While the Java language provides many advantages over C and C++, its implementation on Solaris presents barriers to the delivery of reliable applications. These barriers prevent general acceptance of Java for production software within Sun. A review of the problem indicates that these issues are not inherent to Java but instead represent implementation oversights and inconsistencies common to projects which do not communicate effectively with partners and users.
Within Sun, the institutional mechanism for promoting this sort of communication between partners is the System Architecture Council codified in the Software Development Framework (SDF). We propose that the process of releasing our Java implementation will benefit from conformance with the SDF.
Introduction
This document details the difficulties that keep our Solaris Java implementation from being practical for the development of common software applications. It represents a consensus of several senior engineers within Sun Microsystems. We believe that our Java implementation is inappropriate for a large number of categories of software application. We do not believe these flaws are inherent in the Java platform but that they relate to difficulties in our Solaris implementation.
We all agree that the Java language offers many advantages over the alternatives. We would generally prefer to deploy our applications in Java but the implementation provided for Solaris is inadequate to the task of producing supportable and reliable products.
Our experience in filing bugs against Java has been to see them rapidly closed as "will not fix". 22% of accepted non-duplicate bugs against base Java are closed in this way as opposed to 7% for C++. Key examples include:
4246106 Large virtual memory consumption of JVM
4374713 Anonymous inner classes have incompatible serialization
4380663 Multiple bottlenecks in the JVM
4407856 RMI secure transport provider doesn't timeout SSL sessions
4460368 For jdk1.4, JTable.setCellSelectionEnabled() does not work
4460382 For Jdk1.4, the table editors for JTable do not work.
4433962 JDK1.3 HotSpot JVM crashes Sun Management Center Console
4463644 Calculation of JTable's height is different for jdk1.2 and jdk1.4
4475676 [under jdk1.3.1, new JFrame launch causes jumping]
In personal conversations with Java engineers and managers, it appears that Solaris is not a priority and the resource issues are not viewed as serious. Attempts to discuss this have not been productive and the message we hear routinely from Java engineering is that new features are key and improvements to the foundation are secondary. This is mentioned only to make it clear that other avenues for change have been explored but without success. Here we seek to briefly present the problem and recommend a solution.
Defining the Java Problem
These are the problems we have observed which we believe indicate the need for an improved implementation and a modified approach.
1. The support model seems flawed
Since Java is not a self-contained binary, every Java program depends fundamentally upon the installed Java Runtime Environment (JRE). If that JRE is broken, correction and relief is required. This sort of relief needs to happen in a timely manner and needs to fix only the problem without the likelihood of introducing additional bugs. Java Software does not provide such relief.
Java packages are released (re-released) every four or five months, introducing bug fixes and new features and new bugs with each release. These releases are upgrading packages which remove all trace
We have 100 mbit Internet access here in Japan.
You will get 100 mbit sek both ways.
First you need to order a fiber connection from NTT for arround 2000 Euro once payment.
After that you need to pay an 10 euro a month for access to internet. If you want static ip accress so that you can put up a server it is arround 80 euro a months.
The most new houses and flats all have that installed now so if you move in there you do not need to pay the 2000 Euro!
WAKE UP THE REST OF THE WORLD.
True I download here in Tokyo at 300 kbytes / sek in my browser in my 12 Mbit down / 1 mbit up connection.
Speeds are depending on the distance to the hub.
All the new flats here has 100 mbit per default glass fiber. That is 100 mbit both ways.
If you want to have fun you can also download by data using your FOMA 3G phone everywhere. Is fatser than the most DSL connection outside of Japan.
That also have a lot of hot spots for your laptom ready.
Regards, Lars
I forgot to tell that we have 12 Mbit internet connection here for less than you get a 512 kbit for in Europe.
Please thing of that you will become lonely and strange if you do that for longer time.
Move to the city or find a job close to home.
I am currently living in Tokyo a city that is 3 times bigger than London so I know what I am talking about for NOT commuting.
It is "normal" for Japanese to commute 1 1/2 hours each way after working 12 hours here.
Regards,
Lars
Hi,
.NET ;)
Even Sun admits that Java has a problem using to many resources for small tasks.
I don't know if that is better than
The Java Problem
Author: Julian S. Taylor
Reviewed by: Steve Talley, Mark Carlson, Henry Knapp, Willy (Waikwan) Hui, Eugene Krivopaltsev, Peter Madany, Michael Boucher
Executive Summary
While the Java language provides many advantages over C and C++, its implementation on Solaris presents barriers to the delivery of reliable applications. These barriers prevent general acceptance of Java for production software within Sun. A review of the problem indicates that these issues are not inherent to Java but instead represent implementation oversights and inconsistencies common to projects which do not communicate effectively with partners and users.
Within Sun, the institutional mechanism for promoting this sort of communication between partners is the System Architecture Council codified in the Software Development Framework (SDF). We propose that the process of releasing our Java implementation will benefit from conformance with the SDF.
Introduction
This document details the difficulties that keep our Solaris Java implementation from being practical for the development of common software applications. It represents a consensus of several senior engineers within Sun Microsystems. We believe that our Java implementation is inappropriate for a large number of categories of software application. We do not believe these flaws are inherent in the Java platform but that they relate to difficulties in our Solaris implementation.
We all agree that the Java language offers many advantages over the alternatives. We would generally prefer to deploy our applications in Java but the implementation provided for Solaris is inadequate to the task of producing supportable and reliable products.
Our experience in filing bugs against Java has been to see them rapidly closed as "will not fix". 22% of accepted non-duplicate bugs against base Java are closed in this way as opposed to 7% for C++. Key examples include:
4246106 Large virtual memory consumption of JVM
4374713 Anonymous inner classes have incompatible serialization
4380663 Multiple bottlenecks in the JVM
4407856 RMI secure transport provider doesn't timeout SSL sessions
4460368 For jdk1.4, JTable.setCellSelectionEnabled() does not work
4460382 For Jdk1.4, the table editors for JTable do not work.
4433962 JDK1.3 HotSpot JVM crashes Sun Management Center Console
4463644 Calculation of JTable's height is different for jdk1.2 and jdk1.4
4475676 [under jdk1.3.1, new JFrame launch causes jumping]
In personal conversations with Java engineers and managers, it appears that Solaris is not a priority and the resource issues are not viewed as serious. Attempts to discuss this have not been productive and the message we hear routinely from Java engineering is that new features are key and improvements to the foundation are secondary. This is mentioned only to make it clear that other avenues for change have been explored but without success. Here we seek to briefly present the problem and recommend a solution.
Defining the Java Problem
These are the problems we have observed which we believe indicate the need for an improved implementation and a modified approach.
1. The support model seems flawed
Since Java is not a self-contained binary, every Java program depends fundamentally upon the installed Java Runtime Environment (JRE). If that JRE is broken, correction and relief is required. This sort of relief needs to happen in a timely manner and needs to fix only the problem without the likelihood of introducing additional bugs. Java Software does not provide such relief.
Java packages are released (re-released) every four or five months, introducing bug fixes and new features and new bugs with each release. These releases are upgrading packages which remove all trace
We have 100 mbit Internet access here in Japan. You will get 100 mbit sek both ways. First you need to order a fiber connection from NTT for arround 2000 Euro once payment. After that you need to pay an 10 euro a month for access to internet. If you want static ip accress so that you can put up a server it is arround 80 euro a months. The most new houses and flats all have that installed now so if you move in there you do not need to pay the 2000 Euro! WAKE UP THE REST OF THE WORLD.