I have decided to learn another language and am in the picking phase.
Currently looking into Java and C#, but leaning towards Java because it is cross-platform. I will be mostly building web based apps, but the variety of Java editions scares me. Java EE, SE, ME, FX, what are they differences? Are there any advantages of using one to another?
Okay, FX is for desktops, ME for mobile, SE and EE are the same, but one is for "business" the other is not. So, if I learn SE for example, what would it take to switch to EE? Or FX? My problem is that I can't really understand why SE, EE and FX are separate products? They both run same JVM, and both can do the same resulting apps. Why they are separated then?
Think of them a bit like this:
ME ~= Compact framework
SE ~= .NET client profile
EE ~= full .NET framework (and some extra bits :)
FX ~= Silverlight
It's not an exact comparison, but it's a close enough start...
It is not so devastating.
Java SE is the standard for normal applications.
Java ME is for mobile telephones, a subset without floating point for instance.
Java EE is an addition for Java SE for web applications and web servers.
Java FX is a flash player alternative, but now with java bindings/integration.
Hence Java SE forms the basics. Java EE is for web applications.
In future java will get a modular system, and the distinction will be just on library level.
When you say editor, i think you mean IDE(Integrated Development Environment).
The reason why Java has so many editors and C# doesn't, is because Java is opensource, while C# is not. So the only real good IDE you are going to find out there for C# is called "visual studio"(It is not free)
I would highly recommend you to go for java, because almost all of the tools are free to use, and even the application servers where you deploy your apps.
Don't be affraid of the java editions, if you would like to build web apps, you will need to go for JavaEE(Enterprise Edition).
Anyway this is what each of them does:
SE(Standard Edition): It contains the most basic libraries, often used in desktop apps, but it is part of the Enterprise Edition too.
EE(Enterprise Edition): Used for enterprise apps(not just web apps), so that means distributed programming, from web apps, desktop to web services...
ME(Micro Edition): Is meant for mobile technologies, not just phones, also vending machines, smart tvs, missile guidance... ;)
FX: Is a rich development platform for developing powerful clients in an easy way.
Regarding to your question, the differences between EE and SE, i already answered, in other words:
EE is an extension of SE, that includes EE and allows you to program enterprise apps.
So if you want to program in EE, you need to have SE installed(Just think about it as a system requirement).
I don't really understand what do you mean by bussiness. What i can tell you is that the Enterprise Edition, has in its libraries integrated a tool for developing bussiness components, called EJB(Enterprise Java Beans).
The reason why EE, SE and FX are separet products is because a separation of concerns is needed.
Example: Maybe you create a desktop app that does not need at all to communicate via internet. Why would you have in it enterprise libraries for distributed programming?
Whit all respects, but the last question is a bit of no sense.
The different versions (SE, EE, ME and FX) are all just different APIs that sit on top of the JVM (you can find full descriptions here: Your First Cup). They are not different languages so there's no new syntax to learn switching between them, just different API calls.
Personally I prefers C# for developing web apps because of it's integration with ASP.NET and the MVC frameworks.
See the description here Java perspective
Related
I'm new to Java and have just started with some simple code.
I'm on a Linux machine, use the vim editor, use javac for compilation and 'java' for running
programs.
Basically, for the time being, I am looking for building a desktop application using Java. I've heard about Java (EE/SE/ME) and my assumptions about them are:
"Core Java" is the "basic" Java language(with all the rules about variables,
looping, methods classes etc).
Java SE is for Desktop Apps.
Java EE is for Web apps (using the HTTP protocol).
Java ME is for Mobile Apps.
However, I came to know that the difference among them is that "specification", from Difference between Java SE & Java EE
So my question is, can I create Desktop Apps using Java EE as well? Or are they only for creating Web Apps?
Java EE is a large collection of technologies that together forms a more or less coherent framework for building enterprise applications.
Now in the enterprise, server applications are used a lot and so many technologies focus on server functionality and/or multi-user. Serving web requests is but a part of this, there's also functionality for e.g. processing messages (JMS) and server remote method calls (remote EJBs).
A complete Java EE implementation like GlassFish or JBoss AS is not that often used for desktop applications (unless it's an application intended for personal desktop used, but that's browser based).
HOWEVER...
Nearly all of the technologies that make up Java EE can be independently used on top of Java SE and in combination with a graphical user interface.
For instance, there's an ORM framework in Java EE called JPA that makes it rather easy to store objects inside a database. A database, possibly an embedded one, can of course be used with desktop applications and this often makes sense. E.g. an email application might store mails in such a database. JPA explicitly has a section in its spec about being useable in Java SE.
There's also a framework for dependency injection in Java EE called CDI. This among others makes it easy to isolate dependencies and get hold of them. It's a natural fit for MVC graphical applications to e.g. get hold of the model in a controller. Like JPA, CDI has explicit support for Java SE.
As the last example, Java EE by default requires JMS to be present, but in this case JMS is not even specifically a Java EE sub-spec. Java EE only requires a JMS provider to be present, so naturally Java SE can use JMS (there is even API in JMS that is only legal to be used in Java SE). Messaging in a way can be part of an architectural pattern that is just as useable in desktop applications as it's in server applications (the desktop toolkit Cocoa for example uses it intensively).
There are more Java EE technologies useable in desktop applications, but I hope the above has given you some idea.
Java EE is a collection of technologies, including web apps.
Most of it isn't, though--things like JMS and JPA are part of Java EE, and are application-type-neutral.
Java EE is Java SE + enterprise technologies. So yes, you can build desktop app using java EE.
Java EE is just a set of specifications. Most of its implementation need something more than Java Runtime Environment used for JSE.
Different parts of Java need different kinds of containers.
Parts of Java EE 6 You can run on JRE:
Note about JSR 299 from the Weld website:
But the specification does not limit the use of CDI to the Java EE
environment. In the Java SE environment, the services might be
provided by a standalone CDI implementation like Weld (see Section
18.4.1, “CDI SE Module”), or even by a container that also implements the subset of EJB defined for embedded usage by the EJB 3.1
specification.
GlassFish can also run Java SE app in Embedded Enterprise Bean Container within the same JVM as Java EE app, so You can for example access Java EE's EJB using local interfaces.
Souroce of the images
Okay guys, I was new to Java and now I have become a bit "old". So I could figure it out.
This is it :
The ONE AND ONLY ONE required thing to Java development is a Java compiler which we get if we install a JDK and the thing we need to run a Java utility is a JVM. So these are the only things we require for ANY sort of Java Development(No matter Desktop, Web or mobile).
Then what is Java SE, Java EE and Java ME ?
Those are the above mentioned two things(Java compiler + JVM) plus a set of libraries(SE for Desktop, EE for Web, ME for mobile). So if any of us have enough time and have got a Java Compiler + JVM, we can build our own libraries for all those functionalities.
But following the concept "Don't reinvent the wheel" and because we'll be better off using a library/tool that has been running smoothly for years we all use the tools/libraries provided by SE, EE and ME.
So the answer is, I can develop any sort of applications with just a Java compiler(/usr/bin/javac on a Linux machine). The only thing is that there will be a lot of 'reinvention of the wheel'. And all java apps run on the same JVM(no matter what sort), in case of linux(/usr/bin/java).
How diferent is Java used in Android apps development from Java used to develop regular desktop applications? Can I use the skills acquired by developing Java Android applications in Java EE web development?
What is Java ME all about ?
How diferent is Java used in Android apps development from java used to develop regular java applications?
From a language point of view, almost identical.
From an user interface API and application life-cycle point of view, almost completely different.
Can i use the skills acquired by developing Java Android applications in Java EE web development?
Yes. Your pure "Java-skills" will come in handy for sure. But as said above, the application life-cycle for instance, is completely different from most other scenarios.
What is Java ME all about ?
JavaME is an older technique, typically used for phones without touch screens. It defines (compared to Android) a very minimal API and was originally designed to run on very limited devices compared to todays smart phones.
Android is, roughly, JavaSE without some of the more specialized features, like security layers (JSE and JAAS), GUI (AWT, Swing and Java2D).
Android's API uses the JavaME class hierarchie for OpenGL ES.
So if you know Android, you can easily move to JavaSE development.
JavaEE relies on JavaSE, but it's about server applications, so you will have to learn how it works. Look for servlets, JSP and JSF to learn more about it.
JavaME is slightly different than JavaSE. JavaME's API is smaller and less powerful than JavaSE, and slightly different.
Well, in order to develop both for Android, Java ME and Java EE the base thing to know is Java SE. Java ME is getting old. The most popular staff to develop in Java ME is software for Blackberry.
Java EE development is pretty hard to learn technology, cause it actually consists of a big ammount of frameworks and smaller technologies. It's complicated because of many things, but, definately in order to use it you should start learning Hibernate/JPA, Java SE, RMI and OOP itself. Then you may look into Spring technology.
For Android Java is about a programming language and some core java library
J2ME is also a mobile application development framework supported by many phones. The common thing between Android and J2ME is only the Java language. Both have different set of terminology for development.
Web: It's about target platform and programming model. Android's Java is for mobile development platform. Here the apis, software stack, concepts are totally different from what are there for Web development.
I have a few questions to understand better Java's usage in context of web applications:-
Is Java EE web development suitable for small start-up (with less human resource) looking to develop an web application ?
What kind of difficulties may arise in Java EE web development, deployment & maintenance ?
What kind of things should be kept in mind/ considerations to be made when moving from PHP background to Java ?
Why Java web applications are not so popular today? ( or in case I perceived it wrongly, please list any major deployments beside linkedIn and ebay)
and Finally, What are some of the most important things to learn before starting web development in Java EE ?
Thank you
Generally the answer to the question of "what technology to use" is "the one which you have most experience with". However, Java EE is huge and clunky, and definitely not good for rapid prototyping, which you will be doing if you're doing a startup.
Personally I would recommend a more modern and dynamic environment. If you're coming from PHP, you should be able to pick up Ruby on Rails or Django (Python) easily. These two choices are in my opinion orders of magnitude better than Java EE. If you want to stick with Java, at least go with the Play framework then.
Is Java EE web development suitable for small start-up (with less human resource) looking to develop an web application ?
Yes, I worked in a startup where I was the only full time programmer.
What kind of difficulties may arise in Java EE web development, deployment & maintenance ?
The same as in any other web development shop. Of course, the problems have their Java flavor. For instance, one bug we discovered was caused by different minor version of JDK used on the live system than on our test system.
What kind of things should be kept in mind/ considerations to be made when moving from PHP background to Java ? Do not code the PHP way. Java's strength is OOP and its many libraries/ open source frameworks. Use that.
Why Java web applications are not so popular today? ( or in case I perceived it wrongly, please list any major deployments beside linkedIn and ebay)
I don't know why you think that, but Java is used everywhere. It is one of the few languages that Google officially uses. They use PHP as well, but it has a "lower" status.
and Finally, What are some of the most important things to learn before starting web development in Java EE ? Use Java's strong points which I mentioned above.
Updated after comment
I cannot make the choice for you. If you are in doubt and in a big hurry you should not go with Java. This is common sense. However, it is an opportunity for your team to learn and grow. Maybe there is a PHP/other client for Cassandra. I knew a former PHP programmer in a startup, who switched to Java. Not saying anything bad about PHP programmers in general, but he did all kinds of strange things, such as not leveraging the power of Java web frameworks and writing lots of procedural code mixed with HTML and SQL. Obviously there are lots of Java programmers who would do the same thing. The point is that your team will probably learn new ways to do things and benefit from it in the future.
Allow me to answer these from the perspectives of a developer/architect in a small start-up, experiencing a bunch of these issues.
What kind of difficulties may arise in Java EE web development, deployment & maintenance ?
How do you decide on which toolset/framework to use? Do you need an IDE? Which version control system and why? Do you want to develop at some place and deploy somewhere else, or develop directly on the server? Do you buy a linux box for this, or rent some cloud? How much do they cost, in terms of licenses and training?
What kind of things should be kept in mind/ considerations to be made when moving from PHP background to Java ?
How would your servlet send out an e-mail? It's much simpler in PHP. Need secure transfer of encrypted objects? Java is your friend. What about session tracking? Use cookies, or have a dedicated class do it? How do you access the database? Want to use hibernate? What other tools is hibernate dependent on? What are their costs (license+learning)? Can you use JDBC directly? What are the pros and cons? Which db to use to why.
Why Java web applications are not so popular today? ( or in case I perceived it wrongly, please list any major deployments beside linkedIn and ebay)
I am not sure if this is the case, but possible reasons could be the availability of .net and integration with C# based systems and Apple ditching Java from its SDK. But that is my speculation, don't quote me on it. I am developing a large scale system myself with Java 6.
and Finally, What are some of the most important things to learn before starting web development in Java EE ?
(This is my opinion) have a test or trial set up of the entire architecture. Is the GUI web-brower based? Is it an applet? Standalone application talking to a server? JNLP system downloading archives and JRE off the net? You will find some stuff do not work on Windows 7, some do not on Vista, W3C have deprecated the applet tag from HTML but Sun/Oracle asks you to use it, different browsers do not support contents of your style sheet, etc.
Firewall set up is another major challenge - you start using thread pooling using Spring libraries and your capabilities to use DBvisualizer to check on DB tables are gone! Now you need a DBA and a sys-admin to fix these who you do not have!
Personally I found the LAMP architecture (Linux-Apache-MySQL-PHP) the fastest way to go for smaller applications, but if you need heavier guns for your app (security, GUI with swing, multithreading, etc), replace the P in LAMP with a tomcat container. The hardest thing I find is to judge the value of a tool in the context of my application - I do not need a tool that generates Java files with getter/setter methods given a list of variables - to me that is yet another level of indirection, but then JUnit in eclipse is helpful for debugging.
Just shared some of my thoughts - hope this helps, - M.S.
For a startup an interesting choice could be the Lift web framework, which is used for developing "Java Web Applications" (although in Scala).
What has me going is the degree of web application development we are talking about.
There are different levels of web application development. For example, if I was asked to develop a web application to deal with housing customer information for a small mom and pop bakery (definitely not a enterprise situation), is there anything wrong with using Java EE as opposed to Java SE if I really want to.
I know you might say that it would be overkill, and I can understand that, however, am I going to run into development issues that I would not run into using Java SE? In other words, I am trying to determine when does a small business web application turn into a enterprise web application. It seems to me that I should be able to use Java model that I want.
Am I wrong in my thinking here?
Need clarification here if you can help me.
There seems to be some confusion over the usage of Java EE and Java SE terminologies. Just because EE expands to Enterprise Edition, it does not mean that it is used only by enterprises.
Java EE happens to be a set of specifications that are bundled together to form a platform. The moment you need to write a web application, you need to use the Servlet + JSP specifications at a bare minimum, which is a subset of the Java EE specification.
Java SE, on its own is usually used to write standalone applications. It is better to refer to Java SE more as an API or a library, rather than an as specification, in contrast to Java EE. It can be considered as a platform for the "non-enterprisey" applications.
Don't take Java EE literally. Java EE is not just enterprise development, per-se.
Java EE gives you the entire stack for building web apps on Java. You just can't do web development on Java otherwise.
Bottom line - you need the Java EE stack, even if you are a small/medium business. Don't let the name fool you.
Theres nothing wrong with using a full Java EE container. However this usually comes at the cost of complexity.
The minimum you need is a servlet container which is a subset of the Java EE specifications.
Full Java EE containers tend to have more to configure in them than simple servlet containers which may add overheads that are not worth it.
The other thing to consider is If you do use just javax.servlet to compile .war files then these are compatible with full Java EE containers so there is nothing to stop you upgrading at a later point.
Another point to keep in mind is JBOSS / GlassFish which implement the full Java EE stack use more memory and may have longer startup times than say tomcat.
If however you know that you will be using more of Java EE at a later point such as EJB; then I would start out with the full Java EE container.
To Summarise
Personally I would start out using just a servlet container. (not full Java EE). If and only if I needed a full Java EE stack then I would move to a full Java EE container.
What is the equivalent of a Java applet in .NET? Is it Silverlight? Is Java applet still widely in use?
Java applets were "the new hot thing" in 1997, when Java 1.0 came out. After a few years, they became less and less popular, mainly because installing Java on a computer was a big hurdle for many people (you had to download the whole JRE, which was big, it took a long time to install and Java was not that fast at that time - so many people saw it as a slow, bloated thing).
Macromedia Flash (which became Adobe Flash later, ofcourse) had advantages over Java applets in this regard - the plug-in was quick and easy to install, and so it became the dominant thing for interactive multimedia stuff on the web.
Microsoft's Silverlight is meant to be a competitor for Flash and Sun's JavaFX.
JavaFX is Sun's technology that should make it easy to do Flash-like things on the Java virtual machine. If JavaFX becomes a success, then Java applets using JavaFX might become popular again.
Note that earlier this year, Sun released a completely rewritten Java browser plug-in which is quicker and easier to install than the old plug-in. On of the things Sun is working on is making it just as easy to install the Java plug-in as it is to install the Flash plug-in.
Silverlight is analagous to Java applets, but not really equivalent. In my experience, Java applets are being used less and less.
Java applets are seriously out of vogue now - I haven't heard of any new apps using them in years. .NET has silverlight, which is more of a response to Flash than to Java applets.
In this day and age with JQuery and Mootools, MVC architecture, and Chrome's V8 engine, it might actually be better to just write your application in Javascript.
Silverlight.
However, while Silverlight may be the new hotness, Java applets are still a lot more popular... most people have a JVM, but most do not appreciate a massive Silverlight install just to see your web page.
Now, many things that could only be reasonably done in Java or ActiveX are done in plain old JavaScript using new AJAX/DHTML libraries like JQuery and Ext JS. Example: Google Maps. Unless you're doing fancy graphics, try JavaScript first.
From a language perspective, there is a Java-like language available in .NET called J#, which can ease your pain if you are translating Java code to the .NET platform. It doesn't emulate the Java GUI libraries, etc. but at least emulates the syntax.
Silverlight or XBAP. See the FAQ for differences.
Basically XBAP applications work on Windows only and run on the full .NET Framework. Silverlight on the other hand uses different core and set of libraries and is designed to be cross-platform.
Either SilverLight, or an ActiveX control (still in use on some sites). Java applet will work only if a JVM is installed on the client machine.
You'll see applets in use more in enterprises where tight control is maintained over installed Java versions and the browsers i.e. where the execution environment is constrained.
However I'm seeing fewer and fewer applet solutions even in these environments, especially with the rise of RIAs.