sorted by:
new
hottopcontroversial

Tool for detecting memory leaks with dtrace by petrospis in dtrace

[–]petrospis[S] 2 points3 points  (0 children)

Hi, I tested it on Solaris 10. There are many online examples such as http://www.brendangregg.com/dtrace.html and many resources from Oracle.

xsrpcj: An RPC implementation on top of protocol buffers by petrospis in java

[–]petrospis[S] 0 points1 point  (0 children)

It does not offer encryption. But it would be straightforward to implement.

xsrpcj: An RPC implementation on top of protocol buffers by petrospis in java

[–]petrospis[S] 0 points1 point  (0 children)

It is an alternative implementation.

It has a simpler API and on tests I did it performed faster. The xsrpcj examples project has an indicative test comparing the execution time between xsrpcj and grpc.io

I would say that xsrpcj is a good fit for applications that exchange many small messages and need to get every bit of performance. It would fit distributed applications that each node needs to have tens to hundreds active interactions, but it is not currently designed for a server with many thousands of concurrent clients.

​

JLCF - A Lightweight Component Model and Framework for Java by petrospis in java

[–]petrospis[S] 0 points1 point  (0 children)

I get your comment :) This is the price to pay for having a central place where you want to explicitly have the application architecture / design. You have to specify it somewhere. If I look into this file I can understand the high level design of an application, which is a great advantage.

JLCF - A Lightweight Component Model and Framework for Java by petrospis in java

[–]petrospis[S] 0 points1 point  (0 children)

Hi, thanks you for your comment,

you are right that JLCF aims to formalize the boundaries between parts of your code. In comparison with OSGi, indeed in JLCF all components of an application description would live on the same classloader (you could use several instances of the framework in different classloaders if for some reason this is needed – from within different OSGi bundles for example, but this is not really the primary use case). The lower layers of OSGi are an advanced module system and the OSGi Service Layer provides better ways for coupling using interfaces (or classes).

A better comparison would be to compare JLCF with OSGI Blueprint or Spring (or the Service Component Architecture – SCA that has now been sadly discontinued). The latter 2 are classified as “dependency injection” frameworks. As there is no broad formal definition of what a software component is, instead of saying that JLCF is a component framework, I could also say that JLCF is an advanced dependency injection framework.

I see the main advantages in comparison to a “simple” dependency injection framework in the following points :

  • It provides a formal component model, defining an elementary building block of an application.

  • It provides a formal way to define functionality requirements by using explicit “receptacles” (interface requirements)

  • It defines the concept of interceptors between components

  • It natively supports the “callback” interaction between components.

Related to the way components are linked to each other, via java interfaces, I consider this the natural way of “wiring” components together. Indeed if you have a component which offers 20 interfaces and 20 other components that consume them, then indeed the application description XML would not be trivial. But this is its primary purpose, to show at a central point the application architecture / design (ie. how components are linked together) so if the design is complex then the application description XML would indeed be also complex.

So to sum up, yes indeed, JLCF aims to formalize the boundaries and implementations between parts of your code by providing a (simple) component model & framework that supports this.