Speed Optimization in J2EE Application, Client side? - java

Currently i am working on speed optimization of J2EE Application. The performance of the application is currently(in my case server is running pretty fast) more depended on the amount of time that it takes to download the associated files like js, css etc.
My Question:
Is there any way to compress these files(js, css,
images etc..) and send it to client machine?
I have came through some technologies which compress the js into a single line, but its causing some problems with the current syntax.
I like to know some way to compress and sent the files, if possible, for best client-side performance.

There is basically Two way to achive this functionality are as below
1) minify your css and js with minfy tool which avilable online.
I use Google Closure Tools, it uses Rhino to interpret your code while modifying it to enusre that it still works after minification. Many free tools exists: YUI Compressor, UglifyJS, etc.
UglifyJS is also good as well, try it here http://marijnhaverbeke.nl/uglifyjs
Google Closure Tools: https://developers.google.com/closure/
2) Gzip your css and js.Do server specific configuration to use Gzip
here i have link from where you can learn how GZip work
http://betterexplained.com/articles/how-to-optimize-your-site-with-gzip-compression/

Related

How to use Twitter Bootstrap in productions, LESS or compressed CSS?

I'm working in J2EE project which want to use Twitter Bootstrap as main style for front-end, with some customizations for fitting product.
I don't know should I use LESS or CSS format introduced by Twitter Bootstrap, if use LESS I have to compile these files to CSS at server or client side, which Java framework help me at server side because I need to cache the stylesheet in product mode, otherwise don't need to cache them.
I'm wondering that precompile at client site will impacts to product performance, anyone made a benchmark for that?
You could try wro4j for that, which can be used as a runtime or build-time solution for server-side transformation of less into css and also handles the caching. You can read more about less support for wro4j here:
Wro4j, Page Load Optimization and Less.js
Less css support
I would say go with CSS if you don't want the hassle of dealing with server-side compilers.
If you do go that route this is a good less compiler for java:
http://www.asual.com/lesscss/
Never compile client-side unless that is all you have to work with, it takes a huge impact on the browser vs gzipped or compressed/minified css.
:)
LESS is awesome for development, but only use the compiled .css for production. Whatever you do, absolutely do not have less.js/LESS compile client-side for production. Even if you you experience snappy response times with less.js and .less files in the head of your HTML during development, the response times for everyone else will be all over the board. I don't know if anyone can make good benchmarks for it, because of the endless number of ways you could import/add the LESS files. If you Have 130 mixins in separate .less files imported and compiled client-side that's going to have difference performance than one .less file, even if the resulting size is the same. And then taking file size, computer hardware specs etc. into consideration, it would be tough to get reliable results with any benchmarks.
My recommendation is to either use use something like node.js and less.js to compile to css on the fly every time you save. Or use one of the handful of nice gui tools out there that will watch the project and compile every time you save. (LESS.app, Crunch App, WinLESS etc)

GWT opening a file from a byte array in memory

Are there ways to receive a byte array or string array from the serverside to GWT client and open it as file?
The byte array is already in memory and we don't want to write it to a file in the server and pass the URL back to the client.
Thanks
GWT Java is compiled into Javascript.
So, try writing a Javascript-based app first, to open your server file "as a file" by your Javascript client. Even if you do not know Javascript - then at least, perform a thought experiment:
- What are the limitations placed by the brosers
- Why do browser conventions place such limitations?
What your javascript app cannot do, so too your GWT app.
What you are thinking is to use File IO API to access your files sitting on the server. There are two possible reasons why you wish to do that:
You are familiar with File IO and you want to do on GWT Java what you have been doing for years with Java, and you are too fixated to change your perspective.
You want to write a web-based interface to your operating system, and you have grand plans for your app.
If you are in situation 1, you are lucky. You simply need to change your perspective to respect the asynchronicity and remoteness of thin-client-server communications.
But in the case that this is a Mt Everest that you have to climb and you still persist in trying File IO patterns on GWT, then you need to be prepared for a large project. I am saying "File IO patterns" rather than "file io" because you would have to emulate them. Obviously, browser security technology does not yet allow you to open a file on the browser's system. And for that reason, there is no point for GWT to supply that functionality.
Secondly, File IO belongs to the java.io realm. And again, browser security does not allow you most of the functionality of java.io. Without the set of file.io functionality on GWT, how then can you have File IO.
What you can do is to scale down on your expectations of File IO and write down a specification of what the features of File IO you would like to have. Like, open, close, read, etc. Then you write a some GWT Java classes to let you perform those little tit-bits of emulated file IO.
So just now, I decided to google "GWT inputstream outputstream" and there are some opensource projects out there from whom you could borrow/steal some code to achieve your life long fulfilling goal of emulating client-server file io thro GWT.
But my advice to you is, you should translate your spec of functionality into a REST service. REST is how google docs is accessed. Study google data api and learn how they do it, including the authentication framework.

creating a file uploader

I'm not a java programmer (I come from asp.net c#) but I'm considering writing a small java application to upload files. In my web app, the user needs to upload a spreadsheet to my server and I want to check the file size and extension before the upload. Most uploader seems overly bloated for what I'm looking to do and I want to build something really simple.
What do I need to do to make this? Eclipse seems to be the best IDE for java. What else do I need and how difficult would it be to write an uploader?
Thanks.
I don't want to steer you away from Java, but you should be able to check file size and extension with javascript. That should only be a dozen or less lines of javascript and should be pretty fast (runtime) since an applet doesn't have to load.
I've been working on REST java ee webservices using Jersey (jax-rs). These allow you to define custom paths, accept and return types (ie text/xml, multipart, etc), methods (GET,POST,etc) and be just about has finely grained as you would like. I haven't done anything with file upload, but I found an example here to get you started. Jersey is a stable, growing, highly-extensible framework (did I mention it supports MVC) and that's why I'm suggesting that you adopt it. Here is a tutorial to get you started with jax-rs, and of course there's always the project site for reference.
Hope this helps.

GWT Strength compared to other framework?

One of the main strength of GWT is to code in java and everything gets compiled and is loaded by several browsers through gwt deferred binding??
Apart from this, i.e. working only on a single code base, do GWT has any other advantage compared to other existing framework??
Edit:
I'm trying to say why should we use gwt and not another framework?? What is there in GWT that makes it special for web application development?? What GWT makes for us and another framework or toolkit don't do??
As i said above GWT makes deferred binding which is a plus, so I wanted what other things it do that makes it special and unique??
My point of view :
Pure Java : In standard web application you write html, css, php, javascript, mysql and others and others. In gwt you write java and java and java. Pure Java knowledge is enough for everything.
gwt-rpc mechanism is very simple to communicate with server and uibinder or any other tools are enough for ui development. plus there are many widgets that facilitate front-end developing
Debug : Debugging Java code is very very easy than debugging Javascript code
MVP Development with Activities and Places
Compiler that you can do all the thing, that you can do in Javascript, in GWT. In addition, working with JSON and XML is very easy and History management is unbleviable
and at last I'm a big big fan of Google and they did it so they did the right thing
One of the other benefits of GWT is that you can share code between the client and server components of your app. For example, if you're doing a graphical app you can write computational geometry code and have the same code evaluate on both sides. Of course, you can also do the same thing by using server-side Javascript (for example, Node.js), but server-side Java has serious advantages for performance, ease of deployment, and interoperability with other things.
My favorite benefit is their RPC mechanisms. JSON gives you a huge reduction in payload size, but GWT's serialization policies allow the data to be sent over the wire without key labels for each value and reduces payload size by another 30% or so. On top of that, its easy to build those services using Spring and Hibernate.
Another benefit is the use of md5 hashes for the filenames of compiled JavaScript, allowing you to set never expires cache headers for all of your code.
Last but not least (actually, it is the least cool of the benefits), there are free tools now for GUI design so you don't have to build a GUI by writing XML and Java or HTML and CSS.
GWT follows a principle of no compromise high-performance Javascript.
They have already invested a lot of work into making your application highly performant. For instance, the "compiled" Javascript files it generates are actually .html files. This is due to an issue that some browsers do not correctly support compressed .js files. This sort of tweaking is beyond what most people would do manually.
There are easy to use tools to help you improve the performance of your own application. GWT.runAsync, for instance, allows you to define splitting points in your Javascript which will be used to automatically divide up monolithic Javascript files into bite sized chunks to load.
As has been said, the RPC mechanism performance and ease of design is amazing. MD5 hash based names for the compiled Javascript means for great caching.
My biggest plus for GWT still has to be the debugging capabilities. Javascript debugging has always been messy and frustrating. With GWT you can employ the full debugging facilities of Java when working on your client side code.
There are no simple answers to these questions:
I'm trying to say why should we use
gwt and not another framework?? What
is there in GWT that makes it special
for web application development?? What
GWT makes for us and another framework
or toolkit don't do??
There is no silver bullet. Everything depends on the project and requirements. GWT may be good in one project and other frameworks may be good in other projects. It also depends which other frameworks are taken into account.
In my opinion the most significant element which makes GWT different from almost all other Java web frameworks is that the client side is fully in JavaScript while most of other frameworks generate usually plain HTML code. The JavaScript approach to the client has its benefits, to name a few:
it is fully AJAX which creates great user experience,
views state is managed in the browser,
it communicates with the server asynchronously;
it communicates with the server only to get the datal
However, there are also some drawbacks:
browser history support - it isn't as good as in HTML based frameworks; proper use of history mechanism isn't easy and requires extra effort from developers;
applications aren't SEO friendly;
more complicated page layouts may kill web browsers - sometimes it takes a long time to generate a page, especially when using additional component libraries;
For developers it is very important that GWT hides JS from them. You write in Java and you get fully working AJAX based client application in JS usually without touching a single line of JS. This is great especially when you need a lot of AJAX in your application and you don't know JS. This is specific to GWT - using JS and AJAX in other frameworks isn't usually that easy (Vaadin may be an exception but it is GWT based).
It is worth mentioning that in many cases GWT can be combined with other web frameworks - this way you can have most of you application content created in HTML based frameworks and some more complicated AJAX parts in GWT.
If you want a recent comparison of Java Web Frameworks, here is an interesting presentation from Devoxx 2010 :
http://raibledesigns.com/rd/entry/my_comparing_jvm_web_frameworks

What is the best way to implement a big (1GB or more) file uploader website in PHP or Java?

What is the best way to implement a big (1GB or more) file uploader website in PHP or Java? Using the default way of uploading in PHP or Java results in running out of RAM space and slowing the website very dramatically.
It would be unwise to open the file on the client side, read its whole content to memory, close it and then start sending the contents, precisely because the contents can exceed the available memory.
One alternative is to open the file, read a chunk of it (remembering where the last chunk ended of course), close the file, upload to the server, and reassemble the file on the server side by appending to previous chunks. This is not a trivial procedure, and should take into consideration things like resource management, IO faults and synchronization, especially when working in parallel with multiple threads.
We've been using http://www.javaatwork.com/ftp-java-upload-applet/details.html for uploading very big files to dedicated hosting. It works a treat even with lots of RAW (photo) files.
Only drawback is it's not multi-threading and locks your browser until it's all uploaded.
Still to find another Java uploader as good looking as this (important to us), but there are a few multi-threaded ones out there that look pretty bad :-)
I would recommend JumpLoader [google it] , as it offers a lot of useful features. I have integrated it into my opensource CMS project, works just fine (of course, few tunings here and there is needed). Has Javascript interface which you can access with raw Jscript or JQuery [I used latter, coded little plugin for it]. The only drawback would be JumpLoader on applet's forehead :P , which you can have removed for 100 bucks.
Overall, features like multiple uploading, image and document editing in pre-upload, partitioned uploads, transmission integrity check via md5 fingerprinting blah blah blah, are very attractive.

Categories

Resources