8

How can one identify whether some code (a serv-let or a simple class) is running on Google App Engine run-time (Java) so that one can decide whether to utilize app engine's specific libraries or not? Is there some reliable runtime enviroment ID for that?

Adam Crossland
  • 14,198
  • 3
  • 44
  • 54
nsegae
  • 81
  • 2
  • Possible duplicate of [How to check in Java App Engine if we are on development workstation](http://stackoverflow.com/questions/1574637/how-to-check-in-java-app-engine-if-we-are-on-development-workstation) – Dan Cornilescu May 09 '16 at 01:28
  • Not a duplicate. That's a different problem. Sufficiently different that "clean" solutions to that problem won't work for this one. – Stephen C Sep 26 '22 at 22:53

6 Answers6

4

You can check the com.google.appengine.runtime.version property:

String appEngineVersion = System.getProperty("com.google.appengine.runtime.version");

If it's set, it's App Engine.

But I would consider using separate build targets instead, to avoid the runtime overhead.

Matthew Flaschen
  • 278,309
  • 50
  • 514
  • 539
  • 1
    Thanks a lot for the answer. I have 2 separate implementation subclasses for the 2 cases and they are quite small (200 lines in code size in total of both) to need separate builds I suppose. – nsegae Nov 10 '10 at 02:57
2

As explained here you can check the following property:

String environment = System.getProperty(
    "com.google.appengine.runtime.environment")

environment is "Production" when running on App Engine, and "Development" when running in the development server.

Sridhar Ratnakumar
  • 81,433
  • 63
  • 146
  • 187
Reza
  • 145
  • 1
  • 2
  • 12
2

similar to what @Reza wrote, but a bit cleaner:

use SystemProperty.environment.value() to get "Production" when running on App Engine, and "Development" when running in the development server.

Arnaud
  • 7,259
  • 10
  • 50
  • 71
Yonatan Maman
  • 2,428
  • 1
  • 24
  • 34
1

I saw no type-safe solution here so here it is:

if (SystemProperty.environment.value() == SystemProperty.Environment.Value.Production) {
    // The app is running on App Engine...
}
Zsolt Safrany
  • 13,290
  • 6
  • 50
  • 62
  • This misses the point. You are using GAE classes, so if GAE is not present (i.e. on the classpath) you won't be able to successfully load this code. – Stephen C Sep 26 '22 at 22:50
  • @StephenC, GAE classes not being present is not the same as GAE runtime not being present. You can still have the required classes on your classpath for this. – Zsolt Safrany Sep 27 '22 at 16:36
  • But you *have to* have them on the classpath for this to work. That *could be* a big cost to pay for what is essentially a cosmetic issue. Also: directly accessing the the Java system properties is perfectly type-safe. Sure it breaks a (porous) abstraction, but the chances of that materially affecting anything are infinitesimal. – Stephen C Sep 27 '22 at 23:18
1

As @Matthew Flaschen said, there are system properties that you can check to determine if GAE is present or not. This link gives the details.

If you go down this route, your application needs to be built so that the main code has no static dependencies on the GAE classes; i.e. no imports or other references to GAE packages and classes in the code (apart GAE class names, etc in String literals). All dependencies have to be isolated to code that gets loaded using Class.forName(String) AFTER you've determined whether or not GAE is present.

This represents a non-trivial overhead:

  • You'll probably end up with an extra Adapter interface and (at least) two implementations for the GAE and non-GAE cases.
  • You've got the (minor) runtime overheads of dynamically loading the relevant class at startup, and calling through the Adapter interface.
  • Your JAR file is that much bigger as a result.
  • You now have to test on two platforms.

On the other hand, you do have the potential advantage of having one JAR that works in both GAE and non-GAE contexts.

@David P. Caldwell commented:

The other possibility is to load the GAE development server classes yourself; you can essentially run the development server inside a servlet container (I use Tomcat), which can give you more control over the development environment.

This is not quite the same as what (I think) the OP was trying to do. Nonetheless, it is a very interesting idea. If this approach works for running a production implementation on a non-GAE platform, it would allow you to avoid implementing a stack of non-GAE adapter code; see previous.

The downside is that if you run into issues and try to get support from Google, you may run into a roadblock; i.e. "we don't support GAE when it is used this way".

Stephen C
  • 698,415
  • 94
  • 811
  • 1,216
  • The other possibility is to load the GAE development server classes yourself; you can essentially run the development server inside a servlet container (I use Tomcat), which can give you more control over the development environment. – David P. Caldwell Sep 26 '22 at 17:26
0

There is another way to do this as well. This is explained well in gaevfs's documentation on how to write Portable Code: http://code.google.com/p/gaevfs/wiki/ApplicationPortability

Of interest to you is the following line:

boolean isGoogleAppEngine = getServletContext().getServerInfo().contains( "Google" );
Travis Webb
  • 14,688
  • 7
  • 55
  • 109