We Keep Coding

Compare java and scala in MultiThread aspect [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 11 years ago.
I just hear and see people saying scala is designed for MultiThread though it's actually for general purpose.
And it claims "The thing is that while you can make classes thread-safe in Java (if you know what you're doing ), Scala makes it easy and natural to do."
And indeed AKKA and Lift is written in scala.(actually java and scala)
But java also did improves in this aspect with the new package of java.util.concurrent.
So why didn't AKKA and Lift born in JAVA?
Maybe you will say scala makes java looks like C. :-)
Anyone can tell more insight or deeper thoughts on this?
I know the fact that it is possible to mix JAVA and scala. Scala is able to call seamlessly into Java code. So what java have,so does scala.
But what scala really improves that java haven't done yet regardless of different grammers?
Only some design like Actors/Agents or something else?
(note Actors/Agents are cannot solve all the problem in MultiThread.)
Or does scala compiler and adopting some functional language grammer really matters or helps more than in java?
I heard some news that scala is going to be able to adopt XText. To be able to leverage XText to write thread logic, not sure if this is true or not.
Scala looks like a mixture of languages and using this approach makes it more extensible to solve problems in this aspect?
UPDATE
Thanks for your excellent answers from different angles. I think they are all very good. No matter what side you are standing.
EDIT
Topic below (in SO one year ago) was asking about the similiar thing. The "constructive" conclusion is quite similiar. But this time ,some new points are coming out probably the way I am asking is a bit different. Just FYI.
Related:
What advantages does Scala have over Java for concurrent programming?
Java Concurrency: CAS vs Locking
Difference in MultiThread aspect between Java and C/C++
Pitfalls/Disadvantages of Functional Programming
Actually I am very interested in some one can answer this question in some brand new angle which could enlighten my mind , provide some idea unknown before.
But it's closed due to not constructiveness. :-)

I am not really an expert in this, but Scala is a (partly at least) a functional programming language while Java is not (it is imperative). One feature of functional programming is that it avoids (in a 'natural' way) side-effects.
Thread-safety on the other hand is pretty much about avoiding side-effects (i.e. different threads modifying same objects/parts of memory/other resources at the same time).

As it is today, I find Scala much worse than Java with respect to working with multiple threads.
The language specification doesn't define some really important things, that you would rely on, to make thread-safe code.
For instance, you should know that final instance fields are very special when working with multiple threads. They are guaranteed to have their initial value visible to all threads after the constructor has completed, even if the object is published with race conditions.
Scala makes no guarantees that a val will be compiled to a final field. It is usually the case, but since the specs don't state it clearly, you cannot take it for granted. Therefore, either you write boilerplate synchronization code that wouldn't exist in Java, or you write code that is not guaranteed thread-safe (and hope for the compiler to continue mapping your vals to final fields).

I'd say it not so much a matter of the actual language, but more about applying principles which ease concurrent programming, e.g. share nothing, message passing, immutable objects, side-effect free functions, etc. Scala is not a FP language in it's strictest sense, but it delivers access to functional programming techniques.
Abstractions like Actors/Reactors, which are part of the framework (not language), completely free the developer to handle threads and critical section synchronization directly. What's more: Since 2.9.x, parallel collections are directly included in the library.

Java Concurrency - modern examples, tutorials, excersies, step-by-step apps [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 9 years ago.
I want to learn features of java.util.concurrent libraries (so everything older, or non-java specific is no option for me).
I know basics and theory about concurrency and multithreading, I am not looking for theory.
I am now reading Java Concurrency in Practice. To be honest, I am quite disapointed of examples in this book. They're too short and simple and "dummy" for me. I am looking for some nice Java 5+ concurrency examples and exercies explained.
Is there something like that? I am quite afraid that If I don't use what I learned in JCIP very soon, I am going to forget it pretty much :/

Why not just search on GitHub (here is an example) ?
I have no affiliation, btw. But you can find projects that use "java concurrency" in the description or refer to the library in the code.
Another option is to think of your favourite Java frameworks. e.g. Tomcat or Quartz (though I don't know if they use Java 5 concurrency per se). Such frameworks would be excellent examples because it is real-world stuff.

definitely learn by making an application. for example, you could make your own real time online stock trading system or even an auction system. stuff like that that will thoroughly test your concepts. or you could participate in open source projects which focus on these types of applications..

I don't agree with your opinion of Java Concurrency in Practice, nevertheless, you might also want to look at "The Art of Multiprocessor Programming" by M. Herlihy and N. Shavait.
I recommend both books to understand more about the underlying principles of concurrency; rather than just skim read some code snippets.

Considering we are talking about "Shared state concurrency"
Look at the implementation of these two frameworks:
LMAX Disruptor :
They have very nicely used the concept of cache lines and ring buffers to achieve an extreme level of concurrency. Of course they are relying on atomic classes in concurrent utils plus their own ring buffer based concepts.
Google Guava Concurrent package:
They have decorated the Futures and Executor interfaces to offer real world concurrent event driven primitives. Underlying their framework is a good understanding of java concurrency classes and design patterns.
Shared state concurrency is not the only flavor, you may also like to check what Actor based frameworks e.g. AKKA are doing. This kind of concurrent programming is called message passing concurrency.

What is your preferred scripting language in java world (scripting language on JVM) and way? [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.
What is your preferred scripting language in java world (scripting language on JVM) and way? When do you prefer your scripting language over java (in what situations for example for prototyping)? Do you use it for large projects or for personal projects only?

For me, Clojure wins hands down. Being a Lisp, it's concise and dynamically typed, it has enormous expressive power so I can write a lot of functionality in a few lines. And its integration with Java is unsurpassed – I'm only partly joking when I say Clojure is more compatible to Java than Java itself. As a result, the entire breadth of Java libraries, both from the JDK and 3rd party, is fully useable.
Finally, with a little care Clojure code can be as fast as Java code, so I'm not even losing performance.

My favorite is Jython, and I use it by embedding a Jython interpreter in my Java application. It is being used in commercial projects, and it allows to easily customize the application according to the customers' needs without having to compile anything. Just send them the script, and that's it. Some customers might even customize their application themselves.

I've successfully used Groovy in a commercial project. I prefer scripting languages because of duck typing and closures:
def results = []
def min = 5
db.select(sql) { row ->
if (row.value > min)
results << row;
}
Translation: Run a SQL query against the database and add all rows where the column "value" is larger than "min" to "result". Note how easily you can pass data to the inner "loop" or get results out of it. And yes, I'm aware that I could achieve the same with SQL:
def results = []
def min = 5
db.select(sql, min) { row ->
results << row;
}
(just imagine that the String in "sql" has a "?" at the right place).
IMHO, using a DB with a language which doesn't offer rich list operations (sort, filter, transform) and closures just serves as an example how you should not do it.
I'd love to use Jython more but the work on Jython 2.5 has started only recently and Python 2.2 is just too old for my purposes.

I might prefer Scala, but I can't say, still learning. At the moment using Groovy to write small utility programs. Haven't tried even Groovy on Grails. Heard lots of good about Lift Framework for Scala as well.

JavaScript Rhino has a compelling advantage -- it is included with the JDK. That being said, later versions of Rhino than the one with Java 6 have nice features like generators, array comprehensions, and destructuring assignment.
I favor using it whenever the ceremony of handling Java exceptions clutters up the code for no real benefit. I also use it when I want to write a simple command-line script that takes advantage of Java libraries.

Java. Seriously. It's a powerful, easy-to-use (if a tad verbose) language that everybody knows. The integration with Java is great.

The company I work for embeds Groovy into a Java/Spring website, which is deployed on a number of sites. The scripts are stored externally of the compiled WAR file, and allow us to manipulate some of the site logic without having to roll out new WAR's to each site. So far, this approach has worked very elegantly for us.
A particularly nice feature of Groovy is that it can closely resemble Java code, which makes it very easy to port existing Java classes to it.

How about SISC (Second Intepreter of Scheme Code)?
REF: http://sisc-scheme.org/

Is the Java API poorly designed and why? [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 14 years ago.
I have heard this a lot, the the Java API is poorly designed. Do you agree and if so, how? I know there are major issues with the Calendar/Date apis. The collections api takes a lot of boilerplate code to use. The File/IO API can be complicated for some things.
But, does this apply across the aboard? And to which versions of Java?

In short, Java APIs are OK.
Longer answer is that some APIs went through changes, sometimes significant, over Java releases and may contain odd pieces. Date, for instance, has quite a few deprecated methods. Nevertheless, what's important is that those API do exist. Java is strong with it's standard library where you can find API for almost anything (may be not always perfect API, but good enough).
P.S. Next time someone produces such a statement, ask him how many languages he designed himself in his life.

Java was not a poorly designed API. Java was made at a time when current best practices weren't exactly known. A lot of implementations were done in a way that are now frowned upon. Since that time there has been a LOT of work done in order to incorporate better techniques and practices. That is why there is a lot of deprecated code.
A bunch of this stuff is talked about in the AMAZING book Effective Java. Bloch talks about some of the "mistakes" that were made in the initial implementation and how they have worked at trying to fix them. If you are a serious Java developer and haven't checked out Effective Java I recommend it HIGHLY. (I actually recommend all of 3 of Bloch's books. He is an excellent writer with a thorough understanding of Java.)

Some of the "is the Java API bad" is covered in the book Effective Java.
There are some parts of the API, like java.util.Date that clearly are poorly designed (all but a couple of methods are deprecated as of JDK 1.1).
There are some other things, such as the lack of interfaces on some of the JDK 1.0 classes (which happened because there were no such thing as interfaces when they were created (interfaces were added before 1.0 but after 0.0).
There are some things that were not done "right" because the convention came after JDK 1.1 has a number of things in the AWT change due to JavaBeans and the naming conventions used).
There are some other things that were not possible before language changes such as enums and generics.
A lot of the API is good. Some of it is poor. The early stuff in JDK 1.0 was clearly written for HotJava (an all Java web browser) and was not really thought out for general consumption.
It is safe to say that the older the API the "poorer" it is. Newer APIs are designed with the knowledge of what came before it. That goes across langauges too - Java is (depending on your opinion) better than C++. C++ is (depending on your opinion) better than C, etc..

Java is old (it has its origins in the early 90s although it wasn't released to 1.0 until 1995 or so) and anything that old has APIs you can criticize. It's not that they're bad per se. They're simply a product of their time and that philosophy is now considered bad (usually with good reason but not always).
To address the ones you bring up:
Date is awful just because it's mutable. An immutable date class would be much cleaner (Calendar has the same problem);
A public constructor on String is, at best, problematic. There's some disagreement on whether or not this is even a problem. In my opinion it is but it's not a massive problem by any stretch;
The java.io.* classes remind me a little of the C++ iostream library in the sense that they were an experiment that I think history has shown to be not a success (if not a failure). Just look at the code you have to write to read a text file into a String. Most other languages have a standard call that'll do this.
And some others:
The pre-1.2 collections are problematic. Josh Bloch (of Effective Java fame) was the architect for the changes to the Java Collections framework in 1.2. It was a massive change for the good and include interfaces for all the classes, abstract implementations, etc;
java.util.Properties extends Hashtable. This is a classic example of a product of its time. In the 90s object frameworks tended to inherit from something. Nowadays the tendency is (rightly) composition over inheritance but that wasn't the case 10-15 years ago.

You could argue that it is "poorly designed" because if they had to do it over now, its authors would build it differently. However, they have made a laudable effort over the years trying to make the best of it. However, hindsight is 20/20.
The Java API has the same problem of any library that has to "evolve while running".
It had been so many years since Java first came out, and many design decisions on the language and the library have evolved. However, the need to be backward-compatible keeps constraining the API and changes to it.
There are many specific examples of usability issues (I've been studying them for the past few years), but then again, few APIs are perfect.

I wouldn't say all of it is poorly designed. The main problem is backward compatibility, people still expect features that have long become deprecated to be available so there code written 10 years ago won't have to be changed. This makes the API rather large and often allows multiple ways to do the same thing with out it being clear which one is better.

Is the Java API poorly designed and why?
No
Because, although it is not perfect, the amount of bad API's if way lot less than the part that is just great!
Anyway, you really should ask this, to whom you heard it from directly, otherwise it will be what in my country is called "Broken telephone" ( which otherwise is a great kids game :)) where each node in the chain of massages modifies the message subtlety and at the end something like:
I don't like java.util.Calendar
may end up to
Java API is completely broken and the desingner should be jailed.
Of course in the middle there's a "message transformation"!!!
:)

Like anything that is around for some time, it gets stale. As with .NET, Sun, et al, have tried to keep things new. But, time stagnates everything, especially considering you cannot change interfaces, only add, as changes break things. :-)

No, Java API is great for most parts, but some parts of it are just rotten. Everyone uses Date and Calendar as examples (here's the mandatory joda-time link) but I'd use XML API (the native/W3C one that is since there's several nowadays) as a good example too: The issue with that part of the whole API is that it just doesn't work as expected and doesn't conform to the rest of the API.
Also one important factor with Java API is that it's consistent and not just within itself but within versions and platforms (with the exception of AWT) and I sure haven't hit any magical spot with Java API yet which would've changed/broken something when doing a version switch.

I started using the Java API in ~1995. Any API which is that old is easy to criticize.
To answer the question of Why:
Java introduced enums too late - the API would be much better if it had enums from the beginning.
WORA (Write Once, Run Everywhere) - or as some say "Write Once, Debug Everywhere". It is incredibly difficult to make a great API when your target is the least common demoninator. No "real" Windows or Mac or Unix or Linux developer can ever be happy with Java.

What are the benefits of Java? [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.
I always hear that programmers try to pick the right tool for the job. I've never programmed in Java, so I was wondering What are its benefits? Why is it so popular? What should I use it for?
I just program recreationally. Is there anything about it that makes it particularly fun??

I think after 12 years or so, the "write once, run anywhere" mantra is almost true. Writing Java code pretty much isolates you from the platform dependent aspects of the systems on which you deploy it.

Portability
Incredible breadth of libraries
Bottom-up security
Performance
Robustness

Massive communities, the amount of help, libraries, IDE's, is huge (and thats a good thing).

For a casual programmer Java can teach a lot about object-oriented programming, and encourage good programming habits in general, without the need to worry about as many of the "messy" details (pointers, memory management) as, say, C++.
It's also a bit easier to debug "catastrophic" errors.

Java is really good at integration - there are specifications and implementations for integrating with many kinds of systems that you're likely to run into in an "enterprise" environment.
It's not really a "fun" language relative to popular high-level languages.

This seems to be getting healthy answers, but you might also want to look at "Why do people use Java?"

Java is a good language, but that is secondary to the importance of the standard library that comes with it. The jdk may not be the most elegant kit ever built, but it is extensive, powerful and reliable. Programming in Java the language is simple. Programming with appropriate reuse of the jdk is what it is all about.

Cross platform is in my opinion the most relevant benefit.
The main goal of Java was to create a programming language that could run anywhere. The target was GUI apps. This however never happen because the environment was too slow at the beginning ( now it has been improved ) but it prove true in the server side where the cost of development reduced a lot because the product development can be done in PCs and the deployment in very expensive hardware.
It brought easy of development also, because it was designed to have C++ like syntax but running on a virtual platform to avoid platform specific code. At first the penalty was the execution speed, because it was interpreted, but release after release the interpreters became more and more faster that even MS model its next generation of development after java and call it .net
Additionally You can have a read of the Java design goals here

I want to add one point: Java keeps a good compatibility to earlier versions. That means, your Java-projects are compile and run in most cases without any problem on newer versions. That seems to be a little point, but this stability in API's and language helps to build a big community around Java, including good tool-support.
Others already mentioned other important points:
good portability
lot's of libraries for nearly anything
easy debugging and easy to catch problems

There are only two reasons to use Java:
The Java Virtual Machine (Hotspot).
The huge amount of available libraries and tools.
There are other languages that run on the JVM and make better use of Java libraries than Java does, however.

After using Java for some time, I've come to the conclusion that it's fun to write in, limited in some very irritating ways, and it's performance is good though it seems that many programs are crippled by poor design.
I'm not sure if the latter is a function of Java, or an effect of Java.
In either case, in addition to all of the above stated benefits it's very useful for doing "net" related things. Treating resources with a simplified interface regardless of "where" the particular resource is, etc...
It is by no means a universal hammer.

oop provides like encypsilation ,inheritance,polymorphism not available in traditional programing .oop is closer to real life presentation of the programming
1. Relation ships can be representation using inheritance
2. Programme developement become easy due to increased modularity