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 11 years ago.
Improve this question
I can do a presentation on a java related technology on the local Oracle User Group (OUG).
The last several times I talked about Java 7 (two or three times) and DVCS. The organizers didn't like the DVCS topic too much because it doesn't come from Oracle, but allowed it anyway.
So, please, can you propose some topics that would be:
1. trendy (optional)
2. oracle related (I prefer java related) (a must)
3. Could be presented in a 1-hour session.
4. Are not too complex. The audience is ... how to put it mildly: more DB oriented than Java oriented. Introductory lectures are perfect.
I saw a presentation on Chronon (a new debugger). This could have been the perfect presentation, but the product is not open-source and not that Oracle related.
I need something simple with a lot of value. I'm thinking for parts of (JSRs) JDK7 and JDK8, but I explained JDK7 already, and jigsaw and others from JDK8 are not clearly defined yet.
invokedynamic and its ramifications for the predominant and upcoming dynamic languages (Groovy, JRuby, Scala, Clojure, Redline Smalltalk come to mind first).
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
About 3 month ago, I was charged to do a presentation and a demo explaining what is SOA composition.it wasn't easy to do it because latest eclipse version (neon) doesn't support BPEL projects any more, Eclipse Luna and an extension helped me in this situation.
From that time there's some questions that roam around in my mind :
why there's no new tutoriel about SOA composition ?
Are these architectures are deprecated ? if yes why are they ?
I do think (and this is an opinion) that SOAP/SOA/ESB/BPEL is obsolete and taken over by RESTful Architectures. By RESTful I don't mean things that have a primitive JSON+HTTP API, but real distributed applications, where endpoints are not dumb, but define the part of the workflow that belongs to them.
So, the two conceptual things colliding are: Do I want a central "smart" component (like ESB, and pure BPEL services) and dumb (for example SOAP) endpoints. Or do I rather have no central components and smart "endpoints" (like REST resources).
I think conceptually the latter is the clear winner in many cases (not all arguably). There are practical problems however. Companies always like to centralize. Centralization looks "neat" and "tidy", especially for an Enterprise Architect. Until the central components grow out of proportions that is.
One of my clients introduced an ESB just last year, so it's definitely not over. But I do think (again, this is just my opinion), that we already tried centralized architectures and monoliths. They always end in the "legacy system" bin, that can not be replaced because it does everything. So we know where they lead, we need to try something different. :)
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 7 years ago.
Improve this question
I'm really new to Java and I'd like to ask you ,which aspects of Java SE are considered to be necessary for someone wanting to learn Java ME? Something like prerequisites.
To start with Java SE, I chose this book, but since I don't have much time, it would be great to hear from experienced developers which parts I should definitely focus on and which parts I could skip to save time.
If is there any topic from Java SE that could also be considered a prerequisite for Java ME, feel free to mention it.
According to content in the book that you mentioned in the questions
Section 1 is must, would teach you basics about java.
Section 2: If you have already worked in any oo language then you can skip this section and come back to it later stage.
Section 3 and Section 6 will be good for you as the code you need to write , need to be memory efficient and multi-threaded.
If you really need to learn JavaME from Java SE, then you should read an old Java SE 1.4 book, and just stick to the basics of the language.
Why? Well Java ME is based on JRE 1.3, so there are no generics, no collections (added in Java 6) and let alone Java 8's new stuff. If you buy a recent Java SE book, you might get confused because you won't be able to use these new features.
Second thing that differs, it is not an homogeneous platform. It is divided in two parts (CLDC/CDC for the core classes, and MIDP for the GUI classes). And there are optional profiles (JSRs) that migh or might not be supported in a certain device.
Other than this, you should always keep an eye on memory efficiency. Old devices do not have much RAM, so you should never try to load large images or data in memory, and always free resources when not used.
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 recently learned java by reading the book Head First Java and I also bought the book Effective Java which I'm planning to finish later. I've been searching the ways to improve Java programming skills online but all I found are algorithm practice questions just like questions in the book Cracking the Coding Interview. I finished about a hundred of them and I found they are useful; however, I still cannot see how this is related to making real object oriented applications like desktop softwares or Android Apps.
Every time I visit stackoverflow.com, under tag Java I see those questions about things that I have never heard of. I'm really frustrated. Am I on the wrong track to the real programming world?
Thanks.
There are many options you might resort to, to improve your development and design skills. And all come through developing real-purpose applications. If you are at loss yourself to find a problem interesting enough and complex enough for you to exercise and hone your skills, you can always contribute to opensource projects. For instance you might go through java projects hosted in github, pick one you like, and have a look at its todo list if any, or pick a an issue and investigate it, fix it if you can and contribute a patch.
This exercise will expose you to product-grade codebases (depending on the project your chose) and several aspects of software development and will most certainly help you improve your skills.
link for java projects hosted at github
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 9 years ago.
Improve this question
I am considering using Akka in one of my projects, but I have to use only Java. A majority of the material (books/articles) are on Scala version, so I am wondering if I use Java I would be a second-class citizen.
Are there any significant functional/performance differences between the two?
Thanks
In terms of performance of Akka itself it will be the same since you are going to be running the same Akka byte code. However in terms of integrating you will be using the Java API and be limited to the language features of Java. As such you will be a second-class citizen in terms of using the API. However in functional and performance terms it will be pretty much identical. Just keep in mind that your Java code will be interacting with the library differently from Scala code. With Scala you have access to closure and other constructs that you cant use with Java (yet). Nevertheless Akka is a great library also when used from Java....
I think the main web site page on Akka sums it all: 11 lines of Scala, 17 lines of Java (+50%).
No or negligible performance difference (bytecode, JVM,...). The performance issues will be around what you write on top of Akka.
Significant functional performance (not in terms of possibilities but code clarity... and clarity has a direct relationship to bugs and fixing them)
Between the two implementations, there are no differences in terms of performance and functionality. If your formation is Java then Akka can be a good solution to introduce the actor model in your Java projects. Clearly with Scala would have the advantages that the whole expressiveness of the language offers.
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 last year.
The community reviewed whether to reopen this question 3 months ago and left it closed:
Original close reason(s) were not resolved
Improve this question
I am aware of following projects (mostly from http://www.w3.org/community/markdown/wiki/MarkdownImplementations):
implemented in Java:
txtmark http://github.com/rjeschke/txtmark (claims to be fastest MD processor running on the JVM)
Markdown4j http://code.google.com/p/markdown4j (fork of txtmark, advantages? more active dev?)
MarkdownPapers http://markdown.tautua.org/ (based on JavaCC parser)
pegdown http://github.com/sirthias/pegdown
MarkdownJ http://code.google.com/p/markdownj (abandoned?)
implemented in Scala:
Laika https://github.com/planet42
Actuarius http://henkelmann.eu/projects/actuarius/ (acc. to author not fully standards compliant)
Knockoff http://tristanhunt.com/projects/knockoff (only subset of MD?)
ScalaMD https://github.com/chirino/scalamd
Q: What are the respective performance characteristics, pitfalls, quirks? Which ones support the Github extensions? Which one would you recommend for a Play! / Scala application?
The fantastic microbenchmark tool created by MarkdownPapers' author compares the performance for the following implementations:
MarkdownPapers
PegDown
Knockoff
MarkdownJ
TxtMark
TxtMark far exceeds the performance of the other tools, as shown in the following graph:
PegDown, which supports many GitHub extensions and others, is far more fully featured. Custom plugins or extensions are also possible.
My use case involved processing markdown from an administrative screen where performance was less impactful than a rich feature set, which meant PegDown won over TxtMark.