I'll be working on a project for instrumenting a relatively complex java application, and I'm planning to use java.lang.instrument to hook into the JVM and redefine classes before they're loaded.
What is your take on this package? Is it well supported across JVMs? Does it work well with Hotspot?
Thanks!
java.lang.instrument is used by many very popular frameworks and pieces of software, including:
AspectJ
JRebel
JProfiler
The java profiling extensions themselves
which leds me to the conclusion that it is save to use. (Maybe not in your in case but that wasn't the question).
I use all the given frameworks while using the HotSpot compiler, and got no problems.
If you want to profile the java application, I would suggest using existing java profilers as this API is definitely still pretty new and has some issues.
Though the following article was written in 2005, the findings pretty much are still relevant
http://www.javalobby.org/java/forums/t19309.html
Related
I have a java spring GWT web application. I need to use a profiler to view why is a certain function that slow (on server)... After some searching, seems that insight is a good way... tried it and it works... what I did is create a tc server instance (developer edition) with insight and add the project to it. It works.
The problem here is that I use maven plugin "org.codehaus.paranamer", that is a plugin that I use to get function paramater names... It works post-compilation to add a special private field in the class that holds the parameters names.
This is a problem with insight since it seems that it modifies the code too and that it works on the source code not the compiled version in the target folder.
What I can do to make this work? FYI, all I need is profile the app.. not necessarily with insight....
Edit:
I ended up using visualvm... It can help with profiling the app on the cpu level and the memory level... That is the way I can use the common remote profiling mechanism jerry was talking about.
For profile of JAVA apps(including tomcat instances), I strongly recommend the TPTP(Eclipse Test & Performance Tools Platform). You can read a lot here:
http://www.eclipse.org/articles/Article-TPTP-Profiling-Tool/tptpProfilingArticle.html
Especially for TPTP working with tomcat instance:
http://www.deepakgaikwad.net/index.php/2009/02/10/tutorialprofiling-with-tptp-and-tomcat.html
Some of the information in the above article may be outdated, but main workflow is the same.
For commercial profilers, I will recommend yourkit profiler: http://www.yourkit.com/
I don't know if there is a trial edition available now, but years ago, this profile is more user friendly than TPTP.
I've created a stand alone java desktop application using Netbeans. I want a way to test the performance of my application. I need some tool with the help of which my application can be evaluated. I heard about Software metrics, is this related to my context. Or is there any tool or plugin available in Netbeans through which I can test.
Have a look at the Netbeans Profiler:
http://netbeans.org/features/java/profiler.html
Netbeans has one of the best profilers going for Java apps, it runs well and provides as much detail as you want. Since you're using Netbeans I'd take advantage of it!
In terms of tutorials, there's one here about memory leaks and how to debug / discover them using the profiler. Once you get going with it the other features should come pretty easily.
I have a Java application that runs on BlackBerry (JDE 4.5). I want to port this application to Android, and be able to maintain the 2 applications simultaneously. I may also want to port this application to other Java platforms (J2ME ?).
I understand that a good part of the code will have to be specific to each platform (UI and other stuff). But I also feel that a lot of the code could (should) be shared (domain related classes).
What is the best way to achieve this, and what are the pitfalls to avoid?
I have been able so far to create a JAR with all my shared classes, that I have been able to integrate into my BlackBerry application (using preverify and rapc). But:
The JAR is a J2SE library. How can I make sure that it will run (or even compile) on BlackBerry, Android or J2ME?
I am also using a JSON library targeting J2ME (https://github.com/upictec/org.json.me/). This library seems to make use of some kind of preprocessing directives (CLDC, see https://github.com/upictec/org.json.me/blob/master/src/main/java/org/json/me/JSONObject.java#L392). How can I use (or convert) this library using the right preprocessing definitions?
This is likely to be difficult:
As you have already identified, the UI code will have to be different for each platform.
There are major differences between Java SE / Android and Java ME-based platforms. For example, ME doesn't have the Collections framework, or the java.io or java.nio stacks.
It is hard to predict from the information you've provided, but there's a fair chance that you'll spend more time fighting the platform dependencies than you are saving by sharing the code-base.
These days, the biggest stumbling block to sharing code this way is that the BlackBerry VM and Android VM both support different versions of the Java language. BlackBerry uses a subset of Java 1.3, Android uses a subset of Java 1.5. (As an aside, neither platform implements a Java VM, both use their own VMs. Java is used as the programming language. Java bytecodes must be transformed to the appropriate native VM format before they can run on the platform.)
The biggest difference you will find as a library implementor is that the BlackBerry lacks the things that were introduced in 1.5, very important things like generics and enums. Even worse, the Collections classes are missing from the BlackBerry. It is unfortunate, but that is the way it has been for a long time now.
This means that to be truly portable you have to write to the lowest-common denominator, which means using (very) old-style classes like Hashtable and Vector, not having generics, rolling your own enums (as in the 1st edition of Effective Java) and so on.
Or you build two libraries, a modern version for Android and a stripped-down version (with just the bare stuff you need) for the BlackBerry.
Hard to say what`s right for you.
Rather than prepackage your shared library, I would consider sharing the library project and having it as a dependency in your mobile applications' build process. That would allow you to share the code base, but have it built by the appropriate builders for your target devices. With a bit of IDE magic and some attention to detail, you should be able to pick up errors before anything is shipped out.
Alternatively, set up your library project to use two separate builders to pick up errors. That would allow cleaner distribution, but you may run into problems trying to convince your IDE to treat the project as being device specific in order to identify problem areas.
It would be likely that you would end up supporting the lowest common denominator device (cough Blackberry), and forgoing the additional facilities of the more extensive Java implementation on Android.
Unfortunately the answer will be one of experimentation. Try it and see what happens.
The article Porting Android code to BlackBerry has some good detail on how to work with code shared between the two platforms.
it will be very difficult to create shared library for blackberry and android.
if you want simple method, create your application as web app.
using
phonegap with jQtouch
Why Java is still used in web development? I'm just curious..
There are a number of reasons:
1. It is by no means a dead language. There are thousands of Java developers out there.
2. Many available Java developers means that it relatively easy to find maintenance programmers if necessary.
3. The Java / J2EE architecture is robust and reasonably elegant. It makes it possible to architect well built applications.
4. The free tools available for it are enterprise ready. For example, Apache / Tomcat / JBoss are a solid foundation to build a web-app from.
5. Excellent support for developers. Eclipse is one of the best developer platforms available. Ant and Maven support for Java is excellent.
6. There is a good availability of third-party (and open-source) libraries and Eclipse plug-ins for most of the additional functionality that might be needed but does not come in the core libraries.
7. There is also great support tools from commercial vendors: ORacle; IBM / Rational; etc.
8. Updated versions with newer language constructs are constantly being developed.
In short, it is a good tool for the job. It is compares favourably to other development platforms (.Net, Ruby, etc), and perhaps is better than some.
Simple. It's a cross platform environment, that is clearly defined, and controlled. Sure, Sun has a big deal of say in what is available in the Java environment, but there is plenty of 3rd party support and development in the Java environment.
Yes, Java applications start up slightly slower than Native applications, but take a look at VUZE... Once it's started, it's nearly native speed (or at least it was when I was using it). With the JIT (Just in Time) compilers, code caching, and other features, there isn't much of a reason that there would be a major speed penalty...
One big reason I think is because it's platform independent meaning they can easily run on all operating systems as long as you have the Java Runtime Environment installed. This could allow you to, for example, compile code in Windows and deploy on Unix.
I would also add that while this is only a con against .Net, your application server doesn't have to be Windows so it is cheaper to throw more hardware at it.
For the same reason as why COBOL and FORTRAN still exist. Because the language has proven itself to be robust and reliable.
Compare it with cars. Some people want the latest models because it has more power, better speed, improved features and whatever more. Others will just use a reliable car that's made to last for many years without much need for additional maintenance. Some buy a new car every 3 years, others will use their cars for half a century or more.
When talking about Java & the web, people seem to happily mix things by concentrating on Java applications deployed with Web Start (or even Applets), and forgetting that Java is a common language for implementing plain old dynamic web sites (or web applications). The latter is especially true for larger, more "enterprisey" systems. Even if on the desktop Java never really took off, on the server side it certainly did.
Without going into much detail, a couple of reasons why Java is used for creating web sites / applications:
It's a tried and true approach for building large-scale web apps. Either using just the basic (Java EE) technologies of Servlets and JSP, or newer frameworks built on top of those, such as JSF, Wicket or Google Web Toolkit. (Just one example of high scalability: Gmail is implemented in Java, using Google Web Toolkit.)
A mind-boggling amount of Java libraries exist, for all kinds of tasks — both open-source and commercial ones. If you need some in the backend of your app it may make a lot of sense to do the whole app using the same technology.
There are a lot of skilled Java developers out there — something that may affect tech desicions when launching (larger) projects
When creating a web interface for, or integrating into, an existing Java enterprise system (which are common) it may be beneficial to use the same language
Edit: I also agree with Doug about the tools and developer support. For example, IntelliJ IDEA may well be the most advanced IDE for any language (and I've heard this also from people who've used Eclipse and Visual Studio extensively... ;-) )
It's ubiquitous. The tools are great across the board. It's powerful. The community is huge. There is an amazing amount of available libraries / products / toolkits / frameworks. The JVM is great.
You can build cathedrals with this language. Those tend to stand for centuries.
Since Java doesn't run on the iPad, doesn't that hurt Java web development? Developing a web application that supports desktop and mobile is a possible path, but if your site uses Java or Flash, you have eliminated that opportunity.
We have a web application that is for both desktop and mobile (supports swiping, zooming, and such using jQuery). We decided against Java, Flash, and Silverlight because they do not work with iPad. The iPad is a growing base and web applications will have to keep up to support it.
It will be interesting to see how this affects web development with Java... time will tell.
I just found out about JRuby, and I like the idea of running Ruby on Rails and being able to call Java libraries.
I would like to know about some experiences with running enterprise production applications in JRuby. Are stability and performance acceptable?
Thanks.
Here is a blog post from a company that created a cross-platform, multithreaded, desktop simulation application with JRuby. I think their success indicates JRuby is ready for enterprise production applications.
http://spin.atomicobject.com/2009/01/30/ruby-for-desktop-applications-yes-we-can
Actually it's pretty fast too. I'm not sure how they all compare now, but with the new dynamic invoke bytecode added to the JVM, it should become by far the fastest implementation available.
Groovy and Grails should also get a big speed boost from this pretty soon.
We're using it at our company on a large project. The major problem we find is that there isn't as large of a community built around the technology as say Java or .Net. Which makes recruiting difficult.
JRuby is among the fastest Ruby implementations right now and definitely production ready.
Here's some "success stories" from jruby.org:
http://wiki.jruby.org/wiki/Success_Stories
Jason Seifer says yes. His presentation on Ruby VM's is on InfoQ.
A look at the different Ruby virtual machines (JRuby, MagLev, IronRuby, Rubinius, MacRuby) and how to choose what fits best within the enterprise.
http://www.infoq.com/presentations/seifer-ruby-vm-comparison
The JRuby Wiki has moved to Kenai. The success stories page can be found here now:
http://kenai.com/projects/jruby/pages/SuccessStories