We Keep Coding

Restful web application, Java or PHP? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I'm creating an Android application which will access data using a restful web application.
I have quite a lot of experience with Java, but minimal experience with PHP.
Having looked online, it is difficult to determine which language is more suitable, scalable, portable etc.
I'm hoping that the Application may one day have many concurrent users and therefore I need the most suitable option.
If anyone has any experience writing a web application in either language, I'd be really interested to hear about your experiences, and any problems you faced.. i.e. for a java web application do you need a tomcat server or another embeddded to server for it to be able to run?
Thanks, for any answers, Matt.

If you already have experience with java, I would suggest you use the following to build your REST services: http://restlet.com/
Its very easy, and efficient. The performance is very smooth. For PHP, you will have some learning curve, and also there is no standard. Mixing java with PHP is like combining a VERY STRICT LANGUAGE (java) with a VERY LENIENT LANGUAGE (PHP). So its safer to be on the same language.
Tutorials:
Official tutorials to get started: http://restlet.com/learn/tutorial/2.2/
Good step by step tutorial with screenshots and code snippets: http://java.dzone.com/articles/restlet-framework-hello-world

Short:
Take JAVA!
Always choose the language you are comfortable with. Also I think Java is better suited in the end.
PHP isn't my favorit. Most of the people like it, because it is easy to start with. (It was also for me the second (non Browser) language I touched.)
Framework Tips
WebFrontend: Play Framework
Back End&Scaleability: AKKA
JSON: Gson
Long:
Scaleability in the meaning to scale to lots of concurrent users:,
is more a architectonical issue, as a question for the right language. You can write scaleable software in any language. The difference isn't the scaleability of a language, but it could be the performance. One language will take longer for the same task as the other one. But you could always throw more Servers in, to scale out.
Architectures to consider if you want to scale out, are in my opinion message based designs. My favorite is the actor model, there is a very good framework for that in Java, the akka framework (production proved). But I think you first should get your software running. If you get enough users... scalability problems are the problems you like to have (they mean you have users).
Scaleable doesn't only mean, that you can scale to many concurrent users. But the ability, to handle the complexity of the software or can handle concurrent development and so on (your team will grow, thats also a problem to handle). In this topics Java is as clearly static typed OOP language, better suited.
Also the performance will not be as good as in Java (it is a interpreted language). But there are always options. Facebook started with PHP. In an interview one of the lead developers, told that PHP isn't that scaleable, because PHP wasn't designed for OOP. But the performance issue was handled, through writing a compiler for PHP (outputs C++). [If if find the link I will post it] .
Update the PHP Compiler is Called HipHop and it uses HHVM (Hiphop virtual machine), Facebook developed it after excessive CPU usage

You can consider looking at https://jersey.java.net/ As a web container you can use anything like Tomcat. I have used Google App Engine in the past.

To get started quickly with Java look into http://dropwizard.io/, using less EE frameworks and more standard Java.
Has Jersey for REST and is supereasy to run.

Swing vs JavaFx for desktop applications [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I have a very big program that is currently using SWT. The program can be run on both Windows, Mac and Linux, and it is a big desktop application with many elements.
Now SWT being somewhat old I would like to switch to either Swing or JavaFX. And I would like to hear your thoughts on three things.
My main concern is what will be better for a desktop GUI application? (I looked online and a lot of people suggest that JavaFX is just as good as Swing, but I didn't see many valid arguments except simple opinion flame wars). It has to work on both Windows, Mac and some popular Linux distributions.
What will be cleaner and easier to maintain?
and what will be faster to build from scratch?
I am using MVC methology in my application, if that is of any help.

What will be cleaner and easier to maintain?
All things being equal, probably JavaFX - the API is much more consistent across components. However, this depends much more on how the code is written rather than what library is used to write it.
And what will be faster to build from scratch?
Highly dependent on what you're building. Swing has more components around for it (3rd party as well as built in) and not all of them have made their way to the newer JavaFX platform yet, so there may be a certain amount of re-inventing the wheel if you need something a bit custom. On the other hand, if you want to do transitions / animations / video stuff then this is orders of magnitude easier in FX.
One other thing to bear in mind is (perhaps) look and feel. If you absolutely must have the default system look and feel, then JavaFX (at present) can't provide this. Not a big must have for me (I prefer the default FX look anyway) but I'm aware some policies mandate a restriction to system styles.
Personally, I see JavaFX as the "up and coming" UI library that's not quite there yet (but more than usable), and Swing as the borderline-legacy UI library that's fully featured and supported for the moment, but probably won't be so much in the years to come (and therefore chances are FX will overtake it at some point.)

As stated by Oracle, JavaFX is the next step in their Java based rich client strategy.
Accordingly, this is what I recommend for your situation:
What would be easier and cleaner to maintain
JavaFX has introduced several improvements over Swing, such as, possibility to markup UIs with FXML, and theming with CSS. It has great potential to write a modular, clean & maintainable code.
What would be faster to build from scratch
This is highly dependent on your skills and the tools you use.
For swing, various IDEs offer tools for rapid development. The best I personally found is the GUI builder in NetBeans.
JavaFX has support from various IDEs as well, though not as mature as the support Swing has at the moment. However, its support for markup in FXML & CSS make GUI development on JavaFX intuitive.
MVC Pattern Support
JavaFX is very friendly with MVC pattern, and you can cleanly separate your work as: presentation (FXML, CSS), models(Java, domain objects) and logic(Java).
IMHO, the MVC support in Swing isn't very appealing. The flow you'll see across various components lacks consistency.
For more info, please take a look these FAQ post by Oracle regarding JavaFX here.
JavaFX Frequently Asked Questions

No one has mentioned it, but JavaFX does not compile or run on certain architectures deemed "servers" by Oracle (e.g. Solaris), because of the missing "jfxrt.jar" support. Stick with SWT, until further notice.

I don't think there's any one right answer to this question, but my advice would be to stick with SWT unless you are encountering severe limitations that require such a massive overhaul.
Also, SWT is actually newer and more actively maintained than Swing. (It was originally developed as a replacement for Swing using native components).

On older notebooks with integrated video Swing app starts and works much faster than JavaFX app. As for development, I'd recommend switch to Scala - comparable Scala Swing app contains 2..3 times less code than Java.
As for Swing vs SWT: Netbeans GUI considerably faster than Eclipse...

I'd look around to find some (3rd party?) components that do what you want. I've had to create custom Swing components for an agenda view where you can book multiple resources, as well as an Excel-like grid that works well with keyboard navigation and so on. I had a terrible time getting them to work nicely because I needed to delve into many of Swing's many intricacies whenever I came upon a problem. Mouse and focus behaviour and a lot of other things can be very difficult to get right, especially for a casual Swing user. I would hope that JavaFX is a bit more future-orientated and smooth out of the box.

Which are the advantages of developing in Java a server-side application compared to other languages? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
Our company is starting the development of a client-server application and a discussion is going on about which technologies should be used.
For the client (GUI) side we tend to QT and C++. For the server side, we have been advised to use Java and indeed it looks like it is one of the languages being used most for server development.
Can anyone elaborate on the advantages offered by Java for server side development and why adopting it should make our life as developers easier and/or allow us to reach better results than if we used, let´s say, .NET or even C++?
Thanks in advance.

Some advantages:
Run compiled code across platforms.
Managed memory (garbage collection).
Hude wealth of excellent open-source libaries.
Large developer market.
Easy migration for C++ developers.
Some disadvantages:
Aging language — has not kept up with language advances IMO (e.g. adding functional facilities).
Future uncertain after Oracle aquistion (will become clearer with time).
Low level programming difficult.
You may want to look also at other languages which run on the JVM, such as Scala and Groovy, at .NET (it can run on Linux et al using Mono) and even the D language, which provides a C++ like, compiled to native, language with modern features such as garbage collection (optional), code contracts, lambdas etc. These languages provide many of the benefits of Java over C/C++ but have also taken the progression a bit further or in different directions.

Apart from platform independence, the main advantage of server-side Java development is the wide selection of mature libraries and standardized frameworks. However, the main focus here is on web development.
For a C++ client, Java could still be beneficial if you use REST as protocol between client and server (JAX-RS is pretty nice). Otherwise, it depends very much on your application domain and whether there are Java libraries that could help you in that regard.

Let's put it this way... it's not which server-side language is better and what not, it is what's available in your company that you can leverage of and make good use of it. When you work in a big corporation, sometimes you cannot just introduce "yet another language"... it doesn't work that way. :)
Further, every language has its pros and cons. You can almost argue the pros/cons in both way depending on how biased or open-minded you are. You can choose RoR and all that bleeding age technologies, but if your team members are not comfortable in dealing a brand new language, how exactly are you going to maintain the project in long run? I mean, if your team is familiar with PHP, I don't see anything wrong using that compared to Java, .NET, etc.
Your customers don't care the underlying implementation as long as it works.

Java advantages:
- mature
- good to excellent backward compatibility
- wide range of available frameworks for almost any problem
- robust - garbage collection, APIs as java.util.concurrent
- great tools to manage code quality, good IDEs etc.
- very good performance
- support for scripting
disadvantages:
- sometimes too many frameworks for the same thing
- not all the frameworks have as good quality of code as you need
- looks easier than really it is

You have many options in server side. Since you have the control over server side you can basically use anything. Using .NET forces you to use Windows Server so i will prefer a framework that can run on any operating system and is portable.
Java was the right answer 5-10 years ago. Because it had portability, and can work on any system. But these days developers look for languages/frameworks that are easier to use, maintain and code. I will vote on Python these days for server side development because of this, its fast it easier to read and maintain code wise, and it has many open source projects/libraries that you can use, even Google is favoring python over Java(GAE had python support first, then support for Java came). You can use django on python for web development and twisted for writing a server that uses TCP to communicate.

There are several issues you need taken in accout to select the language:
which are the languages which know your team best / good enougth
which are the languages which know the team thet must maintain the server
are there the right frameworks with an quality that makes you want to use them
will the code be maintainable as long as the server is in production
how fast will be the development -- the importent thing here is not the time you spend to type the code - more important is the time that you need until the product works stable enougth to use it for production without reasonable bugs
communication with other systems - if every system you need to communicate with is an .net - that it would be wise to build the new system in .net too
are there any constraints (must use this server, open source policy of your company, ...)
cost of licences, ...
...
At least the descicion to use a specific language for an project with a reasonable size, is always the question of cost. But not only the cost to build the system, also the cost to maintain it. - The points mentioned above are all cost related: for example: if you do not knwo the language you are slower (-> $), if the system can not be maintained, it must be rebuiled (-> $), if there are not the right libs, you need to implemnt it by your own (-> $), if the language you picked make it easy for bugs to hide, you need a long time until the system can go in production (-> $)
In MHO, the advantages of Java are: the wide spread knowlege (this is for .net too), a huge amount of realy mature open source framworks (this is the point for Java against .net), and the usage of a strong typed system and a compiler wich result in less bugs is a long term advantage of Java and .net over every not strong typed scripting language)
One must have for all languages you use on a Server is an Garbage collection!

How do I best catch up with the latest developments in java? [closed]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a book, tool, software library, tutorial or other off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 8 years ago.
Improve this question
I am applying for a job as java developer. I programmed some hobby apps in java until 2001, after that I have mostly worked in c++ and other languages. Meanwhile, it feels like java has grown a lot, and there are all kinds of acronyms (EJB, spring, etc) unknown to me.
Where can I find a concise, clear explanation of the recent (5 years) development of java? What are key elements to understand?

2001? Wow, times have changed. That was what? Java 1.3?
Firstly, language features:
Generics: Java added generics in the 5.0 release in 2004, basically as syntactic sugar to stop you do all those casts from Objects out of collections;
Annotations: also in Java 5. Used extensively in persistence frameworks, Spring and elsewhere;
Typesafe enums: Java 5 added an enum type, which is basically a class (sort of);
Concurrency: Java 5 added extensive concurrency utils so multithreading has changed a lot; and
Asserts: a highly underused language feature added in Java 1.4. If enabled when you run your program, assets can check for various conditions and bomb out if they aren't true. The fact that you can turn them on or off when you run your program is great for diagnostics.
Thing is though, the above aren't even the big changes. In the early part of this decade, Java underwent radical architectural and philosophical changes.
Back in 2001 the big things were EJB, Swing and servlets/JSP. None of them really are anymore (at least not directly).
Proably the biggest thing to happen in Java (since its inception imho) is Spring and Spring really became big about 5 years ago. Spring is a lightweight container that also seeks to hide implementation differences between different providers and APIs. The biggest thing about Spring however is the principle of "inversion of control" or "dependency injection". The idea is that classes ("beans") are assembled from an external config ("application context").
A typical pattern in the earlier J2EE days was the Service Locator. It's now viewed largely as an anti-pattern. Basically you'd see code like this:
public MyClass() {
this.dataMember = ServiceLocator.locate("some service");
}
If you go around advocating this sort of approach these days you will be viewed as an anachronism, a rank amateur, a crackpot or some combination of the three.
Dependency injection, in its simplest form, will instead inject the necessary behaviour into classes without regard for the actual implementation. This kind of separation is deceptively powerful and a profound shift that Sun (still) hasn't really caugh tup with. It also greatly enhances unit testing.
Swing is still around but not so big anymore. Sun released JavaFX as a Flash competitor and applet replacement in recent months. I personally don't think it has much of a future (as Joel put it in his recent podcast, Java on the desktop is basically dead) but others will disagree.
EJB was big in 2001. Not so much anymore. It was (correctly) viewed as a nightmare of XML configuration, differences in application servers that made them largely non-portable (or non-trivially portable if you prefer) and they're such a heavyweight solution (pre-3.0) that they don't really have that many applications.
EJB 3.0 has taken a much more Spring-like approach of dependency injection (sort of) and annotations of POJOs (plain old Java objects).
Servlets and JSP were big in 2001. Struts began then or soon thereafter and was big until a few years ago. It's now been surpassed by other more modern Web frameworks (like Struts 2--no real relation to STruts 1 despite the name--Spring MVC, Seam and so on).
The big thing these days--not just in Java--is of coruse the Web and RIAs. Flash/Flex and Javascript/HTML/CSS (plus frameworks) rule the roost here these days (and yes theres GWT but it has a small following).
Weblogic and Websphere aren't as big as they were in 2001. JBoss still has a lot of momentum but my appserver of choice these days is Sun's Glassfish v2 or v3 Prelude.
IDEs have also changed. JBuilder was big in 2001. Now there are only really three: Eclipse, Netbeans and IntelliJ (probalby in that order of popularity but my preference is IntelliJ, which is also the only commercial one of the bunch).

I strongly encourage you to read blogs. That's usually the best way to get up to speed.
https://stackoverflow.com/questions/48701/what-is-the-best-blog-for-java-development
Plus look at this SO thread:
Learning Java

Subscribe and listen to The Java Posse podcast.

cletus gave an astonishing answer, but I have to strongly disagree with
Java on the desktop is basically dead
In fact, it is more than alive :] Eclipse IDE is far more than just a developer tool. Check out SWT/JFace/Eclipse RCP framework at eclipse.org - with it, you can build applications like Eclipse yourself. Text editors, graphical diagram editors, modelling tools, reports.. I can't keep up with Eclipse technologies myself... some of them have made it into Spring and are even planned in next Java version to be supported natively (modules like OSGi). Forget Swing, desktop apps these days are being developed in RCP way.
Some info can be found at http://wiki.eclipse.org/index.php/Rich_Client_Platform and eclipse zone at dzone.com.
Java now has support for JavaScript by default and aditionally a number of languages like python, ruby etc. have been "ported" to its ecosystem as Jython, JRuby. There is also a new language called groovy and its flagship project grails (which uses Spring and Hibernate).
GWT (Java to JavaScript converter + set of widgets) is gaining attention. There is even an emergent project called Eclipse RAP that aims to bring RCP stuff into the web.
Apart from JBoss and Glassfish, you may be interested in Jetty - an extremely lightweight yet powerful alternative.

JavaFX is now out: Are Applets and Java Desktop officially dead/dying? [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
JavaFX is now out, and there are promises that Swing will improve along with JavaFX. Gone will be the days of ugly default UI, and at long last we can create engaging applications that are comparable to Flash, Air, and Silverlight in terms of quality.
Will this mean that Java Applets that hail from 1990's are dead and not worth going back to?
Same with Java Desktop: What will be compelling for us Java Developers to use it rather than JavaFX?

In my opinion Java Applets have been dead for years. I wrote some in the late 90s - a Tetris game during an internship to demonstrate on a 40MHz ARM Acorn Set Top Box for example. Of course I bet there are some casual game sites that have tonnes of them still, and thus it will remain supported, but active development will/has dropped off.
Java Web Start is a handy technology in my opinion. That will still work with JavaFX, it's just another library for that system.
JavaFX will give Java opportunities beyond technical tools (like SQL Developer), in-house business applications and server applications (where it excels). I think it's one of those libraries that is worth learning for any Java developer, if they can get the time. There's no arguing that user interface libraries for Java have been sorely lacking, or overly complex, for many a year.
However there's a lot of competition out there, and it is very new (which means the development tool support is very raw, compared to Flash and Silverlight). Also people don't like downloading massive runtime environments, although broadband makes it less painful than 5 years ago for many!

I think this discussion is somewhat misleading. I an no fan of applet technology either (and I have been underwhelmed by JavaFX). But the point that this thread is missing is that, unless I am mistaken, JavaFX is built on top of applet technology. They are not competing or mutually exclusive. See these articles here and here.
It could be that the confusion is somewhat intentional on Sun's part as they do not want JavaFX and applets to be mentioned in the same sentence, since Applets had so many problems.

Java Applets are not dead.
They had a bad history, for several reasons:
Most platforms had bad browser plug-ins for the entire 90s, moving into the 2000s, and this gave Applets (and Java, to some extent) a reputation for slowness and large downloads.
The actual Applet platform created a new VM for each applet, which further created sluggishness, especially in the startup of an Applet.
many Applet developers weren't conscientious about minimizing the size of the jars they pushed down, even Further creating the impression of sluggishness
The improvements which bring JavaFX also bring improvements to the Applet (they are one and the same). VMs can be shared and caching is better than before. In addition, higher average user bandwidth can help even poorly designed applet deployments startup quickly. If you look along the axes of install base and platform power, the Applet is still pretty high up, if not the top, in my opinion.
JavaFX is cool, but it requires an additional runtime, and for many parts of it is just syntactic sugar on top of the Applet platform. Almost any problems Applets have today are shared by JavaFX for this reason

Java Applets died not because of the concept of an applet, but because the JRE plugin for web browsers was abyssmal.
In fact, Flash proved that there is a role for in-line interactive content.
JavaFX is a new way of programming rich internet applications - essentially equivalent to Java applets or Flash content. The new JRE runtime (1.6.0_10, aka "Update 10") includes lots of features that make running Java in the context of a browser much more palatable.
JavaFX != Java Desktop. The two are quite different, and each have a place in a developer's toolbox.

Actually, Java applets are a nice technology which could have been as ubiquitous as Flash, if only Sun didn't lose the PR and technology war with Microsoft.
Microsoft was pushing DirectX controls at a time, and leveraging IE market share against applets. I remember doing some benchmarks then: Java applet of 3 MB (which was large), loaded from local disk (to take network load times out of equation), took around 5 seconds to start in Opera. The same applet somehow took about 2 minutes to start in IE.
So, it wasn't that technology sucked; it wasn't that applets were slow because they were too big; they were slow because the dominant browser at the time deliberately made them slow. :)
I guess that JavaFX is Sun's attempt to revive a lot of ideas from applets, at a different time and in a different market.

Though this might eventually be true , currently JavaFX lacks controls , no mobile devices support and other lacunae which makes it 'not there yet'

Will this mean that Java Applets that hail from 1990's are dead and not worth going back to?
JavaFX and associated changes are an attempt to revitalize the applet space - applets were always dogged by poor plugin implementations and flakeu`y bridges into the browser. That's been improved - though still needs more work - but at last Sun has recognized it needed work and has done something about it. Applets are better positioned than they have ever been. Of the competition you mention - Flash, Air, and Silverlight - I think you missed out the key competitor - the browser/javascript - the browser makers are also addressing key platform weaknesses - javascript performance, ability to do arbitrary drawing ( ie canvas etc ). For low-end requirements I think a pure play browser approach is going to win out - for higher end graphics - JavaFX has a chance.
Same with Java Desktop: What will be compelling for us Java Developers to use it rather than JavaFX?
As a big developer of Java Desktop apps, one of the things that's missing is a decent set of basic widgets and the time to play! It needs a killer table implementation - you can embedded swing but kinda what's the point. Now I could write my own by that's not really where I'm adding value in my kinda of job.

1 - Will this mean that Java Applets that hail from 1990's are dead and not worth going back to?
With the update to the Java plug-in - all applets, not just JavaFX-based applets get the improved user experience and performance. That being said - I don't think there are many (if any) killer applets out there. If there were - JavaFX would never have been needed.
2 - Same with Java Desktop: What will be compelling for us Java Developers to use it rather than JavaFX?
If you are building GUI applications and want to run it in Java - in particular across multiple platforms (e.g. desktop, applets and mobile) as well as make it easier to work with someone who has actual Photoshop/GIMP skills - JavaFX is your best choice because it was designed explicitly for that type of process. However, remember JavaFX can call Java code and it can also make remote calls (either getting back XML or JSON). I think the most likely integration point will be to use JavaFX for UI and caching of results but all of the heavy coding logic will be on the server. Where it can be written in Java or .NET or assembler if you can get your assembler to emit XML or JSON :).

I agree with the others, Java Applets already died. JavaFX could possibly fill that void. However, I just don't see it replacing Java Desktop any time soon. It's the same thing as saying web apps will replace all desktop apps. Some people do believe that, and I agree that web apps will grow in popularity, however, desktop apps will continue to have a place for quite awhile.

We cannot easily write applets down as there are way too many good code on a web. Lots of it was written by people who are not specialists in software development but are specialists in various high end areas that they tried to explain and illustrate with the help of Java applets, the top technology at that time. They may not have time to learn new language and rewrite they work any. Many are not active for years.
I also see Java applets as more appropriate for community projects that are based on server side builds and code reviewing. Various fancy user friendly tools can make development of web components fast and easy but the result is either not human readable at all or very difficult to review.
We have recently launched the Ultrastudio.org project that still relies on Java applet technology. I was thinking a lot about putting more languages and platforms but at the end was forced to conclude that it is either less secure or otherwise way more complex to do.