I'm a Java newbie. Wanted to know if all Java SE classes are available in Java ME. If not why is it so?
No, only a subset is available, see http://java.sun.com/javame/technology/index.jsp for an introduction.
A brief overview is given in this Wikipedia article:
Noteworthy limitations
Compared to the Java SE environment, several APIs are absent entirely, and some APIs are altered such that code requires explicit changes to support CLDC. In particular, certain changes aren't just the absence of classes or interfaces, but actually change the signatures of existing classes in the base class library. An example of this is the absence of the Serializable interface, which does not appear in the base class library due to restrictions on reflection usage. All java.lang.* classes which normally implement Serializable do not, therefore, implement this tagging interface.
Other examples of limitations depend on the version being used, as some features were re-introduced with version 1.1 of CLDC.
CLDC 1.0 and 1.1
The Serializable interface is not supported.
Parts of the reflection capabilities of the Java standard edition:
The java.lang.reflect package and any of its classes not supported.
Methods on java.lang.Class which obtain Constructors or Methods or Fields.
No finalization. CLDC does not include the Object.finalize() method.
Limited error handling. Non-runtime errors are handled by terminating the application or resetting the device.
No Java Native Interface (JNI)
No user-defined class loaders
No thread groups or daemon threads.
It's worth noting that where J2ME versions of J2SE classes are apparently available, they often have a reduced API. So you can't always assume that code using 'available' classes will port straight over.
If memory serves, there are one or two methods with differening names too. Memory doesn't serve well enough right now to recall a specific example.
No, Java ME is a significantly restricted subset of Java SE. Java SE is an enormous standard library, and most of the devices Java ME is intended to run on don't have the resources to support all that overhead.
Take a look at the javadocs for CLDC 1.1, the main, universally supported API accessible to Java ME.
No they are not. The reason for this is the standard library is quite large, making it difficult to use on embedded devices with small amounts of memory and slower processors.
See this page for more info about whats included and whats not.
Related
Are there any best practices for the implementation of API versioning? I'm interested in the following points:
Controller, service - e.g. do we use a different controller class for each version of the API? Does a newer controller class inherit the older controller?
Model - if the API versions carry different versions of the same model - how do we handle conversions? E.g. if v1 of the API uses v1 of the model, and v2 of the API uses v2 of the model, and we want to support both (for backward-compatibility) - how do we do the conversions?
Are there existing frameworks/libraries can I use for these purposes in Java and JavaScript?
Thanks!
I always recommend a distinct controller class per API version. It keeps things clean and clear to maintainers. The next version can usually be started by copying and pasting the last version. You should define a clear versioning policy; for example N-2 versions. By doing so, you end up with 3 side-by-side implementations rather than an explosion that some people think you'll have. Refactoring business logic and other components that are not specific to a HTTP API version out of controllers can help reduce code duplication.
In my strong opinion, a controller should absolutely not inherit from another controller, save for a base controller with version-neutral functionality (but not APIs). HTTP is the API. HTTP has methods, not verbs. Think of it as Http.get(). Using is another language such as Java, C#, etc is a facade that is an impedance mismatch to HTTP. HTTP does not support inheritance, so attempting to use inheritance in the implementation is only likely to exacerbate the mismatch problem. There are other practical challenges too. For example, you can unherit a method, which complicates the issue of sunsetting an API in inherited controllers (not all versions are additive). Debugging can also be confusing because you have to find the correct implementation to set a breakpoint. Putting some thought into a versioning policy and factoring responsibilities to other components will all, but negate the need for inheritance in my experience.
Model conversion is an implementation detail. It is solely up to the server. Supporting conversions is very situational. Conversions can be bidirectional (v1<->v2) or unidirectional (v2->v1). A Mapper is a fairly common way to convert one form to another. Additive attribute scenarios often just require a default value for new attributes in storage for older API versions. Ultimately, there is no single answer to this problem for all scenarios.
It should be noted that backward-compatibility is a misnomer in HTTP. There really is no such thing. The API version is a contract that includes the model. The convenience or ease by which a new version of a model can be converted to/from an old version of the model should be considered just that - convenience. It's easy to think that an additive change is backward-capable, but a server cannot guarantee that it is with clients. Striking the notion of backwards-capable in the context of HTTP will help you fall into the pit of success.
Using Open API (formerly known as Swagger) is likely the best option to integrate clients with any language. There are tools that can use the document to create clients into your preferred programming language. I don't have a specific recommendation for a Java library/framework on the server side, but there are several options.
I have a question regarding Java EE security best practices.
What are the advantages and disadvantages of using either annotations or a deployment descriptor to define Security for a web application?
Are there cases where you favor one over the other?
Thank you in advance :)
Well, it is mater of fashion. Some years ago there was massive movement "to sepearate application instrumentation from the programming" (you can read, for example, spec of EJB, where there is special role for this even, this person is not have to be even programmer). In this way use of XML was indorsed (instead of plain txt file or property files). And than annotations bring back those XML file to the code. I think it is due the mass in Spring framework. It was really hard to configure application (there was no good way to "debug" your configuration). Using annotation is "lightweight" way to make configuration. In simple scenarios you can skip defining relationships between your components, because they can be inferred from you code elements.
Using annotations is elegant (you do not require additional XML files) but requires to recompile your code every time you made a change.
What is the difference between the next terms, it can help a lot in interviews and general understanding.
Framerwork
Library
IDE
API
Framework
Some predefined architecture that a developer has chosen and which dictates how the application will be written. It usually already includes many concepts which helps the developer to concentrate on the domain of the application instead of the plumbing. This plumbing is provided by the framework. For example the .NET framework provides out-of-the-box tools that would allow you to talk to web servers, without even knowing the internals of the TCP/IP protocol (actually it helps knowing the internals but you get the point).
Library
A reusable compiled unit that can be redistributed and reused across various projects. Well not necessary compiled in case of dynamic languages.
IDE
It's the development environment where you create the other three parts (usually text editor), it might also include compiler and the possibility to execute, debug and see the output of the program in order to speed up the development process.
API
Application Programming Interface. This could mean many things but usually it is a set of functions given to the disposition of the developer and which perform specific tasks and work only in a specific context.
IDE is a tool for fast, easy and flexible development
An API is provided for an existing software. Using these third party applications can interact with main/primary application.
A framework or library are typically same. They are a common set of functionality for other software to use.
Ref: wiki for Framework, API
Framework: a collection of libraries and programming practices to provide general functionality for a program, so that it doesn't have to be rewritten. Typically a framework for an application program will handle user display and input, among other things. The intent is usually to hide the more complex functionality of an application, and to encourage a certain style.
Library: A piece of software to provide certain functionality to other programs that call it. Typically designed to be reusable and modular, so that a library can be distributed and be useful without its source code.
Integrated Development Environment: A integrated set of tools to write programs and turn them into finished products, usually including at least an editor, compiler, linker, and debugger. IDEs sometimes provide support for frameworks.
Application Programming Interface: A set of function calls and sometimes variable accesses available to a program, typically being the public interface of one or more libraries.
I am going to work on the OSGi-based Embedded/Mobile applications. I have some confused questions need to be clarified.
(1) Can Equinox run on J2ME environment or not?
(2) How to start the Equinox OSGi container under the pure J2ME environment (not JDK and JRE installed)?
(3) Can I use some external jars / Third party's jars (which is based on JRE classes) for the embedded application?
Thank you!
Java ME is something of an "embedded" environment, meaning amongst other things that there is generally not as much memory to run in or storage space. At one time there were application size limits.
What this means is that instead of trying to dump big, fat, J2SE jars into a device with limited capabilities, perhaps you should try rethinking what you are trying to accomplish.
Also consider that the version of Java that mobile phones run is fairly limited, so many 'regular' Java applications and libraries will not work there.
You can include jars in your applications, by taking their contents and dumping them in the jar you create.
In other words, you have to think differently about Java ME - it's not the bloated world that most Java stuff inhabits.
I don't know much about Equinox OSGi but, as I found from it's web page, it's looks like support OSGi MEG. Then it could run on mobile devices with Java ME CDC runtime not CLDC.
OSGi should depends on features of CDC VM as like dynamic class loading, refelection or else.
Please find phoneME CDC project (phoneME advanced) from here.
I'm in the beginning phases of a Blackberry/J2ME project -- and along with other limitations that come with this wonderful platform, the lack of support for reflection and 1.3 language level mean that the vast majority of existing IoC containers are unusable. (Google has Guice for Android with no AOP, but even that requires support for annotations).
So the space of IoC containers on J2ME is pretty limited. The one framework that has caught my attention is called Signal Framework, and it looks pretty promising. It tries to stay conceptually close to Spring Framework's IoC, implementing a small subset of its functionality, and does so without relying on bytecode-modification or causing runtime xml parsing. Instead, it processes configuration XMLs at build-time to generate java code which implements this IoC functionality.
Generally speaking, code generation at build time seems like a very wise approach for mobile applications -- and if my app has to do less XML parsing on user's device, that's great too!
So, what have your experiences been with implementing IoC on J2ME/CLDC, and how were you able to extinguish that bitter taste in your mouth?
We used Spring ME at TomTom. It worked out pretty well.
In J2ME you need to reduce the number of classes you use as much as possible to reduce the size of jar files. This leads to many design compromises not least of which is flexibility.
It is not easy to adjust to J2ME development when you have to throw must of what you hae learnt (and come to value highly) about OO out the window. The truth is if you want apps that can run on a large range of phones you need to be very sensitive to the constraints of the devices.
As such I do not think an IoC framework will match many people's needs for J2ME development.
You might be interested in checking out FallME. Even though I haven't used it personally, it seems like a no non-sense framework built specifically for the J2ME platform.
I came across Spring ME during a Dutch JUG conference (have no experience with it whatsoever).
Signal Framework it is.
Update: unfortunately, Signal is very undercooked right now, so I'm going with Israfil IOC with custom additions.