Cristian Vrabie

Sun JDK on Linux Ubuntu 9.10.
java version "1.6.0_15"
Java(TM) SE Runtime Environment (build 1.6.0_15-b03)
Java HotSpot(TM) Server VM (build 14.1-b02, mixed mode)

The difference is pretty small though. It might be e "fluke" or an inaccuracy of my testing code.

Btw. I keep noticing that there is a small difference for static methods on PC. That makes it even more weird. Static methods should be faster right? The calls to static methods are resolved at compile time so no polymorphism lookup should occur.

Ya. I was thinking to do that myself. Here is the re-run:

On PC (sun-jdk):
Direct refference => 1,546,818,889
Direct refference (final method) => 1,544,656,939
Parent refference => 1,548,618,054
Interface refference => 1,552,144,756
Static refference => 1,737,086,755

On Android (1.5):
Direct refference => 3,650,238,037
Direct refference (final method) => 3,492,218,018
Parent refference => 3,484,863,281
Interface refference =3,869,232,177
Static refference => 3,345,306,297

I ran the test several times. I couldn't notice any real difference for final methods, though in theory there should be as final methods are not virtual.
Anyone around that can explain. Pretty please?!

In the 2009 Google I/O talk about writing real-time games for Android http://developer.android.com/videos/index.html#v=U4Bk5rmIpic it is recommended that for performance we don't use interfaces. Supposedly the calls through an interface reference are about 30% slower. It is also mentioned that calls to static methods are faster.

In these circumstances, i asked myself if all calls to a non-direct reference are slower. I'm not an expert at low level stuff, but it looks to me that calling a method through a interface reference is about the same thing as calling a method through a reference to a parent class. But this would mean that we shouldn't use inheritance at all. And that, for someone like me that usually trades performance for scalability, it sounds crazy.

I decided to make a quick test to see if this is true. Here's the code I used: http://pastebin.com/m7c7c0043

First I ran it on my PC and I was stupefied to find results like these at every run:
Direct refference => 1,596,318,257
Parent refference => 1,550,725,582
Interface refference => 1,552,626,591
Static refference => 1,751,394,872
So the interface calls are about the same. Actually sometimes they were faster by a negligible amount.

Then I tested it in an Android application, using a HTC Hero Phone. (Note: I reduced the number of iterations from 1000000000L to 5000000L).
Results were something like:
Direct refference => 3,767,791,749
Parent refference => 3,477,020,264
Interface refference => 4,690,185,547
Static refference => 3,327,636,719


So the interfaces are slower. I can now confirm with my own test. I guess the virtual machine is quite different.
The good thing is that calls through parent references are not slower. Wohoo! OOP for life

What do you guys think? I'm especially interested if the code I used is a good test case.
Also, I'm genuinely interested why interfaces are slower. I guess some king of lookup is done at runtime. But then why doesn't this happen for references to a parent class. In my example, the child class overrides the parent class so the same lookup should occur to tell the jvm to run the method in the child not the one in the parent.

I took the SCJP exam yesterday morning with my wife ( https://coderanch.com/t/478959/Sun-Certification-Results/certification/Passed-SCJP-with ).
Scored 90% which I think was pretty good because I didn't practiced that hard. What I did and I really recommend is taking the practice exams in Examlab 1.6 by Devaka Cooray. Really good for learning.
What I really can't forget of myself is that I did a stupid mistake at one question. A variable initialized in a for was used outside it and I didn't see that. Stupid! Stupid! Stupid! But I did 100% at threads!
Can hardly wait to get started on SCJD

Good luck to you all!

I managed to do this work by making the C program create the pipe, then opening it from Java as a normal file. Pretty easy actually.

Thanks!
I will try the solution for named pipes outside VM and post my findings.

Hi everybody!
I never had the chance to use pipes in Java so I'm a newbie in this field. I know from C that pipes can be used to communicate between 2 separate processes.
When reading about this in Java I see two different definitions:
1. that a pipe can be used ONLY to communicate between threads in the same JVM.
2. a pipe can be used to communicate with another process as long as the pipe is not created by Java.
Which one is it? I would need this to communicate between a Java process and a C process.
Thanks!
Cristian

Did you ever found an answer to this? I'm facing a similar situation.

I understand. You're right of course. However, as I tried to explain, I don't know in what application my library will end up nor what user system that application will use, and I don't want to force the programmer to change his data model only to be compatible with my library. In any case, even if I would compose the Entity with the Principal this doesn't change the fact that I need to find a scalable and preferably transparent way to know what principal is making a call to my service.

The more I think about it, it seems more tricky. For example, what if a user wants to use the library but in a daemon of some sort (so there will be no users). I think that I need to make the rights system pluggable into the service. Hmmm...

The issue is not what information I store in the entity, but rather how I put it there and more generic, how I make it available to the service.

Hi guys! I'm once again turning to the great people from JavaRanch in search of advice. Hope you can throw in some ideas or any thoughts that come to mind.

I'm trying to write a library that has the purpose of creating, manipulating and persisting some data. For the sake of simplicity we can consider that i only have this data structure:
Entity{ String id; String author; //... other many data fields }
The library exposes itself to the rest of the code through a service layer. Simplified the interface for the service is something like:
public interface EntityService{ Entity get(String entityId); Entity newInstance(/*some parameters*/); void save(Entity entity); void delete(String entityId); }
The thing is, that all these service methods require to know the principal that performed the action. newInstance and save need it so it can save it as metadata with the object (the person that created/modified the object), and all of them need it so it can check if that principal has the rights to get/create/edit/save.

The difficulty is that there's no way to predict in what type of application will the library be used, and thus what user system that application will use. Plus we want to make the library easy to use in any situation. So how to solve this?
The first thing that comes to mind is to add parameters to all methods. At this moment, the requirements of the library are pretty low so a string username would suffice.
public interface EntityService{ Entity get(String entityId, String username); Entity newInstance(String username, /*other parameters*/); void save(Entity entity, String username); void delete(String entityId, String username); }
At this moment I see 3 problems with this approach:
# This is not scalable. As the library extends we might need some other type of information besides that username so we'll need to change the list of parameters which ruins backwards compatibility
# It's not actually easy or pleasant to use. An automated system would be preferred.
# It's ugly

In order to automatize this, what would help is for the service to have access to some sort of execution context.

If I were to implement this specific for an web application I would probably create a servlet filter or AOP interceptor that would have access to the required information, then store it in a ThreadLocal variable so the EntityService could read it from there. But I can't know for sure if it will be used in a web application even though I can bet that 99% of the uses will be in some sort of web service/application. Further more, taking this approach would require that the programmer of the end application would adapt this interceptor to fit his application.

Anyone has any ideas? Any thoughts would be appreciated. For example I'm starting to think that the rights system shouldn't even be in the library, but the responsibility of the using application. This would limit the requirement for the username. What do you think?

Found the problem:
When I provide the callback to the scheduler I do:
this.scheduler.addTask(id, delay, this);
As you know, in Spring the transaction is started by the proxy that wraps the entityService. However, because I use JDK proxies, this won't be the proxy, but the proxy target (the original service). So when the callback is invoked it bypasses the transaction mechanism completely. The trick is to provide the actual proxy to the scheduler. I did this by letting EntityService implement ApplicationContextAware and BeanNameAware and fetching the proxy from the applicationContext at initialization:
public class EntityService implements ApplicationContextAware, BeanNameAware, InitializingBean{ ... public void setApplicationContext(ApplicationContext ac){ this.ac = ac; } public void setBeanName(String beanName){ this.beanName = beanName; } public void afterPropertiesSet(){ this.myProxy = this.ac.getBean(this.beanName); } ... @Transactional(readOnly = false) public void generateWithDelay(String id, long delay){ Entity e = new Entity(); e.setStatus("IN_CONSTRUCTION"); e.setId(id); this.dao.save(e); this.scheduler.addTask(id, delay, this.myProxy); }

In the end I solved this by opening a transaction programatically in the run method of the TimerTask.
However I'm still curious why it didn't worked declaratively and if it is possible to make it work this way.

Hey thank you. I did indeed forgot to specify that. After you told me I read about this setting on hibernate docs so I added to my session factory bean these properties:
<prop key="hibernate.current_session_context_class">org.hibernate.transaction.JDBCTransactionFactory</prop> <prop key="hibernate.transaction.factory_class">thread</prop>
Unfortunately this didn't help. I still get the same exception in the same situation.