Its on the Android market, and you need an Android 2.2 OS. If you can't see it in the market, then its likely that it isn't supported on your phone yet.
1. FlashBlock Problem Go to your browser settings page by hitting menu->more->settings Scroll down to and hit "Enable plug-ins" Click On Demand This for all intents and purposes makes flash work like FlashBlock does on PC's
2. "seems to force you to watch embedded videos with Flash" If you long press on the YouTube video when you're on a web page, you'll be prompted to open the app in: "Browser", or "YouTube", or "Opera Mini" (if you installed this one), etc.. If you select YouTube then it'll open the video in the YouTube app.
HTML5 is just a series of different interpreters. Take away the JavaScript -interpreter- and the HTML's structured page -interpreter- and the CSS style -interpreter- and there's not much left to HTML5 or anything else on the web. The web is a blob of content tied together by an array of interpreters. Please please use rational discourse to give ammunition to your beliefs instead of regurgitating marketing propaganda.
"Sometimes doing wrong math you get the right result."...
Oh my god, pragmatism from a Slashdot poster? Get the hell off our island!
Not everyone can just throw resources at supporting the 8+ mobile / tablet platforms out there. The guys with big pockets will support them all, but those that can't or won't support all mobile platforms will just pick those that they can afford to, which will ultimately cause further fragmentation in an already fragmented ecosystem. If I was a flash developer (which I'm not, but for the sake of argument), I'd rather be given the ability to deploy on as many platforms as I could with the limited resources that I have available. The more platforms that I can deploy too making as few changes as possible, the better off I am. If I had a Flash application that ran on PC's/Macs and needed to port to Android and/or iPhone, it would be a lot easier to take my existing source base and tailor the existing code (using heavy reuse) to make the platform run on Android, or other low profile devices. Take it with juxtaposition porting my application to iPhone which would require new programming methodologies and new code(from scratch) in addition to everything I'd need to do flash in order to shrink my existing flash version onto a low profile device. The advantage of doing the native port being that I have slightly more control over the programming practice and I have the possibility of making a better performing application(assuming I know anything about performance tuning) for the target platform.
I played countless hours of my teen age years with some friends mooching off a local game store just to play this game. It got to be such a habit that we were on a first name basis with the employees.
Which is why I added the caveat. In reality, you don't really have to restart the system even on a fatal flaw. Init isn't terribly insecure with the old version if the exploit was a vulnerability in sockets for instance; whereas if there was a socket bug in libc and you were running Apache, sure as hell you want to reload Apache with the fresh version.
You could have tight capacity limitations on the existing hardware and you can't setup new servers fast enough, so having even one of a HA cluster can severely impact the cluster's throughput. Its obviously not the situation you want to be in, but it does happen. Another possibility is that there's an inherent flaw in the cluster software itself, which requires a full cluster restart. No matter how HA your HA infrastructure is, it can and does go down.
Libc is easy. Install the update while the app is running. The old version of the library stays alive in ram as long as processes still have handles to it which is no big whoop unless its an exploit that you really must clean up immediately. If application X uses libc, the next time its started it'll get the new version of the library and happily co-exist with the old one, nay?
Smart phones came from dumb cell phones. Appliances that you had no control over. If anything, Cell Phones are going the way of the open architecture. Give 5-10 years and we'll probably have the same environment for development as we do for PC's. This is amplified by the fact that there's so much competition right now to get developers onto their platforms. The more you entice them, the easier you need to make the system to development on. Short-sided market driven decisions in OS and API design can cause long term impact on systems security.
Open handset or not, Google does make approvals for their platform which is the only way that their own 'proprietary' apps like market and maps get shipped to phones.
*sigh* "locked into Sony's proprietary formats" vs. what exactly? DS with its locked in platform? What mobile gaming platorm isn't locked in?
Dedicated Gaming devices:
Sony PSP: Systems Proprietary and not licensed, Games: Pay to develop for / license required
Nintendo GameBoy/DS: Systems Proprietary and not licensed, Games: Pay to develop for / license required
Sony PS3 (Disc Content): Systems Proprietary and not licensed, Games: Pay to develop for / license required
Sony PS3 (Download Content): Systems Proprietary and not licensed, Games: Pay to develop for / license required
XBox 360 (Disc Content): Systems Proprietary and not licensed, Games: Pay to develop for / license required
XBox 360 (Market Content): Systems Proprietary and not licensed, Games: Free to develop (if you have the Tools) / license required Phone/MID derivatives:
Symbian: Systems Proprietary under license, Games: ??
Sun/Oracle Java Moble: Systems Proprietary under license, Games: Free to develop / no licensing requirements
Microsoft WinMo/CE: Systems Open but licensed per seat, Games: Free to develop (if you have the Tools) / no licensing requirements
RIM: Systems Proprietary and not licensed, Games: Free to develop / no licensing requirements (I haven't looked at RIM for development since 2000 when they made pagers, so I could be wrong here)
Apple: Systems Proprietary and not licensed, Games: Licensed to develop & sell / licensing requirements as per app store policy
Android (Market): Systems Open and free, Games: Free to develop / licensing requirements as per app store policy
Android (Direct): Systems Open and free, Games: Free to develop / no licensing requirements
Linux Variants (Generally): Free to develop / no licensing requirements
Its interesting that you think that -just this year- overtaking China in ratings means you're doing a good job of international relations. I guess the fact that you're improving your relations as all could be considered positive.
I've worn both hats in being a full time admin and a full time developer. The roles are so totally different that its hard to find people even remotely capable of doing both tasks. I never did them at the same time, but its always possible as long as the scope of the responsibility is small enough to make it possible. That's not to say there won't be political / technical problems with your role, but its possible:
Political: Assuming development and operations are run through different management branches, who are you responsible for resolving issues? When you have a show-stopper in production and the only solutions are 2 solid weeks of development effort or hours a week of extra maintenance, what happens?
Technical: You've just quit the company and someone's taken your place as IT guy on the server. They've realized you're the worst IT guy on the planet and the server's almost always on fire; saved only by a bug in the service pack you never bothered to upgrade away form. The company all of a sudden has a huge problem that was completely blind-sighted to because the developer making the system was also maintaining it. Maybe you the developer knew about issues in the code and decided that the best solution was to code around the defect instead of considering upgrade / replacement solutions. Maybe a new coder comes in without your personal knowledge of the defect and the system breaks, etc..
Does that same train of trust trickle down to new employees / Incompetent employees? Like it or not, not everyone is perfect, and people make mistakes. Having unlimited developer access to systems means that they can tamper with things and make them worse, blow up the databases, etc..by accident. Even admins aren't perfect. I blew away a (non-essential luckily) database once through en erroneous rm once. People are flawed. The issue usually comes down to the fact that IT people rarely decide to poke their noses into stable systems to make tweaks without good reason. Developers who are often a lot more attached to their works want to make things run well, perfect, etc.. and tweaks here and there introduce bugs that can cause real problems. Your developers may all be rocket scientists that don't make mistakes (wait they make mistakes too, so scratch that) but the rest of us err, and hence we're human.
True, if you need to install a debugger in production, I think you've already lost any benefit you had in being able to reproduce a problem. The only reason you're on production is because the bug can't be reproduced, so changing the parameters that case the issue only increases the chance that the bug will disappear before a developer has a chance to diagnose it.
The tools for analysis should ALWAYS be installed, and the tools installed should be sensible and only grant as much information as needed to reasonably diagnose most problems while not affecting run-time performance/stability. Sometimes this is just impossible. Ideally, there should never be bugs that can't be fixed, but the amount of effort to diagnose can at times be so insurmountable that a workaround is preferred over the detection/fix. If you start to get many of these 'unfixable' problems, you should be thinking on how flimsy the code/environment are to begin with and consider how to increase the reliability of either/both of them.
I've generally seen the opposite in my years. Developers often overlook the environment in so many fundamental ways, that just being a developer of the product overlooks many of the fundamentals of the environment that applications are actually run in. Examples: Front-side caching / load balancers, nightly backups, peek/volatile latency, limited bandwidth, resource sharing with other apps, intermittent peripheral service downtime.. All these things and a hell of a lot more are rarely in the minds of devs that just want to write code.There are usually senior dev's that have been annoyed so often with bugs that they're well aware of production concerns who can help development catch possible problems before they're shipped.
The problem I usually run into with Operations people is that once they've decided that the problem isn't theirs they tend to take the issue hands-off and just rely on development to find the solution to -their- problem (though dev's do this as well in reverse). Personally, I've rarely run into admins that wouldn't allow access to things needed to diagnose the bugs, but sometimes that falls into the subjective category where one dev may think X is reasonable where another would say 'security violation', etc..
But access to the development servers was why it was working perfectly fine before! You shut off production's access to dev and now the system's hosed! FIX IT!!!
1. No matter how perfect your setup is, there will always be variations between prod and the most meticulously setup prod clone, shadow, backup, standby, etc... that will cause some (hopefully not many) bugs to present themselves in one environment and not in others 2. Data changes behavior -- Even if the web apps are identical, a small change to a database table could cause breakage in ways you never imagined. This can be controlled through proper layering and decoupling, but it always seems to creep up when you don't even notice it
Developers should never have direct access to production. The usual steps for solving production issues should usually be solved as follows: 1. If a support person gets the defect (either directly finding it or from a customer/user) then they look up in their knowledge base to make sure that the company doesn't already know about the problem and have a reasonable solution. If the problem hasn't been logged and is outside of the technical competence of the support staff, it usually gets thrown on IT / Operations support
2. Operations support should one again verify that the problem hasn't been addressed before. Often problems will just continue to re-occur. Some problems just never get solved for one reason or another. Some problems -could- be solved, but the fix is just easier than a large amount of investment in making the problem go away. Often 'reboot the server' is a good enough solution for problems with low frequency occurrences and high complexity solutions.
3. Operations doesn't know the problem, so its time to poke around the logs, system resources, network connections, etc... A good network and systems management solution makes this problem moot. I've seen tons of production problems end up being the result of rarely used disks getting full with nobody bothering to alarm on them. Finally, ops throws their hands up in the air and are like 'WTF.. this is a development issue'.
4. This step is the hand-off between operations and development. I say hand-off, but in reality, this is when the two teams need to start COLLABORATING to find a solution. Too often either operations chucks the problem onto development's lap, or else development takes the problem and ignores operations until they find what they think the problem is or give up. The best solution in dealing with development related production problems are for both teams to work together and use shared knowledge and experiences of both groups to diagnose and resolve the issue. I've played on both teams over the years and I know quite well that Developers too often want to assume they know everything about deployments, servers, environments, etc.. Often that knowledge is diluted and ends up blinding them to issues that could be diagnosed at least in part with a network administrator / operations support. The worst situation is for this step is to get into the cycle of blaming one another for the defect. Tough to diagnose problems too often flame into blame games which always exacerbate the time to find, diagnose, and resolve an issue.
5. Development asks for information X, Y, and Z. If there's enough information to gather an accurate diagnosis, a solution or a workaround is devised. If its a workaround, the problem and the solution should be logged somewhere so that all parties (support/admin/development) can see what problems are outstanding and if the problem comes up again, the workaround to address it. If the solution is a new release / patch / etc.. the fix should go through the general release cycle as usual (though much faster for more severe problems). Some problems don't and may never have evident solutions. The trick here is to find an adequate workaround that keeps stakeholder impact to the minimum.
Developers should always have access to:
- Server / Database logs (Just don't put anything confidential within logs that can compromise customer / user privacy)
- Production IP's, and other data that is unique per release environment
Developers shou
Re:Not remotely similar to the Microsoft situation
on
The Case For Oracle
·
· Score: 1
1. I wouldn't want to re-implement Swing, but the nice folks at Apache Harmony have basically (if not entirely) implemented the J2SE stack which includes Swing/AWT, etc... Since Google took harmony to make Android anyways, I don't see too much work in porting the native bits of harmony Swing/AWT to Android.
"It's way too over-engineered and is mostly useless now."
I really like AWT's Image abstraction. It makes writing to hardware pretty fast and efficient without needing to dip into plaf specific OGL/DX code directly (The JVM internally runs through them, but the abstraction means you don't need to worry about them).
2. I've yet to try it, but Proxy has been defined in the Android SDK since version 1. If you meant java.lang.instrumentation then you're right. The API does seem to be absent.
Re:Not remotely similar to the Microsoft situation
on
The Case For Oracle
·
· Score: 1
1Ghz phones with 100's of MB ram can certainly handle the computing requirements of desktop java, maybe not well, but they could run. Swing is pretty poor for mobile platforms, but supporting Swing doesn't mean supporting it well. Not having AWT support (for library compatability if NOTHING else) was just a stupid decision. Giving the developers the choice of how to develop would've been better in my eyes:
1. Stock JSE - Non-optimized to Android implementation of graphics but portable 2. Android Graphics - More tailored for embedded systems but totally proprietary to Android 3. OpenGL - Very fast, open, and portable but requires writing everything yourself (or through someone's toolkit)
I just bumped into the fact that Android doesn't support java.beans which was annoying since my app had used Introspector for some bean fuddling. It meant I had the option of rewriting the Introspector methods myself using relfection, or I could move Harmony's java.beans into Android. I chose the harmony route since it seemed the most straight forward. The reason Google probably decided to cut beans was because it requires java.awt.Image (used in TONS of projects) but since they don't support AWT, I'd also have to port AWT into Android, or just clip out the AWT dependencies. In the end I just took out the Image bits (There are thankfully not too many dependencies, and none of them are relevant for my Android purposes).
Google could always release a full JSE stack and add a big fat Android native extension for their custom bits. As for Dalvik vs. Hotspot, I'm not sure of the advantages of using one over the other in embedded. I'd assume Google put more work into making it faster for embedded, but I can't really say definitively. The company that created Dalvik before Google bought them probably went with their own over licensing issues over anything else, since Sun did (does?) have field of use limitations on embedded systems, or has this changed?
Re:Not remotely similar to the Microsoft situation
on
The Case For Oracle
·
· Score: 5, Insightful
Firstly, on a strictly legal sense, they're suing over Patents and Copyrights. The copyright route seems rather fishy, and I wouldn't be surprised if this argument gets dropped later. The patent suit is like all others, and has little if anything to do with the spirit of java, etc..
On a philosophical sense, Oracle is correct. Android may never claim to be Java, but anyone who isn't a retard knows that Google is enticing Java developers into their pseudo-compatible platforms. From a personal perspective, it is annoying porting existing java apps into AppEngine / Android. The standard class libs limitations make interoperability between stock java and Google's platforms more difficult. This IS similar to the tack that Microsoft made proprietary core feature additions. Microsoft was never forced to use Java when coming up with their proprietary JVM. They chose java because it had buzz, and they assumed it would be next good language to assimilate and conquer. I don't think Google wants to kill Java, but I think they want to steal the large pool of existing Java developers and coerce them to use their platforms. Does this diversity hurt java (the language) in the end? Yes. Much of the advantage of java is in the rich set of additions built upon existing platforms. If those libraries now have to choose which platform to track against, it means two versions of common libraries, and smaller guys may just not bother to support J2SE,Android,AppEngine,GWT, etc...
Add speed bumps into the road. Depending on how fast the road speeds are supposed to be, you can make the bumps smoother for faster areas and higher for slow traffic ones (like before what should be a 4-way stop / light).
Slashdot Mirror
Its on the Android market, and you need an Android 2.2 OS. If you can't see it in the market, then its likely that it isn't supported on your phone yet.
What the heck do you mean?
1. FlashBlock Problem
Go to your browser settings page by hitting menu->more->settings
Scroll down to and hit "Enable plug-ins"
Click On Demand
This for all intents and purposes makes flash work like FlashBlock does on PC's
2. "seems to force you to watch embedded videos with Flash"
If you long press on the YouTube video when you're on a web page, you'll be prompted to open the app in: "Browser", or "YouTube", or "Opera Mini" (if you installed this one), etc.. If you select YouTube then it'll open the video in the YouTube app.
HTML5 is just a series of different interpreters. Take away the JavaScript -interpreter- and the HTML's structured page -interpreter- and the CSS style -interpreter- and there's not much left to HTML5 or anything else on the web. The web is a blob of content tied together by an array of interpreters. Please please use rational discourse to give ammunition to your beliefs instead of regurgitating marketing propaganda.
"Sometimes doing wrong math you get the right result." ...
Oh my god, pragmatism from a Slashdot poster? Get the hell off our island!
Not everyone can just throw resources at supporting the 8+ mobile / tablet platforms out there. The guys with big pockets will support them all, but those that can't or won't support all mobile platforms will just pick those that they can afford to, which will ultimately cause further fragmentation in an already fragmented ecosystem. If I was a flash developer (which I'm not, but for the sake of argument), I'd rather be given the ability to deploy on as many platforms as I could with the limited resources that I have available. The more platforms that I can deploy too making as few changes as possible, the better off I am. If I had a Flash application that ran on PC's/Macs and needed to port to Android and/or iPhone, it would be a lot easier to take my existing source base and tailor the existing code (using heavy reuse) to make the platform run on Android, or other low profile devices. Take it with juxtaposition porting my application to iPhone which would require new programming methodologies and new code(from scratch) in addition to everything I'd need to do flash in order to shrink my existing flash version onto a low profile device. The advantage of doing the native port being that I have slightly more control over the programming practice and I have the possibility of making a better performing application(assuming I know anything about performance tuning) for the target platform.
I played countless hours of my teen age years with some friends mooching off a local game store just to play this game. It got to be such a habit that we were on a first name basis with the employees.
"Hope it doesn't contain vulnerabilities!"
Which is why I added the caveat. In reality, you don't really have to restart the system even on a fatal flaw. Init isn't terribly insecure with the old version if the exploit was a vulnerability in sockets for instance; whereas if there was a socket bug in libc and you were running Apache, sure as hell you want to reload Apache with the fresh version.
You could have tight capacity limitations on the existing hardware and you can't setup new servers fast enough, so having even one of a HA cluster can severely impact the cluster's throughput. Its obviously not the situation you want to be in, but it does happen. Another possibility is that there's an inherent flaw in the cluster software itself, which requires a full cluster restart. No matter how HA your HA infrastructure is, it can and does go down.
Libc is easy. Install the update while the app is running. The old version of the library stays alive in ram as long as processes still have handles to it which is no big whoop unless its an exploit that you really must clean up immediately.
If application X uses libc, the next time its started it'll get the new version of the library and happily co-exist with the old one, nay?
Smart phones came from dumb cell phones. Appliances that you had no control over. If anything, Cell Phones are going the way of the open architecture. Give 5-10 years and we'll probably have the same environment for development as we do for PC's. This is amplified by the fact that there's so much competition right now to get developers onto their platforms. The more you entice them, the easier you need to make the system to development on. Short-sided market driven decisions in OS and API design can cause long term impact on systems security.
Open handset or not, Google does make approvals for their platform which is the only way that their own 'proprietary' apps like market and maps get shipped to phones.
I'm not in the MS ecosystem, so I'm not up on what can be used for free and what couldn't.
*sigh* "locked into Sony's proprietary formats" vs. what exactly? DS with its locked in platform? What mobile gaming platorm isn't locked in?
Dedicated Gaming devices:
Sony PSP: Systems Proprietary and not licensed, Games: Pay to develop for / license required
Nintendo GameBoy/DS: Systems Proprietary and not licensed, Games: Pay to develop for / license required
Sony PS3 (Disc Content): Systems Proprietary and not licensed, Games: Pay to develop for / license required
Sony PS3 (Download Content): Systems Proprietary and not licensed, Games: Pay to develop for / license required
XBox 360 (Disc Content): Systems Proprietary and not licensed, Games: Pay to develop for / license required
XBox 360 (Market Content): Systems Proprietary and not licensed, Games: Free to develop (if you have the Tools) / license required
Phone/MID derivatives:
Symbian: Systems Proprietary under license, Games: ??
Sun/Oracle Java Moble: Systems Proprietary under license, Games: Free to develop / no licensing requirements
Microsoft WinMo/CE: Systems Open but licensed per seat, Games: Free to develop (if you have the Tools) / no licensing requirements
RIM: Systems Proprietary and not licensed, Games: Free to develop / no licensing requirements (I haven't looked at RIM for development since 2000 when they made pagers, so I could be wrong here)
Apple: Systems Proprietary and not licensed, Games: Licensed to develop & sell / licensing requirements as per app store policy
Android (Market): Systems Open and free, Games: Free to develop / licensing requirements as per app store policy
Android (Direct): Systems Open and free, Games: Free to develop / no licensing requirements
Linux Variants (Generally): Free to develop / no licensing requirements
Its interesting that you think that -just this year- overtaking China in ratings means you're doing a good job of international relations. I guess the fact that you're improving your relations as all could be considered positive.
1. Some libel is criminal (even in the US)
2. It gives everyone not in the US a reason to slap their heads and yell WTF
But Oh my god, don't show nudity on public TV! That's just obscene!
I've worn both hats in being a full time admin and a full time developer. The roles are so totally different that its hard to find people even remotely capable of doing both tasks. I never did them at the same time, but its always possible as long as the scope of the responsibility is small enough to make it possible. That's not to say there won't be political / technical problems with your role, but its possible:
Political: Assuming development and operations are run through different management branches, who are you responsible for resolving issues? When you have a show-stopper in production and the only solutions are 2 solid weeks of development effort or hours a week of extra maintenance, what happens?
Technical: You've just quit the company and someone's taken your place as IT guy on the server. They've realized you're the worst IT guy on the planet and the server's almost always on fire; saved only by a bug in the service pack you never bothered to upgrade away form. The company all of a sudden has a huge problem that was completely blind-sighted to because the developer making the system was also maintaining it.
Maybe you the developer knew about issues in the code and decided that the best solution was to code around the defect instead of considering upgrade / replacement solutions. Maybe a new coder comes in without your personal knowledge of the defect and the system breaks, etc..
Does that same train of trust trickle down to new employees / Incompetent employees? Like it or not, not everyone is perfect, and people make mistakes. Having unlimited developer access to systems means that they can tamper with things and make them worse, blow up the databases, etc..by accident. Even admins aren't perfect. I blew away a (non-essential luckily) database once through en erroneous rm once. People are flawed. The issue usually comes down to the fact that IT people rarely decide to poke their noses into stable systems to make tweaks without good reason. Developers who are often a lot more attached to their works want to make things run well, perfect, etc.. and tweaks here and there introduce bugs that can cause real problems. Your developers may all be rocket scientists that don't make mistakes (wait they make mistakes too, so scratch that) but the rest of us err, and hence we're human.
True, if you need to install a debugger in production, I think you've already lost any benefit you had in being able to reproduce a problem. The only reason you're on production is because the bug can't be reproduced, so changing the parameters that case the issue only increases the chance that the bug will disappear before a developer has a chance to diagnose it.
The tools for analysis should ALWAYS be installed, and the tools installed should be sensible and only grant as much information as needed to reasonably diagnose most problems while not affecting run-time performance/stability. Sometimes this is just impossible. Ideally, there should never be bugs that can't be fixed, but the amount of effort to diagnose can at times be so insurmountable that a workaround is preferred over the detection/fix. If you start to get many of these 'unfixable' problems, you should be thinking on how flimsy the code/environment are to begin with and consider how to increase the reliability of either/both of them.
I've generally seen the opposite in my years. Developers often overlook the environment in so many fundamental ways, that just being a developer of the product overlooks many of the fundamentals of the environment that applications are actually run in. Examples: Front-side caching / load balancers, nightly backups, peek/volatile latency, limited bandwidth, resource sharing with other apps, intermittent peripheral service downtime.. All these things and a hell of a lot more are rarely in the minds of devs that just want to write code.There are usually senior dev's that have been annoyed so often with bugs that they're well aware of production concerns who can help development catch possible problems before they're shipped.
The problem I usually run into with Operations people is that once they've decided that the problem isn't theirs they tend to take the issue hands-off and just rely on development to find the solution to -their- problem (though dev's do this as well in reverse). Personally, I've rarely run into admins that wouldn't allow access to things needed to diagnose the bugs, but sometimes that falls into the subjective category where one dev may think X is reasonable where another would say 'security violation', etc..
But access to the development servers was why it was working perfectly fine before! You shut off production's access to dev and now the system's hosed! FIX IT!!!
1. No matter how perfect your setup is, there will always be variations between prod and the most meticulously setup prod clone, shadow, backup, standby, etc... that will cause some (hopefully not many) bugs to present themselves in one environment and not in others
2. Data changes behavior -- Even if the web apps are identical, a small change to a database table could cause breakage in ways you never imagined. This can be controlled through proper layering and decoupling, but it always seems to creep up when you don't even notice it
Developers should never have direct access to production. The usual steps for solving production issues should usually be solved as follows:
1. If a support person gets the defect (either directly finding it or from a customer/user) then they look up in their knowledge base to make sure that the company doesn't already know about the problem and have a reasonable solution.
If the problem hasn't been logged and is outside of the technical competence of the support staff, it usually gets thrown on IT / Operations support
2. Operations support should one again verify that the problem hasn't been addressed before. Often problems will just continue to re-occur. Some problems just never get solved for one reason or another. Some problems -could- be solved, but the fix is just easier than a large amount of investment in making the problem go away. Often 'reboot the server' is a good enough solution for problems with low frequency occurrences and high complexity solutions.
3. Operations doesn't know the problem, so its time to poke around the logs, system resources, network connections, etc... A good network and systems management solution makes this problem moot. I've seen tons of production problems end up being the result of rarely used disks getting full with nobody bothering to alarm on them. Finally, ops throws their hands up in the air and are like 'WTF.. this is a development issue'.
4. This step is the hand-off between operations and development. I say hand-off, but in reality, this is when the two teams need to start COLLABORATING to find a solution. Too often either operations chucks the problem onto development's lap, or else development takes the problem and ignores operations until they find what they think the problem is or give up. The best solution in dealing with development related production problems are for both teams to work together and use shared knowledge and experiences of both groups to diagnose and resolve the issue. I've played on both teams over the years and I know quite well that Developers too often want to assume they know everything about deployments, servers, environments, etc.. Often that knowledge is diluted and ends up blinding them to issues that could be diagnosed at least in part with a network administrator / operations support. The worst situation is for this step is to get into the cycle of blaming one another for the defect. Tough to diagnose problems too often flame into blame games which always exacerbate the time to find, diagnose, and resolve an issue.
5. Development asks for information X, Y, and Z. If there's enough information to gather an accurate diagnosis, a solution or a workaround is devised. If its a workaround, the problem and the solution should be logged somewhere so that all parties (support/admin/development) can see what problems are outstanding and if the problem comes up again, the workaround to address it. If the solution is a new release / patch / etc.. the fix should go through the general release cycle as usual (though much faster for more severe problems). Some problems don't and may never have evident solutions. The trick here is to find an adequate workaround that keeps stakeholder impact to the minimum.
Developers should always have access to:
- Server / Database logs (Just don't put anything confidential within logs that can compromise customer / user privacy)
- Production IP's, and other data that is unique per release environment
Developers shou
1. I wouldn't want to re-implement Swing, but the nice folks at Apache Harmony have basically (if not entirely) implemented the J2SE stack which includes Swing/AWT, etc... Since Google took harmony to make Android anyways, I don't see too much work in porting the native bits of harmony Swing/AWT to Android.
"It's way too over-engineered and is mostly useless now."
I really like AWT's Image abstraction. It makes writing to hardware pretty fast and efficient without needing to dip into plaf specific OGL/DX code directly (The JVM internally runs through them, but the abstraction means you don't need to worry about them).
2. I've yet to try it, but Proxy has been defined in the Android SDK since version 1. If you meant java.lang.instrumentation then you're right. The API does seem to be absent.
1Ghz phones with 100's of MB ram can certainly handle the computing requirements of desktop java, maybe not well, but they could run. Swing is pretty poor for mobile platforms, but supporting Swing doesn't mean supporting it well. Not having AWT support (for library compatability if NOTHING else) was just a stupid decision. Giving the developers the choice of how to develop would've been better in my eyes:
1. Stock JSE - Non-optimized to Android implementation of graphics but portable
2. Android Graphics - More tailored for embedded systems but totally proprietary to Android
3. OpenGL - Very fast, open, and portable but requires writing everything yourself (or through someone's toolkit)
I just bumped into the fact that Android doesn't support java.beans which was annoying since my app had used Introspector for some bean fuddling. It meant I had the option of rewriting the Introspector methods myself using relfection, or I could move Harmony's java.beans into Android. I chose the harmony route since it seemed the most straight forward.
The reason Google probably decided to cut beans was because it requires java.awt.Image (used in TONS of projects) but since they don't support AWT, I'd also have to port AWT into Android, or just clip out the AWT dependencies. In the end I just took out the Image bits (There are thankfully not too many dependencies, and none of them are relevant for my Android purposes).
Google could always release a full JSE stack and add a big fat Android native extension for their custom bits. As for Dalvik vs. Hotspot, I'm not sure of the advantages of using one over the other in embedded. I'd assume Google put more work into making it faster for embedded, but I can't really say definitively. The company that created Dalvik before Google bought them probably went with their own over licensing issues over anything else, since Sun did (does?) have field of use limitations on embedded systems, or has this changed?
Firstly, on a strictly legal sense, they're suing over Patents and Copyrights. The copyright route seems rather fishy, and I wouldn't be surprised if this argument gets dropped later. The patent suit is like all others, and has little if anything to do with the spirit of java, etc..
On a philosophical sense, Oracle is correct. Android may never claim to be Java, but anyone who isn't a retard knows that Google is enticing Java developers into their pseudo-compatible platforms. From a personal perspective, it is annoying porting existing java apps into AppEngine / Android. The standard class libs limitations make interoperability between stock java and Google's platforms more difficult. This IS similar to the tack that Microsoft made proprietary core feature additions. Microsoft was never forced to use Java when coming up with their proprietary JVM. They chose java because it had buzz, and they assumed it would be next good language to assimilate and conquer. I don't think Google wants to kill Java, but I think they want to steal the large pool of existing Java developers and coerce them to use their platforms. Does this diversity hurt java (the language) in the end? Yes. Much of the advantage of java is in the rich set of additions built upon existing platforms. If those libraries now have to choose which platform to track against, it means two versions of common libraries, and smaller guys may just not bother to support J2SE,Android,AppEngine,GWT, etc...
Add speed bumps into the road. Depending on how fast the road speeds are supposed to be, you can make the bumps smoother for faster areas and higher for slow traffic ones (like before what should be a 4-way stop / light).