Ditto. In fact, I recently bought a $10 soldering iron to fix a loose connection on my rabbit ears. Wii + Netflix + Antenna + DTV converter + CRT = just about anything I care to watch for $10/mo.
I hate that the launcher disappears whenever something is maximized. And I hate that the window title and the menu bar occupy the same space and have different functionality on mouse-over. This completely fails the grandpa test: I have no idea how I would ever walk my grandpa through a simple task over the phone when things are constantly shifting, disappearing, and changing depending on where the cursor is. Horrible interface.
What frustrates me about Unity is the same thing that frustrated me about Windows 7. Simple tasks take longer to accomplish. Take opening a terminal, for example. In Maverick I can click Applications -> Accessories -> Terminal, or click on the terminal icon I have on my panel. In Natty I have to either:
1. Right-click on the Applications icon and select "Accessories" 2. Click "See all" to expand the list 3. Scroll down a list of gigantic icons and find the terminal 4. Click on the terminal
Or:
1. Click on the Ubuntu icon 2. Type t-e-r-m 3. Click on the terminal
Or:
1. Left-click on the Applications menu in the launcher 2. Choose "Accessories" from the drop-down in the top-right 3. Click "See all" to expand the list 4. Scroll down a list of gigantic icons and find the terminal 5. Click on the terminal
None of these workflows are intuitive and they simply do not make sense. Yes, once I open the terminal I can pin it to the launcher, but this means that in order to prevent throwing my PC out of the window I have to pin virtually everything to the launcher. Then what good is the search/menu function that comprises the bulk of new functionality in Unity?
So let me get this straight. It's better for someone to take, for example, C, or Ruby, or PHP and implement roll their own implementations of:
1. Thread pool management 2. Load balancing and fail-over 3. Session replication 4. Distributed transaction management 5. Naming directory 6. EIS connection management 7. Pluggable authentication and authorization 8. HTTP request parsing and invocation 9. Tags and markup for data binding / AJAX support 10. UI component model 11. Logging 12. Web service management and deployment (including WSDL generation and publishing) 13. XML binding (marshaling and unmarshaling) 14. And so forth and so on
Now in this scenario the implementations will likely:
1. Only implement the functionality that is (perceived to be) needed 2. Will not be tested 3. Will not have the benefit of community scrutiny, certification, or knowledge 4. Will not be immediately understood by any developer other than the author(s) regardless of how much experience they have
Yes, you have to invest to learn JEE.
Yes JEE deals with complex issues and as a result is difficult to understand.
However, having invested that time, anyone who knows it in one place knows it everywhere. That is what saves time and money -- being able to hire someone who already knows JEE and have them hit the ground running.
Further, having a prescribed solution for many common problems allows developers to focus on the business needs, not the boilerplate.
Anyone who does not appreciate what JEE brings to the table is not a serious enterprise developer.
I've worked in many an enterprise and I have yet to use Spring for anything other than perhaps embedded unit testing of EJBs/JMS. And when it comes to that, I prefer OpenEJB anyway (although OpenEJB can be integrated with Spring if you absolutely have to).
Spring is to JEE as Struts is to JSF. It was an interesting precursor, but the improvements made in subsequent JDK releases have made it obsolete.
I'm haven't done a whole lot of reading on IPv6, so I was just curious whether the increased address space leads to any difference in how routing is done. It seems that with a unique public addresses and no NAT there would be more direct routes that could be taken, which would potentially mean more routers with the same address in their routing tables, which would mean more targets to check. Then, depending on congestion along various paths, one landmark may *seem* like the closest when in fact it simply has a fatter pipe going to the target.
And then, as another poster suggested, there is tunneling and all the other additional features in IPv6 , which would make it harder to do this.
Re:What problem does Gnome 3 solve?
on
GNOME 3 Released
·
· Score: 1
KDE didn't try to replace the desktop paradigm, and it was never their intent to eliminate configuration options. Every so often you look at your existing code base and think "X would be *so* much easier if this all got cleaned up" and after enough of that you refactor. When refactoring the first priority is to get the thing compiling and running minimally, and then re-implement functionality in order of criticality.
It took 6 minor releases, but KDE 4.6 now has feature parity with 3.5 (more or less) plus the advantage of a cleaner, more extensible code base and tons of new features. Bugs and crashes notwithstanding, KDE 4 isn't that different from Windows, Gnome, or its KDE predecessors.
You may not like Nepomuk and Akonadai, but at least you can turn them off. The KDE group has always had the philosophy that the user should be in control and should be able to tweak every aspect of the experience.
Now, with Gnome 3 we're being told that their way is better, and less is more. So not only are we back to a minimal set of configurability and flexibility, but it looks like it will stay that way.
I've been with Gnome for the last 3 releases of Ubuntu, and I plan to try Unity with Natty, but I don't expect to like Unity as much as I'll like Gnome 3 in FC 15 (when that comes out). If Gnome 3 doesn't work for me, then I'll go back to KDE (now that it's stable).
In a GUI, without dragging the system to its feet, with 10,000 line scrollback and copy/paste, as well as command history and editing, I will consider using a GUI.
Also:
cd smj
To get to "src/main/java/com/domain/package" takes about 2 seconds to type, and about 2 minutes to click on tiny little tree node icons and wait for the subtree to expand and the UI to refresh. Editing with vi takes way less time that messing with gedit or similar. (Granted, nothing in vi is CLI-specific, but it helps to have it instantly accessible within the CLI.)
SSH'ing to other systems is much faster in CLI, and gives you instant access to scp, etc.
I use a GUI where it makes sense (NetBeans manages just about everything I need for authoring and building code) but for deploying, starting, monitoring, and configuring applications there is nothing that beats CLI.
A good terminal emulator is like a good browser--the power and flexibility to go where you need to go and do what needs to be done, and a common framework (tabs, scrollback, etc.) to manage the viewing and input experience.
It's basically the same as AM2+. AM[n]+ means support for both AM[n] and AM[n + 1] processors. Although in this case it's a little different as the processor is not an "AM4" processor, but I guess that's okay since it looks like it will work in (some) AM3 socket chipsets (800-series).
As soon as Bulldozer hits I plan on getting a dirt-cheap Phenom II X6 to replace my Athlon II X4... which will go back my old motherboard to make a new system for my kids...
So a delayed upgrade, and still a 1:1 ratio of motherboard-to-CPU, but an upgrade nonetheless...
If I remember correctly the writing materials were not part of the public record and were to be destroyed. The public record consists of the testimony and other statements made in the courtroom and recorded by the court stenographer. I think the policy of collecting and/or destroying juror notes is probably to the benefit of both the juror and the court, as the may consist of doodles, conjecture, opinion, and other potentially embarrassing content.
When I served on a jury the bailiff collected our cell phones before the trial and gave them back afterward. They also provided all writing materials and collected them when the trial was over. Seems perfectly reasonable to me.
My point wasn't that you *can't* implement whatever methods you want, it's that it doesn't do any good. Consider a remote EJB. (Clustered EJBs have to be remote.) The client pulls down an Employee object by calling EmployeeSession.getEmployeById. The client then calls Employee.promote() on their local instance. Does that have the desired effect? No, the client must then call EmployeeSession.updateEmployee and pass in the modified object. What if employee.promote() has to update the employee's manager reference and then update the manager's subordinates collection? What if there are business rules that have to be observed that consider entities that exist outside of the normal scope of the employee and manager? What if there are interactions with other EIS?
At this point it makes more sense to have an EmployeeSession.fireEmployee() method that takes an employee ID. The implementation then loads the employee by ID (so that it is in the persistence context), performs whatever additional validations and logic are necessary, and then returns the modified Employee object.
Now consider that this may be a web service method. That being the case, all of the fields on Employee have to be readable and mutable, because XML does not care about data protection. In that scenario you absolutely cannot trust the client to submit a pristine/valid Employee object, so you have to go field by field and do validations *anyway*. In this scenario a EmployeeSession.fireEmployee method makes much more sense, as all the client supplies is a client ID, and there is no ambiguity as to whether the other fields may be updated.
I meant the classes themselves. For example, you're not supposed to use non-static private fields in a stateless session bean, message driven bean, servlets, etc. In the best case the field values will just be lost as the instance is discarded and the request handling thread returns to the pool; in the worst case you will have concurrent access to the same instance of the bean which leads to lost updates and race conditions on those fields. (The spec implies that concurrent access to a stateless bean is possible, but I've never seen a container implement them in this way. Usually a new instance is created for each thread.)
I've been noticing that Java is moving away from OOP. If you use EJB3 persistence (i.e. JPA), JAXB, JSF, WebBeans, or any number of recent technologies you'll find that:
- Business methods (stateless EJBs/web services, servlets, JSF components, entities, etc.) are stateless and non-thread-safe
- All data containers must adhere to the Java Bean specification; all mutable properties must either have a public setter method or the entire object must use field access
- Data objects are encumbered by persistence state, making complex operations on object graphs either costly (eager fetching) or perilous (lazy initialization exceptions, stale object state exceptions, etc.)
- Most, if not all, user state is managed in the HTTP session or client (in the case of a fat client)
The result is that business logic exists as a set of stateless functions (that happen to exist in a class) and that the date is a set of functionless state (all fields must be exposed so that the business methods and container can operate on them). So basically you have a set of functions in a class file that receive a set of data (entities or business keys), operate on it, and then return some other data that then is stored as a name/value pair in a session or a field on some Swing control.
This movement away from OOP has been driven largely by JEE and container-managed services, which are multi-threaded, clustered, and distributed. In order to do that efficiently, the programs have to separate data and logic.
There have been some attempts to "fix" this such as Seam, but the reality is that these solutions do not scale. They are good for hotel reservation apps, but not a 300 table enterprise OSS system.
So OOP is going the way of the Dodo, but the writing has been on the wall for some time. Java,.NET, and other technologies in the business of driving large scale enterprise applications are still very much relevant.
Is this just for merchants? Every time I make a transaction as a seller they bug me about linking to a checking account, but so far I've managed to avoid doing it. The day they require it is the day I stop using them altogether.
But the people who make the decision to use Oracle technologies (Oracle database, Oracle J2EE and all the other technologies) are usually not programmers, its PHBs who like the fact that some guy in a suit is saying good things about this "Oracle" thing and are duped into buying it (and the fact that in many cases there is no comparable alternative that is as good as the Oracle product unless you are willing to sign your soul to Microsoft or IBM)
In my experience this is not true. I happen to love Java as a language and a JEE because of its openness and support and innovation within the community. I choose JEE as a platform when developing large business applications because of the built-in support for the features I need -- clustering/failover, high availability JNDI, XA transaction support, messaging, connection pooling, servlets, AJAX, etc. Java also makes sense in many situations because the applications that are being integrated with are also JEE based, especially in the enterprise.
As far as I know, Java is also the only platform with freely available tools like Maven, Hudson (now Jenkins), JUnit, Sonar, FindBugs, etc. that automate dependency management, continuous build, and code analysis. (All of these are free, community-supported tools, by the way.)
In fact, for what I do, I can't think of a reason *not* to use Java. I've been in countless mergers, and every other company we've merged with had a Java shop.
The JEE stack I prefer is RedHat/JBoss, but I've used others, including Oracle. Oracle's is terrible, and one hopes that they will make use of Glassfish and NetBeans to improve their commercial offering. (I love NetBeans.) With Oracle's licensing terms and cost it would definitely be a management decision to use that particular suite of applications, but that should not reflect on Java or JEE in general.
HTML has never been the problem. It's trivial to make a page that is HTML compliant. The problem has always been (and will always be) CSS, DOM, and scripting, which are not covered by HTML and have already been defined and standardized well beyond the capabilities of current browsers. And as long as there are patents and royalties involved , things like embedded video will never be settled on, largely due to the intractability of the open source community on such topics.
Besides, it's not like there won't be a standard. It will just have a minor version, or will include modules of functionality. So your page may require a browser that supports HTML 5.1, or HTML 5 plus HTML canvasing 1.1 or some such. It's already being done with XML (XML, XML schema definitions, XSL, XPath, XSL:FO, etc. are all separate standards) with huge success.
Hate to break it to you, but we have a numberless HTML zombie right now. Are Google, Microsoft, Mozilla, and Apple waiting patiently for the specification to be complete? No, HTML 5 is here today. Officially it's HTML 4 + stuff in HTML 5 that's already been agreed on. The vendors know where they want to go with the markup and with the exception of Microsoft, they all produce several releases a year. All of the engines have undergone complete revisions in the last few years to better position themselves for extensibility. Adding new markup is the easy part. The hard part is stuff not covered by the HTML spec: codecs, platform integration, hardware support, etc.
I can't wait for the rolling spec. It will mean more functionality sooner.
The web 2.0 as we know it was created by the Firefox
The web as we know it today resulted from:
1. A need to apply complex formatting, logic, animation, and user interaction
2. An absence of a formal standard for the above
3. Many vendors' ideas and attempts to fill this immediate need through proprietary extensions to the markup
4. The glacial pace of standards bodies to document and ratify standards
5. Many vendors' iterative attempts to back away from their proprietary extensions in favor of the now finalized standards
Firefox benefits from the fact that it came on the scene (in a meaningful way) between 4 and 5, so it had the advantage of implementing standards from the outset. Netscape and IE already had an installed base and had to work iteratively to move toward the standards while ensuring backward compatibility and offering a migration path. (Opera was around, but no one designed pages purely for Opera, so they didn't have the problem with an installed base.) Since Netscape's ideas (e.g. <layer>) differed so radically from the eventually formalized standard, they had more work to do, and because they lacked the market share and financial power of IE, they fell behind and failed.
Where Microsoft failed with IE4-IE6 is that they continued to provide their own extensibility features and neglected the standards. In essence they failed to restrict themselves to the standards, and where there was conflict they chose to ignore the (emerging) standards. But because of their market share their momentum carried them through.
Firefox got where it is by being faster, being available on more platforms, and its extensibility through plugins (adblock, popup blocking, and privacy features). Yes, its rigorous implementation and adherence to standards helped, but not as much as the other things.
And now the growing market share for Firefox and Chrome is putting pressure on Microsoft to play ball, lest they lose ground on other fronts (.NET/Silverlight). Microsoft isn't the biggest player in the game anymore (Firefox + Chrome + Opera are) and Microsoft is losing badly in the handheld/ultra-portable market. (Microsoft does have a significant share of the desktop, but note that it is split between IE6, IE7, and IE8, which all behave differently.)
So now Microsoft is playing catch-up, and to their credit they seem to following the standards as much as possible, especially the emerging HTML5 standards. They have a commitment to their developers and customers to produce a browser that will continue to support the.NET/IIS stack features (and NTLM) and they are moving in the right direction.
The last part of the above post is actually incorrect. (javax.faces.convert.NumberConverter) uses DecimalFormat, which by default produces either a Long or a Double depending on whether the value fits into a Long. You can call DecimalFormat.setParseBigDecimal to make it use BigDecimal, though. Also, DecimalFormat does some digit manipulation via DigitList before calling Double.parseDouble. So Double.parseDouble("2.2250738585072012e-308") is affected, but new DecimalFormat.parse("2.2250738585072012e-308") is not. The resulting Double value for the latter is actually 2.2250738585072014.
Slashdot Mirror
Ditto. In fact, I recently bought a $10 soldering iron to fix a loose connection on my rabbit ears. Wii + Netflix + Antenna + DTV converter + CRT = just about anything I care to watch for $10/mo.
I hate that the launcher disappears whenever something is maximized. And I hate that the window title and the menu bar occupy the same space and have different functionality on mouse-over. This completely fails the grandpa test: I have no idea how I would ever walk my grandpa through a simple task over the phone when things are constantly shifting, disappearing, and changing depending on where the cursor is. Horrible interface.
What frustrates me about Unity is the same thing that frustrated me about Windows 7. Simple tasks take longer to accomplish. Take opening a terminal, for example. In Maverick I can click Applications -> Accessories -> Terminal, or click on the terminal icon I have on my panel. In Natty I have to either:
1. Right-click on the Applications icon and select "Accessories"
2. Click "See all" to expand the list
3. Scroll down a list of gigantic icons and find the terminal
4. Click on the terminal
Or:
1. Click on the Ubuntu icon
2. Type t-e-r-m
3. Click on the terminal
Or:
1. Left-click on the Applications menu in the launcher
2. Choose "Accessories" from the drop-down in the top-right
3. Click "See all" to expand the list
4. Scroll down a list of gigantic icons and find the terminal
5. Click on the terminal
None of these workflows are intuitive and they simply do not make sense. Yes, once I open the terminal I can pin it to the launcher, but this means that in order to prevent throwing my PC out of the window I have to pin virtually everything to the launcher. Then what good is the search/menu function that comprises the bulk of new functionality in Unity?
Ditto. I hated Unity as soon as I started playing with it, and felt no different an hour later.
I was frustrated with KDE from 4.0 - 4.5, but 4.6.2 seems to have addressed most of my gripes.
So let me get this straight. It's better for someone to take, for example, C, or Ruby, or PHP and implement roll their own implementations of:
1. Thread pool management
2. Load balancing and fail-over
3. Session replication
4. Distributed transaction management
5. Naming directory
6. EIS connection management
7. Pluggable authentication and authorization
8. HTTP request parsing and invocation
9. Tags and markup for data binding / AJAX support
10. UI component model
11. Logging
12. Web service management and deployment (including WSDL generation and publishing)
13. XML binding (marshaling and unmarshaling)
14. And so forth and so on
Now in this scenario the implementations will likely:
1. Only implement the functionality that is (perceived to be) needed
2. Will not be tested
3. Will not have the benefit of community scrutiny, certification, or knowledge
4. Will not be immediately understood by any developer other than the author(s) regardless of how much experience they have
Yes, you have to invest to learn JEE.
Yes JEE deals with complex issues and as a result is difficult to understand.
However, having invested that time, anyone who knows it in one place knows it everywhere. That is what saves time and money -- being able to hire someone who already knows JEE and have them hit the ground running.
Further, having a prescribed solution for many common problems allows developers to focus on the business needs, not the boilerplate.
Anyone who does not appreciate what JEE brings to the table is not a serious enterprise developer.
I've worked in many an enterprise and I have yet to use Spring for anything other than perhaps embedded unit testing of EJBs/JMS. And when it comes to that, I prefer OpenEJB anyway (although OpenEJB can be integrated with Spring if you absolutely have to).
Spring is to JEE as Struts is to JSF. It was an interesting precursor, but the improvements made in subsequent JDK releases have made it obsolete.
I'm haven't done a whole lot of reading on IPv6, so I was just curious whether the increased address space leads to any difference in how routing is done. It seems that with a unique public addresses and no NAT there would be more direct routes that could be taken, which would potentially mean more routers with the same address in their routing tables, which would mean more targets to check. Then, depending on congestion along various paths, one landmark may *seem* like the closest when in fact it simply has a fatter pipe going to the target.
And then, as another poster suggested, there is tunneling and all the other additional features in IPv6 , which would make it harder to do this.
Will the same technique work for IPv6?
KDE didn't try to replace the desktop paradigm, and it was never their intent to eliminate configuration options. Every so often you look at your existing code base and think "X would be *so* much easier if this all got cleaned up" and after enough of that you refactor. When refactoring the first priority is to get the thing compiling and running minimally, and then re-implement functionality in order of criticality.
It took 6 minor releases, but KDE 4.6 now has feature parity with 3.5 (more or less) plus the advantage of a cleaner, more extensible code base and tons of new features. Bugs and crashes notwithstanding, KDE 4 isn't that different from Windows, Gnome, or its KDE predecessors.
You may not like Nepomuk and Akonadai, but at least you can turn them off. The KDE group has always had the philosophy that the user should be in control and should be able to tweak every aspect of the experience.
Now, with Gnome 3 we're being told that their way is better, and less is more. So not only are we back to a minimal set of configurability and flexibility, but it looks like it will stay that way.
I've been with Gnome for the last 3 releases of Ubuntu, and I plan to try Unity with Natty, but I don't expect to like Unity as much as I'll like Gnome 3 in FC 15 (when that comes out). If Gnome 3 doesn't work for me, then I'll go back to KDE (now that it's stable).
When I can do this:
tail -F server.log | grep -E 'my.package.(foo|bar)'
In a GUI, without dragging the system to its feet, with 10,000 line scrollback and copy/paste, as well as command history and editing, I will consider using a GUI.
Also:
cd smj
To get to "src/main/java/com/domain/package" takes about 2 seconds to type, and about 2 minutes to click on tiny little tree node icons and wait for the subtree to expand and the UI to refresh. Editing with vi takes way less time that messing with gedit or similar. (Granted, nothing in vi is CLI-specific, but it helps to have it instantly accessible within the CLI.)
SSH'ing to other systems is much faster in CLI, and gives you instant access to scp, etc.
I use a GUI where it makes sense (NetBeans manages just about everything I need for authoring and building code) but for deploying, starting, monitoring, and configuring applications there is nothing that beats CLI.
A good terminal emulator is like a good browser--the power and flexibility to go where you need to go and do what needs to be done, and a common framework (tabs, scrollback, etc.) to manage the viewing and input experience.
It's basically the same as AM2+. AM[n]+ means support for both AM[n] and AM[n + 1] processors. Although in this case it's a little different as the processor is not an "AM4" processor, but I guess that's okay since it looks like it will work in (some) AM3 socket chipsets (800-series).
... and this is why I always buy Asus. No release for my particular motherboard yet, but it looks like it's coming...
As soon as Bulldozer hits I plan on getting a dirt-cheap Phenom II X6 to replace my Athlon II X4 ... which will go back my old motherboard to make a new system for my kids ...
So a delayed upgrade, and still a 1:1 ratio of motherboard-to-CPU, but an upgrade nonetheless...
If I remember correctly the writing materials were not part of the public record and were to be destroyed. The public record consists of the testimony and other statements made in the courtroom and recorded by the court stenographer. I think the policy of collecting and/or destroying juror notes is probably to the benefit of both the juror and the court, as the may consist of doodles, conjecture, opinion, and other potentially embarrassing content.
When I served on a jury the bailiff collected our cell phones before the trial and gave them back afterward. They also provided all writing materials and collected them when the trial was over. Seems perfectly reasonable to me.
My point wasn't that you *can't* implement whatever methods you want, it's that it doesn't do any good. Consider a remote EJB. (Clustered EJBs have to be remote.) The client pulls down an Employee object by calling EmployeeSession.getEmployeById. The client then calls Employee.promote() on their local instance. Does that have the desired effect? No, the client must then call EmployeeSession.updateEmployee and pass in the modified object. What if employee.promote() has to update the employee's manager reference and then update the manager's subordinates collection? What if there are business rules that have to be observed that consider entities that exist outside of the normal scope of the employee and manager? What if there are interactions with other EIS?
At this point it makes more sense to have an EmployeeSession.fireEmployee() method that takes an employee ID. The implementation then loads the employee by ID (so that it is in the persistence context), performs whatever additional validations and logic are necessary, and then returns the modified Employee object.
Now consider that this may be a web service method. That being the case, all of the fields on Employee have to be readable and mutable, because XML does not care about data protection. In that scenario you absolutely cannot trust the client to submit a pristine/valid Employee object, so you have to go field by field and do validations *anyway*. In this scenario a EmployeeSession.fireEmployee method makes much more sense, as all the client supplies is a client ID, and there is no ambiguity as to whether the other fields may be updated.
I meant the classes themselves. For example, you're not supposed to use non-static private fields in a stateless session bean, message driven bean, servlets, etc. In the best case the field values will just be lost as the instance is discarded and the request handling thread returns to the pool; in the worst case you will have concurrent access to the same instance of the bean which leads to lost updates and race conditions on those fields. (The spec implies that concurrent access to a stateless bean is possible, but I've never seen a container implement them in this way. Usually a new instance is created for each thread.)
I've been noticing that Java is moving away from OOP. If you use EJB3 persistence (i.e. JPA), JAXB, JSF, WebBeans, or any number of recent technologies you'll find that:
- Business methods (stateless EJBs/web services, servlets, JSF components, entities, etc.) are stateless and non-thread-safe
- All data containers must adhere to the Java Bean specification; all mutable properties must either have a public setter method or the entire object must use field access
- Data objects are encumbered by persistence state, making complex operations on object graphs either costly (eager fetching) or perilous (lazy initialization exceptions, stale object state exceptions, etc.)
- Most, if not all, user state is managed in the HTTP session or client (in the case of a fat client)
The result is that business logic exists as a set of stateless functions (that happen to exist in a class) and that the date is a set of functionless state (all fields must be exposed so that the business methods and container can operate on them). So basically you have a set of functions in a class file that receive a set of data (entities or business keys), operate on it, and then return some other data that then is stored as a name/value pair in a session or a field on some Swing control.
This movement away from OOP has been driven largely by JEE and container-managed services, which are multi-threaded, clustered, and distributed. In order to do that efficiently, the programs have to separate data and logic.
There have been some attempts to "fix" this such as Seam, but the reality is that these solutions do not scale. They are good for hotel reservation apps, but not a 300 table enterprise OSS system.
So OOP is going the way of the Dodo, but the writing has been on the wall for some time. Java, .NET, and other technologies in the business of driving large scale enterprise applications are still very much relevant.
Is this just for merchants? Every time I make a transaction as a seller they bug me about linking to a checking account, but so far I've managed to avoid doing it. The day they require it is the day I stop using them altogether.
It's actually commit logs ... but then again I've yet to meet a PHP dev that actually uses a VCS ;)
But the people who make the decision to use Oracle technologies (Oracle database, Oracle J2EE and all the other technologies) are usually not programmers, its PHBs who like the fact that some guy in a suit is saying good things about this "Oracle" thing and are duped into buying it (and the fact that in many cases there is no comparable alternative that is as good as the Oracle product unless you are willing to sign your soul to Microsoft or IBM)
In my experience this is not true. I happen to love Java as a language and a JEE because of its openness and support and innovation within the community. I choose JEE as a platform when developing large business applications because of the built-in support for the features I need -- clustering/failover, high availability JNDI, XA transaction support, messaging, connection pooling, servlets, AJAX, etc. Java also makes sense in many situations because the applications that are being integrated with are also JEE based, especially in the enterprise.
As far as I know, Java is also the only platform with freely available tools like Maven, Hudson (now Jenkins), JUnit, Sonar, FindBugs, etc. that automate dependency management, continuous build, and code analysis. (All of these are free, community-supported tools, by the way.)
In fact, for what I do, I can't think of a reason *not* to use Java. I've been in countless mergers, and every other company we've merged with had a Java shop.
The JEE stack I prefer is RedHat/JBoss, but I've used others, including Oracle. Oracle's is terrible, and one hopes that they will make use of Glassfish and NetBeans to improve their commercial offering. (I love NetBeans.) With Oracle's licensing terms and cost it would definitely be a management decision to use that particular suite of applications, but that should not reflect on Java or JEE in general.
HTML has never been the problem. It's trivial to make a page that is HTML compliant. The problem has always been (and will always be) CSS, DOM, and scripting, which are not covered by HTML and have already been defined and standardized well beyond the capabilities of current browsers. And as long as there are patents and royalties involved , things like embedded video will never be settled on, largely due to the intractability of the open source community on such topics.
Besides, it's not like there won't be a standard. It will just have a minor version, or will include modules of functionality. So your page may require a browser that supports HTML 5.1, or HTML 5 plus HTML canvasing 1.1 or some such. It's already being done with XML (XML, XML schema definitions, XSL, XPath, XSL:FO, etc. are all separate standards) with huge success.
Hate to break it to you, but we have a numberless HTML zombie right now. Are Google, Microsoft, Mozilla, and Apple waiting patiently for the specification to be complete? No, HTML 5 is here today. Officially it's HTML 4 + stuff in HTML 5 that's already been agreed on. The vendors know where they want to go with the markup and with the exception of Microsoft, they all produce several releases a year. All of the engines have undergone complete revisions in the last few years to better position themselves for extensibility. Adding new markup is the easy part. The hard part is stuff not covered by the HTML spec: codecs, platform integration, hardware support, etc. I can't wait for the rolling spec. It will mean more functionality sooner.
The web 2.0 as we know it was created by the Firefox
The web as we know it today resulted from:
1. A need to apply complex formatting, logic, animation, and user interaction
2. An absence of a formal standard for the above
3. Many vendors' ideas and attempts to fill this immediate need through proprietary extensions to the markup
4. The glacial pace of standards bodies to document and ratify standards
5. Many vendors' iterative attempts to back away from their proprietary extensions in favor of the now finalized standards
Firefox benefits from the fact that it came on the scene (in a meaningful way) between 4 and 5, so it had the advantage of implementing standards from the outset. Netscape and IE already had an installed base and had to work iteratively to move toward the standards while ensuring backward compatibility and offering a migration path. (Opera was around, but no one designed pages purely for Opera, so they didn't have the problem with an installed base.) Since Netscape's ideas (e.g. <layer>) differed so radically from the eventually formalized standard, they had more work to do, and because they lacked the market share and financial power of IE, they fell behind and failed.
Where Microsoft failed with IE4-IE6 is that they continued to provide their own extensibility features and neglected the standards. In essence they failed to restrict themselves to the standards, and where there was conflict they chose to ignore the (emerging) standards. But because of their market share their momentum carried them through.
Firefox got where it is by being faster, being available on more platforms, and its extensibility through plugins (adblock, popup blocking, and privacy features). Yes, its rigorous implementation and adherence to standards helped, but not as much as the other things.
And now the growing market share for Firefox and Chrome is putting pressure on Microsoft to play ball, lest they lose ground on other fronts (.NET/Silverlight). Microsoft isn't the biggest player in the game anymore (Firefox + Chrome + Opera are) and Microsoft is losing badly in the handheld/ultra-portable market. (Microsoft does have a significant share of the desktop, but note that it is split between IE6, IE7, and IE8, which all behave differently.)
So now Microsoft is playing catch-up, and to their credit they seem to following the standards as much as possible, especially the emerging HTML5 standards. They have a commitment to their developers and customers to produce a browser that will continue to support the .NET/IIS stack features (and NTLM) and they are moving in the right direction.
The last part of the above post is actually incorrect. (javax.faces.convert.NumberConverter) uses DecimalFormat, which by default produces either a Long or a Double depending on whether the value fits into a Long. You can call DecimalFormat.setParseBigDecimal to make it use BigDecimal, though. Also, DecimalFormat does some digit manipulation via DigitList before calling Double.parseDouble. So Double.parseDouble("2.2250738585072012e-308") is affected, but new DecimalFormat.parse("2.2250738585072012e-308") is not. The resulting Double value for the latter is actually 2.2250738585072014.