Slashdot Mirror

Generic types have been added to Java for public release in version 1.5.
There is an early access release of the compiler for generics.

For those people who want generics now, there is a non-Sun implementation of generic types.

Generic types have been added to Java for public release in version 1.5.
There is an early access release of the compiler for generics.

For those people who want generics now, there is a non-Sun implementation of generic types.

Any other questions?

What about the Object class? Having everything (with the exception of native datatypes that can be wrapped into classes) be a descendant of a superclass is a far more elegant solution than using c++'s hackish and syntactically awkward template feature.

Java SDK v1.5 (not yet released) contains support for 'generics', which are very much like C++ templates for Java:

http://java.sun.com/features/2003/05/bloch_qa.html

A Sun article says "When it comes to business relationships, the one between Sun Microsystems, Inc. and Ford Motor Company has always been solid." (yeah, I heard that with Firestone too--"solid" :-). Anyway, I wonder if this Linux move was at Sun's expense or was it in another area?

Sun Rays are nice, but you can go even cheaper if you get a low-cost PC ( A iDOT Lindows Webstation box, perhaps?), and Knoppix with the Encrypted Persistent Home Directory which you can save on a USB pen drive...

This looks like regular Gnome2, which is included in new Solaris versions...

The real MadHatter screenshots seems to be here.

Links:

• Globus FAQ
• Python Globus (pyGlobus)
• The Condor Project
• Beowulf FAQ

if you want X Term support the cost is through the roof. I want to know why the X capable clients cost so much more than the Winterm clients.

Is the cost really through the roof? We use SunRay's in a classroom lab and in several simulators for X applications. The cost per unit is quite affordable, even taking into account the SunRay server. We also run windows apps on them using Citrix ICA. The Sunrays themselves were cheap - the Citrix side of things was the expensive component, far more than the cost of the SunRays or the SunRay server, and you don't need Citrix for the X side of things.

Most recently, the sun ray is about half the price, has cool take-your-session-anywhere technology, and last I heard isn't selling like hotcakes. So either HP knows something I don't or this is just more evidence of clueless management...

Sun's solution includes - is based around - the UltraSPARC series of processors. Okay, they'll flog you an x86 box if you insist on one, but that's a side-issue. Sun sell tin; the software exists to make the tin useful. You can't make yourself a F15k out of open source and industry standards.

Brain Drain my ... behind. India trains them, we teach them to be entrepreneurs, and now all that labor is flowing back to India. Software companies are setting up shop there and moving jobs there.

The swank new Adobe India digs. These are to house 600+ engineers in the next few years. Hmmm, Adobe just layed off 600 [400?] people or so in their latest round. Some of the jobs elliminated in San Jose became available in India. So long suckers, thanks for making Framemaker a good product, but we can squeeze more money out of it in India.

Same can be said of Sun

I am sure more examples can be dredged up. Now is this a good thing? Certainly for the Indians that benefit & India as well. Not good for me as a US based programmer unless I want to go live in India.

I guess everyone on the planet's living standard needs to reach parity before this process will even out. Short term ours decreases, while the 3rd world catches up. This process has already finished in Japan. Now that they are at the top it is time for their poorer neighbors to live it up while they stagnate. China, Malaysia, etc. come to mind.

So which is the #1 64 bit architecture out there? Well, PA-RISC and Alpha are systems which HP is trying to replace with Itaniums. Shame really, they were both very good systems. The Opteron is outselling the Itanium, which is fantastic, except it looks like the Itanium is selling at a rate of about 13000 a year, so neither of the 64-bit ones coming from teh x86 shops are really in the running at the moment. And where's MIPS these days? That leaves SPARC, Power4+ and the PPC970 (too early to tell for that one). Well, the Power4+ seems to perform better than the UltraSPARC, but it only goes up to 32 processors per box, as opposed to 106 for the UltraSPARC III. For quite a lot of applications, large numbers of processors in a box is better than clusters, so these really do offer a lot in terms of performance. I'd expect that those 106 way Sun boxes to have very high scores in the Spec throughput tests.

There's also other measures of quality, such as reliability. IBM has a pretty good reputation for it with the high end products (there was that one story about some ols S/390 which was up for 8 years and only the case was part of the original install), but then again, Sun doesn't have a bad reputation there either. They're both good, and x86 is nowhere near either of them.

So is the SPARC the #1 64 bit architecture out there? Depends on what you mean by #1, but it's certainly a contender for many definitions.

Do you have any opinions about something more analogous to a library card or a security key? I guess I'm thinking about something like SunRays for the home, although the idea is obviously more of a vague notion, right now.

I think something very fishy is going on here. CNet did a small interview with Bill Joy :

http://news.com.com/2100-1012_3-5073205.html?tag=f d_top

however the guy in the picture certainly ain't Bill Joy. Here's some URL's which show defintely other pictures identifying Bill Joy :

http://www.counterbalance.net/bio/joy-frame.html
http://java.sun.com/features/1999/07/bill.joy.html
http://www.sun.com/executives/perspectives/joy.htm l

The False CNet Bill Joy has a chin butt, piercing eyes and no glasses, while the 3 above URL's show the real Bill Joy with _no_ chin butt , no piercing eyes and all 3 of them with glasses. Did some fake dude show up at CNet's, faking as Bill Joy (commiting identity theft) and possibly tell some false rumours?

Robert

I think something very fishy is going on here. CNet did a small interview with Bill Joy :

http://news.com.com/2100-1012_3-5073205.html?tag=f d_top

however the guy in the picture certainly ain't Bill Joy. Here's some URL's which show defintely other pictures identifying Bill Joy :

http://www.counterbalance.net/bio/joy-frame.html
http://java.sun.com/features/1999/07/bill.joy.html
http://www.sun.com/executives/perspectives/joy.htm l

The False CNet Bill Joy has a chin butt, piercing eyes and no glasses, while the 3 above URL's show the real Bill Joy with _no_ chin butt , no piercing eyes and all 3 of them with glasses. Did some fake dude show up at CNet's, faking as Bill Joy (commiting identity theft) and possibly tell some false rumours?

Robert

dear reader the gnome armageddon has started,

first of all i want to clarify that this text was meant to be a source of information otherwise i wouldn't have spent so much time into writing it. belive me it took me a couple of days writing this text in a foreign language. even if you don't care at all for gnome, you may find some interesting information within this text that you like to read. please try to understand my points even if it's hard sometimes, otherwise you wake up one day and feel the need to switch to a different operating system.

on the following lines i'm trying to give you a little insight of the gnome community. the things that are going on in the back, the information that could be worth talking and thinking about.

many of us like the gnome desktop and some of us were following it since the beginning. gnome is a promising project because it's mostly written in C, easy to use, configurable and therefore fits perfectly into the philosophy of u*nix. only to name some of its advantages.

unfortunately these advantages changed with the recently new released version of gnome. the core development team somehow got the idea of targeting gnome to a complete different direction of users. the so called corporate desktop user. in other words they're targeting people that aren't familiar or experienced with desktop environments. usually business oriented people who are willing to pay money for getting gnome on their computers.

having this new target in mind, the core development team mostly under contract by companies like redhat, ximian and sun decided to simplify the desktop as much as even possible by removing all its flexibility in favor of an easy clean simple interface to not confuse their new possible customers. so far the idea of a clean easy to use desktop is honourable.

some of the new ideas, features and implementations such as gconf, an evil windows registry like system, new ordering of buttons and dialogs, the removal of 90%-95% of all visible preferences from the control center and applications, the new direction that gnome leads and the attitude of the core development team made a lot of users really unhappy. these are only a couple of examples and the list can easily be expanded but for now this is enough. now let me try to get deeper into these aspects.

you may imagine that users got really frustrated because their beloved gnome desktop matured into something they didn't want. during the time, the frustration of a not less amount of people increased. more, more and more emails arrived on the gnome mailinglists where users tried to explain their concerns, frustrations and the leading target of GNOME.

but the core development team of gnome don't give a damn about what their users are thinking or wanting and most of the time they come up with their standard purl. the reply they give is mostly the same. users should either go and 'file a bug' at bugzilla or the user mails are being turned so far that at the end they sound like being trolls or the user feedback is simply not wanted. whatever happens the answers aren't really satisfying for the user. even constructive feedback isn't appreciated.

if you gonna think about this for a minute then things gonna harden that they are directing into the commercial area. the core development team actually don't care fo

dear reader the gnome armageddon has started,

first of all i want to clarify that this text was meant to be a source of information otherwise i wouldn't have spent so much time into writing it. belive me it took me a couple of days writing this text in a foreign language. even if you don't care at all for gnome, you may find some interesting information within this text that you like to read. please try to understand my points even if it's hard sometimes, otherwise you wake up one day and feel the need to switch to a different operating system.

on the following lines i'm trying to give you a little insight of the gnome [gnome.org] community. the things that are going on in the back, the information that could be worth talking and thinking about.

many of us like the gnome desktop and some of us were following it since the beginning. gnome is a promising project because it's mostly written in C, easy to use, configurable and therefore fits perfectly into the philosophy of u*nix. only to name some of its advantages.

unfortunately these advantages changed with the recently new released version of gnome. the core development team somehow got the idea of targeting gnome to a complete different direction of users. the so called corporate desktop user. in other words they're targeting people that aren't familiar or experienced with desktop environments. usually business oriented people who are willing to pay money for getting gnome on their computers.

having this new target in mind, the core development team mostly under contract by companies like redhat [redhat.com], ximian [ximian.com] and sun [sun.com] decided to simplify the desktop as much as even possible by removing all its flexibility in favor of an easy clean simple interface to not confuse their new possible customers. so far the idea of a clean easy to use desktop is honourable.

some of the new ideas, features and implementations such as gconf [gnome.org], an evil windows registry like system, new ordering of buttons and dialogs, the removal of 90%-95% of all visible preferences from the control center and applications, the new direction that gnome leads and the attitude of the core development team made a lot of users really unhappy. these are only a couple of examples and the list can easily be expanded but for now this is enough. now let me try to get deeper into these aspects.

you may imagine that users got really frustrated [osnews.com] because their beloved gnome desktop matured into something they didn't want. during the time, the frustration of a not less amount of people increased. more [gnome.org], more [gnome.org] and more [gnome.org] emails arrived on the gnome mailinglists where users tried to explain their concerns, frustrations and the leading target of GNOME.

but the core development team of gnome don't give a damn about what their users are thinking or wanting and most of the time they come up with their standard purl. the reply they give is mostly the same. users should either go and 'file a bug' at bugzilla [gnome.org] or the user mails are being turned so far that at the end they sound like being trolls or the user feedback is simply not wanted. whatever happens the answers aren't really satisfying for the user. even constructive feedback [gnome.org] isn't appreciated.

if you gonna think about this for a minute then things gonna harden that they are dir

I don't know, I think the picture on Sun's site is also...pretty carefully selected, if what you say is true.

when a local university hired Sun Microsystems to do an evaluation on server consolidation. You'll never guess what they suggested. Buy an E15K. This was after the university had major failures with an already implemented E10K. FWIW, I think that suggestion is still being considered. Sun also suggested that the university switch to iPlanet for their LDAP directory. I still think that some people at the university thought that Sun might actually suggest another companies product.

Take a look at this and look at the bottom, the second to last link in the 'See Also' section, and then look at the 'last updated' date.

Interesting, isn't it? ;)

The benefits from the memory subsystem will be offset by the fact that objects containing pointers will be twice as big as on IA32. That means objects could have twice the cache footprint and twice the memory bandwith requirements.

I thought I remembered SPARC being able to do this, but it looks like SPARC programs must be compiled with 64 bit pointers to efficiently perform 64 bit arithmetic.

There you are. You cannot modify and distribute, so open source it ain't. But hey, it's better than nothing.

Yes, Java has evolved. It started as one platform and has kinda-sorta branched out into 3 spaces: small, medium and large. The "large" spec, for use on "large" server-type computers, is J2EE. The whole J2EE spec is online, and free to anybody who feels like implementing it. It takes time and energy to have Sun "certify" that it meets the spec, and so they charge to become certified, but JBoss did just fine without for a good long time. True, Applets are passe now, (partially/mostly because of the shitty JVM's that came stock in IE for so long) but Java is not going anywhere for a long time to come.

C# is one programming language I've stayed away from--and for no particular reason. I had picked up the C# specification [PDF] in 2000, but never really got down to the canonical "hello world" program. Today in 2003, as I look back, I guess I haven't missed much.

Let's go back to August 2000 and revisit Hejlsberg's famous O'Reilly interview by Josh Osborn.

Why are there no enums in Java, for example? I mean, what's the rationale for cutting those?

And Java has enums now, just like they come in C#.

one of our key design goals was to make the C# language component-oriented

I think this was really nice, and fitted in well with Microsoft's COM framework. I remember COM enthusiasts mentioning how every C# object would automatically be a COM object, thereby eliminating all that old school drudgery.

C# is the first language to incorporate XML comment tags that can be used by the compiler to generate readable documentation directly from source code.

Python and Java have docstrings (or javadoc) as part of the language.

Developers are building software components these days. They're not building monolithic applications or monolithic class libraries.

Developers are building all sorts of stuff, and not just "components". I think that statement is overrated.

Boxing allows the value of any value type to be converted to an object, while unboxing allows the value of an object to be converted to a simple value type.

Thanks, now Java has it too!

Unsafe code allows you to write inline C code with pointers, to do unsafe casts, and to pin down memory so it won't accidentally be garbage-collected. [...] The real difference is that it's still running within the managed space. The methods you write still have descriptive tables that tell you which objects are live, so you don't have to go across a marshalling boundary whenever you go into this code. Otherwise, when you go out to undescriptive, unmanaged code (like through the Java Native Interface, for example), you have to set a watermark or erect a barrier on the stack.

Honestly, I didn't understand the stuff about "unsafe code", the implementation of IL, and the implementation of generics. Just for comparison sake, Python also has a scheme for inlining C and C++ code.

Let's face it, some people like to program in COBOL, some people like to program in Basic, some like C++, and some will like C#, I hope. But we're not trying to tell you to forget everything you ever did.

I've raised this point to Java bigots on several occasions. It's just too difficult (and sometimes impossible) to interface Java with other languages. (In this context,

C# is one programming language I've stayed away from--and for no particular reason. I had picked up the C# specification [PDF] in 2000, but never really got down to the canonical "hello world" program. Today in 2003, as I look back, I guess I haven't missed much.

Let's go back to August 2000 and revisit Hejlsberg's famous O'Reilly interview by Josh Osborn.

Why are there no enums in Java, for example? I mean, what's the rationale for cutting those?

And Java has enums now, just like they come in C#.

one of our key design goals was to make the C# language component-oriented

I think this was really nice, and fitted in well with Microsoft's COM framework. I remember COM enthusiasts mentioning how every C# object would automatically be a COM object, thereby eliminating all that old school drudgery.

C# is the first language to incorporate XML comment tags that can be used by the compiler to generate readable documentation directly from source code.

Python and Java have docstrings (or javadoc) as part of the language.

Developers are building software components these days. They're not building monolithic applications or monolithic class libraries.

Developers are building all sorts of stuff, and not just "components". I think that statement is overrated.

Boxing allows the value of any value type to be converted to an object, while unboxing allows the value of an object to be converted to a simple value type.

Thanks, now Java has it too!

Unsafe code allows you to write inline C code with pointers, to do unsafe casts, and to pin down memory so it won't accidentally be garbage-collected. [...] The real difference is that it's still running within the managed space. The methods you write still have descriptive tables that tell you which objects are live, so you don't have to go across a marshalling boundary whenever you go into this code. Otherwise, when you go out to undescriptive, unmanaged code (like through the Java Native Interface, for example), you have to set a watermark or erect a barrier on the stack.

Honestly, I didn't understand the stuff about "unsafe code", the implementation of IL, and the implementation of generics. Just for comparison sake, Python also has a scheme for inlining C and C++ code.

Let's face it, some people like to program in COBOL, some people like to program in Basic, some like C++, and some will like C#, I hope. But we're not trying to tell you to forget everything you ever did.

I've raised this point to Java bigots on several occasions. It's just too difficult (and sometimes impossible) to interface Java with other languages. (In this context,

• JSR 014 public spec.
• A discussion with Josh Bloch with examples.

• JSR 014 public spec.
• A discussion with Josh Bloch with examples.

Only a fool would be short-sighted enough to not to see the danger of using (supporting) Microsoft protocols, especially over the Internet.

In the Halloween Document, a Microsoft strategist wrote:

> OSS projects have been able to gain a foothold in many server applications because of the wide utility of highly commoditized, simple protocols. By extending these protocols and developing new protocols, we can deny OSS projects entry into the market.

Or consider this evidence in the Java case:

> Microsoft's Executive Vice President, Paul Maritz, outlined Microsoft's strategy to win the browser war with Netscape and simultaneously "neutralize Java" by "tying" the "user interface" and "APIs" "back to Windows,"

This quote also shows us how Microsoft operates:

> at this point its [sic] not good to create MORE noise around our win32 java classes. Instead we should just quietly grow j++ share and assume that people will take advantage of our classes without ever realizing they are building win32-only java apps."

And then there's this little gem:

> "Subversion has always been our best tactic," John Ludwig, Microsoft's vice president in charge of Java development, wrote. "It leaves the competition confused, and they don't know what to shoot at anymore."

Perhaps this quote sums it up the best:

> "This is really the core of Microsoft's business," Gartner Research Director Chris LeTocq said. "Microsoft is in business to leverage APIs. That's a key element of the successful market share it has."

If you haven't understood the point, then here it is...

If you continue to accept the ASF format, then you are encouraging websites to use it.

But it's still a protocol that is controlled by Microsoft.

In the future, Microsoft will:

1. Upgrade ASF to an incompatible format.

2. Start enforcing their ownership of ASF by restricting its use to Microsoft platforms (as GIFs started to be enforced).

3. Lock up ASF using Microsoft .Net and DRM protocols.

And the websites that are using ASF will go along blindly. Why? Because no one has been complaining to them about their use of ASF, so they have no reason to avoid Microsoft's "improvements."

And at that point, the content of those websites will become unavailable to you unless you are running Windows XP.

It really annoys me when people fail to protect themselves, and everyone else, because they are too lazy or short-sighted to put up with a little temporary inconvenience. Are you hoping that someone else will do the work of protecting your freedom? Well, don't.

It's up to you. If you want the Internet to remain free, then stop supporting Microsoft protocols.

Maybe I'm being too fussy about this, but a code generator, traditionally has always meant a part of the compiler back-end which actually translates intermediate code to machine-level instructions.
I think you're being too fussy. Anything that generates code can reasonably be called a code generator. You are just most familiar with the backends of compilers.

Code generation can allow a developer to compensate for missing abstractions in the underlying language or architecture. For example, it's almost trivial to write generator for a Java type-safe enum class with a couple of pages of java tied to a Velocity template for an enum. You just have to be sure that your build process regenerates the class if your input changes. The input could be something as simple as
color {red, green, blue}

It's then easy to add features to your enum infrastructure that aren't in Bloch's class and have them show up in all the project enums (like correct serialization and localization).

The GUI builders that spit out code fragments are just the tip of the iceberg when it comes to code generators. Imagine a utility that could generate the plumbing to make EJB or RMI methods directly accessable from a Windows DCOM client, without it knowing or caring that it's talking to Java on the other end.

Or automatically generating classes for Customer, Order, and Product from an existing database table, and seamlessly loading, caching and saving their instance data without the application knowing or caring that it is persistent.

Automating this sort of tedious programming is what code generation is all about.

OpenFirmware

In the beginning...Sun made AWT and it was very low level hardward/OS linked.

Then came Swing, which was more abstract, higher level, and less hardware specific, with more functionality in some areas and less in others.

Then came SWT, which came about to increase speed by moving closer to the lower level APIs, to avoid lots of bloat, to be closer to host OS look and feel, and once again more hardware/OS specific and this was good..

There are always differences, and more differences

---
Sun doesn't plan on abandoning its development all together (see Project Rave) I beleive it is suppose to be a new IDE implementation, but still based on Netbean foundation.

New Java Specification Request also include a common java ide plugin standardization, so this may be another reason they are doing some of this.

However, it is still a klunky interface to the problem, notably that (a) there are disparate levels of quality across sites and indexability (if that's even a word) and (b) sites can come and go. What the submitter wants is a site where people can dump their experiences for others to find, the idea being that through time, a catalogue of problems & solutions is generated.

Meanwhile, IBM has quietly pushed Eclipse. I keep getting the impression that IBM understands both the two relevent cultures (Java developers and open-source people) a lot better than Sun.

It's nice to have a native binary for another platform and all, but it couldn't have been too much work to just repackage a binary they already have.
Product packaging as debs for Debian linux (link to Java bug db)

Do you want to give us a simple take-home message for each of the six areas of improvement?

I'll give it a whirl...

Generics - Provides compile-time type safety for collections and eliminates the drudgery of casting.

Enhanced for loop - Eliminates the drudgery and error-proneness of iterators.

Autoboxing/unboxing - Eliminates the drudgery of manual conversion between primitive types (such as int) and wrapper types (such as Integer).

Typesafe enums - Provides all the well-known benefits of the Typesafe Enum pattern (Effective Java, Item 21) without the verbosity and the error-proneness.

Static import - Lets you avoid qualifying static members with class names, without the shortcomings of the Constant Interface antipattern (Effective Java, Item 17).

Metadata - Lets you avoid writing boilerplate code, by enabling tools to generate it from annotations in the source code. This leads to a "declarative" programming style where the programmer says what should be done and tools emit the code to do it.

It's unbelievable that someone who knows something of embedded systems would post this kind of vitriol without posting benchmarks or, at the very least, performing a google search first. It's also disturbing that the myth about Java's slowness is still stuck in people's heads. Java's bytecode certainly does not execute as fast as native code, but making a blanket statement about the poor performance of every JRE and Java program is absurd. See this 2 year old article: Embedded Java

Embedded Java is a very big thing; please see:

Javas Consumer and Embedded Technologies
Key Embedded Java Standards
EMBEDDED SYSTEMS GO REAL TIME WITH JAVA TECHNOLOGY
Using Java Technology to Standardize Real-Time Development

Learn C. It's pretty similar to Java...

Well, sort of. Java does share some of its syntax with C, so it will look familiar to a C programmer, but this is an oversimplification. Java has no preprocessor, global variables, pointers, goto statement, struct type, union type, enumerated types, bitfields, typedef, function pointers, or variable-length argument lists. Java has well-defined primitive type sizes, where in C it is dependent on the platform. Java has objects and method overloading, where C does not. Java has garbage collection, where in C you have to roll your own. In Java you can declare variables anywhere, but in C you cannot. Finally, Java has no need of forward references. Your toolchain is also completely different - not just your compiler, everything. In addition, the programming methodologies you use with Java are entirely different from those you use in C. If you want to move from C to Java and still program effectively, you have to learn a completely different way of thinking.

Remember that you are going to be controlling things, not drawing widgets on a screen, so an OO language is not really necessary (or even desirable).

I'm curious, why do you say that OO isn't desirable? I can see that it may not be desirable on a system that has existing APIs written in C, but for new systems, why is this a poor choice? From personal experience, I have encountered a system whose flagrant abuse of structs and function pointers was enough to make a sane man weep. OOP would have really helped to make this more understandable and compact. I've also heard some arguments that object-orientated (Java, C++) and procedural languages (C) are both poor choices for embedded systems, and the best paradigm to use is a logic or declarative programming language.

Instead, you will be reading and writing IO ports, which will involve a certain amount of bare metal programming. Java won't really let you do this.

Again, sort of. Usually, any system that supports Java is going to provide Java layer drivers for its hardware, just like any system that supports C is going to have C APIs. There are some good processors specifically designed to run Java programs in an embedded environment that provide Java access to the HW layer. In addition, any J2ME system has standardized ways of accessing the hardware that most J2ME users will use. Please see the following:

Dallas Semiconductor TINI
Imsys SNAP
J2ME

If there is still some piece of hardware that you don't have a Java API for, you c

It's unbelievable that someone who knows something of embedded systems would post this kind of vitriol without posting benchmarks or, at the very least, performing a google search first. It's also disturbing that the myth about Java's slowness is still stuck in people's heads. Java's bytecode certainly does not execute as fast as native code, but making a blanket statement about the poor performance of every JRE and Java program is absurd. See this 2 year old article: Embedded Java

Embedded Java is a very big thing; please see:

Javas Consumer and Embedded Technologies
Key Embedded Java Standards
EMBEDDED SYSTEMS GO REAL TIME WITH JAVA TECHNOLOGY
Using Java Technology to Standardize Real-Time Development

Learn C. It's pretty similar to Java...

Well, sort of. Java does share some of its syntax with C, so it will look familiar to a C programmer, but this is an oversimplification. Java has no preprocessor, global variables, pointers, goto statement, struct type, union type, enumerated types, bitfields, typedef, function pointers, or variable-length argument lists. Java has well-defined primitive type sizes, where in C it is dependent on the platform. Java has objects and method overloading, where C does not. Java has garbage collection, where in C you have to roll your own. In Java you can declare variables anywhere, but in C you cannot. Finally, Java has no need of forward references. Your toolchain is also completely different - not just your compiler, everything. In addition, the programming methodologies you use with Java are entirely different from those you use in C. If you want to move from C to Java and still program effectively, you have to learn a completely different way of thinking.

Remember that you are going to be controlling things, not drawing widgets on a screen, so an OO language is not really necessary (or even desirable).

I'm curious, why do you say that OO isn't desirable? I can see that it may not be desirable on a system that has existing APIs written in C, but for new systems, why is this a poor choice? From personal experience, I have encountered a system whose flagrant abuse of structs and function pointers was enough to make a sane man weep. OOP would have really helped to make this more understandable and compact. I've also heard some arguments that object-orientated (Java, C++) and procedural languages (C) are both poor choices for embedded systems, and the best paradigm to use is a logic or declarative programming language.

Instead, you will be reading and writing IO ports, which will involve a certain amount of bare metal programming. Java won't really let you do this.

Again, sort of. Usually, any system that supports Java is going to provide Java layer drivers for its hardware, just like any system that supports C is going to have C APIs. There are some good processors specifically designed to run Java programs in an embedded environment that provide Java access to the HW layer. In addition, any J2ME system has standardized ways of accessing the hardware that most J2ME users will use. Please see the following:

Dallas Semiconductor TINI
Imsys SNAP
J2ME

If there is still some piece of hardware that you don't have a Java API for, you c

It's unbelievable that someone who knows something of embedded systems would post this kind of vitriol without posting benchmarks or, at the very least, performing a google search first. It's also disturbing that the myth about Java's slowness is still stuck in people's heads. Java's bytecode certainly does not execute as fast as native code, but making a blanket statement about the poor performance of every JRE and Java program is absurd. See this 2 year old article: Embedded Java

Embedded Java is a very big thing; please see:

Javas Consumer and Embedded Technologies
Key Embedded Java Standards
EMBEDDED SYSTEMS GO REAL TIME WITH JAVA TECHNOLOGY
Using Java Technology to Standardize Real-Time Development

Learn C. It's pretty similar to Java...

Well, sort of. Java does share some of its syntax with C, so it will look familiar to a C programmer, but this is an oversimplification. Java has no preprocessor, global variables, pointers, goto statement, struct type, union type, enumerated types, bitfields, typedef, function pointers, or variable-length argument lists. Java has well-defined primitive type sizes, where in C it is dependent on the platform. Java has objects and method overloading, where C does not. Java has garbage collection, where in C you have to roll your own. In Java you can declare variables anywhere, but in C you cannot. Finally, Java has no need of forward references. Your toolchain is also completely different - not just your compiler, everything. In addition, the programming methodologies you use with Java are entirely different from those you use in C. If you want to move from C to Java and still program effectively, you have to learn a completely different way of thinking.

Remember that you are going to be controlling things, not drawing widgets on a screen, so an OO language is not really necessary (or even desirable).

I'm curious, why do you say that OO isn't desirable? I can see that it may not be desirable on a system that has existing APIs written in C, but for new systems, why is this a poor choice? From personal experience, I have encountered a system whose flagrant abuse of structs and function pointers was enough to make a sane man weep. OOP would have really helped to make this more understandable and compact. I've also heard some arguments that object-orientated (Java, C++) and procedural languages (C) are both poor choices for embedded systems, and the best paradigm to use is a logic or declarative programming language.

Instead, you will be reading and writing IO ports, which will involve a certain amount of bare metal programming. Java won't really let you do this.

Again, sort of. Usually, any system that supports Java is going to provide Java layer drivers for its hardware, just like any system that supports C is going to have C APIs. There are some good processors specifically designed to run Java programs in an embedded environment that provide Java access to the HW layer. In addition, any J2ME system has standardized ways of accessing the hardware that most J2ME users will use. Please see the following:

Dallas Semiconductor TINI
Imsys SNAP
J2ME

If there is still some piece of hardware that you don't have a Java API for, you c

It's unbelievable that someone who knows something of embedded systems would post this kind of vitriol without posting benchmarks or, at the very least, performing a google search first. It's also disturbing that the myth about Java's slowness is still stuck in people's heads. Java's bytecode certainly does not execute as fast as native code, but making a blanket statement about the poor performance of every JRE and Java program is absurd. See this 2 year old article: Embedded Java

Embedded Java is a very big thing; please see:

Javas Consumer and Embedded Technologies
Key Embedded Java Standards
EMBEDDED SYSTEMS GO REAL TIME WITH JAVA TECHNOLOGY
Using Java Technology to Standardize Real-Time Development

Learn C. It's pretty similar to Java...

Well, sort of. Java does share some of its syntax with C, so it will look familiar to a C programmer, but this is an oversimplification. Java has no preprocessor, global variables, pointers, goto statement, struct type, union type, enumerated types, bitfields, typedef, function pointers, or variable-length argument lists. Java has well-defined primitive type sizes, where in C it is dependent on the platform. Java has objects and method overloading, where C does not. Java has garbage collection, where in C you have to roll your own. In Java you can declare variables anywhere, but in C you cannot. Finally, Java has no need of forward references. Your toolchain is also completely different - not just your compiler, everything. In addition, the programming methodologies you use with Java are entirely different from those you use in C. If you want to move from C to Java and still program effectively, you have to learn a completely different way of thinking.

Remember that you are going to be controlling things, not drawing widgets on a screen, so an OO language is not really necessary (or even desirable).

I'm curious, why do you say that OO isn't desirable? I can see that it may not be desirable on a system that has existing APIs written in C, but for new systems, why is this a poor choice? From personal experience, I have encountered a system whose flagrant abuse of structs and function pointers was enough to make a sane man weep. OOP would have really helped to make this more understandable and compact. I've also heard some arguments that object-orientated (Java, C++) and procedural languages (C) are both poor choices for embedded systems, and the best paradigm to use is a logic or declarative programming language.

Instead, you will be reading and writing IO ports, which will involve a certain amount of bare metal programming. Java won't really let you do this.

Again, sort of. Usually, any system that supports Java is going to provide Java layer drivers for its hardware, just like any system that supports C is going to have C APIs. There are some good processors specifically designed to run Java programs in an embedded environment that provide Java access to the HW layer. In addition, any J2ME system has standardized ways of accessing the hardware that most J2ME users will use. Please see the following:

Dallas Semiconductor TINI
Imsys SNAP
J2ME

If there is still some piece of hardware that you don't have a Java API for, you c

Your phone probably supports J2Me, so you might be able to write code in java and upload it to the phone. Check out http://java.sun.com/j2me/. I'm not sure how much of the cell's functionality is exposed to the jvm. But if you can get to the Camera and do IP you should be set.

Lazy? How the f*** is a 40-something year-old man supporting a family, paying a mortgage, making car payments, putting kids through college, etc., supposed to "find another line of work"? Is he supposed to sell his house, move into a dorm, and have his family live in an RV at Walmart while he attends the local college? Momma's boys like you make me sick. Grow up.
Sounds like something H1-B Microsystems or similar pulled off

Well, obviously you havent dealt with the lower quality, someone like H1-B Microsystems or other companies that have screwed over the consumer or high-caliber employees through imported workers. Eventually, the people who outsourced will end up wasting money trying to clean up what mistakes that their international outsourcing did - versus those who saved their money by staying domestic.

(ii) The following additional restrictions apply if you use the SOFTWARE other than solely for internal business purposes. (For applicable licensing terms for all such uses of the SOFTWARE, please contact Microsoft Corporation at (206) 703-4515.) (1) You may commercially distribute the SOFTWARE only in conjunction with and as part of your software product to which you have added significant and primary functionality and value. (2) Unless your software product requires your customer to license Microsoft Office for Windows, or a component of it, in order to operate, you may not reproduce or use the SOFTWARE for commercial distribution in conjunction with a general purpose word processing [no competing with Word], spreadsheet [or Excel], or database software product [Access, ditto], or an integrated work or product suite [like Office] whose components include a general purpose word processing, spreadsheet, or database management software product except for the exclusive purpose of importing or exporting data to the various formats supported by the SOFTWARE and included in your application (e.g., reading data from and writing data to a single data source at one time). Note: a product which includes limited word processing, spreadsheet, or database components along with other components that provide significant and primary value, such as an accounting product with limited spreadsheet capability, is not considered to be a "general purpose" product.

Great... Just what we need, processors that can perform an instruction, then wait 40000 cycles for the next instruction to be read from memory. I wish we could see some memory improvements to go along with these.

Sun is working on something along those lines, check it out

You mean a system like a Sun Ray 150 thin client?

Sun gives away a lot of its softwar to students, for free.

And MIT is certainly not the Microsoft Institute of Technology. The Harvard-MIT Data Center is an all Java project, whose faculty are contributors to some of the Apache Jakarta open source projects.

dear reader the gnome armageddon has started,

first of all i want to clarify that this text was meant to be a source of information otherwise i wouldn't have spent so much time into writing it. belive me it took me a couple of days writing this text in a foreign language. even if you don't care at all for gnome, you may find some interesting information within this text that you like to read. please try to understand my points even if it's hard sometimes, otherwise you wake up one day and feel the need to switch to a different operating system.

on the following lines i'm trying to give you a little insight of the gnome community. the things that are going on in the back, the information that could be worth talking and thinking about.

many of us like the gnome desktop and some of us were following it since the beginning. gnome is a promising project because it's mostly written in C, easy to use, configurable and therefore fits perfectly into the philosophy of u*nix. only to name some of its advantages.

unfortunately these advantages changed with the recently new released version of gnome. the core development team somehow got the idea of targeting gnome to a complete different direction of users. the so called corporate desktop user. in other words they're targeting people that aren't familiar or experienced with desktop environments. usually business oriented people who are willing to pay money for getting gnome on their computers.

having this new target in mind, the core development team mostly under contract by companies like redhat, ximian and sun decided to simplify the desktop as much as even possible by removing all its flexibility in favor of an easy clean simple interface to not confuse their new possible customers. so far the idea of a clean easy to use desktop is honourable.

some of the new ideas, features and implementations such as gconf, an evil windows registry like system, new ordering of buttons and dialogs, the removal of 90%-95% of all visible preferences from the control center and applications, the new direction that gnome leads and the attitude of the core development team made a lot of users really unhappy. these are only a couple of examples and the list can easily be expanded but for now this is enough. now let me try to get deeper into these aspects.

you may imagine that users got really frustrated because their beloved gnome desktop matured into something they didn't want. during the time, the frustration of a not less amount of people increased. more, more and more emails arrived on the gnome mailinglists where users tried to explain their concerns, frustrations and the leading target of GNOME.

but the core development team of gnome don't give a damn about what their users are thinking or wanting and most of the time they come up with their standard purl. the reply they give is mostly the same. users should either go and 'file a bug' at bugzilla or the user mails are being turned so far that at the end they sound like being trolls or the user feedback is simply not wanted. whatever happens the answers aren't really satisfying for the user. even constructive feedback isn't appreciated.

if you gonna think about this for a minute then things gonna harden that they are directing into the commercial area. the core development team actually don't care fo

Where have you been? I've had a 64-bit machine for almost 5 years now. ;) It's even been EOLed since July 2002.

Hello, if you visit this site you might learn a little bit about Open Firmware... especially the Open part