Easy to Learn Java: Programming Articles, Examples and Tips

Start with Java in a few days with Java Lessons or Lectures


Code Examples

Java Tools

More Java Tools!

Java Forum

All Java Tips


Submit News
Search the site here...
Search the JavaFAQ.nu
1000 Java Tips ebook

1000 Java Tips - Click here for the high resolution copy!1000 Java Tips - Click here for the high resolution copy!

Java Screensaver, take it here

Free "1000 Java Tips" eBook is here! It is huge collection of big and small Java programming articles and tips. Please take your copy here.

Take your copy of free "Java Technology Screensaver"!.

Easy Learn Java: Programming Articles, Examples and Tips - Page 427

Previous 1060 Stories (530 Pages, 2 Per Page) Next

Sun president: PCs are so yesterday

Go to all tips in Daily Tips

I read the article below on News.com
Such news article unfortunately disappear fast. That's why I decided to
republish this article on my site. The chief of SUN (owner of Java) gives his
vision of tomorrow, when services, not applications and handhelds, not PCs will
dominate in the computer world... Why I publish it? To give you a time to
prepare yourself, when one day you will discover that world around you is
changed and you on the way to lose your job. If you read it I promise you that
you probably will not lose it Smile

SAN JOSE, Calif.--Increasingly, the personal computer is a relic.

So asserted Jonathan Schwartz, president of server and software maker Sun
Microsystems. Instead, what has become important are Web services on the
Internet and the mobile phones most will use to access them, he argued at a
Friday speech here at a meeting of the American India Foundation.

"The majority of the applications that will drive the next wave of
innovation will be services, not applications that run on the desktop. The real
innovation is occurring in the network and the network services," Schwartz

Sun, which sells the back-end infrastructure that powers such services, has
promulgated variations of this message for years. But there's evidence the idea
has some merit.

Schwartz points to the increasing wealth and power of companies, like eBay,
Google, Yahoo and Amazon.com, that profit from free services available over the
network. Among his audience, many more people said they'd rather have access to
Internet services than their desktop computing applications. And Microsoft--the
company with the biggest financial stake in the PC software business--has
struggled to cope with the arrival of Web services.

The threat to PCs is twofold. Not only are services moving to the network,
Schwartz said, but PCs won't be the way people use those services--particularly
in poorer areas of the world that have risen higher up Sun's corporate priority
list. Instead, that access will come through mobile phones.

"The majority of the world will first experience the Internet through their
handset," Schwartz said.

When it comes to aiding developing regions' digital development, "Our
collective generation believes the desktop PC is the most important thing to
give to people. I don't buy that. The most important thing to give is access to
the Internet."

Since Schwartz became Sun's president last year, the company has touted a
campaign to bridge the digital divide, for example by promoting freely available
open-source software such as OpenOffice.org. Schwartz doesn't pretend his
company's motives are altruistic, though.

"Clearly it's in my company's best interest to have 50 million people in
sub-Saharan Africa join the network," Schwartz said.

But he does argue that there's more to be gained from pervasive network access
than just a restoration of Sun's financial health and improvement to its
stagnant stock price. The network also helps bring value to society, he said.

"The Internet has clearly become, as electricity and railroads did before
it, a social utility," Schwartz said.

One case in point was visible with the online classified ad site Craigslist
during the effort to cope with the Katrina hurricane that devastated states on
the Gulf Coast. And he expects more with the approach of the next storm, Rita.

"The Internet--and one organization in particular called Craigslist--played
an absolutely central role to recovery efforts," Schwartz said. "While
the Federal Emergency Management Agency was stumbling and trying to figure out
how to present its information, Craigslist was providing a connection vehicle
for people who wanted to find their friends, their family members, their

2213 bytes more | comments? | Printer Friendly Page  Send to a Friend | Score: 0
Posted by Anonymous on Monday, January 09, 2006 (00:00:00) (2690 reads)

Once upon an Oak ...

Go to all tips in Story by Dr. Kabutz

The Java Specialists' Newsletter [Issue 055] - Once upon an Oak ...

Author: Dr. Heinz M. Kabutz

JDK version:

Category: Language

You can subscribe from our home page: http://www.javaspecialists.co.za (which also hosts all previous issues, available free of charge Smile

Welcome to the 55th edition of The Java(tm) Specialists' Newsletter sent to 4461 Java Specialists in 85 countries. We had a good growth in the last two weeks, thanks to your concerted effort in forwarding this newsletter to your friends. There are three people in particular that I want to thank, although many more would be worthy of a mention:

  • Mike Cannon-Brookes mentioned me on his rebelutionary weblog. Mike works for Atlassian, the company that produced the bug tracking tool JIRA.
  • Henri Yandell mentioned me on his bayard weblog.
  • Kevin Oliver from Salesforce.com for convincing many of his colleagues to subscribe.

    Please see the end of this email for information about my upcoming Design Patterns Course.

    When I studied for Java Certification a few years ago, I used a little program to help me along, called JCertify, published by EnterpriseDeveloper.com. I really enjoyed this little program, and I hope to think that my error reports mean that the questions now have correct answers Wink Due to my long-standing relationship with the original author (who is also subscribed to The Java(tm) Specialists' Newsletter), they have given our newsletter a special discount link, where you can get a 20% discount until the 7th of September. I don't benefit in any way if you purchase JCertify - I am simply passing along information about a great little program that you can benefit from.

    Unce upon an Oak ...

    A few weeks ago I was talking to someone about the origins of Java, and it occurred to me that I had big gaps in that part of world history. History had never been my forte, at school this was my weakest subject at 35% (at my worst level). Perhaps I should add that I was very weak with South African history, which at the time of me going to high school supposedly started with the white settlers arriving on the shores, and consisted almost entirely of remembering dates. I found such parrotting frivolous, and so my marks were not too hot.

    Trying to fill my gaps of Java's history, I started digging around on Sun's website, and eventually stumbled across the Oak Language Specification for Oak version 0.2. Oak was the original name of what is now commonly known as Java, and this manual is the oldest manual available for Oak (i.e. Java). For more history on the origins of Java, please have a look at The Green Project and Java(TM) Technology: An Early History. I printed the manual and kept it next to my bed in case of insomnia (so I thought). When I started reading it, I discovered answers to ancient questions: Why can we have only one public class per .java file? Why are protected members also accessible from the same package? Why do short fields use as much memory as int fields (at least pre-JDK 1.4)?

    In this newsletter I want to highlight the differences between Java 0.2 (i.e. Oak 0.2) and what we have now. For your reference, I will include the section numbers in the Oak 0.2 specification.

    Why is each public class in a separate file? (Section 1)

    This is a question that I have frequently been asked during my courses. Up to now I have not had a good answer to this question. In section 1, we read: "Although each Oak compilation unit can contain multiple classes or interfaces, at most one class or interface per compilation unit can be public".

    In the sidebar it explains why: "This restriction is not yet enforced by the compiler, although it's necessary for efficient package importation"

    It's pretty obvious - like most things are once you know the design reasons - the compiler would have to make an additional pass through all the compilation units (.java files) to figure out what classes were where, and that would make the compilation even slower.

    One-line Javadoc comments (Section 2.1)

    Oak had the ability to write a one-line JavaDoc comment:

    public class OneLineJavaDoc {
      //* The number of lines allowed in a document.
      public int numberOfLines;

    This is fortunately not supported in Java as it is quite confusing.

    Additional Keywords (Section 2.3)

    Oak had some additional keywords that are not currently used in Java:

  • ushort, string, Cstring and unsynchronized were already obsolete in version 0.2 of Oak. Isn't it amazing how quickly things become obsolete in our industry?
  • clone, const and goto were keywords
  • protect and unprotect were nasty keywords for writing terrible exception code. More about that later...
  • enum was a keyword, but in the sidebar it said: enum isn't implemented yet. So, in answer to the question: Why does Java not have enum? The answer is not some heavy object-oriented philosophical answer about polymorphism and strategy patterns. It is simply that James Gosling didn't implement it in time and his management forced him to push the language out of the door before he could finish the feature Smile

    Unsigned integer values (Section 3.1)

    The specification says: "The four integer types of widths of 8, 16, 32 and 64 bits, and are signed unless prefixed by the unsigned modifier.

    In the sidebar it says: "unsigned isn't implemented yet; it might never be." How right you were.

    Storage of Integer values (Section 3.1)

    In my newsletter on Determining Memory Usage in Java, I noted that when you have a data member of byte or short, that they still use up at least 4 bytes of memory. This was changed in JDK 1.4, but the historical reason is found in the Oak spec:

    "A variable's type does not directly affect its storage allocation. Type only determines the variable's properties and legal range of values. If a value is assigned to a variable that is outside the legal range of the variable, the value is reduced modulo the range."

    I wish I had known that when I wrote my first Java program. I spent a lot of time deciding which data types I wanted to use in order to save memory, but I was actually wasting my time. Please note that this has changed as of JDK 1.4, so now it does help to use bytes and shorts to reduce the memory footprint.

    Arrays (Section 3.5)

    In Oak, you were able to declare arrays as follows:

    int a[10];
    a[5] = 1;

    However, we were also able to declare an array in the current Java fashion, with new. I think having two ways of doing the same thing causes confusion, so I am very pleased that this way of making new arrays has been removed.

    Const vs. Final (Sections 4.6 and 4.9)

    It appears that final was initially only meant to be used for classes and methods, and that const was used for making fields constant.

    Private did not exist (Sections 4.10)

    This is the most surprising part of Oak 0.2. There were only three access levels as opposed to our current four. There was private which did not require a keyword, and which equated to our current "package private" or "friendly" or "package access" type of access level. All classes in a particular package could use all variables and methods declared in the classes in that package, regardless of public, protected and private declarations. I am very glad that they introduced a more private version of private, one that was only accessible within the class.

    The lack of private as we know it today explains why when a member is protected, it is also accessible from within the same package. When Oak was written, protected was obviously accessible within the package because their private (our "package access") was the most restrictive access level. I seem to remember that in JDK 1.0 we had a fifth access level called "private protected", which meant that only subclasses could access the member.

    This piece of surprising history also explains why fields are not private by default - they actually were "private" originally when private meant different things.

    I don't need to emphasize how pleased I am that we now have the more restrictive "private" modifier. Without that, our industry would be in even more trouble.

    Abstract Methods (Section 5)

    Abstract methods were defined as in C++:

    public interface Storing {
      void freezeDry(Stream s) = 0;

    Assertions and Pre/Postconditions (Sections 7, 7.1 and 7.2)

    Unfortunately the assertions in Oak 0.2 were not implemented in time, so they were thrown out to satisfy the release deadline. In case you think that assertions are back in JDK 1.4, have a look at the power that "those" assertions gave you:

    class Calender { 
      static int lastDay[12]= 
      int month assert(month>=1 && month<=12); 
      int date assert(date>=1 && date<=lastDay[month]); 

    While objects are not required to obey the legality constraints within methods, the constraints are enforced at the entry and exit of every public and protected method.

    I wish that James Gosling had worked a few extra weekends (if that were possible) to finish the implementation of assert as it appeared in the original Oak spec. Preconditions and Postconditions were also loosely defined, but were also kicked out due to time pressure. Pity.

    Post-incrementing Strings (Section 8.1.4)

    In Oak, you were able to post-increment a String. You could literally say s1++;, which was equivalent to s1 = s1 + 1;. The post-increment statement is often (if not always) implemented as +=1 so it seems that this also was true for Strings. Fortunately this is not allowed in Java anymore.

    Goto ... (Section 9.3)

    Of course, being based on C, Oak included the infamous goto statement. Fortunately this is not in Java.

    Exceptions (Section 9.4)

    Where does the name RuntimeException come from? Aren't all exceptions thrown at runtime? These are exceptions which are thrown by the runtime system.

    In Oak 0.2, all exceptions were unchecked, meaning that there was no throws clause. My guess is that checked exceptions were only added once the whole exception hierarchy had already been set in wet concrete. I would have had a separate branch for checked exceptions, something like:

    public class Throwable { }
    /** Serious errors in the virtual machine */
    public class Error extends Throwable { }
    public class CheckedException extends Throwable { }
    public class IOException extends CheckedException { }
    public class UncheckedException extends Throwable { }
    public class NullPointerException extends UncheckedException { }

    This way you would avoid catching unchecked exceptions when you catch CheckedException. However, as it appears, the exception class hierarchy was developed before the idea of checked vs. unchecked exceptions, so we are stuck with an exception mechanism that will cause headaches for generations to come.

    Asynchronous Exceptions (Section 9.4.2)

    If your program gets an asynchronous exception, you are dead. A few weeks ago I was looking at a program that was throwing OutOfMemoryError. This can happen at any time really, which is why it is called an asynchronous exception. Another place where this can happen is with Thread.stop(). As you can imagine, this is inherently dangerous, that is why it is deprecated. In Oak, life was even more dangerous. You could cause an asynchronous exception in another thread using Thread's postException() method. Now that was dangerous! Imagine if other threads could cause asynchronous exceptions at any place in your code!

    In order to safeguard your code, you could "protect" it. If you wanted to indicate that you had some critical code which could not handle asynchronous exceptions, you did the following:

    protect {
      /* critical section goes here */

    And code that was quite happy with asynchronous exceptions did the following:

    unprotect {
      /* code that can afford asynchronous exceptions */

    There was a note in the sidebar saying that the default would probably be changed to not allow asynchronous exceptions except in explicitely unprotected sections of code.

    I'm very glad that this feature was binned. I cannot imagine how complex our Java programs would have become with it in place.


    That's it. The rest of the manual was filled with a Glossary and an Index, to push the manual to 38 pages.

    Even though this manual was written way back in 1994, it provided for fascinating reading, even late at night Wink

    Until next time ...


    Copyright 2000-2004 Maximum Solutions, South Africa

    Reprint Rights. Copyright subsists in all the material included in this email, but you may freely share the entire email with anyone you feel may be interested, and you may reprint excerpts both online and offline provided that you acknowledge the source as follows: This material from The Java(tm) Specialists' Newsletter by Maximum Solutions (South Africa). Please contact Maximum Solutions for more information.

    Java and Sun are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries. Maximum Solutions is independent of Sun Microsystems, Inc.

  • 12124 bytes more | Printer Friendly Page  Send to a Friend | Score: 0
    Posted by jalex on Saturday, January 07, 2006 (00:00:00) (2117 reads)

    Previous 1060 Stories (530 Pages, 2 Per Page) Next

    530| 529| 528| 527| 526| 525| 524| 523| 522| 521| 520| 519| 518| 517| 516| 515| 514| 513| 512| 511| 510| 509| 508| 507| 506| 505| 504| 503| 502| 501| 500| 499| 498| 497| 496| 495| 494| 493| 492| 491| 490| 489| 488| 487| 486| 485| 484| 483| 482| 481| 480| 479| 478| 477| 476| 475| 474| 473| 472| 471| 470| 469| 468| 467| 466| 465| 464| 463| 462| 461| 460| 459| 458| 457| 456| 455| 454| 453| 452| 451| 450| 449| 448| 447| 446| 445| 444| 443| 442| 441| 440| 439| 438| 437| 436| 435| 434| 433| 432| 431| 430| 429| 428|
    | 426| 425| 424| 423| 422| 421| 420| 419| 418| 417| 416| 415| 414| 413| 412| 411| 410| 409| 408| 407| 406| 405| 404| 403| 402| 401| 400| 399| 398| 397| 396| 395| 394| 393| 392| 391| 390| 389| 388| 387| 386| 385| 384| 383| 382| 381| 380| 379| 378| 377| 376| 375| 374| 373| 372| 371| 370| 369| 368| 367| 366| 365| 364| 363| 362| 361| 360| 359| 358| 357| 356| 355| 354| 353| 352| 351| 350| 349| 348| 347| 346| 345| 344| 343| 342| 341| 340| 339| 338| 337| 336| 335| 334| 333| 332| 331| 330| 329| 328| 327| 326| 325| 324| 323| 322| 321| 320| 319| 318| 317| 316| 315| 314| 313| 312| 311| 310| 309| 308| 307| 306| 305| 304| 303| 302| 301| 300| 299| 298| 297| 296| 295| 294| 293| 292| 291| 290| 289| 288| 287| 286| 285| 284| 283| 282| 281| 280| 279| 278| 277| 276| 275| 274| 273| 272| 271| 270| 269| 268| 267| 266| 265| 264| 263| 262| 261| 260| 259| 258| 257| 256| 255| 254| 253| 252| 251| 250| 249| 248| 247| 246| 245| 244| 243| 242| 241| 240| 239| 238| 237| 236| 235| 234| 233| 232| 231| 230| 229| 228| 227| 226| 225| 224| 223| 222| 221| 220| 219| 218| 217| 216| 215| 214| 213| 212| 211| 210| 209| 208| 207| 206| 205| 204| 203| 202| 201| 200| 199| 198| 197| 196| 195| 194| 193| 192| 191| 190| 189| 188| 187| 186| 185| 184| 183| 182| 181| 180| 179| 178| 177| 176| 175| 174| 173| 172| 171| 170| 169| 168| 167| 166| 165| 164| 163| 162| 161| 160| 159| 158| 157| 156| 155| 154| 153| 152| 151| 150| 149| 148| 147| 146| 145| 144| 143| 142| 141| 140| 139| 138| 137| 136| 135| 134| 133| 132| 131| 130| 129| 128| 127| 126| 125| 124| 123| 122| 121| 120| 119| 118| 117| 116| 115| 114| 113| 112| 111| 110| 109| 108| 107| 106| 105| 104| 103| 102| 101| 100| 99| 98| 97| 96| 95| 94| 93| 92| 91| 90| 89| 88| 87| 86| 85| 84| 83| 82| 81| 80| 79| 78| 77| 76| 75| 74| 73| 72| 71| 70| 69| 68| 67| 66| 65| 64| 63| 62| 61| 60| 59| 58| 57| 56| 55| 54| 53| 52| 51| 50| 49| 48| 47| 46| 45| 44| 43| 42| 41| 40| 39| 38| 37| 36| 35| 34| 33| 32| 31| 30| 29| 28| 27| 26| 25| 24| 23| 22| 21| 20| 19| 18| 17| 16| 15| 14| 13| 12| 11| 10| 9| 8| 7| 6| 5| 4| 3| 2| 1|

    Home Code Examples Java Forum All Java Tips Books Submit News, Code... Search... Offshore Software Tech Doodling

    RSS feed Java FAQ RSS feed Java FAQ News     

        RSS feed Java Forums RSS feed Java Forums

    All logos and trademarks in this site are property of their respective owner. The comments are property of their posters, all the rest 1999-2006 by Java FAQs Daily Tips.

    Interactive software released under GNU GPL, Code Credits, Privacy Policy