In Codename One, a code like the following doesn't compile:
Runnable r = (Runnable & Serializable)() -> Log.p("Serializable!");
I get:
error: cannot find symbol
symbol: method getImplMethodKind()
location: interface SerializedLambda
Is there any way to write a Runnable to the Storage? Thank you
No. Unlike Java serialization we don't write Class data only the data of the object. Since the bytecode is transpiled to native platforms there's no applicable class data to write. We also don't support the Serializable interface, only our version of Externalizable which isn't compatible.
You can write something based on that but it won't be as pretty as you need to create a regular class. That's because we can't use reflection voodoo to load an oddly structured class dynamically.
Related
I created a function module and gateway service that reads data from SNAP_BEG table which is stores DUMP issues. There is no any error except that.
When I try to use link as /DumpsetSet I get
"Method 'DUMPSETSET_GET_ENTITYSET' not implemented in data provider class"
I found that how to redefine implementation but what code should I write in it? I cant find an example for this. Function module code is.
SELECT * FROM SNAP_BEG INTO TABLE ET_SNAP_BEG.
Or I just need to use something else?
What type of link should I use. I got one more project someoneelse done and I cant see difference in implementation from mine.
Edit: I can get firs record that program find by /DumpsetSet('username'). But it is not giving me all datas anyway.
Did you map the GetEntitySet to a data source from SEGW - SAP Gateway Service Builder, under the Service Implementation part. After this operation you should generate runtime objects.
There is a good blog for this, here.
I have created a single jar for Java 7 & 8 for a JDBC driver (using -source/-target compile options). However, I am having difficulty compiling applications that use the new/overloaded methods in the ResultSet interface:
//New in Java 8
updateObject(int columnIndex, Object x, SQLType targetSqlType)
// Available in Java 7
updateObject(int columnIndex, Object x, int targetSqlType)
Note that SQLType is a new interface introduced in Java 8.
I have compiled the driver using Java 8, which worked fine. However, when any application using the driver accesses the method updateObject(int, Object, int) from Java 7, it gets a compilation error saying “class file for java.sql.SQLType not found”, although the application is not using SQLType. I think this is because Java looks at all the overloaded methods to determine the most specific one, and when doing so it can not access the new updateObject method in Java 8 (as SQLType is not defined in Java 7). Any idea how I can resolve this issue?
Note that the updateObject method has a default implementation in the ResultSet interface in Java 8 --- so I can not even use a more generic type instead of SQLType in the new method. In that case any application that uses the new method gets a compilation error saying updateObject is ambiguous.
You can't use something compiled in Java 8 (for instance) in a lower version (say Java 7). You will get something like Unsupported major.minor version.... You need to use two JARs, one for version 1.7 and the other one for version 1.8. Eventually, the one for the 1.7 can't have that SQLType if it's not supported on that JDK; on the other hand, you are encouraged to maintain the overloaded version when you do the 1.8 version.
Notice that this doesn't have nothing to do with backwards compatibility.
In this case, I would call it the application’s fault. After all, your class is implementing the ResultSet interface and applications using JDBC should be compiled against that interface instead of your implementation class.
If a Java 7 application is compiled under Java 7 (where SQLType does not exist) against the Java 7 version of the ResultSet interface, there should be no problems as that interface doesn’t have that offending updateObject method and it doesn’t matter which additional methods an implementation class has. If done correctly, the compiler shouldn’t even know that the implementation type will be your specific class.
You may enforce correct usage by declaring the methods of your Statement implementation class to return ResultSet instead of a more specific type. The same applies to the Connection returned by the Driver and the Statement returned by the Connection. It’s tempting to use covariant return types to declare your specific implementation classes but whenever your methods declare the interface type instead, you are guiding the application programmers to an interface based usage avoiding the problems described in your question.
The application programmer still may use a type cast, or better unwrap, to access custom features of your implementation if required. But then it’s explicit and the programmer knows what potential problems may occur (and how to avoid them).
In UVM Cookbook, it is written that class object instantiation is done at run time. But before run time, during compilation/elaboration also we may have all the details of class.
As depicted in the below image (Taken from UVM Cookbook), it is showed that Module and Interface instant creations are done in elaboration phase, but class object creation are done at run time.
Consider this sample example.
// Inside any .sv file
class A;
int a;
endclass
A x;
initial
x=new();
Now in this case there is no need of creating class at run time, as we have all the details of class available in compile/elaboration time like another module or interface details.
So why in Systemverilog, specifically only class instantiations are done at run time?
Even in C++ also object creation are not done at run time.
Note : In the question, I am talking about simple classes, not using inheritance, in which run time creation may become mandatory. By Creation I do not refer to memory allocation, as memory for all (module, interface, class) will be allocated during simulation only. I am just taking the context of the image.
All objects are created at run-time.
Maybe you are confusing run-time with run-phase? Run-phase is part of the phasing mechanism in uvm that allows for separation between different periods in a simulation. All uvm components can thus be synchronized by phase.
Object creation here is done in the build_phase, which is part of the run-time.
As #Tudor points out, all object instances are created at run time. They have to be because all objects have to execute their constructor. This is the same as C++.
Consider I have large library package with sophisticated tree of private or package modules — let's call it funnylib. It's not desirable for enduser to touch internal modules directly (like funnylib.foo, funnylib.bar etc), so I want to provide external interface instead — like this:
funnylib.d:
public import funnylib.foo;
public import funnylib.bar;
public import funnylib.baz;
to be just imported like import funnylib by enduser. The problem is that D disallows having funnylib.d and funnylib/ at the same time.
Is there something like "default package module" in D, like there is __init__.py in Python? If no, what is right way to do design described above?
Update1: I thought about moving iternal modules to package like funnylib_private, so funnylib will import fine, but this will have cost of protection lowering (strongly undesirable), as funnylib will no longer access package protected symbols, and will result in unpleasant file layout.
You cannot have a module and a package with the same name. So, for instance, Phobos couldn't have a std/algorithm.d and a std/algorithm/sorting.d. std/algorithm.d and std/algorithm would conflict. The typical thing to do is what ratchet freak describes and use a module named all which publicly imports all of the modules within that package. But if you want to hide the fact that you're using sub-modules at all, then you could simply do something like
funnylib.d
_funnylib/foo.d
_funnylib/bar.d
_funnylib/baz.d
and not document _funnylib anywhere, but that doesn't work very well with ddoc, because it's going to generate the documentation for each of the _funnylib modules, and the most that it'll generate for funnylib.d is the module documentation, because it doesn't have any symbols to document. The module system is not designed with the idea that you're going to be hiding modules like you're trying to do.
Now, there is currently a proposal under discussion for making it possible to cleanly split up a module into a package when it gets too large (e.g. so that when you split up std.algorithm into std.algorithm.search, std.algorithm.sorting, etc. code which explicitly uses std.algorithm.countUntil won't break even though it's now std.algorithm.search.countUntil). And once that's sorted out, you could use that, but the documentation would still be done for each sub-module, not for your uber-module. It's really meant as a means of transitioning code, not trying to hide the fact that you're splitting up your modules. It's basically just the equivalent of using an all module but with some semantic sugar to avoid breaking code in the case where the package used to be a single module.
create a simple all module with the public imports that is documented to import the library
module funnylib.all;
public import funnylib.foo;
public import funnylib.bar;
public import funnylib.baz;
In this stackoverflow question I learned that Prism/Unity is not as decoupled as I thought, e.g. if I have this class which gets menuManager injected into its constructor, then I have to make sure that this class actually exists somewhere (I thought that you could just pull the .dll that contains the class and the container would deal with it, e.g. injecting a null in its place):
public class EmployeesPresenter
{
public EmployeesPresenter(IMenuManager menuManager)
{
}
}
But I can deal with that: the application cannot run without a MenuModule (or else as was suggested I could have a NullMenuModule which does nothing but keeps the application from breaking).
However, the application I am building will have a MenuManager class in the MenuModule and every module will have to register everything it wants to have in the menu with the MenuManager. However, I want to be able to swap out MenuModules e.g. have a InfragisticsMenuModule and have a TelerikMenuModule, etc.
However, when I am in e.g. the CustomersModule, in order to use TelerikMenuModule, I need to reference it. And when I want to use InfragisticsMenuModule, I need to reference that.
So how will I be able to "hot swap" TelerikMenuModule with InfragisticsMenuModule without recompiling all my modules with new references, e.g. I want to replace this:
Application.exe
Customers.dll
TelerikMenuModule.dll
with this:
Application.exe
Customers.dll
InfragisticsMenuModule.dll
and simply be able to restart the application and it runs with the new InfragisticsMenuModule.dll and does not complain that TelerikMenuModule.dll no longer exists.
This is where interfaces come in. You need something like:
public interface IMenuSystem
{
// whatever operations need to be offered by a menu system
}
Application.exe and Customers.dll may only refer to that interface. They aren't allow to know about a specific implementation.
Then you would use configuration steps (calling Register... methods or using a config file) to specify which type will provide the implementation of MenuSystem.
For obvious reason MEF comes to mind here and is designed for stuffs like this. I haven't had a chance to use Unity, so I'm not sure if it has something built in like this (i.e. scanning a directory for an IMenuModule implementation), but MEF can do this.
Suggestion also is to put this IMenuModule in a common assembly (separate from your other assembly). I usually called this thing Something.Core.dll.
So you might have: Application.exe, Customer.dll, Application.Core.dll, and your specific MenuModule implementation.
Your specific MenuModule implementation will reference the Application.Core assembly to gain access to its IMenuModule interface and implement it there.