Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
For the past few weeks now I've been studying Concurrency(Multithreading) in Java. I find it difficult and rather different than anything I've encountered in the Java language so far(or in programming in general). Often I have to reread and reread over and over again until I start to understand a small concept fully.
It's frustrating and I've wondered why this part of the Java programming language has given me so much trouble.
Usually when I look at the code of a single-threaded program I look at the main method and start going step by step in my mind through the whole execution(like a debugger). Throughout this process I try to keep in mind EVERYTHING like variables and their states(values) at every point in the execution. Often times when doing that I even stop at certain points and think how the program execution would alter in different scenarios. If I can go through a program from start to finish like that, I feel like I've fully understood the code and the material.
The problem that I have, I suppose, is that when I try to apply this method for a concurrent application, there are so much things happening at once(sleep(), synchronized methods, acquiring intrinsic locks, guarded blocks using wait(), etc.) and there's so much uncertainty of when something will execute, that it becomes nearly impossible for me to keep up with everything. That's what frustrates me, because I want to have a feeling of "I have control over what's happening", but with concurrency that's impossible.
Any help would be appreciated!!!
Concurrency is a simple concept, really - you have several separate paths of execution, which can interact with each other. The stuff you mentioned, like syncing, blocks, waits and so on are technical details, tools.
I would suggest trying to do some coding :-) Come up with a multi-thread program idea and code it. At some point you will need to use one of the tools you listed and it will all begin to fall into place. This is NOT a concept you should to understand only in theory ^^
More over a Science, Concurrent Programming is an art.
Before going into Java concurrency, PLEASE DO go through the conceptual things first.. i.e. what are the major problems in concurrency? what is a lock? what is a semaphore? what is a barrier? why we are using those? how can we use them for different purpose like variable protection, synchronization etc.? Likewise there are some.
Then you would probably get some very important knowledge before getting into language specific usage.
For a person who have followed sequential programming all the time and first looking at concurrency, definitely it would be harder to understand those things at once. But I am sure you can go to the level that you are in sequential programming for concurrent programming also after some time. :))
Related
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 6 years ago.
Improve this question
First of all, I love Python, and I currently use it for most stuff. However, as a PhD student, I mostly implement prototypes for testing and evaluating ideas. This also includes that I'm usually the only one coding, and that -- while I certainly try to write half-way efficient code -- performance is not a primary issue. And for quick prototyping, Python is for me just neat.
Now I consider to go with some of my stuff more "serious", i.e., to bring it into a productive environment, make it better maintainable, and maybe more efficient. So I wonder if it's worthy to rewrite my code to, say, Java (with which I'm also reasonably familiar). I know that Python is not slow, but things like Java's static typing including seems to make it less prone to errors on a larger scale, particularly when different people work on the same project.
It's only worth it if it solves a real problem, note, that problem could be
I want to learn something better
I need it to go faster to reduce power requirements in my colo.
I need to hire more people and the talent pool for [insert language here]
is too small.
Insert innumerable real problems here.
Python and Java are both suitable for production. Write it in whatever makes it easiest to solve the problems you and or your team are facing and if you want to preempt some problems make sure you've done your homework. Plenty of projects have died because they chose C/C++ believing performance was going to be a major factor without thinking about the extra effort involved in using these language well.
You mentioned maintainability. You're likely to require more code to rewrite it in Java and there's a direct correlation between Bugs and LOC. It's up for debate which one is easier to maintain. I'm sure both camps believe theirs is.
Of the two which one do you enjoy coding with the most?
The crucial question is this one: "Java's static typing including seems to make it less prone to errors on a larger scale". The crucial word here is "seems." Sure, Java will help you catch this one particular type of error. But how important is that, and what do you have to pay for it? The overhead imposed by Java's type system means that you have to write more lines of code, which means reduced productivity. I've used both and I have no doubt that I'm more productive in Python. I have found that type-related bugs in Python are generally easy to find and fix. Keep in mind that in a professional environment you're not going to ship code without testing it pretty carefully. The bottom line for a programming environment is productivity - usable functionality per unit of effort, not the number of bugs you found and fixed during development.
My advice: if you have a working project written in Python, don't rewrite it unless you're certain there's a benefit.
Java is inherently object oriented. Alternatively python is procedural.
As far as the ability of the language to handle large projects you can make do with either.
As far as producing more usable products I would recommend java script as opposed to java because of its viability in the browser. By embedding your js in a publicly hosted website you allow people with no coding knowledge to run your project seamlessly in the browser.
Further more all the GUI design features of HTML are available at your disposal.
That said any language has it's ups and downs and anything I've said here is simply my perception.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I have noticed people speak about AI. My perception of A.I is code written such that a program can learn and simulate human behavior or even write its own code. I want to know if this can be done with java language on an IDE and if so an example code would be nice( code that can write its own code).
This can be done in any general-purpose language; there is nothing inherent to a computer language which would make the resulting program either able or unable to "learn" because learining is a much higher-level concept.
Also note that learning is not exactly a clear-cut concept: any program whose behavior changes based on previous input could be argued to have "learnt" something.
Historically, LISP has been perceived as a language particularly well-suited for AI work, and indeed was the primary language of the AI movement of the '80s. An important reason for this is that it is particularly easy to make a program which writes LISP programs. This not to say that a Java program couldn't be made to do the same; it would just be far less convenient and require much more library support.
What you refer to is called http://en.wikipedia.org/wiki/Self-modifying_code and is not the same as AI. It was often used in the assembler days for performance optimization (for example removing a conditional statement after it is sure it will never be executed again) but I have never seen it used in Java, even thought it surely is possible. See also Self modifying code in Java.
You might want to take a look at machine learning. This branch of AI revolves around systems which learn from data given to them. If you really want to learn, there is a course available on machine learning on coursera.org.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
I am new to this. I have been learning java for a few months and I am working on my first project, myself.
What confuses me is that I write a few lines, run it, sometimes it works, a lot of times it doesnt. Then I have to google it, find a solution, incorporate it. Then I try to write more code, sometimes it works and often I have to repeat the whole process , or ask here at stackoverflow.
Now probably because i am new , with practice I won't need to look up things as often, HOWEVER, as my skills get better, the projects I take on will get harder as well,so I am guessing that I will STILL have to keep looking things up. Like I learnt how to send data over TCP/IP, then I had to look up how to encrypt it, then how to encrypt with strong encryption, then store that data in a derby datase , each time I have to continually look things up.
So the question:
Part 1:Does this process ever end? Surely it must, otherwise how do software projects get finished. Programmers couldn't be looking things up all the time? Do I just need loads and loads of coding hours?
Part 2:It always seems to take longer than I anticipate. If I am using the GUI editor to design a form and think I can do it in two days ( as an example) something ALWAYS goes wrong and it takes 2-3 times as long. If I am so lousy, I won't even be able to hold a job, I'd be fired in 3 days :(
Any help from experienced people greatly appreciated.thanks
Le Prince De Dhump
As you get more experienced, you will have to look things up less and less. However, I can tell you that you will never stop looking things up altogether. I've been using Java for about 8 years now and still use Google to look up code snippets and answers to questions all the time. There's no shame in it, it's just part of being a programmer.
Part1: I write programs for about 25 jars and still use google or search in books to find solutions [Its often faster than come up with something new of your own]. More practice and better knowledge of the libraries, data structures and algorithms reduce the amount of searching on the web.
Part2: It is a common problem in software development to underestimate the time needed for the implementation. You need a lot of practice and review what was the reason it took longer than expected. It seams that software developers tend to blank out all the little problems that will eat so much time while implementation.
My advice: Split your problem in little peaces and estimate the needed time separately. If possible compare the problems to one you have solved in the past and remember how many time they took. And at the end of the project review which estimations where totally wrong and try to figure out what was the reason. That helps for future estimations.
Out there are so many books which try to help you to solve the time estimation problem. Reading some of them may also give clues what the pitfalls are.
I think it is a more general issue regarding with the concept of skill acquisition (so perhaps more suitable for "the workplace" site).
There are two good bools about the subject, "Mastery" by Robert Greene and "Outliers" by Malcolm Gladwell, about this subject and the 10,000 hours necessary needed to acquire a disciple.
A short answer: this is the normal: these things that you are doing have not yet been "wired" to your brain and that takes time and attempts. After some time doing those tasks, you will be able to "remember" faster, or do them on subconsciously. Additionally you will be able to build associations, so that your mind will be able to recognise more patterns (or differences) etc. Each thing that gets "in" your head will be accomplished with less effort therefore you will be able to think deeper and achieve more at the same time.
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
After reading "Java concurrent in practice" and "OSGI in practice" I found a specific subject very interesting; Safe Publication. The following is from JCIP:
To publish an object safely, both the reference to the object and the object's state must be made visible to other threads at the same time. A properly constructed object can be safely published by:
Initializing an object reference from a static initializer.
Storing a reference to it into a volatile field.
Storing a reference to it into a final field.
Storing a reference to it into a field that is properly guarded by a (synchronized) lock.
My first question: how many java developers are aware of this (problem)?
How many real world java applications are really following this, AND is this really a real problem? I have a feeling that 99% of the implemented JVMs out there are not that "evil", i.e. a thread is not guaranteed (in fact its practical (almost) "impossible") to see stale data just because the reference is not following the "safe publication idiom" above.
Proportionally, it's probably fair to say that very few programmers sufficiently understand synchronization and concurrency. Who knows how many server applications there are out there right now managing financial transactions, medical records, police records, telephony etc etc that are full of synchronization bugs and essentially work by accident, or very very occasionally fail (never heard of anybody get a phantom phone call added to their telephone bill?) for reasons that are never really looked into or gotten to the bottom of.
Object publication is a particular problem because it's often overlooked, and it's a place where it's quite reasonable for compilers to make optimisations that could result in unexpected behaviour if you don't know about it: in the JIT-compiled code, storing a pointer, then incrementing it and storing the data is a very reasonable thing to do. You might think it's "evil", but at a low level, it's really how you'd expect the JVM spec to be. (Incidentally, I've heard of real-life programs running in JRockit suffering from this problem-- it's not purely theoretical.)
If you know that your application has synchronization bugs but isn't misbehaving in your current JVM on your current hardware, then (a) congratulations; and (b), now is the time to start "walking calmly towards the fire exit", fixing your code and educating your programmers before you need to upgrade too many components.
"is this really a real problem?"
Yes absolutely. Even the most trivial web application has to confront issues surrounding concurrency. Servlets are accessed by multiple threads, for example.
The other issue is that threading and concurrency is very hard to handle correctly. It is almost too hard. That is why we are seeing trends emerge like transactional memory, and languages like Clojure that hopefully make concurrency easier to deal with. But we have a ways to go before these become main stream. Thus we have to do the best with what we have. Reading JCiP is a very good start.
Firstly "safe publication" is not really an idiom (IMO). It comes straight from the language.
There have been cases of problems with unsafe publication, with use of NIO for instance.
Most Java code is very badly written. Threaded code is obviously more difficult than average line-of-business code.
It's not a matter of being "evil". It is a real problem, and will become much more apparent with the rise of multicore architectures in the coming years. I have seen very real production bugs due to improper synchronization. And to answer your other question, I would say that very few programmers are aware of the issue, even among otherwise "good" developers.
I would say very few programmers are away of this issue. When was the last code example you have seen that used the volatile keyword? However, most of the other conditioned mentioned - I just took for granted as best practices.
If a developer completely neglects those conditions, they will quickly encounter multi-threading errors.
My experience (short-terming and consulting in lots of different kinds of environments
Most applications I've seen) agrees with this intuition - I've never seen an entire system clearly architected to manage this problem carefully (well, I've also almost never seen an entire system clearly architected) . I've worked with very, very few developers with a good knowledge of threading issues.
Especially with web apps, you can often get away with this, or at least seem to get away with it. If you have spring-based instantiations managing your object creation and stateless servlets, you can often pretend that there's no such thing as synchronization, and this is sort where lots of applications end up. Eventually someone starts putting some shared state where it doesn't belong and 3 months later someone notices some wierd intermittent errors. This is often "good enough" for many people (as long as you're not writing banking transactions).
How many java developer are aware of this problem? Hard to say, as it depends heavily on where you work.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 6 years ago.
Improve this question
OK I am not only new to concurrency in java but am also fairly new to java programming. I tried understanding concurrency from The java tutorials, tried reading Concurrency in practice but it seemed too advance, so tried reading from couple of other books: SCJP A comprehensive, The java programming language 4th edition.
Its as if there are things which just don't add up or make sense, I am not able to get the why's and how's and form the correct pattern of conceptual understanding. I apologize for describing this exercise in futility. But can someone please recommend good reading materials and/or ways to learn concurrency in java.
but am also fairly new to java programming
Leave the concurrency book aside for a few months and go ahead with reading a basic Java/SCJP book and practicing basic Java a lot. Create so now and then a Thread or Runnable as per the book's instructions. Play around with it for some months until you get a good grasp on it. Then continue with the concurrency book.
Learn walking before running, else you're crawling instead of running.
This sounds like you will soon be tested (class? certification?) "on Java concurrency". You have not experienced the cycle of running into a problem naturally, thinking about how to solve it, and turning to concurrency for a solution. If this is the case...
(1) Don't blame your brain. Rather, take a step back and start thinking about problems that interest you. Write them down. Internet applications are a good place to start. For example-- writing some sort of Internet server that can handle multiple connections from different users, like a game server. Or, a stock trading program that has to handle your robot's orders at the same time as processing information from the broker.
(2) Think concurrency. Now that you have a problem that interests you, and thinking of concurrency simply as multi-tasking, draw a diagram of actors/programs with arrows representing how they need to communicate with each other. Sketch out a dummy-skeleton code. You're not actually going to write a game server; but you can make a simple skeleton class library with simple, empty member functions like connectToGame(){}
(3) Now you're ready. Run a hello-world thread example or two. Flip through your books or browse the Javadocs and see the different concurrent structures that are available. Think about which ones you might apply to your problem. Don't worry about making the "right choice". You will soon find out if you've got something that works.
(4) Embrace trial and error. There is another word for it: learning!
Now, after you get some experience doing this, you'll be able to pick up a Java concurrency book and read about someone else's problem.
Hang in there and don't give up.
My favorite learning Java Book which has a great chapter on concurrency is:
Sun Certified Programmer & Developer for Java 2 Study Guide (Exam 310-035 & 310-027)
It's a difficult subject, nobody has full grasp of it, not even those who designed it.
Many people understand only a subset of it. If you only know a few tricks/patterns that you can use in your programs with confidence, that's good enough. From there you accumulate more and more.
A novice may only know that he can add 'synchronized' keyword to methods. Amazingly that solved a lot of problems and performs just fine, even if he has no idea what he is doing.
To add my two cents worth: concentrate on learning the concepts of concurrency first, rather than the machanics of actually using it in any particular language. If you get bogged down in language constructs it'll be all that much harder to get a high-level understanding of the subject.
To this end I would recommend How to Write Parallel Programs by Carriero & Gelernter (free & legal PDF download). It strikes a good balance between describing the concepts and providing concrete code examples, and doesn't get bogged down in theory. It's actually very readable and entertaining (or maybe that might be just me).
I feel like I understand concurrency backward and forward. Recently, I grabbed a book off the shelf in our office and found it was VERY good. Not just at concurrency, it gives great coverage of Java as a whole.
Introduction to Java Programming, Eighth Edition: Comprehensive Version, Y. Daniel Liang
However, most of my understanding came from experience working with code, tackling problems, and trying examples. I never truly understood threading until I did it.
Concurrency is complex and most people won't get it just from reading. Look through the API and write some test programs to try things out. Whatever book you choose, try to not just read the code, write it out and run it. After a day or two, working with it, you'll have it mostly figured out.