2

Web pages are usually tested by refreshing the page, clicking some UI component, then either writing to a debug log or adding some breakpoints in the IDE... in larger applications, unit tests are written to guarantee the output of the program, etc.

It seems like Java is an awful server-side language for a web page. You have to recompile every time you modify any line of code and pass the built EAR or WAR to the application server... something like Python or PHP (or any other interpreted language) would execute at run-time, removing the need for compilation before testing.

My question: what is the justification to using Java as a server-side language? Why is it better to use than an interpreted language?

Improve this question
21
  • 2
    @VincentSavard Right now, I have to build (which takes 10 minutes), once it finished building, I have to start/stop the server and point it towards the EAR/WAR. Therefore, testing one line of code takes 10+ mintues
    – Kellen Stuart
    Apr 30, 2018 at 19:04
  • 3
    Seems like a flaw in your process, not in the programming language.
    – Vincent Savard
    Apr 30, 2018 at 19:05
  • 1
    Then your strategy must be to test that line of code before it ever gets to the ant job. The ant job, therefore, only has to run one time per release, prior to your integration testing or whatever the next phase in your development process is.
    – Robert Harvey
    Apr 30, 2018 at 19:42
  • 1
    Your question makes no sense. There is no such thing as an "interpreted language". A language is a mathematical specification, a set of rules and restrictions, a piece of paper. It is neither compiled nor interpreted. It just is. Compilation and interpretation are traits of a compiler or interpreter (duh!), not a language. Every language can be implemented by a compiler, and every language can be implemented by an interpreter. There are interpreters for C and C++. There are compilers for ECMAScript, Python, PHP, and Ruby.
    – Jörg W Mittag
    Apr 30, 2018 at 20:28
  • 2
    @KolabCanyon I think you're confused. Bad build/deplyment systems (which is fashionable these days to bitch about) would make even Python and JavaScript to have the same trouble as Java. I once built a C based Web app for a router and I could test it really fast (less than a minute) despite being a bloated web app. Do some sleuthing and find the real root cause than blaming language itself.
    – Unmanned Player
    Apr 30, 2018 at 20:59

4 Answers 4

Reset to default
8

There's the title of your question which is a valid one and then there is the content of the question which contains some poor assumptions and/or incorrect statements. I'll address the body first:

You have to recompile every time you modify any line of code and pass the built EAR or WAR to the application server...

Not true. First of all, technology exists for Java which allows you to modify code and have it change a running application without even restarting the application. I link to the product not to endorse it but rather as proof. I have used it and can verify that it works. Secondly, python must also be compiled. It's just when that compilation occurs. In java you do it ahead up front. In python it happens at runtime (the details may vary depending on the Python variant)

As far as why one would use a pre-compiled language, here are a few reasons off the top of my head

  • bytecode files are smaller than source files and servers (not being human) don't need source.
  • Compiling ahead of time allows you to catch syntactical errors. Why wait until you've loaded your file on the server to find out that you forgot a colon?

The rest of the reasons around why you would choose one over the other really aren't about when you compile. They tend to center around dynamic versus static code and the advantages and disadvantages between the two approaches. I would expect well written Java code to be faster than well written Python though this is a factor that can change over time in both actual speed and whether it matters.

Improve this answer
4
  • It sounds like you have to use JRebel to get a workable development environment. That's really the frustration, is I may not be able to use any product I so desire depending on the licensing
    – Kellen Stuart
    Apr 30, 2018 at 20:58
  • 2
    @KolobCanyon I have no idea why your builds take so long. The fact that you are using ant implies your build environment is antiquated but that still doesn't explain it. Is there a reason you don't test locally? I typically just save and run. The time to build and start a simple app is a few seconds or less. My guess is you have code generation or something like that going on. I would say though that if you can't fix your builds, that might be a tool to consider. It's relatively cheap and works well for "refresh the page" test cycle.
    – JimmyJames
    Apr 30, 2018 at 21:08
  • 5
    @KolobCanyon It sounds like a legacy project but another thing that vastly improves the Java server side experience is using an 'embedded' web server as opposed to build ears and wars and all that. If you are up to your ears (pun intended) in the old web model it can be hard to shift over but I'm reading between the lines that you are maintaining an old system built by (many) other people over the years.
    – JimmyJames
    Apr 30, 2018 at 21:19
  • 1
    @KolobCanyon I'm working on a 100 kLOC project - this is probably much smaller than yours, but it starts in five seconds from my Eclipse (no JSP, just JSON API; no deployment; a new process using embedded Jetty and killing the old one) and I find it way too slow. Your build times would make me quite the job.
    – maaartinus
    May 7, 2018 at 4:01
6

First, your hyperbole is a little off:

You have to recompile every time you modify any line of code and pass the built EAR or WAR to the application server...

That depends entirely if you are using JSP or some other template library to build your application. JSPs and most alternative templates allow you to edit in place and simply reload the page. You just have to remember to copy those changes back to your repository. But there's more, see below.

Why Java?

The biggest advantage that Java has over several other languages is the ecosystem surrounding it. Whether you are building a Spring based application or doing your own thing, typically there is some API out there that is ready to support what you want to do. The Java ecosystem has largely specialized on the server side. Knowing you don't have to reinvent the wheel is a big boon.

Does Java have it's downsides? Absolutely, but that applies to every computer language invented. If you don't think so, you probably haven't built anything substantial with that language.

Blaming Java for a slow build is unfair. Take some time to see if a better build tool can improve your build times. If your build server is anemic, take time to figure out how to improve how it builds. For example, I have a project that takes 2.5 minutes to build on my local machine to compile and create a deployment package from all the Java, C#, and Python pieces. The same process on the build server takes 14 minutes. A lot of that has to do with disk speed and it being an older server. Fix the build.

Why not an interpreted language?

That really depends on the platform you are building and the team you have. It's one thing to say you are using Ruby on Rails or PHP, etc. and another to find competent developers to support your app. To be honest, the personnel issue is the one reason we migrated away from Ruby on Rails in a project.

That said, there are very few technical reasons not to use an interpreted language. Typically it depends on if you can find all the support libraries you need for your particular domain.

  • Pick the language that serves your needs best--including finding people
  • Be careful to work in a way where you can commit working code to version control
  • Be objective when selecting your platform. An app is bigger than the framework or language it's built in.

They aren't mutually exclusive

For teams that use Java for web services and build Single Page Apps in JavaScript, they have the best of both worlds. The user interface is built using one of the many Single Page App platforms with the advantage of being able to experiment quickly. Meanwhile the web service part which doesn't typically change all that much can just be used.

In this world of microservices, it's becoming increasingly common to have a heterogeneous set of technologies. For example, you might have a python based service to take advantage of the natural language support libraries for part of your app mixed in with Java based infrastructure pieces.

Improve this answer
3

The existing answers haven't touched on the real reason Java became popular as a server side language.

When improvements in CPU performance started coming from additional cores rather than increasing clock speeds, applications needed to become multi-threaded to realize those performance gains. Java was one of the first languages in common use to introduce high-level multithreading constructs that made writing highly concurrent applications relatively easy. Despite Java's (no longer deserved) reputation for being slow, it was evident that you could write multithreaded server applications faster and easier in Java than you could in nearly any other language. So that's what people did.

Improve this answer
6
  • Add to that non-blocking I/O which came out in version 1.4. To Be Fair: all of those parallel constructs came from other languages first, and there was already a good set of libraries that implemented those concurrency tools since Java 1.3 days. In 1.5 it actually became part of the standard library, and the JVM was tweaked to make the implementations of those constructs a bit more straight-forward.
    – Berin Loritsch
    May 1, 2018 at 12:44
  • @BerinLoritsch Right. Even before the concurrency libraries, the language had support for threads and the synchronized keyword. I had the experience of attempting multi-threaded code in C++ before learning Java and the experience was like night and day.
    – JimmyJames
    May 2, 2018 at 13:48
  • @JimmyJames, true enough. I do think that some of the things that came along in C# later are easier to work with than what Java has, but they had the benefit of learning from Java's implementation. The rest of C#'s infrastructure (support libraries, etc) aren't as mature as Java's though.
    – Berin Loritsch
    May 2, 2018 at 15:14
  • @BerinLoritsch We've definitely moved on from synchronized. I'm not completely convinced though about the C# implementation being intuitive or easy to follow. I work with a team that ended up with deadlocks using await and they struggled to find the issue and resolve it. I'm really excited by the coroutines concept as in Kotlin.
    – JimmyJames
    May 2, 2018 at 15:25
  • @JimmyJames at the risk of this going on too long, it just goes to show that all multithreaded code is hard. Most common cause for deadlocks using async/await is calling a method that calls Task.Await() which throws a wrench in the whole thing. If you use async you really do need to make it async all the way through the API.
    – Berin Loritsch
    May 2, 2018 at 15:50
1

You have to recompile every time you modify any line of code and pass the built EAR or WAR to the application server

This is a process issue, and one that I didn't see answered above (including the voluminous comments).

Yes, for a production or QA deployment, you need to build a deployable artifact. This is a Good Thing, if only because it prevents well-meaning developers from logging into the server to make code changes.

But for development, you should be using an IDE (such as Eclipse or IntelliJ) to run the server locally. You can change a single line of code and the IDE will incrementally compile and hot-swap the class into the running server. There are some cases where you will need to redeploy the WAR/EAR, but you should never need a full build to do that.

If you don't like IDEs, you can get much the same effect by working with "exploded" WAR/EAR files. This is painful, so I don't recommend it, but it definitely works: Java will let you recompile a single class (which was one of the things that I enjoyed about Java vs C++ in the late 90s), and both Tomcat and Jetty will automatically detect changes to JSPs.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.