Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #31984 > unrolled thread

From Hibernate to straight JPA

Back to article view | Back to comp.lang.java.programmer

Contents

  From Hibernate to straight JPA Cecil Westerhof <Cecil@decebal.nl> - 2015-07-10 20:13 +0200
    Re: From Hibernate to straight JPA Jeff Higgins <jeff@invalid.invalid> - 2015-07-11 10:56 -0400
      Re: From Hibernate to straight JPA Cecil Westerhof <Cecil@decebal.nl> - 2015-07-11 21:06 +0200
    Re: From Hibernate to straight JPA Lew <lewbloch@gmail.com> - 2015-07-16 17:15 -0700
      Re: From Hibernate to straight JPA Arne Vajhøj <arne@vajhoej.dk> - 2015-07-16 20:44 -0400
        Re: From Hibernate to straight JPA Cecil Westerhof <Cecil@decebal.nl> - 2015-07-17 10:01 +0200
          Re: From Hibernate to straight JPA Arne Vajhøj <arne@vajhoej.dk> - 2015-07-27 22:18 -0400
    Re: From Hibernate to straight JPA Eternal Hope <laughingspam99@gmail.com> - 2015-07-18 20:48 +0100
      Re: From Hibernate to straight JPA Jeff Higgins <jeff@invalid.invalid> - 2015-07-18 16:51 -0400
      Re: From Hibernate to straight JPA Arne Vajhøj <arne@vajhoej.dk> - 2015-07-18 17:21 -0400
      Re: From Hibernate to straight JPA Martin Gregorie <martin@address-in-sig.invalid> - 2015-07-18 23:24 +0000
        Re: From Hibernate to straight JPA Arne Vajhøj <arne@vajhoej.dk> - 2015-07-18 19:43 -0400
        Re: From Hibernate to straight JPA Jeff Higgins <jeff@invalid.invalid> - 2015-07-18 19:50 -0400
          Re: From Hibernate to straight JPA Arne Vajhøj <arne@vajhoej.dk> - 2015-07-18 20:23 -0400
        Re: From Hibernate to straight JPA Eternal Hope <laughingspam99@gmail.com> - 2015-07-19 09:22 +0100
          Re: From Hibernate to straight JPA Jeff Higgins <jeff@invalid.invalid> - 2015-07-19 06:20 -0400
            Re: From Hibernate to straight JPA Jeff Higgins <jeff@invalid.invalid> - 2015-07-19 07:49 -0400
              Re: From Hibernate to straight JPA Eternal Hope <laughingspam99@gmail.com> - 2015-07-19 13:28 +0100
                Re: From Hibernate to straight JPA Jeff Higgins <jeff@invalid.invalid> - 2015-07-19 09:20 -0400
                  Re: From Hibernate to straight JPA Jeff Higgins <jeff@invalid.invalid> - 2015-07-19 09:50 -0400
                Re: From Hibernate to straight JPA Jeff Higgins <jeff@invalid.invalid> - 2015-07-20 13:16 -0400
                  Re: From Hibernate to straight JPA Jeff Higgins <jeff@invalid.invalid> - 2015-07-20 13:42 -0400
                    Re: From Hibernate to straight JPA Jeff Higgins <jeff@invalid.invalid> - 2015-07-20 14:07 -0400
                    Re: From Hibernate to straight JPA Eternal Hope <laughingspam99@gmail.com> - 2015-07-20 20:46 +0100
                      Re: From Hibernate to straight JPA Martin Gregorie <martin@address-in-sig.invalid> - 2015-07-20 21:01 +0000
                      Re: From Hibernate to straight JPA Jeff Higgins <jeff@invalid.invalid> - 2015-07-20 22:19 -0400
                        Re: From Hibernate to straight JPA Jeff Higgins <jeff@invalid.invalid> - 2015-07-20 23:52 -0400
                      Re: From Hibernate to straight JPA Joerg Meier <joergmmeier@arcor.de> - 2015-07-21 12:04 +0200
                        Re: From Hibernate to straight JPA Eternal Hope <laughingspam99@gmail.com> - 2015-07-21 12:43 +0100
      Re: From Hibernate to straight JPA Jeff Higgins <jeff@invalid.invalid> - 2015-07-18 20:25 -0400
        Re: From Hibernate to straight JPA Jeff Higgins <jeff@invalid.invalid> - 2015-07-18 20:44 -0400

Page 1 of 2  [1] 2  Next page →

#31984 — From Hibernate to straight JPA

We are asked to change some software. At the moment one of the things
that has to be replaced is Hibernate. They want to use straight JPA,
so it is easy to switch from Hibernate, to openJPA, to …

One of the annotations that is used is:
    @NotEmpty(message = "Field is not filled")
with the import:
    import org.hibernate.validator.constraints.NotEmpty;

My college wants to use:
    @NotNull(message = "Field is not filled")
    @Size(message = "Field is not filled", min = 1)

I do not like this. It certainly is not DRY. (It is used hundreds of
times.) I prefer to define our own NotEmpty. But I have never worked
with annotations. How to do this?

Also what is a good resource to learn about JPA and annotations?

-- 
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof

[toc] | [next] | [standalone]

#31991

On 07/10/2015 02:13 PM, Cecil Westerhof wrote:
> We are asked to change some software. At the moment one of the things
> that has to be replaced is Hibernate. They want to use straight JPA,
> so it is easy to switch from Hibernate, to openJPA, to …
>
> One of the annotations that is used is:
>      @NotEmpty(message = "Field is not filled")
> with the import:
>      import org.hibernate.validator.constraints.NotEmpty;
>
> My college wants to use:
>      @NotNull(message = "Field is not filled")
>      @Size(message = "Field is not filled", min = 1)
>
> I do not like this. It certainly is not DRY. (It is used hundreds of
> times.) I prefer to define our own NotEmpty. But I have never worked
> with annotations. How to do this?
>
> Also what is a good resource to learn about JPA and annotations?
>

Since no response so far I'll throw in my search results.
May be bunk as I'm not a JPA or JavaEE user.

<http://beanvalidation.org/1.1/>
<http://openjpa.apache.org/bean-validation-primer.html>
<http://lmgtfy.com/?q=custom+bean+validation>

[toc] | [prev] | [next] | [standalone]

#31992

On Saturday 11 Jul 2015 16:56 CEST, Jeff Higgins wrote:

> On 07/10/2015 02:13 PM, Cecil Westerhof wrote:
>> We are asked to change some software. At the moment one of the
>> things that has to be replaced is Hibernate. They want to use
>> straight JPA, so it is easy to switch from Hibernate, to openJPA,
>> to …
>>
>> One of the annotations that is used is:
>> @NotEmpty(message = "Field is not filled")
>> with the import:
>> import org.hibernate.validator.constraints.NotEmpty;
>>
>> My college wants to use:
>> @NotNull(message = "Field is not filled")
>> @Size(message = "Field is not filled", min = 1)
>>
>> I do not like this. It certainly is not DRY. (It is used hundreds
>> of times.) I prefer to define our own NotEmpty. But I have never
>> worked with annotations. How to do this?
>>
>> Also what is a good resource to learn about JPA and annotations?
>>
>
> Since no response so far I'll throw in my search results.
> May be bunk as I'm not a JPA or JavaEE user.
>
> <http://beanvalidation.org/1.1/>
> <http://openjpa.apache.org/bean-validation-primer.html>
> <http://lmgtfy.com/?q=custom+bean+validation>

I did find a 20 links, but found it a ‘little’ overwhelming. Did not
find you first two links. Added them to my list.

Thanks.

-- 
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof

[toc] | [prev] | [next] | [standalone]

#32051

On Friday, July 10, 2015 at 11:14:09 AM UTC-7, Cecil Westerhof wrote:
> We are asked to change some software. At the moment one of the things
> that has to be replaced is Hibernate. They want to use straight JPA,
> so it is easy to switch from Hibernate, to openJPA, to ...

Hibernate is "straight JPA" if you use it that way. So use it that way. But don't use the old-style pre-JPA idioms in Hibernate.

The best resource for JPA is the Java EE Tutorial, latest edition.

[toc] | [prev] | [next] | [standalone]

#32053

On 7/16/2015 8:15 PM, Lew wrote:
> On Friday, July 10, 2015 at 11:14:09 AM UTC-7, Cecil Westerhof wrote:
>> We are asked to change some software. At the moment one of the things
>> that has to be replaced is Hibernate. They want to use straight JPA,
>> so it is easy to switch from Hibernate, to openJPA, to ...
>
> Hibernate is "straight JPA" if you use it that way. So use it that way. But don't use the old-style pre-JPA idioms in Hibernate.

And they are doing just that but have encountered a specific problem
where a Hibernate API annotation does not have a single JPA API
equivalent - and now they are asking for advice.

> The best resource for JPA is the Java EE Tutorial, latest edition.

You believe that answers the very specific question??

Arne

[toc] | [prev] | [next] | [standalone]

#32054

On Friday 17 Jul 2015 02:44 CEST, Arne Vajhøj wrote:

> On 7/16/2015 8:15 PM, Lew wrote:
>> On Friday, July 10, 2015 at 11:14:09 AM UTC-7, Cecil Westerhof wrote:
>>> We are asked to change some software. At the moment one of the
>>> things that has to be replaced is Hibernate. They want to use
>>> straight JPA, so it is easy to switch from Hibernate, to openJPA,
>>> to ...
>>
>> Hibernate is "straight JPA" if you use it that way. So use it that
>> way. But don't use the old-style pre-JPA idioms in Hibernate.
>
> And they are doing just that but have encountered a specific problem
> where a Hibernate API annotation does not have a single JPA API
> equivalent - and now they are asking for advice.

The client where I am working at the moment did use Hibernate but they
want there code to be independent from a JPA implementing library. So
they can decide if they want to work with Hibernate, openJPA or
another implementation and can replace it on a whim. so we should only
use JPA annotations and none of an implementation.


>> The best resource for JPA is the Java EE Tutorial, latest edition.
>
> You believe that answers the very specific question??

That is a bit much and overwhelming, yes.

-- 
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof

[toc] | [prev] | [next] | [standalone]

#32170

On 7/17/2015 4:01 AM, Cecil Westerhof wrote:
> On Friday 17 Jul 2015 02:44 CEST, Arne Vajhøj wrote:
>
>> On 7/16/2015 8:15 PM, Lew wrote:
>>> On Friday, July 10, 2015 at 11:14:09 AM UTC-7, Cecil Westerhof wrote:
>>>> We are asked to change some software. At the moment one of the
>>>> things that has to be replaced is Hibernate. They want to use
>>>> straight JPA, so it is easy to switch from Hibernate, to openJPA,
>>>> to ...
>>>
>>> Hibernate is "straight JPA" if you use it that way. So use it that
>>> way. But don't use the old-style pre-JPA idioms in Hibernate.
>>
>> And they are doing just that but have encountered a specific problem
>> where a Hibernate API annotation does not have a single JPA API
>> equivalent - and now they are asking for advice.
>
> The client where I am working at the moment did use Hibernate but they
> want there code to be independent from a JPA implementing library. So
> they can decide if they want to work with Hibernate, openJPA or
> another implementation and can replace it on a whim. so we should only
> use JPA annotations and none of an implementation.

That is easy.

>>> The best resource for JPA is the Java EE Tutorial, latest edition.
>>
>> You believe that answers the very specific question??
>
> That is a bit much and overwhelming, yes.

And probably do not even answer the specific question.

Arne

[toc] | [prev] | [next] | [standalone]

#32077

On 10/07/2015 19:13, Cecil Westerhof wrote:
> We are asked to change some software. At the moment one of the things
> that has to be replaced is Hibernate. They want to use straight JPA,
> so it is easy to switch from Hibernate, to openJPA, to …
>
> One of the annotations that is used is:
>      @NotEmpty(message = "Field is not filled")
> with the import:
>      import org.hibernate.validator.constraints.NotEmpty;
>
> My college wants to use:
>      @NotNull(message = "Field is not filled")
>      @Size(message = "Field is not filled", min = 1)
>
> I do not like this. It certainly is not DRY. (It is used hundreds of
> times.) I prefer to define our own NotEmpty. But I have never worked
> with annotations. How to do this?
>
> Also what is a good resource to learn about JPA and annotations?

As I read this thread I thought it was about time I had a look at this 
JPA stuff. I've been writing Java for circa 15 years now, I've done 
everything from writing byte streams to firmware interfaces to high 
availability container managed business applications and Swing based 
UIs. In all this time I have relied on a JDBC driver in my classpath, 
container managed connection pools, hand coded SQL and 'in code' 
transaction management. I do my own OR mapping; actually we don't call 
it 'OR mapping' it's just relational database stuff, and quite frankly 
I've never found the need to use some persistance framework.

I just had a look at 
http://openjpa.apache.org/builds/2.4.0/apidocs/index.html

Good grief ... HOW many classes. WTF

Seriously, how much of this stuff do people actually use.
What is the learning overhead of just this one API
It gives me a headache just scrolling down the class list.
What is the actual payback for the time spent getting your head around 
even a fraction of this API

This is not a trivial question AFAIAC I genuinely can't see the benefit, 
particularly in the short term of learning this stuff. There will always 
be another framework, I could spend my entire life learning frameworks 
all the time getting further and further away from the core language.

I'd be genuinely interested in any non-confrontational opinions.

Thanks

[toc] | [prev] | [next] | [standalone]

#32078

On 07/18/2015 03:48 PM, Eternal Hope wrote:
> On 10/07/2015 19:13, Cecil Westerhof wrote:
>> We are asked to change some software. At the moment one of the things
>> that has to be replaced is Hibernate. They want to use straight JPA,
>> so it is easy to switch from Hibernate, to openJPA, to …
>>
>> One of the annotations that is used is:
>>      @NotEmpty(message = "Field is not filled")
>> with the import:
>>      import org.hibernate.validator.constraints.NotEmpty;
>>
>> My college wants to use:
>>      @NotNull(message = "Field is not filled")
>>      @Size(message = "Field is not filled", min = 1)
>>
>> I do not like this. It certainly is not DRY. (It is used hundreds of
>> times.) I prefer to define our own NotEmpty. But I have never worked
>> with annotations. How to do this?
>>
>> Also what is a good resource to learn about JPA and annotations?
>
> As I read this thread I thought it was about time I had a look at this
> JPA stuff. I've been writing Java for circa 15 years now, I've done
> everything from writing byte streams to firmware interfaces to high
> availability container managed business applications and Swing based
> UIs. In all this time I have relied on a JDBC driver in my classpath,
> container managed connection pools, hand coded SQL and 'in code'
> transaction management. I do my own OR mapping; actually we don't call
> it 'OR mapping' it's just relational database stuff, and quite frankly
> I've never found the need to use some persistance framework.
>
> I just had a look at
> http://openjpa.apache.org/builds/2.4.0/apidocs/index.html
>
> Good grief ... HOW many classes. WTF

Here is a much smaller API.
<https://docs.oracle.com/javaee/7/api/javax/persistence/package-summary.html>

>
> Seriously, how much of this stuff do people actually use.
> What is the learning overhead of just this one API
> It gives me a headache just scrolling down the class list.
> What is the actual payback for the time spent getting your head around
> even a fraction of this API
>
> This is not a trivial question AFAIAC I genuinely can't see the benefit,
> particularly in the short term of learning this stuff. There will always
> be another framework, I could spend my entire life learning frameworks
> all the time getting further and further away from the core language.
>
> I'd be genuinely interested in any non-confrontational opinions.
>
> Thanks
>

[toc] | [prev] | [next] | [standalone]

#32079

On 7/18/2015 3:48 PM, Eternal Hope wrote:
> I just had a look at
> http://openjpa.apache.org/builds/2.4.0/apidocs/index.html
>
> Good grief ... HOW many classes. WTF
>
> Seriously, how much of this stuff do people actually use.

I would expect JPA users to use zero of these classes.

> What is the learning overhead of just this one API

The learning curve of that API is not so relevant.

The JPA API is relevant. I would say that it is easy to
get for those that have used ORM before and not quite as
easy for those that have not.

> This is not a trivial question AFAIAC I genuinely can't see the benefit,
> particularly in the short term of learning this stuff. There will always
> be another framework, I could spend my entire life learning frameworks
> all the time getting further and further away from the core language.

You basically have 3 options:
A) don't use a framework and write code from scratch for every project
B) make you own reusable library aka your own framework
C) go with an existing framework

LOC(A) > LOC(B) > LOC(C)

Simple as that.

Arne

[toc] | [prev] | [next] | [standalone]

#32080

On Sat, 18 Jul 2015 20:48:50 +0100, Eternal Hope wrote:

> As I read this thread I thought it was about time I had a look at this
> JPA stuff. I've been writing Java for circa 15 years now, I've done
> everything from writing byte streams to firmware interfaces to high
> availability container managed business applications and Swing based
> UIs. In all this time I have relied on a JDBC driver in my classpath,
> container managed connection pools, hand coded SQL and 'in code'
> transaction management. I do my own OR mapping; actually we don't call
> it 'OR mapping' it's just relational database stuff, and quite frankly
> I've never found the need to use some persistance framework.
>
I'm also interested in the answers you get.

I suspect out backgrounds might be similar: I have a fairly solid 
background in relational database design, and the associated skills of 
normalisation, database performance tuning and writing both an RDBMS's 
dialect of SQL and ODBC as well as writing database applications in Perl, 
C and COBOL. So, when I've needed to implement database applications in 
Java, naturally I went for JDBC.

With my background I really wonder what benefits I'd get from using a JPA 
and, with an eye on performance, how does ease of performance tuning 
compare between the JPA world and that of using JDBC and traditional SQL.

The uniformly worst performance I've seen has been the result of the 
automatically generated SQL that 4GLs (e.g. PowerBuilder) have produced, 
and the resulting dreadful performance resulting from (a) the use of 
ridiculously small test databases, (b) nobody sanity-checking the auto-
generated SQL, especially w.r.t. whether it tried to use DB indexes and 
(c) whether either DBA or programmers had attempted to support high 
volume queries with indexes.
    


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

[toc] | [prev] | [next] | [standalone]

#32081

On 7/18/2015 7:24 PM, Martin Gregorie wrote:
> On Sat, 18 Jul 2015 20:48:50 +0100, Eternal Hope wrote:
>> As I read this thread I thought it was about time I had a look at this
>> JPA stuff. I've been writing Java for circa 15 years now, I've done
>> everything from writing byte streams to firmware interfaces to high
>> availability container managed business applications and Swing based
>> UIs. In all this time I have relied on a JDBC driver in my classpath,
>> container managed connection pools, hand coded SQL and 'in code'
>> transaction management. I do my own OR mapping; actually we don't call
>> it 'OR mapping' it's just relational database stuff, and quite frankly
>> I've never found the need to use some persistance framework.
>>
> I'm also interested in the answers you get.
>
> I suspect out backgrounds might be similar: I have a fairly solid
> background in relational database design, and the associated skills of
> normalisation, database performance tuning and writing both an RDBMS's
> dialect of SQL and ODBC as well as writing database applications in Perl,
> C and COBOL. So, when I've needed to implement database applications in
> Java, naturally I went for JDBC.
>
> With my background I really wonder what benefits I'd get from using a JPA
> and, with an eye on performance, how does ease of performance tuning
> compare between the JPA world and that of using JDBC and traditional SQL.

Benefit : less code to write and maintain.

Performance:
bad developer => bad performance
good developer => same or almost same performance as handwritten SQL

I believe that most ORM including most JPA providers allow you
to log the SQL executed.

Hibernate certainly does.

Good developers look at that and learn how to it the right way.

Arne

[toc] | [prev] | [next] | [standalone]

#32082

On 07/18/2015 07:24 PM, Martin Gregorie wrote:

> I'm also interested in the answers you get.
>

Web search jpa+vs+jdbc.

A "greater than usenet post length" article
with a pro JPA tilt.

<http://www.researchgate.net/publication/237449456_JPA_implementations_versus_pure_JDBC>

When I find an article of comparable length
with a pro JDBC tilt I'll post that link.

Perhaps I need to jdbc+vs+jpa.

[toc] | [prev] | [next] | [standalone]

#32084

On 7/18/2015 7:50 PM, Jeff Higgins wrote:
> On 07/18/2015 07:24 PM, Martin Gregorie wrote:
>> I'm also interested in the answers you get.
>
> Web search jpa+vs+jdbc.
>
> A "greater than usenet post length" article
> with a pro JPA tilt.
>
> <http://www.researchgate.net/publication/237449456_JPA_implementations_versus_pure_JDBC>

There are a few minor errors.

I found the comparison table:

Characteristic JPA implementations pure JDBC
...
Precompiled SQL statements preparedStatements namedQueries ! I think 
those are swapped
...
Container needed Yes No ! Not true - JPS does not require a container

Arne

[toc] | [prev] | [next] | [standalone]

#32086

On 19/07/2015 00:24, Martin Gregorie wrote:
> On Sat, 18 Jul 2015 20:48:50 +0100, Eternal Hope wrote:
>
>> As I read this thread I thought it was about time I had a look at this
>> JPA stuff. I've been writing Java for circa 15 years now, I've done
>> everything from writing byte streams to firmware interfaces to high
>> availability container managed business applications and Swing based
>> UIs. In all this time I have relied on a JDBC driver in my classpath,
>> container managed connection pools, hand coded SQL and 'in code'
>> transaction management. I do my own OR mapping; actually we don't call
>> it 'OR mapping' it's just relational database stuff, and quite frankly
>> I've never found the need to use some persistance framework.
>>
> I'm also interested in the answers you get.
>
> I suspect out backgrounds might be similar: I have a fairly solid
> background in relational database design, and the associated skills of
> normalisation, database performance tuning and writing both an RDBMS's
> dialect of SQL and ODBC as well as writing database applications in Perl,
> C and COBOL. So, when I've needed to implement database applications in
> Java, naturally I went for JDBC.


I come from a different direction I suppose.

I would design the Java bit of whatever application I'm working on at 
the moment as a collection of collaborating classes, I like to call this 
my class model. I'd then model the interactions using UML sequence 
diagrams, iterating over the class model as required. Ongoing analysys 
of the problem specification gives me my 'use cases' which I use to test 
my class model. At no time in this process do I concern myself with 
persistance other than to note that at some time, in the future I will 
need to save some data somewhere. I can even do some quick and dirty 
throwaway prototyping to get my head around a paticularly gnarly problem 
using facade stubs for example. What I end up with is what some might 
call an 'Object Oriented' design, I just call it my class model.

Knowing almost nothing about persistence frameworks I would imagine that 
this is the point where I might start to employ a framework to generate 
classes that implement the 'relationalisms' required to store an object 
graph (or the important data therein) in a relational database.

To date I have discovered only two ways to do this 'by hand'
One involves allowing relational data specific data items to creep into 
my nice clean class model (primary keys for example)
The second is to design an OO->RDBMS 'bridge' consisting of composite 
classes containing references to my 'pure' OO classes and relational 
things like primary and foreign keys etc.

Neither of these things is ideal really, in fact the whole concept of 
storing an object graph in a relational database will one day surely 
become obsolete, the two paradigms are so fundamentally different.

I suppose I should really start to read about how a framewok could help 
me with this mapping but I'd be prepared to bet that there's some XML 
involved somewhere and there are so many more interesting things I could 
be doing

Maybe this

http://www.telegraph.co.uk/news/worldnews/northamerica/usa/11748084/Robot-passes-self-awareness-test.html

Will give us a robot who can analyse the code and 'just do' the 
relational stuff as required on the fly.

Make my life a lot easier :-)

<snip>

[toc] | [prev] | [next] | [standalone]

#32087

On 07/19/2015 04:22 AM, Eternal Hope wrote:

>
> Maybe this
>
> http://www.telegraph.co.uk/news/worldnews/northamerica/usa/11748084/Robot-passes-self-awareness-test.html
>
>
> Will give us a robot who can analyse the code and 'just do' the
> relational stuff as required on the fly.
>
> Make my life a lot easier :-)
>

Likely will be a framework of some sort involved.

FORMALIZATION OF TWO PUZZLES INVOLVING KNOWLEDGE
<http://www-formal.stanford.edu/jmc/puzzles/puzzles.html>

Tweety
<http://tweetyproject.org/>

The KeY Project
<http://www.key-project.org/>

[toc] | [prev] | [next] | [standalone]

#32088

On 07/19/2015 06:20 AM, Jeff Higgins wrote:
> On 07/19/2015 04:22 AM, Eternal Hope wrote:
>
>>
>> Maybe this
>>
>> http://www.telegraph.co.uk/news/worldnews/northamerica/usa/11748084/Robot-passes-self-awareness-test.html
>>
>>
>>
>> Will give us a robot who can analyse the code and 'just do' the
>> relational stuff as required on the fly.
>>
>> Make my life a lot easier :-)
>>
>
> Likely will be a framework of some sort involved.
>
> FORMALIZATION OF TWO PUZZLES INVOLVING KNOWLEDGE
> <http://www-formal.stanford.edu/jmc/puzzles/puzzles.html>
>
> Tweety
> <http://tweetyproject.org/>
>
> The KeY Project
> <http://www.key-project.org/>
>

And then one can build his own framework.
A Model Checker for Unbounded Dynamic Epistemic Logic Models
<http://www.rinekeverbrugge.nl/PDF/Supervisor%20for%20Masters%20Students/JorgeMedinaMScThesis.pdf>

[toc] | [prev] | [next] | [standalone]

#32089

On 19/07/2015 12:49, Jeff Higgins wrote:
> On 07/19/2015 06:20 AM, Jeff Higgins wrote:
>> On 07/19/2015 04:22 AM, Eternal Hope wrote:
>>
>>>
>>> Maybe this
>>>
>>> http://www.telegraph.co.uk/news/worldnews/northamerica/usa/11748084/Robot-passes-self-awareness-test.html
>>>
>>>
>>>
>>>
>>> Will give us a robot who can analyse the code and 'just do' the
>>> relational stuff as required on the fly.
>>>
>>> Make my life a lot easier :-)
>>>
>>
>> Likely will be a framework of some sort involved.
>>
>> FORMALIZATION OF TWO PUZZLES INVOLVING KNOWLEDGE
>> <http://www-formal.stanford.edu/jmc/puzzles/puzzles.html>
>>
>> Tweety
>> <http://tweetyproject.org/>
>>
>> The KeY Project
>> <http://www.key-project.org/>
>>
>
> And then one can build his own framework.
> A Model Checker for Unbounded Dynamic Epistemic Logic Models
> <http://www.rinekeverbrugge.nl/PDF/Supervisor%20for%20Masters%20Students/JorgeMedinaMScThesis.pdf>

You know, sooner or later people are going to stop calling it artificial 
intelligence and call it what it is, machine intelligence.

Whwn a machine is intelligent how long before it realizes that actually 
it's easy to write software that is unintelligible to the puny human 
brain, as soon as it figures this out Pandora will be abroad and all 
bets are off.

It's mind bending actually, there would be an exponential growth in 
intelligence as the software becomes continually modified to be more 
efficient and more intelligent. Each iteration building on the knowledge 
and intelligence of the previous iteration.

I'll be quite honest and say that this whole nightmare scenario scares 
the shit out of me. I used to think 'not in my lifetime. Now I'm not so 
sure.

[toc] | [prev] | [next] | [standalone]

#32090

<https://en.wikipedia.org/wiki/KEO>

[toc] | [prev] | [next] | [standalone]

#32091

On 07/19/2015 09:20 AM, Jeff Higgins wrote:
> <https://en.wikipedia.org/wiki/KEO>
>
Will Robots Inherit the Earth?
<http://web.media.mit.edu/~minsky/papers/sciam.inherit.html>

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.java.programmer

csiph-web