Reply
Distinguished Bibliophile
bobstro
Posts: 4,070
Registered: ‎01-01-2012
0 Kudos

The PPSS thread on Android, Java, JVM, DVM

[ Edited ]

Continuing the discussion from the "Java" thread that's drifted away from the OP's problem, I've started this thread where we can expound about things that won't help the OP.

 

Deesy58 wrote:

Is it true that ALL Android devices have the Dalvik Virtual Machine (DVM) installed in order to run apps? 

 

I'd be hestitant to say ALL, but most, yes. I suppose one could hack together something that didn't run DVM (perhaps just using the Linux underpinnings of the OS?) but that's best left as an exercise to the reader.

 

Could the DVM also run Java byte-code?

 

Well, there's this to consider: "... There is no Java Virtual Machine in the Android platform. Java byte code is not executed. Instead Java classes are compiled into Dalvik executables and run on Dalvik, a specialized virtual machine (VM) designed specifically for Android. Unlike Java VMs, which are stack machines, the Dalvik VM is a register-based architecture."

 

So you can write Android programs in the Java language, but it's not going to run on a Sun/Oracle Java VM. Mind you, a lot of code can probably be written to execute in either.
, but there are also dependency issues. I'm no big-time developer, but there would be two considerations:

 

  1. If Android features are required, there would presumably be dependencies on the Android SDK (FT's point).
  2. If Java features NOT supported on Android (AWT, Swing) are required, unsupported functions and the like, then it won't work without being modified to use the Android equivalents.

Is it the case that none of the browsers available for the NOOK products has the ability to execute JavaScript?

 

I think they support some Javascript, but many sites have moved completely off of Flash and to HTML5+CSS3, which probably are not fully supported by the stock browsers.

 

Again, to emphasize: Javascript is not Java, which might be part of the OP's issue in the original thread.

 

Inspired Bibliophile
deesy58
Posts: 2,486
Registered: ‎01-22-2012
0 Kudos

Re: JAVA Revisited


bobstro wrote:

Continuing the discussion from the "Java" thread that's drifted away from the OP's problem, I've started this thread where we can expound about things that won't help the OP.

 

Deesy58 wrote:

Is it true that ALL Android devices have the Dalvik Virtual Machine (DVM) installed in order to run apps? 

 

I'd be hestitant to say ALL, but most, yes. I suppose one could hack together something that didn't run DVM (perhaps just using the Linux underpinnings of the OS?) but that's best left as an exercise to the reader.

 

Could the DVM also run Java byte-code?

 

Well, there's this to consider: "... There is no Java Virtual Machine in the Android platform. Java byte code is not executed. Instead Java classes are compiled into Dalvik executables and run on Dalvik, a specialized virtual machine (VM) designed specifically for Android. Unlike Java VMs, which are stack machines, the Dalvik VM is a register-based architecture."

 

So you can write Android programs in the Java language, but it's not going to run on a Sun/Oracle Java VM. Mind you, a lot of code can probably be written to execute in either.
, but there are also dependency issues. I'm no big-time developer, but there would be two considerations:

 

  1. If Android features are required, there would presumably be dependencies on the Android SDK (FT's point).
  2. If Java features NOT supported on Android (AWT, Swing) are required, unsupported functions and the like, then it won't work without being modified to use the Android equivalents.

Is it the case that none of the browsers available for the NOOK products has the ability to execute JavaScript?

 

I think they support some Javascript, but many sites have moved completely off of Flash and to HTML5+CSS3, which probably are not fully supported by the stock browsers.

 

Again, to emphasize: Javascript is not Java, which might be part of the OP's issue in the original thread.

 


If not all Android devices have the ability to execute programs, how would they be at all useful?  Unless the Android device has the capability of compiling and linking binary code, like that produced by C and C++, how could it execute any applications at all?  Remember, an Operating System (OS) is not an application. 

 

Hmm.  I believe that I already pointed out that the Android OS uses the Dalvik Virtual Machine, rather than the Java Virtual Machine, and I cited my sources for that information.  What has not been answered, however, is whether the DVM can execute Java byte-code.  The descriptions in the Wikipedia article can be interpreted either way (no pun intended), so it is still not clear whether Java applications presented by a gaming Web site could be executed by an Android device. 

 

Whether a machine (bare metal or virtual) is a stack machine or a register-based machine makes no difference.  If the code is compiled properly, it will execute correctly. 

 

"So you can write Android programs in the Java language, but it's not going to run on a Sun/Oracle Java VM."  Huh?  I guess I am missing your point because this makes no sense to me.  Sorry.  If I write a program in the Java language, why would it not run on a Sun/Oracle Java Virtual Machine? 

 

Your #1: Yes.  But that's a big if.  The implication is that if no Android-specific extensions are included in the code, that it would run.  Is this not true?  I'm asking.  I do not know the answer. 

 

Your #2:  The same response. 

 

My understanding of the primary differences between Android and other versions of the Linux Operating System is that Android was designed especially for use on devices with touch screens like smart phones and tablets, rather than devices that use mice and keyboards for interfacing with the user. 

 

Not sure I understand your next point.  As I understand it, Flash and Javascript are different animals.  Flash contains a scripting capability called "Actionscript," but is has a number of differences from Javascript.  HTML5 and CSS3 are still relatively new, so I expect it will take a while before they become integrated into some browsers. 

 

It is still not clear whether a NOOK Tablet with any available browser is able to execute Javascript, which is executed by the browser, and not by a virtual machine. 

 

In any event, it appears that, while the primary Web pages on the pogo.com Web site use Javascript, one must download some of the games in order to play them (Bejeweled, for example).  If the game must be downloaded, it could certainly be written in Java, and be executed by a JVM.  In fact, it probably is written in Java.  Isn't this correct?

 

 

 

Distinguished Bibliophile
bobstro
Posts: 4,070
Registered: ‎01-01-2012
0 Kudos

Re: JAVA Revisited

deesy58 wrote:
Hmm.  I believe that I already pointed out that the Android OS uses the Dalvik Virtual Machine, rather than the Java Virtual Machine, and I cited my sources for that information. 
I didn't say you didn't.

What has not been answered, however, is whether the DVM can execute Java byte-code. 

 

The descriptions in the Wikipedia article can be interpreted either way (no pun intended), so it is still not clear whether Java applications presented by a gaming Web site could be executed by an Android device. 

 

Whether a machine (bare metal or virtual) is a stack machine or a register-based machine makes no difference.  If the code is compiled properly, it will execute correctly.

 

No idea. Have you tried it? You seem fascinated by the idea, so you should probably try it yourself and gain some enlightenment.  I can drop a lot of Java source code into either development environment and have it compile, but that's not what you seem to be describing. In any full application, I'd expect there to be problems with dependencies, but that doesn't mean a contrived example wouldn't work. Let us know what you find out and post the details here.

 

"So you can write Android programs in the Java language, but it's not going to run on a Sun/Oracle Java VM."  Huh?  I guess I am missing your point because this makes no sense to me.  Sorry.  If I write a program in the Java language, why would it not run on a Sun/Oracle Java Virtual Machine? 

 

Dependencies. You could modify the source code and compile for the other environment if you wanted to port it. User interface dependencies (e.g. swing JDK widgets) are one example cited. Lack of mouse on an Android device and lack of touch input on a desktop are obvious potential problems.

 

Your #1: Yes.  But that's a big if.  The implication is that if no Android-specific extensions are included in the code, that it would run.  Is this not true?  I'm asking.  I do not know the answer. 

 

You could presumably write something that is pure java with no external dependencies and have it execute as an intellectual exercise, but if user interface is one of the areas where the two environments differ, an actual user might not be able to do anything useful with it.

 

Your #2:  The same response. 

 

Same answer.

 

My understanding of the primary differences between Android and other versions of the Linux Operating System is that Android was designed especially for use on devices with touch screens like smart phones and tablets, rather than devices that use mice and keyboards for interfacing with the user. 

 

Exactly. The Android SDK provides interfaces that expose Android device features (e.g. touch, phone) to the programmer as FT noted, just like Oracle's Foundation Classes expose desktop features (e.g. mouse) to the desktop app programmer. You have to code to the environment it will run on. That's not to say that you couldn't write code with conditional compilation directives and make one source file compile for both. Again, though, I think that's more of an intellectual exercise than something you'd want to do in practice. The good news is that you can develop for either environment using free software tools, so there's no reason you couldn't spend a pleasant afternoon or forty finding out for yourself.

 

Not sure I understand your next point.  As I understand it, Flash and Javascript are different animals.  Flash contains a scripting capability called "Actionscript," but is has a number of differences from Javascript.  

 

You asked if none of the Android browsers supported Javascript. I wrote "I think they support some Javascript, but many sites have moved completely off of Flash and to HTML5+CSS3, which probably are not fully supported by the stock browsers." So while some Android browsers may support Javascript, that same browser may not support other of technologies that sites moving off of Flash require (HTML5+CSS3), and possibly lack some Javascript features. The suite of Javascript+HTML5+CSS3 is the foundation on which a lot of the "flash-less" sites depend today. To run the popular browser-based apps today, you typically will need either Flash, or the alternate suite.

 

HTML5 and CSS3 are still relatively new, so I expect it will take a while before they become integrated into some browsers.

 

These technologies do work well on the current generation of Chrome, Firefox and other "big name" browsers on Android. That's why Google was so confident in dropping Flash support from Chrome. There are some annoying differences in capabilities between them, but this is nothing new in the world of Internet browsers.

 

It is still not clear whether a NOOK Tablet with any available browser is able to execute Javascript, which is executed by the browser, and not by a virtual machine. 

 

Not sure what you're getting at. Javascript works fine in many browsers on Android today, and can be used (along with HTML5 and CSS3) to develop "hybrid" apps, where the Android SDK specific features are used for device-specific capabiltiies, but device-independent "web" code handles the bulk of the application code. This provides some degree of device-independence for the coder, while still providing "native" app features that can be distributed through an app store. You can code the shell using Android SDK features, and have that single shell deliver a variety of apps in a window using that non-Android specific web suite.

 

In any event, it appears that, while the primary Web pages on the pogo.com Web site use Javascript, one must download some of the games in order to play them (Bejeweled, for example).  If the game must be downloaded, it could certainly be written in Java, and be executed by a JVM.  In fact, it probably is written in Java.  Isn't this correct?

 

With the pogo Android app installed, those games work. The same games appear to use Flash and/or Javascript+HTML5+CSS3 (I'm not sure across all their games) when run in the browser, so clearly something is different between what runs in the app or in the browser. I'm honestly not sure (and not all that interested.)

 

I would be surprised if pogo went the 100% native Android (Java) app though, when using a hybrid approach would let them deliver an Android wrapper hybrid app in the Google Play Store that can simply execute device-independent Javascript+HTML5+CSS3 in a window to deliver their library of games. A similar wrapper app on Apple devices could deliver that same web code on Apple devices. I'm not privy to their EA's internal strategies, and don't feel like reverse engineering them tonight.

 

You could certainly figure it out with some effort if you care to. You obviously are intrigued by all this, so please report back with your results so we can discuss them at length.

Inspired Bibliophile
deesy58
Posts: 2,486
Registered: ‎01-22-2012
0 Kudos

Re: JAVA Revisited

I have not tried it.  I do not possess either the JDK or the Android SDK.  Nor do I (at this time) have the resources to install them.  I recently removed my C and C++ development capabilities from my machine.

I am not "fascinated" by the idea.  I merely asked in an attempt to see if there might be a less radical solution available to the poster than rooting his/her NOOK Tablet.  It appears that there are a number of posters on this forum who are more familiar with Android app development than I am.  Is it asking too much for them to share a little bit of their knowledge?

You are correct that I am not describing the compilation portion of the process, but the execution.  Java was developed to be a WORA (Write Once, Run Anywhere) programming language.  If one can no longer really run it anywhere, is it really still Java?  According to flyingtoastr, the answer would be "no."  According to you, it would appear to be "yes."  I am merely trying to determine which of you is correct.  If that is too much, please forget that I asked.  It really isn't all that important. 

Dependencies?  Are you describing an attempt to run Dalvik dex-code on a Sun/Oracle JVM, and not Java byte-code on a Sun/Oracle JVM?  I thought I had read your post correctly to say that Java byte-code could not be run on a JVM, and I think that is not correct.  After all, that's exactly what the JVM was designed to do.  Obviously I have not correctly understood the substance of your post.  Sorry.

Asserting that any attempt would be a purely intellectual exercise assumes that there is no overlap at all with the dependencies.  I'll have to take your word for it because I don't know. 

Why should I take the time and make the effort to discover something that is already known, and that can be learned by less time-consuming means?  I'm sure that the information is available someplace, and if I cared enough, I would go find it.  There is no shame, bobstro, in admitting that you don't know the answer to a question(s) posed on this forum.  You seem to take personal offense that anybody dared to ask a question that you are not prepared to answer.  Please understand, no offense is intended.

The subject of Javascript was introduced by you.  You asserted that the pogo.com Web site used Javascript.  Many, many Web sites use Javascript.  Javascript is, to the best of my knowledge, executed by the browser, and not by a virtual machine of any sort.  I simply asked whether, if only Javascript is required to execute the gaming software on pogo.com, the browsers that are available for the NOOK Tablet (an Android device) had the capability to execute Javascript.  Flash is not Javascript, and, until recently, even Apple devices could not execute Flash scripts.  I believe that my question is much more simple than you imply: If only Javascript is required to execute the games at pogo.com, then why can't the browsers available for NOOK Tablets play those games? 

My question remains unanswered.  Are Chrome, FireFox and other "big name" browsers available for an unrooted NOOK?  Can a NOOK Tablet execute the same applications programs (apps) as the "big name" browsers?  I ask because I don't know, not for the purpose of starting/continuing an argument.  I own a NOOK Tablet.  I use it exclusively for reading books, working crossword puzzles, and checking the weather with my weather app.  I do not browse the Web with it. 

What I am getting at is to learn whether it is possible, as you seemed to imply, to play games at pogo.com if a user's browser is capable of running Javascript.  Nothing more than that.

The reason I asked was because it doesn't seem all that likely that a user would be required to download a game in order to play it if it could be executed from within the browser.  It seemed more likely  to me that the game software that must be downloaded might be pure Java byte-code, requiring a JVM to execute.  I really do not know if this is correct.  That's why I asked.  Now that I understand that you are not sure, and are not interested, I will withdraw my question.

I accessed the pogo.com game store using my desktop machine running Windows 7.  It seems to me that the ability to download and run a game (Bejeweled, for example) on a Windows device would preclude the ability to run that same game on an Android device unless the code was executable by a Java Virtual Machine which was capable of handling both sets of dependencies.  That is, unless I have missed something else. 

Oh well, it obviously isn't really all that important to you, and it isn't to me, either.  No point in discussing anything at length if we're not really interested, IMO.

Distinguished Bibliophile
bobstro
Posts: 4,070
Registered: ‎01-01-2012
0 Kudos

Re: JAVA Revisited

[ Edited ]

deesy58 wrote:

I have not tried it.  I do not possess either the JDK or the Android SDK.  Nor do I (at this time) have the resources to install them.  I recently removed my C and C++ development capabilities from my machine.

 

The entire Android development suite is freely available. That's one of the attractions of Android for me personally. If you ever are interested, it can be worth checking out.

I am not "fascinated" by the idea.  I merely asked in an attempt to see if there might be a less radical solution available to the poster than rooting his/her NOOK Tablet.

 

Ah, if that was your point, it wasn't clear in your post. It appeared to be a deep-dive into Java and Android internals with no relation to either the OP or Jojo's issues.

 

The immediate problem you'd face is how to get your bytecode on to the device in any way you could execute it. I don't know how you'd do that without rooting the device. At that point, loading the pogo.com Android app from GoPS would be simpler.

 

It appears that there are a number of posters on this forum who are more familiar with Android app development than I am.  Is it asking too much for them to share a little bit of their knowledge?

 

No, not a bit. That's why I started the this thread. As I wrote before, there's nothing wrong with the topic, it just won't help with the problems described.

You are correct that I am not describing the compilation portion of the process, but the execution. 

 

I won't say it can't be done, but rather that doing so would not be trivial and the results likely not worth the effort. And of course, some clever soul could always write a program to make something work. You can, for example, load a program that will allow scripts written in Python execute on an Android device will a high degree of access to Android APIs. There are already game console emulators on Android, and Android devices are getting more powerful every day. I think the odds of this approach working on a NOOK Tablet, particularly an urooted one, are effectively zero.

 

Java was developed to be a WORA (Write Once, Run Anywhere) programming language.  If one can no longer really run it anywhere, is it really still Java?

 

Sun/Oracle Java was meant to fill that role, and Java source code compiled down to byte code should be portable between any Sun/Oracle Java runtime environment, regardless of the underlying OS or hardware in theory. In practice, it breaks down in many ways, but it is true that I can load a compiled Java app on Windows and the same on Linux, for example. How "native" the app looks, and how well it performs sometimes falls short of expectations. There are mainstream apps that work well (e.g. WebEx, I believe).

 

According to flyingtoastr, the answer would be "no."  According to you, it would appear to be "yes."  I am merely trying to determine which of you is correct.  If that is too much, please forget that I asked.  It really isn't all that important. 

 

No, it's not too much to ask, and in this thread, it's a good on-topic question. I'll try to answer more clearly to the best of my ability. Keep in mind, I make no claim to be an expert, nor necessarily correct on every detail. I'm just answering based on my experience and understanding.

 

The key difference that I think you are touching on is that Android apps are written in the Java language, but do not target to the Sun/Oracle Java runtime environment. They target a different (Android) runtime environment which is significantly different, and (I believe) quite incompatible. They'll be (more-or-less) portable between Android devices supporting a sufficiently complete and compatible Android runtime environment. So FT's point about the Android SDK was correct -- they need to target the Android runtime, which the Android SDK exposes to the programmer.

Dependencies?  Are you describing an attempt to run Dalvik dex-code on a Sun/Oracle JVM, and not Java byte-code on a Sun/Oracle JVM?  I thought I had read your post correctly to say that Java byte-code could not be run on a JVM, and I think that is not correct.  After all, that's exactly what the JVM was designed to do.  Obviously I have not correctly understood the substance of your post.  Sorry.

 

I'm saying that a compiled program targeting the Sun/Oracle runtime environment won't work on the Android runtime environment and vice-versa (in general). The dependencies I refer to are specifically device capabilities and interfaces.

Asserting that any attempt would be a purely intellectual exercise assumes that there is no overlap at all with the dependencies.  I'll have to take your word for it because I don't know. 

 

I don't think there would be any practical reason to go to all the effort. The target devices for each runtime environment are very different. I also suspect that write once, run anywhere has shifted recently (more below).

Why should I take the time and make the effort to discover something that is already known, and that can be learned by less time-consuming means?  I'm sure that the information is available someplace, and if I cared enough, I would go find it. 

 

This is my point, Deesy. You responded to a support thread with what certainly appears to have been a topic of only mild interest to yourself, and pursued it across several posts in that thread. That doesn't seem overly helpful, and certainly came across as "enough about your problem, let's talk about something I find interesting."

 

There is no shame, bobstro, in admitting that you don't know the answer to a question(s) posed on this forum.  You seem to take personal offense that anybody dared to ask a question that you are not prepared to answer.  Please understand, no offense is intended.

 

I haven't taken offense. I've gone to the effort of attempting to respond clearly because it helps me clarify my own thinking and understanding. I've always enjoyed teaching computer topics for this very reason, and continue to do so on the side today. In a thread on this topic, this discussion is fine.

The subject of Javascript was introduced by you.  You asserted that the pogo.com Web site used Javascript.

 

It does, yes. Other web technologies as well (more below).

 

Many, many Web sites use Javascript.

 

That is correct.

 

Javascript is, to the best of my knowledge, executed by the browser, and not by a virtual machine of any sort.

 

Yes. It's more of a scripting language than compiled like Java. You can, for example, edit a web page containing Javascript and refresh the page to see the results immediately, with no intermediate steps. (Generally.)

 

I simply asked whether, if only Javascript is required to execute the gaming software on pogo.com, the browsers that are available for the NOOK Tablet (an Android device) had the capability to execute Javascript.

 

The stock NT browser has some support I believe. (I gave my NT away, so can't verify.) I am not sure how complete its support is, particularly of some of the newer Javascript features. I also don't know all of the details about how pogo.com works, but many web sites use a combination of Javascript, HTML5 and CSS3. On such sites, the browser needs to support all features reasonably well, which I doubt the aged NT browser would.

 

Flash is not Javascript, and, until recently, even Apple devices could not execute Flash scripts.  I believe that my question is much more simple than you imply: If only Javascript is required to execute the games at pogo.com, then why can't the browsers available for NOOK Tablets play those games? 

 

Let me take another stab at this:

 

Until recently, Flash was one of, if not the, most popular mechanisms for supporting advanced features such as animation, sychronized sound and other "pretty" capabilities on browsers in any sort of cross-platform way.

 

The reason Apple stated for not supporting Flash was that they (meaning Jobs) felt that open web standards, mainly HTML5, could provide the same experience without using proprietary Adobe products. Google seems to have gone along, dropping Flash support in the Android Chrome browser. This is why we've seen all the screaming from users still trying to use Flash-based sites on these browsers.

 

Since the original uproar, the more proactive web sites have transitions, partially or in full, to using HTML5 (enhanced with Javascript and CSS3) to eliminate the need for Flash to support some or all of their functionality. This is generally perceived as a "good thing", and I believe was behind Adobe's decision to drop support for Flash on Android.

 

Some sites, pogo.com included, do seem to use some Flash. (How much, I'm not sure.)

 

When Jojo responded to the question of "why Java" with the answer "to run games on pogo.com", I suspected he/she was confusing Javascript with Java since, so far as I can see, pogo.com does not use Java in the browser. To access the games on pogo.com in the browser, you need a browser that supports Flash for some older stuff. You may need a browser that supports advanced HTML5/CSS3/Javascript features (I'm not 100% sure). Alternately, you can load and run the Pogo app from GoPS. Do do any of these things will likely require root. Thus my suggestion.

 

So to be concise: I believe Jojo confused Java with Javascript. I believe that pogo.com requires some combination of Flash and/or HTML5+CSS3+Javascript not available in the NT browser.


My question remains unanswered.  Are Chrome, FireFox and other "big name" browsers available for an unrooted NOOK?  Can a NOOK Tablet execute the same applications programs (apps) as the "big name" browsers?  I ask because I don't know, not for the purpose of starting/continuing an argument.

 

There are many alternate browser available in the NOOK app store. One or more of them may provide the features necessary. A better experience can probably be had by loading the Pogo app which is the suggestion strongly made on the site.

 

[...] What I am getting at is to learn whether it is possible, as you seemed to imply, to play games at pogo.com if a user's browser is capable of running Javascript.  Nothing more than that.

 

It might be, but the pogo site recommends the Android app. I assume they do so to avoid having to support a variety of browsers with varying support for whatever web development standards pogo.com uses. To be clear: I am not suggesting that only Javascript is necessary. I think Jojo confused Java with Javascript.

The reason I asked was because it doesn't seem all that likely that a user would be required to download a game in order to play it if it could be executed from within the browser.  It seemed more likely  to me that the game software that must be downloaded might be pure Java byte-code, requiring a JVM to execute.  I really do not know if this is correct.  That's why I asked. Now that I understand that you are not sure, and are not interested, I will withdraw my question.

 

Games of the sort offered at that site annoy me, so I don't want to dive deeply into it. I would be very suprised if pogo (EA) re-wrote every game, so they seem to be delivering them in some sort of platform-independent way with their Android app. I suspect that app is a "hybrid" of the sort I pointed to in my previous post, which allows them to offer a "native" app in the app stores that deals with Android hardware, but serves up web content in a window. That content might be Flash, or HTML5+CSS3+Javascript. If their games didn't drive me bonkers, I might try a few to try to find out. What is interesting to me is that they seem to have done a nice job pulling it off in the first place. Unfortunately for Jojo, their app must be installed on an NT to enjoy it.


I accessed the pogo.com game store using my desktop machine running Windows 7.  It seems to me that the ability to download and run a game (Bejeweled, for example) on a Windows device would preclude the ability to run that same game on an Android device unless the code was executable by a Java Virtual Machine which was capable of handling both sets of dependencies.  That is, unless I have missed something else. 

 

I think Bejeweled uses Flash, but I don't know if it does so on every device, nor whether every game has been done the same way. Many web sites are transitioning away from Flash quickly. There are large numbers of online tutorials and YouTube videos showing techniques to move from Flash to HTML5 in a fairly straightforward manner, and a lot of freely available Javascript frameworks are available that allow a fairly seamless transition. These frameworks make extensive use of HTML5, and often CSS3 as well.


Oh well, it obviously isn't really all that important to you, and it isn't to me, either.  No point in discussing anything at length if we're not really interested, IMO.

 

pogo.com is not interesting to me. (Then again, I don't like AC racing either. :smileyhappy:)

 

The only reason I know any of this is that my son has recently entered the field and keyed me in to modern Javascript programming. When last I'd looked, Javascript was good for delivering annoying browser eyecandy, so I'd ignored it. It has evolved dramatically, to say the least. He's taught this old dog some new tricks, and I'm still learning. The delightful part for me is that I'm finally enjoying coding again after a 23+ year absence brought on by frustration with Microsoft.

 

If you are interested in what's happening with browser-based development (and not popping baloons), I'd recommend spending a half hour watching some of the AngularJS YouTube videos. Electronic Arts (pogo.com) has a YouTube video on HTML5 canvas, which I why I strongly suspect they're going that route.

 

The fun part of the Javascript framework development is that you can, literally, try it out with only a web browser and a text editor.

Inspired Bibliophile
deesy58
Posts: 2,486
Registered: ‎01-22-2012
0 Kudos

Re: JAVA Revisited

The question that was asked, but not adequately answered, was whether it was possible to translate Dalvik ".dex" files into Java byte code for execution by a JVM.  The answer appears to be "yes."

 

The Dare Project at Penn State University, sponsored by the National Science Foundation, has developed a tool that "retargets Android applications in .dex or .apk format to traditional .class files. These .class files can then be processed by existing Java tools, including decompilers. Thus, Android applications can be analyzed using a vast range of techniques developed for traditional Java applications."

 

http://siis.cse.psu.edu/dare/

 

Not sure if this adds anything of value to the discussion, but it seems to answer the unanswered question.

 

 

 

 

 

Distinguished Bibliophile
bobstro
Posts: 4,070
Registered: ‎01-01-2012
0 Kudos

Re: JAVA Revisited

[ Edited ]

That's going the other way though, decompiling and app compiled for Android DVM to Java .class files. There are books on decompiling Android apps if you're interested. While this might let you analyze the Android app, it doesn't sound like it'd run in a JVM without modification and compiling. Presumably, you could decompile JVM bytecode, but that also just gives you ersatz source code that wont run without recompiling.

 

There is a Windows app to emulate Android on a PC, but again, they don't run in JVM.

 

 

 

 

Inspired Bibliophile
deesy58
Posts: 2,486
Registered: ‎01-22-2012
0 Kudos

Re: JAVA Revisited


bobstro wrote:

(...)   

The key difference that I think you are touching on is that Android apps are written in the Java language, but do not target to the Sun/Oracle Java runtime environment. They target a different (Android) runtime environment which is significantly different, and (I believe) quite incompatible. They'll be (more-or-less) portable between Android devices supporting a sufficiently complete and compatible Android runtime environment. So FT's point about the Android SDK was correct -- they need to target the Android runtime, which the Android SDK exposes to the programmer.

--  Java was designed and implemented for the very purpose of allowing computer programs to be run on differing "runtime environments."  So different, in fact, that it was intended to run on different, incompatible, hardware -- like the X86 and the Power PC CPU types, as well as the ARM and Atom processors.  What could be more different than that?

--  I believe that any program written in the Java programming language should be able to be compiled into an intermediate code (dex code or byte code) that will run on a virtual machine on any computing platform, including Android.  Why would this not be true?  The whole purpose of Java is to not be required to rewrite source code. 

(...)   

     This is my point, Deesy. You responded to a support thread with what certainly appears to have been a topic of only mild interest to yourself, and pursued it across several posts in that thread. That doesn't seem overly helpful, and certainly came across as "enough about your problem, let's talk about something I find interesting."

--  I responded directly to the problem posed by poster Jojo480.  Specifically, I asked a couple of questions that were pertinent to the problem posed: "If all Android apps are written in Java, then mustn't all Android devices have a Java Runtime Environment (Java Virtual Machine) installed in order to execute those Java apps?  If one is not developing new Java apps, then one doesn't need a Java compiler, right?"

-- I interpreted your response that "If you root your NT, you cantry the pogo Android app from the Google Play Store" to be a bit terse, and lacking in useful information.  I was trying to elicit information that might provide a "work around" for user Jojo480 to find a way to access the games on the pogo.com Web site.  I'm sorry that you became so upset at my attempt to contribute.

(...)
    
    The stock NT browser has some support I believe. (I gave my NT away, so can't verify.) I am not sure how complete its support is, particularly of some of the newer Javascript features. I also don't know all of the details about how pogo.com works, but many web sites use a combination of Javascript, HTML5 and CSS3. On such sites, the browser needs to support all features reasonably well, which I doubt the aged NT browser would.

--  The entire topic of Javascript is a Red Herring.  Javascript might be used on the Web site, but it would make little sense to infer that Javascript has anything at all to do with playing the games themselves.  A device might be perfectly capable of executing Javascript in its browser(s), but still be incapable of downloading and playing games from pogo.com.

(...)

    So to be concise: I believe Jojo confused Java with Javascript. I believe that pogo.com requires some combination of Flash and/or HTML5+CSS3+Javascript not available in the NT browser.
    
--  It does not appear that Jojo was confused at all.  Because the Pogo Game Manager must be downloaded and installed on a user's device, Java would certainly be more appropriate than Javascript for that purpose.  I will describe what I have discovered about this Web site later in this post.

(...)

    It might be, but the pogo site recommends the Android app. I assume they do so to avoid having to support a variety of browsers with varying support for whatever web development standards pogo.com uses. To be clear: I am not suggesting that only Javascript is necessary. I think Jojo confused Java with Javascript.

--  I believe that you might have been confused by your access to pogo.com with a rooted NOOK.  I accessed the site with three different devices, running three different Operating Systems (I succumbed to my curiosity).  Here is what I learned:

Windows -- If pogo.com is accessed using Windows 7, the site requires that a user download and install the Pogo Games Manager.  If the user does so, a set of Windows executables will be downloaded and installed.  All of them will have the .exe file extension, but additional files will also be downloaded.

If the user goes on to install the Bejeweled game, an additional set of files will be downloaded into the "ProgramData" directory/folder.  Again, it appears that a Windows executable program will actually execute the game.

Apple iPad --  I accessed the pogo.com Web site with an Apple iPad 3 running iOS 6.x using the Dolphin browser.  When selecting a game, I am instructed to update my Flash player, and a link is presented to "GET THE LATEST VERSION HERE."  If the link is selected, the user is taken to the "get.adobe.com/flashplayer/" Web site.  The site defaults to my Operating System being "Mac OS X," "English," and "Safari."  No option is offered for any version of iOS.  If the "DOWNLOAD NOW"  button is selected, the file "install_flash_player_osx(2).dmg" is downloaded.  That completes Step 2 of 3 steps.  Step 3 of 3 simply hangs up (not surprisingly) and proceeds no further.  The "Finished" button appears to have no effect.  Perhaps the Adobe Flash Player might be able to be installed with iOS 7, but I am not, yet, willing to download and install iOS 7.  Results:  The Pogo Games Manager cannot be installed on an iPad 3 running iOS 6.x without "jailbreaking" the Operating System. 

NOOK Tablet --  When accessing the pogo.com game site, the user is presented with a screen that "FREE pogo Games Android App is here!  Play your favorite Pogo games in 1 app."   A button is displayed with the label "Get it Now."  Selecting that button takes the user to the Google Play Store.  At the top of the Google PS screen is a logo and legend referring to POGO Games.  Two choices are offered: "Install" and "Add to Wishlist."  If the "Install" button is selected, the entire screen of the NT will grey out, and will remain that way indefinitely.

It seems clear that the pogo.com Web site detects the platform of the accessing user, and offers different advice as a result of its findings.  Perhaps that is one function of the Javascript you saw on the Web page.  Since it seemed to correctly detect the device/platform on each of three different devices, it is clear that it (Javascript) is working correctly on all three different platform/browser combinations.  After that, however, the next actions differ greatly.  Clearly, Windows uses executables (binary), Apple uses Adobe Flash for at least a part of the process, and Android uses the Google Play Store, which is locked out from NOOK Tablets.  It is not clear how far the process gets with a NOOK Tablet.  In other words, it isn't clear whether the NOOK Tablet hangs up because it cannot interpret dex code (unlikely), or whether some other mechanism is preventing the installation of access to Pogo games.  I do not have the resources necessary to make this determination. 

Aren't the NOOK HD and HD+ able to access Google Play?  Might it have been more useful to Jojo480 to advise that he/she consider upgrading to a newer version of the B&N Nook Tablet?

(...)

    Games of the sort offered at that site annoy me, so I don't want to dive deeply into it. I would be very suprised if pogo (EA) re-wrote every game, so they seem to be delivering them in some sort of platform-independent way with their Android app. I suspect that app is a "hybrid" of the sort I pointed to in my previous post, which allows them to offer a "native" app in the app stores that deals with Android hardware, but serves up web content in a window. That content might be Flash, or HTML5+CSS3+Javascript. If their games didn't drive me bonkers, I might try a few to try to find out. What is interesting to me is that they seem to have done a nice job pulling it off in the first place. Unfortunately for Jojo, their app must be installed on an NT to enjoy it.

--  It seems unlikely that Pogo (EA) would rewrite every game.  It seems clear, however, that the company offers different solutions for different platforms.  It appeared to me by looking at the files installed on my Windows 7 machine that Pogo might install an "engine" that actually runs the games, something like a virtual machine.  You seem focused on Web and browser technology.  I do not believe that HTML5, CSS3 or Javascript plays any significant part in the playing of the games.  I could be mistaken, but I have not, yet, seen evidence that they are.  Flash and Javascript might, indeed, be required to access and download Pogo's games, but it seems unlikely that they would also be required to play those games. 

(...)

    The fun part of the Javascript framework development is that you can, literally, try it out with only a web browser and a text editor.

I have completed an on-line course in Javascript from a reputable training organization, so I am familiar with Javascript.  I also have Adobe CS5, so I can tinker to my heart's delight. 

Inspired Bibliophile
deesy58
Posts: 2,486
Registered: ‎01-22-2012
0 Kudos

Re: JAVA Revisited


bobstro wrote:

That's going the other way though, decompiling and app compiled for Android DVM to Java .class files. There are books on decompiling Android apps if you're interested. While this might let you analyze the Android app, it doesn't sound like it'd run in a JVM without modification and compiling. Presumably, you could decompile JVM bytecode, but that also just gives you ersatz source code that wont run without recompiling.

 

There is a Windows app to emulate Android on a PC, but again, they don't run in JVM.

 


I think you missed the point.

 

The point is: This is a method for producing (translating) Java source code from Dalvik dex code.  "Ersatz" is a strong term chosen by you and offered without a shred of evidence that the resultant program would be inferior in any way.  Of course it would have to be recompiled.  That's the way Java works.  That's also the way Android works.  Note that the Dalvik system appears to require recompilation every single time  a program is run, unlike Java.  That doesn't seem very efficient, and it takes away one of the benefits of pre-compiled WORA code (it makes it easy to be proprietary, however).  What makes you so sure that the Dalvik system wasn't chosen by Google for strictly business reasons?

 

Sun/Oracle Java will work on a smart phone, for example.  http://www.ehow.com/how_7181654_enable-java-smartphone.html

 

Since Oracle offers a development kit (SDK) for Java ME (Mobile Edition?) for smart phones (http://www.oracle.com/technetwork/java/javame/javamobile/training/jmesdk/index.html), it seems unlikely that hardware is a limiting factor for the use of Oracle/Sun Java, or that it is the real reason why genuine Java is not offered on Android devices. 

 

Perhaps there really are technical reasons.  Perhaps you could discover them and share them with us.  It would be nice to know if the real reason why Java byte code cannot (apparently) be interpreted by an Android device has anything to do with dependencies, or if it is just because Google is attempting to make its technology proprietary.  I don't know the answers, but I am not prepared to trust Google.  :smileyfrustrated:

Distinguished Bibliophile
bobstro
Posts: 4,070
Registered: ‎01-01-2012
0 Kudos

Re: JAVA Revisited

[ Edited ]
deesy58 wrote:

--  Java was designed and implemented for the very purpose of allowing computer programs to be run on differing "runtime environments."  So different, in fact, that it was intended to run on different, incompatible, hardware -- like the X86 and the Power PC CPU types, as well as the ARM and Atom processors.  What could be more different than that?

 

As long as you have the correct runtime environment, that's probably still a correct statement. I have no way of testing, other than to say that Java apps targeting the Sun/Oracle JRE can work (see below) cross-platform with the appropriate JRE browser plugin (mostly on desktops).

 

The trick is to have that JRE. I am not aware of any software that will allow apps compiled for the Sun/Oracle JRE to run unmodified on an Android device. There appear to have been various compatibility layers/emulation available in the past, but most seem to have been discontinued. Not to say that they don't exist, but I haven't seen them.

--  I believe that any program written in the Java programming language should be able to be compiled into an intermediate code (dex code or byte code) that will run on a virtual machine on any computing platform, including Android.  Why would this not be true?  The whole purpose of Java is to not be required to rewrite source code. 

 

If you (theorectically) had a Sun/Oracle JRE on Android, it should work. I'm not aware of one to try. It's not the same thing as the DVM. If you want to argue decisions made for Android, you might have more luck writing to Google about it. If you want to insist it will work, you should probably try it for yourself. :smileyhappy:

--  I responded directly to the problem posed by poster Jojo480.  Specifically, I asked a couple of questions that were pertinent to the problem posed: "If all Android apps are written in Java, then mustn't all Android devices have a Java Runtime Environment (Java Virtual Machine) installed in order to execute those Java apps? 

 

Because Android apps are written in the Java language and compiled targeting the Android (DVM) environment. Jojo seems to have been confused about what he's after. Throwing a lot of detail about something that won't help him ... won't help him. Pogo.com doesn't look to use java browser plugins at all. 

 

If one is not developing new Java apps, then one doesn't need a Java compiler, right?"

 

Correct.

-- I interpreted your response that "If you root your NT, you cantry the pogo Android app from the Google Play Store" to be a bit terse, and lacking in useful information. 

 

But correct information. What more is there to say? Again, I don't have a rooted NT to try, so can't say for certain. The app does work on my other (non-B&N) Android devices, but the NT is older.

 

I was trying to elicit information that might provide a "work around" for user Jojo480 to find a way to access the games on the pogo.com Web site.  I'm sorry that you became so upset at my attempt to contribute.

 

Not upset. The whole Java JVM thing was a red herring for pogo.com.

--  The entire topic of Javascript is a Red Herring.  Javascript might be used on the Web site, but it would make little sense to infer that Javascript has anything at all to do with playing the games themselves.  A device might be perfectly capable of executing Javascript in its browser(s), but still be incapable of downloading and playing games from pogo.com.

 

Uhm. Any games written for a browser that are not written in Flash today are probably very heavily based on Javascript+HTML5+CSS3. Without Javascript, they won't work. HTML5 only displays pages. Any programming targeting HTML5 (and not Flash) has to be done in Javascript to work on most browsers out-of-the-box. It's just the way it is.

--  It does not appear that Jojo was confused at all. [...]

 

Other than thinking Java was the problem, perhaps. 

 

Because the Pogo Game Manager must be downloaded and installed on a user's device, Java would certainly be more appropriate than Javascript for that purpose.  I will describe what I have discovered about this Web site later in this post.

 

As I noted in previous posts, depending on the game, it's a lack of either HTML5+CSS3+Javascript, or Flash. Again, I belive it was the name that led Jojo to think he needed Java. As your own investigation reveals, it wasn't Java that was needed. On my NC, I can get as far as loading the game page and it complains about Flash. Not Java.

--  I believe that you might have been confused by your access to pogo.com with a rooted NOOK.

 

That's the device Jojo is using, no?

 

[...] Apple iPad --  I accessed the pogo.com Web site with an Apple iPad 3 running iOS 6.x using the Dolphin browser.  When selecting a game, I am instructed to update my Flash player, and a link is presented to "GET THE LATEST VERSION HERE."

 

That certainly backs up my observation that they're using Flash. I don't know what else they're using. Java wouldn't appear to help.

 

[...] Perhaps the Adobe Flash Player might be able to be installed with iOS 7, but I am not, yet, willing to download and install iOS 7.  Results:  The Pogo Games Manager cannot be installed on an iPad 3 running iOS 6.x without "jailbreaking" the Operating System. [...]

 

Ah, so same as rooting? :smileyhappy: Actually, the reason most web development is shifting off of Flash and to HTML5+CSS3+Javascript is because Steve Jobs decreed that he (Apple) wouldn't support Flash on the iPad. The pogo site does claim that the latest Safari and Mozilla Firefox versions will run their apps. I have no means of testing.

NOOK Tablet --  When accessing the pogo.com game site, the user is presented with a screen that "FREE pogo Games Android App is here!  Play your favorite Pogo games in 1 app."   A button is displayed with the label "Get it Now."  Selecting that button takes the user to the Google Play Store. 

 

So if you're going to the Google Play Store, presumably this is a rooted NOOK Tablet?

 

At the top of the Google PS screen is a logo and legend referring to POGO Games.  Two choices are offered: "Install" and "Add to Wishlist."  If the "Install" button is selected, the entire screen of the NT will grey out, and will remain that way indefinitely.

 

It doesn't work on a NC running CyanogenMod at all. I don't have a rooted NT to test handy. Some people have reported luck with some (not all) games in a browser running a rooted NC on CyanogenMod. Of course, EA may have modified the pogo.com site since then.


It seems clear that the pogo.com Web site detects the platform of the accessing user, and offers different advice as a result of its findings.  Perhaps that is one function of the Javascript you saw on the Web page.

 

That is one of the major reasons for the various Javascript frameworks that I described previously. They can detect the various browsers and platforms and handle a lot of device-specific presentation issues, while allowing the programmer to write code without having to worry as much about each browser variant.

 

Since it seemed to correctly detect the device/platform on each of three different devices, it is clear that it (Javascript) is working correctly on all three different platform/browser combinations. 

 

That depends on the browser. Javascript degrades gracefully, so if your browser doesn't support it, a programmer can have a default page presented. This could be what is showing the "download the app" page.

 

After that, however, the next actions differ greatly.  Clearly, Windows uses executables (binary), Apple uses Adobe Flash for at least a part of the process, and Android uses the Google Play Store, which is locked out from NOOK Tablets.

 

It might be interesting to try it on a Windows machine without Flash installed, just to make sure the Windows app isn't just using existing Flash components.

 

It is not clear how far the process gets with a NOOK Tablet.  In other words, it isn't clear whether the NOOK Tablet hangs up because it cannot interpret dex code (unlikely), or whether some other mechanism is preventing the installation of access to Pogo games.  I do not have the resources necessary to make this determination. 

 

Neither do I, sadly. It may just be that pogo.com (EA) has deliberately disabled access with certain browsers. For example, if you look at their Supported Browsers page, they specifically state that they won't work with Linux, despite the fact that a Linux system can run Firefox and Chrome, as well as Flash, JRE and most other components you and I seem to have tried.


Aren't the NOOK HD and HD+ able to access Google Play?  Might it have been more useful to Jojo480 to advise that he/she consider upgrading to a newer version of the B&N Nook Tablet?

 

Someone with one of those devices would have to try it. There's no guarantee that pogo (EA) will support it on such a device either.

 

 

On my NOOK Color running CM, I can get so far as loading a game up in the default browser, at which time it stops, complaining about an outdated Flash plugin. Others have reported success with some pogo.com games (no extra Java-anything installed) on NOOK Colors. I really think the answer will vary by game.

 

Honestly, I think the best advice would be to find some other games.

(...) I would be very suprised if pogo (EA) re-wrote every game

--  It seems unlikely that Pogo (EA) would rewrite every game.  It seems clear, however, that the company offers different solutions for different platforms. 

 

And more annoyingly, they seem to specifically disable their games on unsupported platforms. That's a "not welcome" sign for sure!

 

[...] You seem focused on Web and browser technology. 

 

Only in as much as Jojo seemed to be confusing Javascript and Java. Again, some pogo.com games can work on even the older NOOK Color, so no loading of "Java" was required. Either Jojo meant something else, or was confused. He/she hasn't been back to clarify.

 

I do not believe that HTML5, CSS3 or Javascript plays any significant part in the playing of the games.

 

You'd have to ask EA. Since Flash is largely seen as going by the wayside with the advent of the newer web-based technologies, I'd be surprised if EA is not paying attention. They do still deliver a lot of Flash games from the pogo.com site in any case.

 

I could be mistaken, but I have not, yet, seen evidence that they are.  Flash and Javascript might, indeed, be required to access and download Pogo's games, but it seems unlikely that they would also be required to play those games. 

 

It'll be some combination of Flash and/or HTML5+CSS3+Javascript, in all likelihood. Those are the biggies for browser-based games these days.

 

I have completed an on-line course in Javascript from a reputable training organization, so I am familiar with Javascript.  I also have Adobe CS5, so I can tinker to my heart's delight. 

 

Be sure to check out some of the HTML5 Canvas frameworks. There are some good videos on YouTube showing how games are being done with Javascript, along with a lot of more "serious" applications. 

Distinguished Bibliophile
bobstro
Posts: 4,070
Registered: ‎01-01-2012
0 Kudos

Re: JAVA Revisited

deesy58 wrote:
I think you missed the point.

Not unless you're changing the question. Your previous "big question" was whether byte code for JVM would run on DVM. The article you quoted is going the other way, and is producing source files (not executing) from the compiled Android programs. This is old news.

 

The point is: This is a method for producing (translating) Java source code from Dalvik dex code.  "Ersatz" is a strong term chosen by you and offered without a shred of evidence that the resultant program would be inferior in any way. 

 

When you decompile Java byte code, you usually end up with source code with all variables renamed, loss of formatting and comments, and a number of other issues. Depending on the complexity of the resulting source (.class) files, they might well be difficult to work with.

 

Of course it would have to be recompiled.  That's the way Java works.

 

Yes, which is why I pointed out that this is different than what you originally asked about. There are books on the topic if you're interested.

 

That's also the way Android works.  Note that the Dalvik system appears to require recompilation every single time  a program is run, unlike Java. 

 

You have to compile to get from java source (the .class files) to bytecode. Again, you were originally asking about taking bytecode compiled for JVM and running it on DVM.

 

That doesn't seem very efficient, and it takes away one of the benefits of pre-compiled WORA code (it makes it easy to be proprietary, however).  What makes you so sure that the Dalvik system wasn't chosen by Google for strictly business reasons?

 

Android apps have to be compiled once for each source code version. Not sure how this is any different.

 

Sun/Oracle Java will work on a smart phone, for example.  http://www.ehow.com/how_7181654_enable-java-smartphone.html

 

I believe that is a Windows product. There are compatibility layers/emulators that will let you run apps (slowly). That's not the same as running bytecode compiled targeting JVM on DVM though. You'd need more than the bytecode.

 

Since Oracle offers a development kit (SDK) for Java ME (Mobile Edition?) for smart phones (http://www.oracle.com/technetwork/java/javame/javamobile/training/jmesdk/index.html), it seems unlikely that hardware is a limiting factor for the use of Oracle/Sun Java, or that it is the real reason why genuine Java is not offered on Android devices. 

 

No, probably not. Android does seem to have won out. I'm sure Oracle is not happy about losing the suit.

 

Perhaps there really are technical reasons.

 

I think Google has taken Android further faster than Oracle might have had they held control. I'm sure, ultimately, Google just wanted control.

 

Perhaps you could discover them and share them with us.

 

If you'd like to start a new discussion on this topic, I'd be happy to participate. This is an entirely new topic, however.

 

It would be nice to know if the real reason why Java byte code cannot (apparently) be interpreted by an Android device has anything to do with dependencies, or if it is just because Google is attempting to make its technology proprietary.

 

The answer is both, I think. Google introduced dependencies that preclude bytecode compiled targeting the Sun/Oracle JRE from running on Android.

 

I don't know the answers, but I am not prepared to trust Google.  

 

I don't necessarily trust Google. Then again, I don't trust Oracle or Apple either. They're producing a nice consumer-focused OS. They are arguably more "open" than Apple, though that's a sword that cuts both ways.

 

The reason I'm interested in the HTML5+CSS3+Javascript developments is that they are based on fully open standards and not controlled by one corporate entity.

Inspired Bibliophile
deesy58
Posts: 2,486
Registered: ‎01-22-2012
0 Kudos

Re: JAVA Revisited

bobstro wrote:
As long as you have the correct runtime environment, that's probably still a correct statement. I have no way of testing, other than to say that Java apps targeting the Sun/Oracle JRE can work (see below) cross-platform with the appropriate JRE browser plugin (mostly on desktops).


The trick is to have that JRE. I am not aware of any software that will allow apps compiled for the Sun/Oracle JRE to run unmodified on an Android device. There appear to have been various compatibility layers/emulation available in the past, but most seem to have been discontinued. Not to say that they don't exist, but I haven't seen them.

--  Your reply appears to be based on the assumption that Pogo games are played from within a browser.  I have been unable to find any credible supporting information on the Internet that would lead me to believe that this is actually the case.  Perhaps you could share your source??

 



Because Android apps are written in the Java language and compiled targeting the Android (DVM) environment. Jojo seems to have been confused about what he's after. Throwing a lot of detail about something that won't help him ... won't help him. Pogo.com doesn't look to use java browser plugins at all.


--  I reassert my contention that Jojo was/is not confused at all, but simply stated what he/she knew to be a fact: Java is required to play Pogo games (more later).

 


 
Not upset. The whole Java JVM thing was a red herring for pogo.com.


--  Java is NOT a red herring when it comes to Pogo games!

 



Uhm. Any games written for a browser that are not written in Flash today are probably very heavily based on Javascript+HTML5+CSS3. Without Javascript, they won't work. HTML5 only displays pages. Any programming targeting HTML5 (and not Flash) has to be done in Javascript to work on most browsers out-of-the-box. It's just the way it is.

--  Again, you are making an assumption.  You continue to assume that Pogo games are played from within a browser, in spite of evidence to the contrary.  You chose not to address the issue of playing Pogo games on a PC computer using the Windows OS.  Perhaps, however, it might have been possible to draw a few inferences from examining how Pogo.com supplies games to a Windows environment, and perhaps it might be reasonable to infer that the games interface might not be too different for other devices.  It would make sense to develop such game playing and managing software using the Java programming language.

 



Other than thinking Java was the problem, perhaps.


--  Again, I believe you are mistaken.


 


As I noted in previous posts, depending on the game, it's a lack of either HTML5+CSS3+Javascript, or Flash. Again, I belive it was the name that led Jojo to think he needed Java. As your own investigation reveals, it wasn't Java that was needed. On my NC, I can get as far as loading the game page and it complains about Flash. Not Java.


--  It appears that you are continuing to assume that Pogo games are played from within a browser.  Why do you assume that Pogo games are played from within a browser, and that HTML5+CSS3+Javascript or Flash have anything at all to do with downloading and playing Pogo games?   Have I missed something?  Perhaps if you could cite your source for this belief it might clear up some confusion. 
 



That's the device Jojo is using, no?


--  No.  My understanding of Jojo's post was that he/she was attempting to play Pogo games on an unrooted NOOK Tablet.  What would lead you to believe that his/her NT was rooted?

 
 


That certainly backs up my observation that they're using Flash. I don't know what else they're using. Java wouldn't appear to help.


--  Yes, but using Flash for what?  Web sites can be, and sometimes are, written completely using Flash.  The fact that the pogo.com Web site uses Flash and Javascript to assist a user to download the Pogo Games Manager and various Pogo games does not, necessarily, mean that Flash would be required to play those games after they have been downloaded. 


--  It appears that Java would not only help, but would be absolutely required to play Pogo games. 

 


 
Ah, so same as rooting?  Actually, the reason most web development is shifting off of Flash and to HTML5+CSS3+Javascript is because Steve Jobs decreed that he (Apple) wouldn't support Flash on the iPad. The pogo site does claim that the latest Safari and Mozilla Firefox versions will run their apps. I have no means of testing.


--  Steve Jobs was a man with an oversized ego.  He suffered greatly, IMO, from the NIH Syndrome (Not Invented Here).  His rationale for denying the use of Java on any Apple products was not very compelling, although his stated reasons for not allowing Flash (it was not sufficiently secure) was a lot easier to understand. 

 


So if you're going to the Google Play Store, presumably this is a rooted NOOK Tablet?


--  No.  My NOOK Tablet is not rooted.  However, I can still use its default browser to access the pogo.com home page and click on a link that takes me to the Google Play Store.  I can then click on a link that would (if it worked) allow me to install the Pogo Games Manager.  That link appears to be within the Google Play Store Web site.  I think you might be confused because of your continuing assumption that Pogo games software is all designed for use within a browser, and it's not.

 


 
It doesn't work on a NC running CyanogenMod at all. I don't have a rooted NT to test handy. Some people have reported luck with some (not all) games in a browser running a rooted NC on CyanogenMod. Of course, EA may have modified the pogo.com site since then.


--  Does this mean that you weren't really sure if it would work when you advised user Jojo480 to root his/her NOOK Tablet in order to play Pogo games?

 



That depends on the browser. Javascript degrades gracefully, so if your browser doesn't support it, a programmer can have a default page presented. This could be what is showing the "download the app" page.


--  It seems obvious that the Web page is able to detect the user's OS (using Javascript or a similar technology), and then displays three different Web pages for three different Operating Systems.  At least, that is what I saw.  I would test it with Linux, but my Linux box shot craps and will no longer boot.  Oh well ... 11 years is a pretty good product life for a computer. 


--  I believe that most modern browsers support Javascript.  A list of 36 browsers to be found at http://en.wikipedia.org/wiki/Comparison_of_web_browsers#JavaScript_support indicates that only eight of them do not support Javascript, and none of the eight appears to be in common use in the United States today.  Those eight are Amaya, Dillo, Links, Lynx, Mosaic, NetSurf, WorldWideWeb and w3m.  All of the more commonly-used browsers appear to support Javascript. 

 



It might be interesting to try it on a Windows machine without Flash installed, just to make sure the Windows app isn't just using existing Flash components.


--  There would be no point in trying this on a Windows machine.  I have already described how the pogo.com Web site responds to a Windows user.  The Windows apps for Pogo games are executables.  They are not Flash (.swf) and are not an intermediate code like byte code or dex code.  They are executable binaries. 

 



Honestly, I think the best advice would be to find some other games.

--  Does that mean that you have changed your advice to the user about rooting his/her NOOK Tablet?

 


 
And more annoyingly, they seem to specifically disable their games on unsupported platforms. That's a "not welcome" sign for sure!

--  You can't really say that.  They might be welcoming users using various platforms by correctly identifying the user's OS and installing the appropriate version of the Pogo Games Manager for that platform.

 


Only in as much as Jojo seemed to be confusing Javascript and Java. Again, some pogo.com games can work on even the older NOOK Color, so no loading of "Java" was required. Either Jojo meant something else, or was confused. He/she hasn't been back to clarify.

--  Actually, it appears that a JVM must be installed in order to play many Pogo games.  Javascript appears to be used only in the Web site that distributes the games and the Pogo Games Manager. 


 
 
It'll be some combination of Flash and/or HTML5+CSS3+Javascript, in all likelihood. Those are the biggies for browser-based games these days.
 
--  Again, you are assuming that these are browser-based games.  This is not my understanding of how Pogo games work.

**********************************************************************************************************************

deesy58 wrote:
I think you missed the point.

bobstro wrote:
Not unless you're changing the question. Your previous "big question" was whether byte code for JVM would run on DVM. The article you quoted is going the other way, and is producing source files (not executing) from the compiled Android programs. This is old news.

--  According to Wikipedia: " Dalvik is the process virtual machine (VM) in Google's Android operating system. It is the software that runs the apps on Android devices. Dalvik is thus an integral part of Android, which is typically used on mobile devices such as mobile phones and tablet computers as well as more recently on embedded devices such as smart TVs and media streamers. Programs are commonly written in Java and compiled to bytecode. They are then converted from Java Virtual Machine-compatible .class files to Dalvik-compatible .dex (Dalvik Executable) files before installation on a device [emphasis mine].  The compact Dalvik Executable format is designed to be suitable for systems that are constrained in terms of memory and processor speed."   http://en.wikipedia.org/wiki/Dalvik_virtual_machine

--  To me, this means that the .class files produced by a standard Java compiler can be (and are) converted to .dex files for interpretation by a DVM. 

--  The article goes on to point out that: "A tool called dx is used to convert some (but not all) Java .class files into the .dex format. Multiple classes are included in a single .dex file. Duplicate strings and other constants used in multiple class files are included only once in the .dex output to conserve space. Java bytecode is also converted into an alternative instruction set used by the Dalvik VM. An uncompressed .dex file is typically a few percent smaller in size than a compressed .jar (Java Archive) derived from the same .class files."

--  Even though Google claims to have developed the Dalvik system in order to improve performance on small devices with relatively slow architectures (like ARM), Oracle conducted tests in 2010 that seemed to contradict Google's assertions: "However, tests performed on ARM devices by Oracle (owner of the Java technology) in 2010 with standard non-graphical Java benchmarks on both Android 2.2 (the initial release to include a just-in-time compiler) and Java SE embedded (both based on Java SE 6) seemed to show that Android 2.2 was 2 to 3 times slower than Java SE embedded."  (Same Wikipedia source.)

--  Although Dalvik does not use the standard Java class libraries, it does use other Java class libraries: "Dalvik does not align to Java SE nor Java ME class library profiles (e.g., Java ME classes, AWT or Swing are not supported). Instead it uses its own library built on a subset of the Apache Harmony Java implementation."  A quick look at the Apache harmony Java implementation reveals that: "Apache Harmony was an open source, free Java implementation, developed by the Apache Software Foundation."  http://en.wikipedia.org/wiki/Apache_Harmony  Also, when discussing the architecture of Apache Harmony, the article goes on to point out that "Class Library: is a Java standard library."

--  In addition: "The Harmony project currently achieve (as of February 2011) 99% completeness for JDK 5.0, and 97% for Java SE 6."  That sounds an awful lot like standard Java.  It appears that the primary differences between standard Java and the Android implementation of Java is largely one of licensing and intellectual property (IP) rights, and not any technology requirements.  After all, there is is little difference in whether the VM is implemented as a stack machine or a register machine if the hardware architecture is register-based, right? 

 

 
When you decompile Java byte code, you usually end up with source code with all variables renamed, loss of formatting and comments, and a number of other issues. Depending on the complexity of the resulting source (.class) files, they might well be difficult to work with.

--  So?  Who cares if variable names are changed and comments are eliminated?  They have no significance in executable code anyway.  Computer hardware recognizes the electronic version of binary, and nothing else.  Computers are all binary, all the time.  No source code is downloaded to an Android device as a part of any app.  It is either byte code, or it is dex code. 

 


Yes, which is why I pointed out that this is different than what you originally asked about. There are books on the topic if you're interested.
 
--  Not sure where you're trying to go with this assertion.  perhaps you could be a bit more explicit. 

 


You have to compile to get from java source (the .class files) to bytecode. Again, you were originally asking about taking bytecode compiled for JVM and running it on DVM. 

--  Everything I have been able to find on the topic suggests that the Java .class files that are usable in the DVM did not have to be recompiled, but were converted from byte code to dex code using a translator called "dx."

--  I believe that you are mistaken when referring to Java source code files as ".class" files.  I believe that Java source code files carry the ".java" file extension, and Java byte code files carry the ".class" file extension. 
 
--  I believe that I misstated the assertion about recompiling dex code.  Only the portions of the byte code or dex code that are being JIT (Just in Time) compiled into executable binary are subject to recompilation.  None of the remainder of the .class or .dex files need to be recompiled at execution time.  They are, instead, interpreted by the Virtual Machine (VM).  As far as I am aware, JIT capability was not added to the DVM until the release of Android V2.2. 

 


 
Android apps have to be compiled once for each source code version. Not sure how this is any different.

-- This is true of all compiled code, regardless of language.  JIT code, on the other hand, is recompiled from byte/dex code directly into executable binary at executuion time. 
 

 


I believe that is a Windows product. There are compatibility layers/emulators that will let you run apps (slowly). That's not the same as running bytecode compiled targeting JVM on DVM though. You'd need more than the bytecode.

--  The fact that it is a Windows product is beside the point.  The point is, Java will run applications on small devices, regardless of the assertions of Google and Apple.  Insofar as running the apps slowly is concerned, didn't Oracle prove that that particular assertion by Google was not true?

-- As I have already pointed out, the dx translator converts Java byte code to Dalvik dex code. 
 
 


No, probably not. Android does seem to have won out. I'm sure Oracle is not happy about losing the suit.

--  So then, you are agreeing that there are probably no hardware or environmental "dependencies" whatsoever that would preclude the use of Java byte code on an Android device if Google wasn't trying to exert total control over their systems? 
 

 
I think Google has taken Android further faster than Oracle might have had they held control. I'm sure, ultimately, Google just wanted control.

--  I totally agree with this position.
 
 


If you'd like to start a new discussion on this topic, I'd be happy to participate. This is an entirely new topic, however.

-- I don't believe that it is a new topic at all.  You have made assertions regarding "dependencies" that I believe are no more than what you have just observed: "Google just wanted control."
 


 
The answer is both, I think. Google introduced dependencies that preclude bytecode compiled targeting the Sun/Oracle JRE from running on Android.

--  Basically, they converted the architecture from a stack machine to a register machine.  That sort of dependency is artificial. I have been able to find nothing that informs me that it was necessary, for technical reasons, that the virtual CPU architecture be so radically changed.  On the other hand, if the purpose of the change was to win a lawsuit for copyright and patent infringement, now that's a different story.  :smileywink:

 
I don't necessarily trust Google. Then again, I don't trust Oracle or Apple either. They're producing a nice consumer-focused OS. They are arguably more "open" than Apple, though that's a sword that cuts both ways.
 
The reason I'm interested in the HTML5+CSS3+Javascript developments is that they are based on fully open standards and not controlled by one corporate entity.

--  I decided to go directly to the source, so I called Pogo "Online Games Support" which provides "Technical Support For POGO Games by Help-Center US."  I spoke with a Support Technician named Joe, who informed me that they were a Microsoft Business Partner and were not authorized to provide support for tablets and phones.  He said that Pogo Games are supported on Microsoft Windows and on Mac OS X devices.  He informed me that the Pogo Games Manager and all Pogo games must be downloaded into the user's computer before they can be played.  He further informed me that all Pogo games are written in the Java programming language, and that Java is required to play them.   [emphasis mine]   (Online Games Support -- Toll Free: 888-998-6718)

--  Now we know why Jojo480 was asking about Java.  :smileyhappy:

Distinguished Bibliophile
bobstro
Posts: 4,070
Registered: ‎01-01-2012
0 Kudos

Re: JAVA Revisited

[ Edited ]

Deesy,

 

  1. Where are you finding a version of Java for Jojo to install on his NOOK Tablet?
  2. Can he install it without root?

 

 

Inspired Bibliophile
deesy58
Posts: 2,486
Registered: ‎01-22-2012
0 Kudos

Re: JAVA Revisited


bobstro wrote:

Deesy,

 

  1. Where are you finding a version of Java for Jojo to install on his NOOK Tablet?
  2. Can he install it without root?

 

 


If you are referring to the JVM, I am not aware that one is available for the NOOK, or for any other Android device, although there could be one that I am not aware of.

 

The information I found suggests that Java byte code can be interpreted by the Dalvik Virtual Machine using the "dx" translator. 

 

Jojo owns a NOOK that uses Android as its Operating System.  Therefore, it already has the Dalvik Virtual Machine (DVM) installed because it is a a part of Android. 

 

The real question that remains unanswered (by anybody, as far as I am aware) is whether the Java byte code for Pogo games could be properly translated and interpreted by the DVM in Android.  I don't know the answer to that question, but I believe that it is the primary pertinent question. 

 

Somebody with an Android device that is not a "Walled Garden" like an unmodified NOOK would have to try it out to see. 

 

Not me.  :smileyindifferent:

 

 

Distinguished Bibliophile
bobstro
Posts: 4,070
Registered: ‎01-01-2012
0 Kudos

Re: JAVA Revisited

deesy58 wrote:
[...] Somebody with an Android device that is not a "Walled Garden" like an unmodified NOOK would have to try it out to see. 

By "not a Walled Garden", do you mean rooted?

Inspired Bibliophile
deesy58
Posts: 2,486
Registered: ‎01-22-2012
0 Kudos

Re: JAVA Revisited

Interpret it however you like.  I have an unmodified NOOK Tablet.  I can access the Google Play Store Web site, but I can't install the Pogo Games Manager.  I imagine that Jojo480 experienced the same problem and called Pogo Technical Support for assistance, as I did.  I expect that, like me, Jojo480 was told that Java is required to play Pogo games.

 

 

Distinguished Bibliophile
bobstro
Posts: 4,070
Registered: ‎01-01-2012
0 Kudos

Re: JAVA Revisited

Assuming you could actually point Jojo to a Java product to install on his unrooted NOOK Tablet, how would you suggest he install it without rooting? How might he get those pogo games onto that unrooted NT?

Inspired Bibliophile
deesy58
Posts: 2,486
Registered: ‎01-22-2012
0 Kudos

Re: JAVA Revisited


bobstro wrote:

Assuming you could actually point Jojo to a Java product to install on his unrooted NOOK Tablet, how would you suggest he install it without rooting? How might he get those pogo games onto that unrooted NT?


I have no interest in pointing Jojo to a Java product to install on his/her unrooted NOOK Tablet.  It was YOU who suggested that Jojo's problem with playing Pogo games on a NOOK Tablet could be solved by rooting the device.  I simply asked some questions that I believed needed to be asked.  Those questions seemed to provoke lengthy and misleading explanations about browser-based applications and Javascript.  I found the information to be confusing, so I decided to investigate further.  I posted the results of my research along with supporting source citations to show that I didn't pull them from thin air. 

 

According to Pogo Games Technical Support, Java is required to install the Pogo Games Manager, and to play Pogo games.  This, despite assurances by you that Java was nothing more than a Red Herring. 

 

As far as I am concerned, this discussion is over.  If you really believe that Pogo games can be played on a rooted NOOK, you should offer persuasive and supported evidence that this is the case, because I am still not convinced, and Jojo has not continued the discussion. 

 

:smileyindifferent:

Distinguished Bibliophile
bobstro
Posts: 4,070
Registered: ‎01-01-2012
0 Kudos

Re: JAVA Revisited

If you'll reread the thread, I merely mentioned that he could try loading the pogo app on a rooted device, nothing more. As some games are reported to work on a NOOK device (no additional Java added), that would seem to be a likely angle to pursue. Far more so than trying to find a nonexistent Java Android package to install to execute unavailable code.