JavaBeans is the component model for Java. Java - coffee. Beans - coffee beans. Isn't it cute?
Enterprise JavaBeans is the *enterprise* component model for Java.
There, that was fairly painless, yes?
As for your comments on IniCaps not conforming to itself, it's used to describe the process of capitalising new words (short for initial capitals) - both the variable and class name conventions can be described as IniCaps.
And you wouldn't want to be an IBM shop in that sort of situation: firstly you've got to be able to sell to people who don't have a 100% IBM infrastructure, and secondly it's not always the right tool for the job. I'm just saying that there are extra features available with the commercial tools and that JBoss isn't currently a complete replacement for them. It's concentrating on its core functionality, and as far as I'm concerned (from a selfish point of view) that's great - it fits perfectly with what I want to use it for.
I think we can at least agree that typical method and variable names in typical Java programs are longer (and therefore more subject to typos) than most programs. It is my opinion that in the general case there is little (if any) useful information embedded in this baggage.
That's the general style, yes: meaningful method and variable names. If you prefer to take other approaches in your own code then there's nothing stopping you from doing so.
I don't, however, expect 20+ character labels with "funny" caps.
You're confusing 'funny' caps with a well-defined style for capitalisation. Java variable names, if you're following Sun's style guide, begin with a lower case letter, and new words are identified with a capital letter, an approach sometimes referred to as IniCaps. Method names use the same style, class names the same but with an initial capital letter. Once you're used to that style, it makes perfect sense, and you're a lot less likely to drop caps. It's preferable to some of the overly abbreviated variable names you get in some C code as far as I'm concerned - particularly for maintenance purposes. I know what the variable userCount contains, or can make a good guess. I have no idea what nusr means.
It's all down to style, of course. There's no reason a C program couldn't be the one with a variable userCount and a Java program the one with nusr, and I've seen both.
Anyway, this is pretty far off of my core complaint, which is that Java seems to be more about buzwords and barriers to entry than about technology.
It's true of all languages that until you know the jargon, you will find it confusing. That's the case with Java to the same extent as other languages.
I do have one more question: is there an assembler for the JVM?
A somewhat unhelpful answer here: yes, but I don't know where you'd go to find it.
Okay, one more: is there some documentation for the JVM in terms of things like registers, service calls, etc.
True - I was oversimplifying horribly there.:) Just trying to separate the functionality in JBoss proper (EJB, but also, as you point out, JNDI, JMS, and other related services) from the Servlet/JSP functionality provided by external apps (Jetty/Tomcat) which are required for a full J2EE solution.
I disagree with you on virtually every front here: Java is far from perverse, and a lot of things you're criticising it for make sense if you think about them. Let's take it one point at a time:
Do I need the JRE and the JDK?
No. The JRE (Java Runtime Environment) is for running Java applications only. The JSDK (Java Software Developers Kit), also known as the JDK or occasionally by the more generic term SDK, provides the same functionality but also the ability to compile Java code.
And let's not even start on variable names like "The_Longest_Yet_Least_Descriptive_Method_Name_I n_The_World."
Let's not, unless we can give examples. Most Java variable names in Sun's own code are fairly self explanatory once you know the basic structure they're working in.
And don't dare drop the capital "t" in "the" in your call, or you'll get an error message in Sanskrit pointing to nine lines before your call. Oh, and you know what else is a great idea? Make everything sensitive to the freaking filenames of the source files.
Actually, in that case the compilation error would be on the line where the error occurred, as with most error reporting in Java programs.
As for case sensitivity, it's pretty much required for a platform-independent system that's going to be running on Unix-like systems.
(If you want to be really frightened, be aware that Java source code is actually UTF rather than ASCII, so you could create a file where all variables are called 'bob', just in different character sets...)
Bingo. IBM's offerings aren't just about the app server - that's actually a very small part of the Websphere family of products. It's the development tools, the extra features, the integration with other IBM back-end systems that make Websphere so attractive, not just the ability to run EJBs. If that's what appeals to you for a particular project, then JBoss can't come close to matching it right now.
That said, if you just want the basic J2EE functionality, you could do a lot worse than JBoss, for a lot more money.
I believe it's actually the same plugin for the IBM HTTP Server and Apache - the differences between them don't affect the interaction with WAS. There are also plug-ins for a range of other servers, including IIS, Netscape Enterprise Server, Domino, and Domino Go Webserver.
Re:What exactly is a Java application server?
on
JBoss Founder Interview
·
· Score: 5, Informative
Not strictly right, AIUI.
The Websphere application family is built up on several layers (described by IBM as the e-business application framework). The Foundation layer contains those tools that provide the fundamental low-level functionality of the system, and this basically comprises WAS and MQ Series.
On top of this you've got the Foundation Extension layer: tools for optimising the performance of the Foundation tools, and for development and deployment. Here you've got tools like VisualAge for Java, the personalization suite for Websphere, and Edge Server (used to be called the performance pack, IIRC, but clearly that didn't sound cool enough...)
Finally, over the top of this you have the Application Accelerator layer, consisting of tools for building particular types of application. That's where Commerce Suite lives, along with tools like the Websphere B2B Integrator.
JBoss itself corresponds to just part of the Websphere Application Server - it's really just an EJB server rather than a full J2EE server. However, combined with Tomcat (and you can download the two as a nicely integrated bundle from the JBoss site) you end up with something comparable in many ways with Websphere Application Server (advanced edition). In some ways it's better, in others it's worse. It's certainly more up-to-date - Websphere is (as with most IBM Java systems) a couple of versions behind the bleeding edge. That gives it the benefit of stability and reliability, but it gives JBoss the advantage in enhanced functionality (such as support for CMP2.0).
The PS2 is not the Saturn. The Saturn architecture was a bodge job based on last minute realisation that the competition was too powerful. The PS2 (for better or for worse) was designed that way, and some PS2 developers who have got to grips with the system are actually very happy with the flexibility the EE/VU0/VU1 combination offers.
Sony has the weakest System.
Sales in the USA are more important than Japan
Not really. Domestic sales are still important to the Japanese software developers, who are widely regarded as the most important in the console market.
PS2 cant keep up in the graphics department, cant keep up in the price department, or the games department with Nintendo.
Hardly. I don't know if you've been following Sony's first party development recently, but they've been churning out a lot of great and in some cases innovative stuff, including GT3, ICO, Ka, Wipeout Fusion, Jak & Daxter, Twisted Metal Black, Frequency, Parappa, Ape Escape, Sky Oddyssey, Wild Arms, Dropship, WRC, and plenty of others.
On the technical front, obviously Nintendo's machine is more powerful. Moore's Law pretty much dictates it. But when was the last time the most powerful console won the race? It didn't help the N64 against the PSX, did it?
Why? PS2 has games, but so do all the other systems.
But PS2 has a lot of exclusive games or games with a long delay before they release on other platforms that will sell systems. FFX, Devil May Cry, MGS2, GT3, GTA3, VF4, Silent Hill 2, State of Emergency to name a handful of them. Because of their position last generation, and their huge advantage in installed userbase this generation gives them a lot of sway with third parties.
Can't swear about American companies (Tronix is my normal shop for US game purchases, though), but you can pick up a Japanese unit pre-modded to play US and Japanese games from Lik-Sang in Hong Kong for a very reasonable price. I've bought from them before, and although some of the cheaper products they sell can be a little shoddy (I wouldn't trust their step down converters as far as I could throw them after one caused my import PS2 to start smoking) they've tended to be prompt and very good for better quality kit.
My personal approach has been to pick up the JP/US Gamecube from Lik-Sang, and the US software from Tronix, who are extremely prompt with delivery (took two days from US to UK by FedEx...)
This always angers me: AMULET was there first
on
Clockless Chips
·
· Score: 2
Whenever the question of asynchronous chip design comes up, everyone points out the Intel work in '97, but nobody mentions the work done by the AMULET group in Manchester. Set up in 1990 they produced the world's first asynchronous chip in 1994, based on the ARM chipset. By the time Intel got their act in order, the second generation AMULET2e had arrived, providing higher performance than a synchronous ARM chip for the same power input.
Insightful, but for the fact that Nintendo have always had a relaxed policy to release dates. This happened with the N64, for example, and I don't think they were exactly petrified about XBox then...
Q: Do you lie awake at night worrying that you'll be first again, but that someone else will make the money?
A: No [...] I often tell the story that Bill gates was trying to sell me MS-DOS in the early 80s and I had to say "Bill, we can't possibly take such a retrograde step, because our operating system really is an operating system and has many features that MS-DOS doesn't have. [...] schoolboy can type 'I am Johnny' into one of our computers and be logged on through the network to a local fileserver. They can use the same commands to get files down from the server that they've learned with a floppy disk." And Bill's answer to that was, "What's a network?"
Don't hold your breath. Emulating newer, more expensive hardware on older systems? If that were true, I'd be emulating my current PIII system on an old 286 rather than wasting the money upgrading.
Joking aside, the crash screen for XBox isn't the BSOD - it's a stylish green-tinted display which has obviously had a lot of work put into it, almost as if they expected it to be seen quite a lot...
Apologies - I meant previous to their current solution (Naomi 2) rather than the XBox/PS2-based solutions they're working with as well.
As for Naomi 2 vs home systems, it looks like accurate home conversions of Naomi 2 titles should be possible - the PS2 version of VF4 appears to be *better* than arcade perfect in some respects, and that's the weakest (oldest) of the home consoles this generation now that DC is bowing out.
Burning Rangers was a Saturn game, and probably the most underrated game on the platform IMHO. Well worth picking up if you can find it these days. Some really innovative ideas in there and great (for the time) fire effects.
I don't pretend to have my finger on the pulse of the arcade industry, but it seemed like an obvious development.
So obvious, in fact, that it's been going on for ages. The System 246 hardware that powers Tekken 4 and other Namco games is essentially a PS2. Sega's previous arcade hardware was essentially a Dreamcast. System 11 (or was it 12?) was a PSX in an arcade case. And so on.
1) Defining these as 'immense successes' is dubious to a certain extent. Sure, most of them were great games, but very few were commercial successes. Jet Grind Radio sold remarkably few units, NiGHTs was likewise a sales disaster (despite huge critical acclaim). The biggest sellers you list there are Virtua Fighter (the arcade hardware for VF4 is Naomi-based, and the home console conversion is targetted at PS2) and Sakura Taisen, which is squarely aimed at the Japanese audience.
2) You forgot Burning Rangers.
A Shining Force sequel for XBox would, of course, cement my purchase of the system.
Slashdot Mirror
JavaBeans is the component model for Java. Java - coffee. Beans - coffee beans. Isn't it cute?
Enterprise JavaBeans is the *enterprise* component model for Java.
There, that was fairly painless, yes?
As for your comments on IniCaps not conforming to itself, it's used to describe the process of capitalising new words (short for initial capitals) - both the variable and class name conventions can be described as IniCaps.
And you wouldn't want to be an IBM shop in that sort of situation: firstly you've got to be able to sell to people who don't have a 100% IBM infrastructure, and secondly it's not always the right tool for the job. I'm just saying that there are extra features available with the commercial tools and that JBoss isn't currently a complete replacement for them. It's concentrating on its core functionality, and as far as I'm concerned (from a selfish point of view) that's great - it fits perfectly with what I want to use it for.
That's the general style, yes: meaningful method and variable names. If you prefer to take other approaches in your own code then there's nothing stopping you from doing so.
You're confusing 'funny' caps with a well-defined style for capitalisation. Java variable names, if you're following Sun's style guide, begin with a lower case letter, and new words are identified with a capital letter, an approach sometimes referred to as IniCaps. Method names use the same style, class names the same but with an initial capital letter. Once you're used to that style, it makes perfect sense, and you're a lot less likely to drop caps. It's preferable to some of the overly abbreviated variable names you get in some C code as far as I'm concerned - particularly for maintenance purposes. I know what the variable userCount contains, or can make a good guess. I have no idea what nusr means.
It's all down to style, of course. There's no reason a C program couldn't be the one with a variable userCount and a Java program the one with nusr, and I've seen both.
It's true of all languages that until you know the jargon, you will find it confusing. That's the case with Java to the same extent as other languages.
A somewhat unhelpful answer here: yes, but I don't know where you'd go to find it.
I guess this is what you want.
True - I was oversimplifying horribly there. :) Just trying to separate the functionality in JBoss proper (EJB, but also, as you point out, JNDI, JMS, and other related services) from the Servlet/JSP functionality provided by external apps (Jetty/Tomcat) which are required for a full J2EE solution.
I disagree with you on virtually every front here: Java is far from perverse, and a lot of things you're criticising it for make sense if you think about them. Let's take it one point at a time:
No. The JRE (Java Runtime Environment) is for running Java applications only. The JSDK (Java Software Developers Kit), also known as the JDK or occasionally by the more generic term SDK, provides the same functionality but also the ability to compile Java code.
Let's not, unless we can give examples. Most Java variable names in Sun's own code are fairly self explanatory once you know the basic structure they're working in.
Actually, in that case the compilation error would be on the line where the error occurred, as with most error reporting in Java programs.
As for case sensitivity, it's pretty much required for a platform-independent system that's going to be running on Unix-like systems.
(If you want to be really frightened, be aware that Java source code is actually UTF rather than ASCII, so you could create a file where all variables are called 'bob', just in different character sets...)
Bingo. IBM's offerings aren't just about the app server - that's actually a very small part of the Websphere family of products. It's the development tools, the extra features, the integration with other IBM back-end systems that make Websphere so attractive, not just the ability to run EJBs. If that's what appeals to you for a particular project, then JBoss can't come close to matching it right now.
That said, if you just want the basic J2EE functionality, you could do a lot worse than JBoss, for a lot more money.
I believe it's actually the same plugin for the IBM HTTP Server and Apache - the differences between them don't affect the interaction with WAS. There are also plug-ins for a range of other servers, including IIS, Netscape Enterprise Server, Domino, and Domino Go Webserver.
Not strictly right, AIUI.
The Websphere application family is built up on several layers (described by IBM as the e-business application framework). The Foundation layer contains those tools that provide the fundamental low-level functionality of the system, and this basically comprises WAS and MQ Series.
On top of this you've got the Foundation Extension layer: tools for optimising the performance of the Foundation tools, and for development and deployment. Here you've got tools like VisualAge for Java, the personalization suite for Websphere, and Edge Server (used to be called the performance pack, IIRC, but clearly that didn't sound cool enough...)
Finally, over the top of this you have the Application Accelerator layer, consisting of tools for building particular types of application. That's where Commerce Suite lives, along with tools like the Websphere B2B Integrator.
JBoss itself corresponds to just part of the Websphere Application Server - it's really just an EJB server rather than a full J2EE server. However, combined with Tomcat (and you can download the two as a nicely integrated bundle from the JBoss site) you end up with something comparable in many ways with Websphere Application Server (advanced edition). In some ways it's better, in others it's worse. It's certainly more up-to-date - Websphere is (as with most IBM Java systems) a couple of versions behind the bleeding edge. That gives it the benefit of stability and reliability, but it gives JBoss the advantage in enhanced functionality (such as support for CMP2.0).
The PS2 is not the Saturn. The Saturn architecture was a bodge job based on last minute realisation that the competition was too powerful. The PS2 (for better or for worse) was designed that way, and some PS2 developers who have got to grips with the system are actually very happy with the flexibility the EE/VU0/VU1 combination offers.
Not really. Domestic sales are still important to the Japanese software developers, who are widely regarded as the most important in the console market.
Hardly. I don't know if you've been following Sony's first party development recently, but they've been churning out a lot of great and in some cases innovative stuff, including GT3, ICO, Ka, Wipeout Fusion, Jak & Daxter, Twisted Metal Black, Frequency, Parappa, Ape Escape, Sky Oddyssey, Wild Arms, Dropship, WRC, and plenty of others.
On the technical front, obviously Nintendo's machine is more powerful. Moore's Law pretty much dictates it. But when was the last time the most powerful console won the race? It didn't help the N64 against the PSX, did it?
But PS2 has a lot of exclusive games or games with a long delay before they release on other platforms that will sell systems. FFX, Devil May Cry, MGS2, GT3, GTA3, VF4, Silent Hill 2, State of Emergency to name a handful of them. Because of their position last generation, and their huge advantage in installed userbase this generation gives them a lot of sway with third parties.
Can't swear about American companies (Tronix is my normal shop for US game purchases, though), but you can pick up a Japanese unit pre-modded to play US and Japanese games from Lik-Sang in Hong Kong for a very reasonable price. I've bought from them before, and although some of the cheaper products they sell can be a little shoddy (I wouldn't trust their step down converters as far as I could throw them after one caused my import PS2 to start smoking) they've tended to be prompt and very good for better quality kit.
My personal approach has been to pick up the JP/US Gamecube from Lik-Sang, and the US software from Tronix, who are extremely prompt with delivery (took two days from US to UK by FedEx...)
Whenever the question of asynchronous chip design comes up, everyone points out the Intel work in '97, but nobody mentions the work done by the AMULET group in Manchester. Set up in 1990 they produced the world's first asynchronous chip in 1994, based on the ARM chipset. By the time Intel got their act in order, the second generation AMULET2e had arrived, providing higher performance than a synchronous ARM chip for the same power input.
Really? What's its score on Solitaire, then?
Insightful, but for the fact that Nintendo have always had a relaxed policy to release dates. This happened with the N64, for example, and I don't think they were exactly petrified about XBox then...
Play Ico on PS2. Play Shenmue II on Dreamcast/XBox. Play Luigi's Mansion on Gamecube.
If you can then say with a straight face that videogames aren't as much art as, say, the winners of the Turner prize, then there's no hope for you.
From an interview with Herman Hauser, of Acorn:
I get moderated up to 4 but this gets left as 0? Strange world. I vote for (Score: 5, Informative). :)
Don't hold your breath. Emulating newer, more expensive hardware on older systems? If that were true, I'd be emulating my current PIII system on an old 286 rather than wasting the money upgrading.
Joking aside, the crash screen for XBox isn't the BSOD - it's a stylish green-tinted display which has obviously had a lot of work put into it, almost as if they expected it to be seen quite a lot...
Over the hills and far away, Teletubbies come to hack!
Eh-oh!
Uh-ehn! Uh-ehn!
Time for tubby shutdown...
Uh-oh...
Apologies - I meant previous to their current solution (Naomi 2) rather than the XBox/PS2-based solutions they're working with as well.
As for Naomi 2 vs home systems, it looks like accurate home conversions of Naomi 2 titles should be possible - the PS2 version of VF4 appears to be *better* than arcade perfect in some respects, and that's the weakest (oldest) of the home consoles this generation now that DC is bowing out.
Burning Rangers was a Saturn game, and probably the most underrated game on the platform IMHO. Well worth picking up if you can find it these days. Some really innovative ideas in there and great (for the time) fire effects.
Sega is using
System 246 boards too.
Sony was there first.
So obvious, in fact, that it's been going on for ages. The System 246 hardware that powers Tekken 4 and other Namco games is essentially a PS2. Sega's previous arcade hardware was essentially a Dreamcast. System 11 (or was it 12?) was a PSX in an arcade case. And so on.
I'm no Sega fanboy, but hoorah for Cutriss.
Except for two things, of course.
1) Defining these as 'immense successes' is dubious to a certain extent. Sure, most of them were great games, but very few were commercial successes. Jet Grind Radio sold remarkably few units, NiGHTs was likewise a sales disaster (despite huge critical acclaim). The biggest sellers you list there are Virtua Fighter (the arcade hardware for VF4 is Naomi-based, and the home console conversion is targetted at PS2) and Sakura Taisen, which is squarely aimed at the Japanese audience.
2) You forgot Burning Rangers.
A Shining Force sequel for XBox would, of course, cement my purchase of the system.